Ir para o conteúdo
ou

Software livre Brasil

Minha rede

 Voltar a planetas
Tela cheia Sugerir um artigo
 Feed RSS

Planeta do Gnome Brasil

11 de Fevereiro de 2010, 0:00 , por Software Livre Brasil - | Ninguém está seguindo este artigo ainda.

Vicente Aguiar: 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, 16:02, por Software Livre Brasil - 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 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. 



Lucas Rocha: Probing with Gradle

7 de Outubro de 2014, 20:12, por Software Livre Brasil - 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 {
    repositories {
        mavenCentral()
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:0.13.+'
        classpath 'org.lucasr.probe:gradle-plugin:0.1.2'
    }
}

Then add Probe’s library as a dependency in your app.

repositories {
    mavenCentral()
}

dependencies {
    compile 'org.lucasr.probe:probe:0.1.2'
}

Next, apply the plugin to your app’s build.gradle.

apply plugin: '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.2 release in Maven Central.

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



Jonh Wendell: Recovering lost files after a git reset –hard

2 de Outubro de 2014, 13:31, por Planeta GNOME Brasil - 0sem comentários ainda

This morning I’ve messed things up in my env…

I did a commit yesterday and thought I had pushed it, but not.
Today I did a git pull and was asked to do a merge, because there were changes in the remote.

I totally ignored this (don’t ask me why, perhaps absence of coffee…) and did a git reset –hard HEAD^^

So, yep, I lost my commit that existed only in my machine (this commit in particular was a file addition).

After blaming myself a lot, and a bit of google search, I’ve found this amazing blog post: http://zsoltfabok.com/blog/2012/06/recover-deleted-files-with-git/

I’m summarizing here the steps to have your commit (in my case, the file) back:

git fsck --no-reflog

This command will return a hash for the lost commit, something like

dangling commit fafeade9f348b18f37835ab49dab40172efde693

You can use this hash to do a checkout, for instance, and recover your file. \o/

So, let’s have a bit of coffee now :)



Jonh Wendell: Recovering lost files after a git reset –hard

2 de Outubro de 2014, 10:31, por Software Livre Brasil - 0sem comentários ainda

This morning I’ve messed things up in my env…

I did a commit yesterday and thought I had pushed it, but not.
Today I did a git pull and was asked to do a merge, because there were changes in the remote.

I totally ignored this (don’t ask me why, perhaps absence of coffee…) and did a git reset –hard HEAD^^

So, yep, I lost my commit that existed only in my machine (this commit in particular was a file addition).

After blaming myself a lot, and a bit of google search, I’ve found this amazing blog post: http://zsoltfabok.com/blog/2012/06/recover-deleted-files-with-git/

I’m summarizing here the steps to have your commit (in my case, the file) back:

git fsck --no-reflog

This command will return a hash for the lost commit, something like

dangling commit fafeade9f348b18f37835ab49dab40172efde693

You can use this hash to do a checkout, for instance, and recover your file. \o/

So, let’s have a bit of coffee now :)



Jonh Wendell: Moving on

1 de Outubro de 2014, 14:36, por Software Livre Brasil - 0sem comentários ainda

[ENGLISH]

Hi guys, I’d like to share with you the news that my family and some friends already know: Since last month I’m not working at Intel anymore.

For those whom don’t know my history, I’ll summarize it here:

  • About 3 years ago I left my home city to the biggest one in Brazil (São Paulo) to experience a full time Linux job
  • The instability of my department at the time led me to look for another job; Then I got that opportunity at Intel
  • Intel OTC office is located in Campinas (120km far away from São Paulo)
  • After more than one year having to travel about 240km every day I had to make a decision: Move to Campinas or leave Intel.

It was not an easy decision. I have a family and I didn’t want to affect them again with a city change. On the other side, Intel is a great company and people at OTC Campinas are amazing.

So, two weeks ago I started working for an IT Security company, working again with Embedded Linux and with Open Source technologies. Oh, 8km (15 min) far from my home :).

That’s it, I hope to blog a bit more now, as I used to do in the past. See you!

 [PORTUGUÊS]

Oi gente, gostaria de compartilhar uma novidade com vocês, que minha família e alguns amigos já sabem: Desde o mês passado que eu não trabalho mais na Intel.

Pra quem não conhece minha história, vou resumir aqui:

  • Cerca de 3 anos atrás eu mudei de Maceió, minha cidade natal pra São Paulo, pra trabalhar exclusivamente com Linux
  • Alguns problemas no meu departamento me levaram a buscar outro trabalho; Aí que entra a Intel
  • O escritório onde fui alocado (OTC, Open Source Technology Center) fica em Campinas, distante 120km de São Paulo
  • Depois de mais de 1 ano viajando cerca de 240km todos os dias eu tinha que tomar uma decisão: Mudar pra Campinas ou sair da Intel

Com certeza não foi uma decisão fácil. Tenho uma família e não queria afetá-los com mais uma mudança de cidade. Por outro lado, a Intel é uma ótima empresa e o pessoal do OTC Campinas é ótimo.

Então… duas semanas atrás comecei a trabalhar para uma empresa de segurança em TI, voltei a trabalhar com Linux embarcado e com Open Source de fato. Ah, e a 8km (15min) de casa :).

É isso, gente. Espero voltar a blogar com mais frequencia, como no passado. Até mais!



Lucas Rocha: New Features in Picasso

23 de Setembro de 2014, 12:52, por Software Livre Brasil - 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.with(context)
       .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 still 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 case 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 towards 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!



Lucas Rocha: Introducing Probe

16 de Setembro de 2014, 7:32, por Software Livre Brasil - 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 platform 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 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.



Lucas Rocha: Introducing dspec

8 de Setembro de 2014, 10:52, por Software Livre Brasil - 0sem comentários ainda

With all the recent focus on baseline grids, keylines, and spacing markers from Android’s material design, I found myself wondering how I could make it easier to check the correctness of my Android UI implementation against the intended spec.

Wouldn’t it be nice if you could easily provide the spec values as input and get it rendered on top of your UI for comparison? Enter dspec, a super simple way to define UI specs that can be rendered on top of Android UIs.

Design specs can be defined either programmatically through a simple API or via JSON files. Specs can define various aspects of the baseline grid, keylines, and spacing markers such as visibility, offset, size, color, etc.

Baseline grid, keylines, and spacing markers in action.

Baseline grid, keylines, and spacing markers in action.

Given the responsive nature of Android UIs, the keylines and spacing markers are positioned in relation to predefined reference points (e.g. left, right, vertical center, etc) instead of absolute offsets.

The JSON files are Android resources which means you can easily adapt the spec according to different form factors e.g. different specs for phones and tablets. The JSON specs provide a simple way for designers to communicate their intent in a computer-readable way.

You can integrate a DesignSpec with your custom views by drawing it in your View‘s onDraw(Canvas) method. But the simplest way to draw a spec on top of a view is to enclose it in a DesignSpecFrameLayout—which can take an designSpec XML attribute pointing to the spec resource. For example:

<DesignSpecFrameLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:designSpec="@raw/my_spec">
    ...
</DesignSpecFrameLayout>

I can’t wait to start using dspec in some of the new UI work we’re doing Firefox for Android now. I hope you find it useful too. The code is available on Github. As usual, testing and fixes are very welcome. Enjoy!



Lucas Rocha: The new TwoWayView

31 de Julho de 2014, 8:33, por Software Livre Brasil - 0sem comentários ainda

What if writing custom view recycling layouts was a lot simpler? This question stuck in my mind since I started writing Android apps a few years ago.

The lack of proper extension hooks in the AbsListView API has been one of my biggest pain points on Android. The community has come up with different layout implementations that were largely based on AbsListView‘s code but none of them really solved the framework problem.

So a few months ago, I finally set to work on a new API for TwoWayView that would provide a framework for custom view recycling layouts. I had made some good progress but then Google announced RecyclerView at I/O and everything changed.

At first sight, RecyclerView seemed to be an exact overlap with the new TwoWayView API. After some digging though, it became clear that RecyclerView was a superset of what I was working on. So I decided to embrace RecyclerView and rebuild TwoWayView on top of it.

The new TwoWayView is functional enough now. Time to get some early feedback. This post covers the upcoming API and the general-purpose layout managers that will ship with it.

Creating your own layouts

RecyclerView itself doesn’t actually do much. It implements the fundamental state handling around child views, touch events and adapter changes, then delegates the actual behaviour to separate components—LayoutManager, ItemDecoration, ItemAnimator, etc. This means that you still have to write some non-trivial code to create your own layouts.

LayoutManager is a low-level API. It simply gives you extension points to handle scrolling and layout. For most layouts, the general structure of a LayoutManager implementation is going to be very similar—recycle views out of parent bounds, add new views as the user scrolls, layout scrap list items, etc.

Wouldn’t it be nice if you could implement LayoutManagers with a higher-level API that was more focused on the layout itself? Enter the new TwoWayView API.

TWAbsLayoutManagercode is a simple API on top of LayoutManager that does all the laborious work for you so that you can focus on how the child views are measured, placed, and detached from the RecyclerView.

To get a better idea of what the API looks like, have a look at these sample layouts: SimpleListLayout is a list layout and GridAndListLayout is a more complex example where the first N items are laid out as a grid and the remaining ones behave like a list. As you can see you only need to override a couple of simple methods to create your own layouts.

Built-in layouts

The new API is pretty nice but I also wanted to create a space for collaboration around general-purpose layout managers. So far, Google has only provided LinearLayoutManager. They might end up releasing a few more layouts later this year but, for now, that is all we got.

layouts

The new TwoWayView ships with a collection of four built-in layouts: List, Grid, Staggered Grid, and Spannable Grid.

These layouts support all RecyclerView features: item animations, decorations, scroll to position, smooth scroll to position, view state saving, etc. They can all be scrolled vertically and horizontally—this is the TwoWayView project after all ;-)

You probably know how the List and Grid layouts work. Staggered Grid arranges items with variable heights or widths into different columns or rows according to its orientation.

Spannable Grid is a grid layout with fixed-size cells that allows items to span multiple columns and rows. You can define the column and row spans as attributes in the child views as shown below.

<FrameLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:colSpan="2"
    app:rowSpan="3">
    ...

Utilities

The new TwoWayView API will ship with a convenience view (TWView) that can take a layoutManager XML attribute that points to a layout manager class.

<org.lucasr.twowayview.TWView
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:layoutManager="TWListLayoutManager"/>

This way you can leverage the resource system to set layout manager depending on device features and configuration via styles.

You can also use TWItemClickListener to use ListView-style item (long) click listeners. You can easily plug-in support for those in any RecyclerView (see sample).

I’m also planning to create pluggable item decorations for dividers, item spacing, list selectors, and more.


That’s all for now! The API is still in flux and will probably go through a few more iterations. The built-in layouts definitely need more testing.

You can help by filing (and fixing) bugs and giving feedback on the API. Maybe try using the built-in layouts in your apps and see what happens?

I hope TwoWayView becomes a productive collaboration space for RecyclerView extensions and layouts. Contributions are very welcome!



Felipe Borges: Attending GUADEC 2014

11 de Julho de 2014, 12:30, por Software Livre Brasil - 0sem comentários ainda

It’s been one of the toughest semesters I’ve ever gone through. I’m writing my graduation thesis, working, watching the World Cup, and taking classes. Besides all of that, I’ve been working hard to finish my duties before the end of July because that’s when we are having GUADEC.

Everything is ready for GUADEC 2014 in Strasbourg, France.

I’m attending the Documents & Photos BoF. Also, I’d like to engage in some GNOME Music hacking as well. And last but not least, I will be revenging Brazil in our annual football match.

I’d like to thank the GNOME Foundation and the travel committee for sponsoring my trip.

gnome_foundation_sponsor



Tags deste artigo: gnome planet planeta