Seja bem vind@, se você é um debiano (um baiano que usa debian) faça parte de nossa comunidade!
Little garden project
17 de Junho de 2014, 11:51 - sem comentários aindaAfter three years living in Montréal we're still amazed by the fact that here we have er... seasons!!
I believe that things have a special beauty when they don't last the time we want them to last, and seasons are all about it! (some people will exclude winter here) Anyways, taking pictures may give them more lifetime without compromising too much their beauty. And sharing them here and there is somewhat sharing our happiness, which might be a good balance in the end :)
At the time we moved the garden was just a single white thing...
then we realized that it provided some chairs, a table and a compost container, yay!
But the grey ground was something to be fixed...
so we hacked it and got some land :)
Few months later and it's finally becoming chard, beets, carrots, spinach, berries, cheries, okra, tomatoes, basil, potatoes, sage, agastache and a saskatoon berry tree!
An introduction to the Debian Continuous Integration project
1 de Junho de 2014, 17:11 - sem comentários aindaDebian is a big system. At the time of writing, looking at my local package list caches tells me that the unstable suite contains 21306 source packages, and 42867 binary packages on amd64. Between these 42867 binary packages, there is an unthinkable number of inter-package dependencies. For example the dependency graph of the ruby packages contains other 20-something packages.
A new version of any of these packages can potentially break some functionality in the ruby package.
And that dependency graph is very small. Looking at the dependency graph for,
say, the rails package will make your eyes bleed. I tried it here, and
GraphViz needed a PNG image with 7653×10003 pixels to draw it. It ain’t pretty.
Installing rails on a clean Debian system will pull in another 109 packages as
part of the dependency chain. Again, as new versions of those packages are
uploaded the archive, there is a probability that a backwards-incompatible
change, or even a bug fix which was being worked around, might make some
funcionality in rails stop working. Even if that probability is low for each
package in the dependency chain, with enough packages the probability of any
of them causing problems for rails is quite high.
And still the rails dependency chain is not that big. libreoffice will pull
in another 264 packages. gnome will pull in 1311 dependencies, and kde-full
1320 (!).
With a system this big, problems will arrive, and that’s a fact of life. As developers, what we can do is try to spot these problems as early as possible, and fixing them in time to make a solid release with the high quality Debian is known for.
While automated testing is not the proverbial Silver Bullet of Software Engineering, it is an effective way of finding regressions.
Back in 2006, Ian Jackson started the development of autopkgtest as a tool to test Debian packages in their installed form (as opposed to testing packages using their source tree).
In 2011, the autopkgtest test suite format was proposed as a standard for the Debian project, in what we now know as the DEP-8 specification.
Since then, some maintainers such as myself started experimenting with DEP-8 tests in their packages. There was an expectation in the air that someday, someone would run those tests for the entire archive, and that would be a precious source of QA information.
Durign the holiday break last year, I decided to give it a shot. I initially
called the codebase dep8. Later I renamed it to debci, since it could
potentially also run other other types of test suites in the future. Since
early January, ci.debian.net run an instance of debci
for the Debian Project.
The Debian continuous Integration will trigger tests at most 4 times a day, 3 hours after each dinstall run. It will update a local APT cache and look for packages that declare a DEP-8 test suite. Each package with a test suite will then have its test suite executed if there was any change in its dependency chain since the last test run. Existing test results are published at ci.debian.net every hour, and at the end of each batch a “global status” is updated.
Maintainers can subscribe to a per package Atom feed to keep up with their package test results. People interested in the overall status can subscribe to a global Atom feed of events.
Since the introduction of Debian CI in mid-January 2014, we have seen an amazing increase in the number of packages with test suites. We had little less than 200 packages with test suites back then, against around 350 now (early June 2014). The ratio of packages passing passing their test suite has also improved a lot, going from less than 50% to more than 75%.
There is documentation available, including a FAQ for package maintainers with further information about how the system works, how to declare test suites in their packages and how to reproduce test runs locally. Also available is development information about debci itself, to those inclined to help improve the system.
This is just the beginning. debci is under a good rate of development, and
you can expect to see a constant flux of improvements. In special, I would like
to mention a few people who are giving amazing contributions to the project:
- Martin Pitt has been working on improving debci to support parallel and distributed workers. Being the current autopkgtest maintainer, Martin also already got some bug fixes and fixes into autopkgtest motivated by debci use cases.
- Brandon Fairchild is a GSOC student working on improving the debci web interface to provide more useful information, display information for multiple suites and architectures, plus making the UI work even without Javascript enabled.
- Lucas Kanashiro is another GSOC student, who is working on investigating patterns among packages that fail their test suites, so that we can figure out how we can fix them, or if there are classes of failures that are actually caused by problems in the debci infrastructure.
On losing contacts with old friends
30 de Maio de 2014, 11:03 - sem comentários aindaIn 2010 I decided to stop using my google account. In 2011 I decided to leave facebook, twitter and other $cool stuff. This was a hard decision. Not because email migration was annoying, nor because I liked to do social networking. It's hard because most of friends depend on either google or facebook to chat. Since I moved to another country, phone calls and presencial meetings have been substantially reduced.
So we keep in contact by using IRC and XMPP. I have good friends who use IRC, mostly Debian people, which is great. I also have lots of friends and contacts not using IRC. In the past they used ICQ, then moved to MSN and now they are using google talk and facebook. I used to explain them that we could talk by using their google account and my Jabber account due to an open standard called XMPP. I enjoy having short conversations in random times, which sometimes takes hours and helps us to keep affectionately connected.
It used to work so well. Now it seems to be gone. I've noticed that I can't connect anymore with contacts using google talk, probably because google has finally put into action their decision to abandon open standards for instant messaging.
I'm not going to list here all the good things that happened in my life when I stopped using all this crap services. But I have to admit that it really hurts to see my contacts disappearing day by day, feeling like my friends are being devoured by these companies, with zero critical sense. You'll say that good friends won't disappear like that if they are good friends. I agree, but the convenience of having people from one-click distance in random hours a day makes a difference, mainly when physical distance is a blocker.
Custom Layouts on Android
12 de Maio de 2014, 9:42 - sem comentários aindaIf you ever built an Android app, you have definitely used some of the built-in layouts available in the platform—RelativeLayout, LinearLayout, FrameLayout, etc. They are our bread and butter for building Android UIs.
The built-in layouts combined provide a powerful toolbox for implementing complex UIs. But there will still be cases where the design of your app will require you to implement custom layouts.
There are two main reasons to go custom. First, to make your UI more efficient—by reducing the number of views and/or making faster layout traversals. Second, when you are building UIs that are not naturally possible to implement with stock widgets.
In this post, I will demonstrate four different ways of implementing custom layouts and discuss their respective pros and cons: composite view, custom composite view, flat custom view, and async custom views.
The code samples are available in my android-layout-samples repo. This app implements the same UI with each technique discussed here and uses Picasso for image loading. The UI is a simplified version of Twitter app’s stream—no interactions, just the layouts.
Ok, let’s start with the most common type of custom layout: composite view.
Composite View
This is usually your starting point. Composite views (also known as compound views) are the easiest way of combining multiple views into a reusable UI component. They are very simple to implement:
- Subclass one of the built-in layouts.
- Inflate a merge layout in the constructor.
- Initialize members to point to inner views with findViewById().
- Add your own APIs to query and update the view state.
TweetCompositeViewcode is a composite view. It subclasses RelativeLayout, inflates tweet_composite_layout.xmlcode into it, and exposes an update() method to refresh its state in the adaptercode. Simple stuff.
Custom Composite View
TweetCompositeView will likely perform fairly well in most situations. But, for sake of argument, suppose you want to reduce the number of child views and make layout traversals a bit more efficient.
Although composite views are simple to implement, using general-purpose layouts has a cost—especially with complex containers like LinearLayout and RelativeLayout. As platform building blocks, they have to handle tons of layout combinations and might have to measure child views multiple times in a single traversal—LinearLayout‘s layout_weight being a common example.
You can greatly optimize your UI by implementing a custom logic for measuring and positioning child views that is specially tailored for your app. This is what I like to call a custom composite view.
A custom composite view is simply a composite view that overrides onMeasure() and onLayout(). So, instead of subclassing an existing container like RelativeLayout, you will be subclassing the more general ViewGroup.
TweetLayoutViewcode implements this technique. Note how it gets rid of the LinearLayout from TweetComposiveView and avoids the use of layout_weight altogethercode.
The laborious work of figuring out what MeasureSpec to use on each child view is done by the ViewGroup’s handy measureChildWithMargins() method—and getChildMeasureSpec() under the hood.
TweetLayoutView probably doesn’t handle all possible layout combinations correctly but it doesn’t have to. It is absolutely fine to optimize custom layouts for your specific needs. This allows you to write both simpler and more efficient layout code for your app.
Flat Custom View
As you can see, custom composite views are fairly simple to write using ViewGroup APIs. Most of the time, they will give you the performance your app needs.
However, you might want to go further and optimize your layouts even more on critical parts of your UI that are very dynamic e.g. ListViews, ViewPager, etc. What about merging all TweetLayoutView child views into a single custom view to rule them all? That is what flat custom views are about—see image below.
Custom Composite View (left) and Flat Custom View (right)
A flat custom view is a fully custom view that measures, arranges, and draws its inner elements. So you will be subclassing View instead of ViewGroup.
If you are looking for real-world examples, enable the “show layout bounds” developer option in your device and have a look at apps like Twitter, GMail, and Pocket. They all use flat custom views in their listing UIs.
The main benefit from using flat custom views is the great potential for flattening your view hierarchy, resulting in faster traversals and, potentially, a reduced memory footprint.
Flat custom views give you maximum freedom as they are literally a blank canvas. But this comes at a price: you won’t be able to use the feature-packed stock widgets such as TextView and ImageView. Yes, it is simple to draw text on a Canvas but what about ellipsizing? Yes, you can easily draw a bitmap but what about scaling modes? Same applies to touch events, accessibility, keyboard navigation, etc.
The bottom line is: with flat custom views,you will likely have to re-implement features that you would get for free from the platform. So you should only consider using them on core parts of your UI. For all other cases, just lean on the platform with composite views, custom or not.
TweetElementViewcode is a flat custom view. To make it easier to implement it, I created a little custom view framework called UIElement. You will find it in the canvascode package.
The UIElement framework provides a measure/layout API which is analogous to Android’s. It contains headless versions of TextView and ImageView with only the necessary features for this demo—see TextElementcode and ImageElementcode respectively. It also has its own inflatercode to instantiate UIElements from layout resource filescode.
Probably worth noting: the UIElement framework is in a very early development stage. Consider it a very rough sketch of something that might actually become useful in the future.
You have probably noticed how simple TweetElementView looks. This is because the real code is all in TweetElementcode—with TweetElementView just acting as a hostcode.
The layout code in TweetElement is pretty much analogous to TweetLayoutView‘s. It handles Picasso requests differentlycode because it doesn’t use ImageViews.
Async Custom View
As we all know, the Android UI framework is single-threaded. And this is for a good reason: UI toolkits are not your simplest piece of code. Making them thread-safe and asynchronous would be an unworthy herculean effort.
This single-threaded nature leads to some fundamental limitations. It means, for example, that you can’t do layout traversals off main thread at all—something that would be useful in very complex and dynamic UIs.
For example, if your app has complex items in a ListView (like most social apps do), you will probably end up skipping frames while scrolling because ListView has to measurecode and layoutcode each child view to account for their new content as they become visible. The same issue applies to GridViews, ViewPagers, and the like.
Wouldn’t it be nice if we could do a layout traversal on the child views that are not visible yet without blocking the main thread? This way, the measure() and layout() calls on child views would take no time when needed in the UI thread.
Enter async custom view, an experiment to allow layout passes to happen off main thread. This is inspired by the async node framework developed by the Paper team at Facebook.
Given that we can never ever touch the UI toolkit off main thread, we need an API that is able to measure/layout the contents of a view without being directly coupled to it. This is exactly what the UIElement framework provides us.
AsyncTweetViewcode is an async custom view. It uses a thread-safe AsyncTweetElementcode factorycode to define its contents. Off-screen AsyncTweetElement instances are created, pre-measured, and cached in memory from a background thread using a Smoothie item loadercode.
I had to compromise the async behaviour a bit because there’s no sane way of showing layout placeholders on list items with arbitrary heights i.e. you end up resizing them once the layout gets delivered asynchronously. So whenever an AsyncTweetView is about to be displayed and it doesn’t find a matching AsyncTweetElement in memory, it will force its creation in the UI threadcode.
Furthermore, both the preloading logic and the memory cache expiration would need to be a lot smarter to ensure more layout cache hits in the UI thread. For instance, using a LRU cachecode here doesn’t seem ideal.
Despite these limitations, the preliminary results from async custom views look very promising. I’ll continue the explorations in this area by refining the UIElement framework and using it in other kinds of UIs. Let’s see where it goes.
Wrapping up
When it comes to layouts, the more custom you go, the less you’ll be able to lean on the platform’s proven components. So avoid premature optimization and only go fully custom on areas that will actually affect the perceived quality and performance of your app.
This is not a black-and-white decision though. Between stock widgets and fully custom views there’s a wide spectrum of solutions—from simple composite views to the more complex async views. In practice, you’ll usually end up combining more than one of the techniques demonstrated here.
Introducing Radio Pyo: live python music!
28 de Abril de 2014, 2:10 - sem comentários aindaRadio Pyo is now online as a beta experiment. All the compositions are made entirely with Python and Pyo. They mostly have pseudo-random music sections, so technically speaking the chances that you listen to the same song twice are very little :)
I'm contacting the composers in order to make all the sources available in a public repository.
Here's a template with some rules for those who want to submit a composition (for now it's just about sending the script to tiago at acaia.ca):
#!/usr/bin/env python # encoding: utf-8 """ Template for a RadioPyo song (version 1.0). A RadioPyo song is a musical python script using the python-pyo module to create the audio processing chain. You can connect to the radio here : http://radiopyo.acaia.ca/ There is only a few rules: 1 - It must be a one-page script. 2 - No soundfile, only synthesis. 3 - The script must be finite in time, with fade-in and fade-out to avoid clicks between pieces. Use the DURATION variable. belangeo - 2014 """ from pyo import * ################### USER-DEFINED VARIABLES ################### ### READY is used to manage the server behaviour depending ### ### of the context. Set this variable to True when the ### ### music is ready for the radio. TITLE and ARTIST are the ### ### infos shown by the radio player. DURATION set the ### ### duration of the audio file generated for the streaming.### ############################################################## READY = False # Set to True when ready for the radio TITLE = "Song Title" # The title of the music ARTIST = "Artist Name" # Your artist name DURATION = 300 # The duration of the music in seconds ##################### These are optional ##################### GENRE = "Electronic" # Kind of your music, if there is any DATE = 2014 # Year of creation ####################### SERVER CREATION ###################### if READY: s = Server(duplex=0, audio="offline").boot() s.recordOptions(dur=DURATION, filename="radiopyo.ogg", fileformat=7) else: s = Server(duplex=0).boot() ##################### PROCESSING SECTION ##################### # global volume (should be used to control the overall sound) fade = Fader(fadein=0.001, fadeout=10, dur=DURATION).play() ### ### Insert your algorithms here... ### #################### START THE PROCESSING ################### s.start() if not READY: s.gui(locals())
Thanks to Olivier Bélanger and Jean-Michel Dumas for all the code!
Mon petit Jean marchant
6 de Abril de 2014, 12:24 - sem comentários aindaI got this cute little walker by following these instructions. It's a simple 3 servo robot controled by a light sensor, mapping light intensity with speed. To avoid beating his face against the wall Jean uses an ultrasonic sensor which also gives him a fancy big-eye look. So smart uh? :) The code doesn't differ much from that one mentioned above. I've just taken these pictures before he gets disassembled, after all I can't afford a microcontroller for each fun I have on this arduino-world thing.
How Android transitions work
13 de Março de 2014, 11:15 - sem comentários aindaOne of the biggest highlights of the Android KitKat release was the new Transitions framework which provides a very convenient API to animate UIs between different states.
The Transitions framework got me curious about how it orchestrates layout rounds and animations between UI states. This post documents my understanding of how transitions are implemented in Android after skimming through the source code for a bit. I’ve sprinkled a bunch of source code links throughout the post to make it easier to follow.
Although this post does contain a few development tips, this is not a tutorial on how to use transitions in your apps. If that’s what you’re looking for, I recommend reading Mark Allison’s tutorials on the topic.
With that said, let’s get started.
The framework
Android’s Transitions framework is essentially a mechanism for animating layout changes e.g. adding, removing, moving, resizing, showing, or hiding views.
The framework is built around three core entities: scene root, scenes, and transitions. A scene root is an ordinary ViewGroup that defines the piece of the UI on which the transitions will run. A scene is a thin wrapper around a ViewGroup representing a specific layout state of the scene root.
Finally, and most importantly, a transition is the component responsible for capturing layout differences and generating animators to switch UI states. The execution of any transition always follows these steps:
- Capture start state
- Perform layout changes
- Capture end state
- Run animators
The process as a whole is managed by the TransitionManager but most of the steps above (except for step 2) are performed by the transition. Step 2 might be either a scene switch or an arbitrary layout change.
How it works
Let’s take the simplest possible way of triggering a transition and go through what happens under the hood. So, here’s a little code sample:
TransitionManager.beginDelayedTransition(sceneRoot); View child = sceneRoot.findViewById(R.id.child); LayoutParams params = child.getLayoutParams(); params.width = 150; params.height = 25; child.setLayoutParams(params);
This code triggers an AutoTransition on the given scene root animating child to its new size.
The first thing the TransitionManager will do in beingDelayedTransition() is checking if there is a pending delayed transition on the same scene root and just bail if there is onecode. This means only the first beingDelayedTransition() call within the same rendering frame will take effect.
Next, it will reuse a static AutoTransition instancecode. You could also provide your own transition using a variant of the same method. In any case, it will always clonecode the given transition instance to ensure a fresh startcode—consequently allowing you to safely reuse Transition instances across beingDelayedTransition() calls.
It then moves on to capturing the start statecode. If you set target view IDs on your transition, it will only capture values for thosecode. Otherwise it will capture the start state recursively for all views under the scene rootcode. So, please, set target views on all your transitions, especially if your scene root is a deep container with tons of children.
An interesting detail here: the state capturing code in Transition has especial treatment for ListViews using adapters with stable IDscode. It will mark the ListView children as having transient state to avoid them to be recycled during the transition. This means you can very easily perform transitions when adding or removing items to/from a ListView. Just call beginDelayedTransition() before updating your adapter and an AutoTransition will do the magic for you—see this gist for a quick sample.
The state of each view taking part in a transition is stored in TransitionValues instances which are essentially a Map with an associated Viewcode. This is one part of the API that feels a bit hand wavy. Maybe TransitionValues should have been better encapsulated?
Transition subclasses fill the TransitionValues instances with the bits of the View state that they’re interested in. The ChangeBounds transition, for example, will capture the view bounds (left, top, right, bottom) and location on screencode.
Once the start state is fully captured, beginDelayedTransition() will exit whatever previous scene was set in the scene rootcode, set current scene to nullcode (as this is not a scene switch), and finally wait for the next rendering framecode.
TransitionManager waits for the next rendering frame by adding an OnPreDrawListenercode which is invoked once all views have been properly measured and laid out, and are ready to be drawn on screen (Step 2). In other words, when the OnPreDrawListener is triggered, all the views involved in the transition have their target sizes and positions in the layout. This means it’s time to capture the end state (Step 3) for all of themcode—following the same logic than the start state capturing described before.
With both the start and end states for all views, the transition now has enough data to animate the views aroundcode. It will first update or cancel any running transitions for the same viewscode and then create new animators with the new TransitionValuescode (Step 4).
The transitions will use the start state for each view to “reset” the UI to its original state before animating them to their end state. This is only possible because this code runs just before the next rendering frame is drawn i.e. inside an OnPreDrawListener.
Finally, the animators are startedcode in the defined order (together or sequentially) and magic happens on screen.
Switching scenes
The code path for switching scenes is very similar to beginDelayedTransition()—the main difference being in how the layout changes take place.
Calling go() or transitionTo() only differ in how they get their transition instance. The former will just use an AutoTransition and the latter will get the transition defined by the TransitionManager e.g. toScene and fromScene attributes.
Maybe the most relevant of aspect of scene transitions is that they effectively replace the contents of the scene root. When a new scene is entered, it will remove all views from the scene root and then add itself to itcode.
So make sure you update any class members (in your Activity, Fragment, custom View, etc.) holding view references when you switch to a new scene. You’ll also have to re-establish any dynamic state held by the previous scene. For example, if you loaded an image from the cloud into an ImageView in the previous scene, you’ll have to transfer this state to the new scene somehow.
Some extras
Here are some curious details in how certain transitions are implemented that are worth mentioning.
The ChangeBounds transition is interesting in that it animates, as the name implies, the view bounds. But how does it do this without triggering layouts between rendering frames? It animates the view frame (left, top, right, and bottom) which triggers size changes as you’d expect. But the view frame is reset on every layout() call which could make the transition unreliable. ChangeBounds avoids this problem by suppressing layout changes on the scene root while the transition is runningcode.
The Fade transition fades views in or out according to their presence and visibility between layout or scene changes. Among other things, it fades out the views that have been removed from the scene root, which is an interesting detail because those views will not be in the tree anymore on the next rendering frame. Fade temporarily adds the removed views to the scene root‘s overlay to animate them out during the transitioncode.
Wrapping up
The overall architecture of the Transitions framework is fairly simple—most of the complexity is in the Transition subclasses to handle all types of layout changes and edge cases.
The trick of capturing start and end states before and after an OnPreDrawListener can be easily applied outside the Transitions framework—within the limitations of not having access to certain private APIs such as ViewGroup‘s supressLayout()code.
As a quick exercise, I sketched a LinearLayout that animates layout changes using the same technique—it’s just a quick hack, don’t use it in production! The same idea could be applied to implement transitions in a backwards compatible way for pre-KitKat devices, among other things.
That’s all for now. I hope you enjoyed it!
how-can-i-help: oportunidades de contribuição com o Debian
11 de Fevereiro de 2014, 12:32 - sem comentários aindaJá faz um tempo desde o meu último post, e pra esse novo vou retomar o assunto do anterior — como começar a colaborar com o Debian, inspirado num post recente do Stefano.
O how-can-i-help é um programa que te mostra oportunidades de colaboração relacionadas aos pacotes que estão instalados no seu sistema: pacotes que precisam de novos mantenedores, pacotes que estão com bugs críticos, pacotes que estão com bugs críticos e vão ser removidos da testing, etc.
Outro tipo de possível contribuição que o how-can-i-help vai listar e que vai ser bastante útil pra quem quer começar são bugs com a tag “gift”, ou seja bugs que o mantenedor do pacote marcou como fáceis para serem resolvidos por novos colaboradores.
Por padrão o how-can-i-help vai rodar toda vez que você instalar um pacote, mas também você também pode rodar ele digitando how-can-i-help manualmente no terminal.
Então, se você quer começar a contribuir com o Debian, você pode começar agora mesmo com:
$ apt-get install how-can-i-help
OBS: o how-can-i-help só estão disponível a partir do Debian jessie (próximo release), ou seja, você precisa estar usando jessie(testing) ou sid(unstable).
Criando um mapa com dados importados do OpenStreetMap
7 de Novembro de 2013, 0:38 - sem comentários aindaEu mapeei todas as estações de compartilhamento de bicicletas do BikeSalvador e queria fazer um mapa que mostrasse essas estações. Quando havia apenas cinco estações, após mapear no OSM, eu criei um arquivo GeoJSON usando o geojson.io. Porém agora já são 19 estações. Seria um retrabalho enorme mapear as estações no OSM e depois criar o geojson manualmente.
Felizmente conheci o osmfilter, um software para filtrar os dados do OpenStreetMap. Combinando o osmfilter com o geojson.io é possível facilmente extrair alguns dados do OpenStreetMap e apresentar essa informação em um mapa personalizado. Então vamos às instruções de como fazer isso.
O primeiro passo é baixar os dados do OSM. Se você quiser trabalhar com a base de dados de todo o Brasil, você pode baixar dos servidores do GeoFabrik. Como eu necessitava apenas dos dados de uma cidade, utilizei o editor JOSM, fiz o download dos dados e salvei em um arquivo .osm no meu computador.
Agora nós precisamos utilizar o osmfilter. Veja as instruções de instalação na página osmfilter no Wiki do OpenStreetMap. O comando que eu utilizei para filtrar as estações de compartilhamento de bicicletas de Salvador foi:
./osmfilter salvador.osm --keep="amenity=bicycle_rental" > bikesalvador.osm
Você pode combinar mais de um filtro em um único comando. Por exemplo, se você quiser filtrar todos os restaurantes italianos, você poderia utilizar --keep="amenity=restaurant and cuisine=italian".
Aqui entra o geojson.io. Acesse o site, clique no botão Open e importe o arquivo gerado pelo osmfilter.
Após isso, você vai ver todos os dados filtrados sobre o mapa, inclusive os metadados. Se parte dos metadados não te interessar, você pode remover uma ou mais colunas.
Você vai precisar de uma conta no GitHub para salvar seu arquivo GeoJSON. Depois de salvar, o GitHub irá te fornecer uma página com o seu GeoJSON e também um código para que você possa incluir o mapa que você criou em uma página web. O mapa gerado pelo geojson.io é esse abaixo:
Quem quiser criar um mapa ainda melhor, recomendo ler esse tutorial de como adicionar uma camada GeoJSON ao Leaflet.
Criando um aplicativo móvel HTML5 em menos de 24 horas
23 de Outubro de 2013, 0:32 - sem comentários ainda
Tudo começou quando meu amigo e colega de trabalho César Velame me propôs fazer um aplicativo que calculasse a nota necessária na prova final para um aluno ser aprovado. Como a UFRB utiliza pesos diferentes entre a prova final e a média da disciplina, muita gente tem dificuldade em calcular a nota necessária para ser aprovado. O intuito do aplicativo foi facilitar a vida desses estudantes.
Começamos a fazer na manhã de segunda-feira. Utilizamos jQuery Mobile, que eu já tinha alguma experiência, pois utilizei no Clips.tk. Acabei não me lembrando que na homepage do jQuery Mobile há uma ferramenta que permite gerar a estrutura básica da página HTML. Isso teria nos poupado algum tempo, mas valeu o aprendizado. jQuery Mobile é fantástico e bem fácil de usar!
Aprendemos também um pouco de javascript para calcular a nota necessária na prova final e fazer isso ser exibido na página. No final do dia, disponibilizamos a primeira versão do aplicativo em fuiprafinal.com.br. Na manhã seguinte, corrigimos alguns erros e fizemos um layout mais atraente. Eu também escrevi algumas frases engraçadinhas para o app mostrar de acordo com a situação do estudante!
Ainda estamos melhorando o Fui pra final! e em breve vamos disponibilizar no Marketplace do Firefox OS e testar a geração de aplicativos nativos para Android e outras plataformas através do PhoneGap.
Essa experiência foi muito interessante, pois foi uma maneira divertida e prática de aprender novas ferramentas. O fato de estar disponibilizando algo para as pessoas nos estimula a programar mais e com melhor qualidade. O código fonte do aplicativo está disponível no GitHub.
Rede Social baseada em Noosfero é premiada no Japão
22 de Outubro de 2013, 17:46 - sem comentários ainda
Fonte: Colivre
Da Bahia, do Brasil para o Mundo! Um ambiente pedagógico que usa o Noosfero para promover a interação de professores e estudantes de pelo menos dez países foi premiado com o “Excellent Workshop Award” do Canvas Workshop Collection, evento realizado em 2012 no Japão. É o World Museum Project, rede coordenada pelo professor japonês Yoshiro Miyata com a proposta de estimular o poder criativo e a liberdade de expressão de crianças e adolescentes.
Segundo Miyata, World Museum Project é uma “rede mundial de pessoas interessadas em atravessar fronteiras culturais e geracionais para criações colaborativas que possam ampliar visões e aumentar paixões”. Reúne usuários do Japão, Austrália, Taiwan, Hong Kong, Filipinas, Rússia, Grécia, Espanha, Estados Unidos, Honduras, entre outros países.
Com ferramentas básicas de criação, a rede permite o desenvolvimento de diferentes tipos de projetos, como animações, obras de arte e histórias. Tudo de forma compartilhada e conectada para propiciar um ambiente de aprendizagem criativa.
Yoshiro Miyata é professor da Universidade de Chukyo e pesquisa ambientes e teorias de aprendizagem. Realiza oficinas interculturais em escolas, museus e comunidades no Japão e em outros países.
Inscrições abertas para cursos de disseminação do Cirandas.net no Recôncavo Baiano
27 de Setembro de 2013, 10:01 - sem comentários ainda
Estão abertas as inscrições para os cursos de disseminação e fortalecimento da plataforma Cirandas.net na região do Recôncavo baiano.
As aulas são voltadas para estudantes, profissionais, integrantes de empreendimentos de economia solidária e interessados no tema.
Entre os tópicos abordados estão as possibilidades oferecidas pelo Cirandas.net, que permite o desenvolvimento de sites para empreendimentos de economia solidária, com lojas online e vitrines virtuais.
As inscrições são gratuitas e podem ser feitas diretamente nos locais de realização das oficinas ou pelo email cursocirandas@colivre.coop.br.
Os cursos são uma realização da Colivre, em parceria com a Universidade Federal do Recôncavo da Bahia (UFRB), com fomento do Fundo de Cultura/Secretaria de Cultura da Bahia.
Debian Day 2013 em Salvador
19 de Agosto de 2013, 21:40O Debian Day Salvador 2013, comemorando o aniversário de 20 anos do Debian, acontece no próximo Sábado dia 24 de agosto. Visite a página do evento para saber mais.
Presidência da República adota plataforma livre Noosfero para construção da Política Nacional de Participação Social
20 de Julho de 2013, 18:49 - sem comentários aindaA Secretaria-Geral da Presidência da República (SG/PR) promoveu, nesta quinta-feira (18/07), no Salão Leste do Palácio do Planalto, o evento “Diálogos Governo e Sociedade: Novas Formas de Participação Social na Política”, no qual representantes de diferentes segmentos da sociedade debateram as recentes manifestações populares e sua relação com as demandas por novos mecanismos de exercício da democracia.
O evento serviu também para o lançamento de duas Consultas Públicas sobre os textos-base da "Política Nacional de Participação Social" e do "Compromisso Nacional pela Participação Social". O processo de construção desses dois textos está aberto a toda sociedade e poderão ser feito por qualquer cidadão, via internet, por meio de uma ambiente digital de participação social, desenvolvido por meio da plataforma livre Noosfero: http://psocial.sg.gov.br
Oficialmente, o desenvolvimento desse projeto da Presidência se deu por meio do SERPRO, contudo a Colivre (Cooperativa de Teconologias Livres da Bahia), criadora dessa plataforma livre, ofereceu todo apoio técnico para que essa implantação acontecesse. Para isso, além de consultoria técnica, foram incluídas e lançadas novas funcionalidades na versão 0.44.0 do Noosfero que possibilitarão a construção colaborativa dos decretos que visam o fortalecimento do diálogo entre o Estado e a Sociedade Civil.
Segundo o site da Presidência da República, o diálogo com os atores sociais para a construção dos dois documentos será o primeiro teste para a nova ferramenta utilizada pelo Governo Federal e aponta para a importância do papel das novas mídias no aprofundamento da participação social.
Representante da Rede Social Livre Blogoosfero, Fred Vasquez defendeu ainda no evento que o uso de tecnologia nacional por todo o governo federal e que os vídeos institucionais sejam hospedados no Serpro e nos sites das universidades brasileiras. O professor da PUC, Ladislau Dowbor, autor do livro Democracia Econômica: Alternativas de Gestão Social, disse que “é importante que a gente se una para que as coisas tenham prosseguimento”.
O ministro Gilberto Carvalho ressaltou que o encontro e plataforma foram elaborados para o governo “mais ouvir as considerações do que falar”. Carvalho considerou o encontro extremamente saudável e afirmou que “ é momento de abrir novos caminhos para o diálogo e a participação”. Pedro Abramovay, da Avaaz (maior comunidade de campanhas e petições online para a mudança social) defendeu que as manifestações de junho de 2013 apontaram um novo caminho para o Brasil.
Fonte: Site da Presidência da República.
Colivre em pauta: cooperativa baiana é citada em duas reportagens do Estadão, em São Paulo.
20 de Julho de 2013, 18:16 - sem comentários ainda
Fonte do Foto: http://instagram.com/p/byl91hGTak
Segundo a reportagem publicada no Estadão, no dia 14 de Julho de 2013, "uma nova geração de programadores e ativistas está convencida de que o Brasil pode dar origem a um novo expoente mundial na área e buscam inspiração nos casos de sucesso de companhias como Mozilla (responsável pelo navegador Firefox), a plataforma de publicação WordPress e a RedHat, grande empresa de software da área. O desafio é lidar com a falta de conhecimento e a insegurança do setor privado, habituado a programas proprietários, já que hoje a maioria dos negócios ainda envolve o setor público."
"Para ganhar espaço, as novas empresas da área precisam se profissionalizar, já que hoje o mercado é muito fragmentado e a maioria ainda atende a setores do governo. “Infelizmente o software livre está associado ao ambiente acadêmico. Há muito preconceito”, diz Vicente Aguiar, sócio-fundador da Colivre, cooperativa de tecnologias livres nascida na Bahia e criadora da plataforma Noosfero, usada na rede social colaborativa Stoa, da Universidade de São Paulo (USP).
Outro ponto é conquistar a confiança das empresas, que temem utilizar uma plataforma cujo código é modificado colaborativamente. “Esse princípio impulsiona o negócio”, diz Aguiar. “O Noosfero foi traduzido para o japonês, russo e alemão. Em qual outro contexto um sistema criado no Nordeste chegaria a esses lugares?”
Na segunda reportagem, "ativistas defendem o ensino de programação nas escolas para reduzir déficit de profissionais de TI e estimular inovação. A disputa por mão de obra no mercado de tecnologia é um dos fatores que atrapalha o desenvolvimento de novos negócios com software livre. 'A maioria dos programadores é cooptada por grandes corporações e abandonam os sonhos para ganhar milhões em outros lugares', diz Vicente Aguiar, da cooperativa Colivre. 'Muitos só precisavam de um empurrãozinho para empreender'.”
Para conferir as reportagem completas, acesse os dois link abaixo: