Ir para o conteúdo
ou

Thin-logo

Tela cheia Sugerir um artigo
Rss-feed

Grupo de Usuários Debian da Bahia - GUD/BA

6 de Dezembro de 2009 , por Desconhecido -

Seja bem vind@, se você é um debiano (um baiano que usa debian) faça parte de nossa comunidade!


A few words on the recent Brazilian elections

3 de Novembro de 2014, por Desconhecido - 0sem comentários ainda

The Brazilian presidential election was exceedingly intense this year. Among many inferences that we can make by following the news and investigating data from the voting results I'd like to share this one, which in my opinion reflects quite well the vote preferences in the country.

First, let me introduce you "Belágua", a small town located in the Northeast region of Brazil. It has 6,524 habitants, 3 buses and 2 hospitals. According to the Brazilian Institute of Geography and Statistics (IBGE), the income per person in Belágua is $146 BRL (or U$59) per month. Believe it or not, it used to be much less. Actually, the city reported in 2013 the highest economic jump in the country, rising more than a thousand positions in the ranking of GDP per capita (from position 4,991 to 3,849). This recent growth was consequence of the social welfare program of the Brazilian government, which also boosted artisanal and manioc flour production. This federal assistance is called "Bolsa família", which benefits 1.814 families in Belágua.

"Bolsa Família currently gives families with per-capita monthly income below $140 BRL (poverty line, ~$56 USD) a monthly stipend of $32 BRL (~$13 USD) per vaccinated child (< 16 years old) attending school (up to 5), and $38 BRL (~$15 USD) per youth (16 or 17 years old) attending school (up to 2). Furthermore, to families whose per-capita monthly income below $70 BRL (extreme poverty line, ~$28 USD), the program gives the Basic Benefit $70 BRL per month."

(from Wikipedia)

Contrary to what many of my middle-class friends believe, and as you can calculate yourself, this little amount of money does not offer anybody a luxury life. It does not make anybody stopping working, nor stopping looking for paid job (but yes, it makes people to start saying NO to forced labor, which is amazing, right?).

/images/belagua.jpg

Belágua, where Dilma got 93.93% of votes (photo by Clarissa Carramilo / from G1)

Also, Belágua has no much physicians around because doctors in Brazil usually wouldn't live in a such city. But now Belágua population can be treated by foreign doctors imported by the recently launched program "Mais Médicos" (More Physicians for Brazil), which hosts two Cuban doctors 15km away. Finally, Belágua people have light, due to the "Luz para Todos" ("Light for All") program.

It's not surprising that Belágua has re-elected the party which has motivated these changes. For 2014 presidential election, Belágua people gave 3.558 votes (93.93%) to Dilma Rousseff (candidate of the current government, from a left-ish party), against 230 (6,07%) to Aécio Neves (from the right coalition), being the city with the largest amount of votes for Dilma, proportionally, followed by "Serrano do Maranhão" (93,75%), which is located in the same region.

On the other hand, the city which gave, proportionally, the largest amount of votes for Aécio Neves has a population of 5,564,635 habitants, where most of citizens are not Brazilians, not yet. Miami, located in US, was the city where Brazilian residents would elect Aécio by 7,225 votes (91,79%), against 646 (8,21%) for Dilma, followed by Atlanta/US (89,47%) and Houston/US (89,22%).

/images/miami.jpg

Miami, where 91,79% of Brazilians voted Aécio (photo by Marc Averette / from Wikipedia)

It's so clear that we do what people call "selfish vote". In general, we don't care about which party has better proposals for the society as whole. Rich people will go against any serious social equality proposal, which will necessarily be followed by higher taxes on their fortunes. As middle class citizens, we care about dollar rates, because we want to get cheaper iStuff from Miami. We're also very upset by the fact that new apartments are being built without that small room in the back, which has been used to accommodate a subservient housemaid who, until last year was not even legally considered a worker.

Those people from Belágua, who used to live in extreme poverty for decades, serving as slaves, they mostly care about having something to eat. Now they eat, so they can think better, they can work, they can sell what they produce in their little yard. And like middle-class and rich citizens, they will give their vote in exchange of what they think is better for them. The big difference here is, if we ask Belágua people why they voted for Dilma, with no embarrassment they will make it very clear, that's because her government has provided them lots of benefits. Asking the same question for most Brazilians in Miami, Atlant, Houston or São Paulo, you'll get not only a bunch of allegedly moral/altruistic reasons, but they will also try to delegitimize in many ways the votes from those marginalized citizens. You'll never get the real reasons from them. They will even try to convince you that whoever receives federal assistance should automatically lose right to vote. Such a statement may seem ridiculous, however it has been very present recently. Actually, such hate speech is happening right now. While I'm writing this post about 2500 people are protesting in São Paulo streets, asking for an immediate military coup because they don't agree with the elections result. These people keep pushing the limits of ridiculousness.

Dilma won with 51.64% of valid votes, a very tight result. The country is clearly divided, mostly by hate, unfortunately.



Um Trabalho a Troco de nada? A resposta da comunidade GNOME para Jô Soares e Bill Gates à luz da teoria da Dádiva

11 de Outubro de 2014, por Desconhecido - 0sem comentários ainda

Sete anos após uma  apresentação feita no IV Fórum GNOME em 2007 com esse mesmo título, finalmente, eu consegui publicar, em parceria com Genauto França Filho (meu orientador de Doutorado), o resultado da pesquisa que tentou responder uma questão que ronda o ecossistema dos projetos de software livre: "quem pode se permitir fazer um trabalho profissional a troco de nada?"  Mais especificamente, esse artigo foi publicado na revista (acadêmica) Sociologias - uma publicação quadrimestral do Programa de Pós-Graduação em Sociologia da UFRGS, destinada a promover intercâmbio entre cientistas sociais.

No entanto, é importante ressaltar que essa questão norteadora da nossa pesquisa foi, inicialmente, levantada por Biil Gates na histórica "Carta Aberta aos Hobbistas" escrita em 1976  - um ano depois da fundação da então "Micro-Soft". Além dele, quatro décadas depois, mais especificamente em outubro de 2006, ela foi "remixada" por Jô Soares, no seu programa de televisão. Em uma de suas entrevistas, ao ser informado pelo Sérgio Amadeu (Prof. da UFABC) e pelo Júlio Neves (Prof. da UNiRio) sobre um possível engajamento voluntário de hackers ligados ao projetos de software livre, Jô Soares ressalta que, na visão dele, "por trás do fato do que é dado (software) de graça há uma intenção de ser vendido. (...) ou é um pessoal que é tudo monge Franciscano?"

O ponto de partida desse artigo que escrevemos na Sociologias é que ainda são poucos os estudos que procuram analisar as características e a natureza desse novo contexto digital (de relações mediadas por dispositivos móveis como computadores, tablets e celulares) para além de um entendimento que tem como base apenas as noções de uma racionalidade utilitária ou do simples interesse econômico. Afinal, podemos dizer que mais recorrente do que esse tipo de pergunta é o tipo de resposta comum (e apressada) que diz que "ninguém trabalha de graça" ou que "sempre há um interesse financeiro nisso tudo".

Para evitar os limites de uma única forma de resposta "apressada" (para não dizer "equivocada") e, com isso, restringir a compreensão sobre a ação dos hackers nesses projetos, avaliamos que era importante respondê-la com um olhar mais científico e aprofundado. Assim, realizamos uma análise mais qualitativa sobre esse "fenômeno" que se apoiou em uma pesquisa de dois anos na comunidade do Projeto GNOME. Essa pesquisa resultou então na minha dissertação de mestrado na UFBA, em um dos capítulos do livro "Software Livre, Cultura Hacker e Ecossistema da Colaboração" e agora nesse artigo publicado na Revista Sociologias.

Membros da Comunidade GNOME por Louis Villa

Em termos de publicação, o diferencial então dessa edição v. 16, n. 36 (2014) da Revista Sociologias é o resgate da obra maussiana que fundamentou conceitualmente essa pesquisa sobre o Projeto GNOME - e, agora, serve também de base do meu projeto de Doutorado. Esse resgaste se dá no contexto de surgimento de uma crítica anti-utilitarista dentro do universo das ciências sociais contemporâneas, a qual foi concretizada pela fundação do MAUSS (Movimento Anti-Utilitarista nas Ciências Sociais).

Contudo, vale ressaltar que esse paradigma sociológico da dádiva busca ir além: mais do que a importância da sua vertente analítica, o MAUSS demonstra ser uma corrente sociológica implicada com a produção de pesquisas que se desenvolve a partir de um paradigma basilar, não apenas nas sociedade tradicionais como também para a sociedade contemporânea: a vida associativa e, em especial, a tripla ação de compartilhar, receber e retribuir. Vale então conferir essa edição da Sociologia da Dádiva na íntegra. 



Probing with Gradle

7 de Outubro de 2014, por Desconhecido - 0sem comentários ainda

Up until now, Probe relied on dynamic view proxies generated at runtime to intercept View calls. Although very convenient, this approach greatly affects the time to inflate your layouts—which limits the number of use cases for the library, especially in more complex apps.

This is all changing now with Probe’s brand new Gradle plugin which seamlessly generates build-time proxies for your app. This means virtually no overhead at runtime!

Using Probe’s Gradle plugin is very simple. First, add the Gradle plugin as a dependency in your build script.

buildscript {
    ...
    dependencies {
        ...
        classpath 'org.lucasr.probe:gradle-plugin:0.1.3'
    }
}

Then apply the plugin to your app’s build.gradle.

apply plugin: 'org.lucasr.probe'

Probe’s proxy generation is disabled by default and needs to be explicitly enabled on specific build variants (build type + product flavour). For example, this is how you enable Probe proxies in debug builds.

probe {
    buildVariants {
        debug {
            enabled = true
        }
    }
}

And that’s all! You should now be able to deploy interceptors on any part of your UI. Here’s how you could deploy an OvermeasureInterceptor in an activity.

public final class MainActivity extends Activity {
   @Override
   protected void onCreate(Bundle savedInstanceState) {
       Probe.deploy(this, new OvermeasureInterceptor());
       super.onCreate(savedInstanceState);
       setContentView(R.id.main_activity);
   }
}

While working on this feature, I have changed DexMaker to be an optional dependency i.e. you have to explicitly add DexMaker as a build dependency in your app in order to use it.

This is my first Gradle plugin. There’s definitely a lot of room for improvement here. These features are available in the 0.1.3 release in Maven Central.

As usual, feedback, bug reports, and fixes are very welcome. Enjoy!



New Features in Picasso

23 de Setembro de 2014, por Desconhecido - 0sem comentários ainda

I’ve always been a big fan of Picasso, the Android image loading library by the Square folks. It provides some powerful features with a rather simple API.

Recently, I started working on a set of new features for Picasso that will make it even more awesome: request handlers, request management, and request priorities. These features have all been merged to the main repo now. Let me give you a quick overview of what they enable you to do.

Request Handlers

Picasso supports a wide variety of image sources, from simple resources to content providers, network, and more. Sometimes though, you need to load images in unconventional ways that are not supported by default in Picasso.

Wouldn’t it be nice if you could easily integrate your custom image loading logic with Picasso? That’s what the new request handlers are about. All you need to do is subclass RequestHandler and implement a couple of methods. For example:

public class PonyRequestHandler extends RequestHandler {
    private static final String PONY_SCHEME = "pony";

    @Override public boolean canHandleRequest(Request data) {
        return PONY_SCHEME.equals(data.uri.getScheme());
    }

    @Override public Result load(Request data) {
         return new Result(somePonyBitmap, MEMORY);
    }
}

Then you register your request handler when instantiating Picasso:

Picasso picasso = new Picasso.Builder(context)
    .addRequestHandler(new PonyHandler())
    .build();

Voilà! Now Picasso can handle pony URIs:

picasso.load("pony://somePonyName")
       .into(someImageView)

This pull request also involved rewriting all built-in bitmap loaders on top of the new API. This means you can also override the built-in request handlers if you need to.

Request Management

Even though Picasso handles view recycling, it does so in an inefficient way. For instance, if you do a fling gesture on a ListView, Picasso will keep triggering and canceling requests blindly because there was no way to make it pause/resume requests according to the user interaction. Not anymore!

The new request management APIs allow you to tag associated requests that should be managed together. You can then pause, resume, or cancel requests associated with specific tags. The first thing you have to do is tag your requests as follows:

Picasso.with(context)
       .load("http://example.com/image.jpg")
       .tag(someTag)
       .into(someImageView)

Then you can pause and resume requests with this tag based on, say, the scroll state of a ListView. For example, Picasso’s sample app now has the following scroll listener:

public class SampleScrollListener implements AbsListView.OnScrollListener {
    ...
    @Override
    public void onScrollStateChanged(AbsListView view, int scrollState) {
        Picasso picasso = Picasso.with(context);
        if (scrollState == SCROLL_STATE_IDLE ||
            scrollState == SCROLL_STATE_TOUCH_SCROLL) {
            picasso.resumeTag(someTag);
        } else {
            picasso.pauseTag(someTag);
        }
    }
    ...
}

These APIs give you a much finer control over your image requests. The scroll listener is just the canonical use case.

Request Priorities

It’s very common for images in your Android UI to have different priorities. For instance, you may want to give higher priority to the big hero image in your activity in relation to other secondary images in the same screen.

Up until now, there was no way to hint Picasso about the relative priorities between images. The new priority API allows you to tell Picasso about the intended order of your image requests. You can just do:

Picasso.with(context)
       .load("http://example.com/image.jpg")
       .priority(HIGH)
       .into(someImageView);

These priorities don’t guarantee a specific order, they just tilt the balance in favour of higher-priority requests.


That’s all for now. Big thanks to Jake Wharton and Dimitris Koutsogiorgas for the prompt code and API reviews!

You can try these new APIs now by fetching the latest Picasso code on Github. These features will probably be available in the 2.4 release. Enjoy!



Introducing Probe

16 de Setembro de 2014, por Desconhecido - 0sem comentários ainda

We’ve all heard of the best practices regarding layouts on Android: keep your view tree as simple as possible, avoid multi-pass layouts high up in the hierarchy, etc. But the truth is, it’s pretty hard to see what’s actually going on in your view tree in each UI traversal (measure → layout → draw).

We’re well served with developer options for tracking graphics performance—debug GPU overdraw, show hardware layers updates, profile GPU rendering, and others. However, there is a big gap in terms of development tools for tracking layout traversals and figuring out how your layouts actually behave. This is why I created Probe.

Probe is a small library that allows you to intercept view method calls during Android’s layout traversals e.g. onMeasure(), onLayout(), onDraw(), etc. Once a method call is intercepted, you can either do extra things on top of the view’s original implementation or completely override the method on-the-fly.

Using Probe is super simple. All you have to do is implement an Interceptor. Here’s an interceptor that completely overrides a view’s onDraw(). Calling super.onDraw() would call the view’s original implementation.

public class DrawGreen extends Interceptor {
    private final Paint mPaint;

    public DrawGreen() {
        mPaint = new Paint();
        mPaint.setColor(Color.GREEN);
    }

    @Override
    public void onDraw(View view, Canvas canvas) {
        canvas.drawPaint(mPaint);
    }
}

Then deploy your Interceptor by inflating your layout with a Probe:

Probe probe = new Probe(this, new DrawGreen(), new Filter.ViewId(R.id.view2));
View root = probe.inflate(R.layout.main_activity, null);

Just to give you an idea of the kind of things you can do with Probe, I’ve already implemented a couple of built-in interceptors. OvermeasureInterceptor tints views according to the number of times they got measured in a single traversal i.e. equivalent to overdraw but for measurement.

LayoutBoundsInterceptor is equivalent to Android’s “Show layout bounds” developer option. The main difference is that you can show bounds only for specific views.

Under the hood, Probe uses Google’s DexMaker to generate dynamic View proxies during layout inflation. The stock ProxyBuilder implementation was not good enough for Probe because I wanted to avoid using reflection entirely after the proxy classes were generated. So I created a specialized View proxy builder that generates proxy classes tailored for Probe’s use case.

This means Probe takes longer than your usual LayoutInflater to inflate layout resources. There’s no use of reflection after layout inflation though. Your views should perform the same. For now, Probe is meant to be a developer tool only and I don’t recommend using it in production.

The code is available on Github. As usual, contributions are very welcome.