[okfn-br] Cuidando do Meu Bairro 2.0

Sexta Janeiro 31 14:49:51 UTC 2014

Oi Andrés,

Estamos trabalhando na parte de usabilidade do Maps. Temos um redesign do
sistema, que visa várias simplificações. Estamos implementando essas
mundanças aos poucos, pq temos que equilibrar com outras demandas que vão
surgindo.

Da parte de estrutura. Somente trocar linguagem/framework sem mudar
arquitetura é um erro tremendo que não costuma gerar qualquer ganho. Já
cometemos esse erro. Porém identificar problemas reais no seu fluxo e
consertá-los, mudando a arquitetura..isso sim é justificável. O que importa
é a mudança de arquitetura e não de linguagem (mas esses dois costumam
andar juntos).

A idéia de fazer um desacoplamento em serviços e redesign das camadas do
maps é: tornar mais simples construir novas interfaces sobre o 'maquinário'
que roda por baixo, torná-lo mais centrado nos dados e diminuir nosso custo
de desenvolvimento.

Quanto a linguagem.. eu considerei Python, Ruby, Scala, Node, Clojure, e
Elixir/Erlang.
Meus motivos pra escolher Ruby foram:
- sou bastante familiarizado
- é de fácil acesso pra outros desenvolvedores (especialmente pra quem já
programa em python.. é um 'pulinho')
- ecossistema muito bom (libs como pry, rspec, guard, entre outras.. ou não
tem análogo nas outras ou são muito superiores)
- rails ou sinatra
- plug and play com ferramentas excelentes (new relic, honeybadger, code
climate, heroku, etc)
- grande foco em testes e qualidade
- se fizer sentido, ganhar performance rodando na jvm com jruby (que
costuma dar menos problema do que rodar python na pypy por exemplo).
- [motivo menor] depois de muitos anos trabalhando com Django ... cansei
dele =P ... "programmer happiness" é importante.

é isso, desculpem o texto longo.
abs

Anderson

Em 31 de janeiro de 2014 08:03, Daniela Mattern
<daniela.mattern em it3s.org>escreveu:

> Oi Andrés!
>
> sobre o lance da interface - super legal ter sua avaliação. Seria bom,
> se pudesse concretizar um pouco mais - falando o que acha confuso e
> tais.
> nos enxergamos esse problema e criamos a possibilidade do usuário
> adicionar os pontos direto dentro do projeto dele. Assim, eles ficarão
> no mapa dele e também no mapa geral que para nos e como um repositório
> de dados georreferenciados.
>
> Lamentavelmente, não todos os usuários entendem isso fácil ...
> acredito que parte disso tem a ver com "guiar o usuário", ter um help
> que faça mais sentido ... podemos sentar qualquer dia desses e pensar
> juntXs essas simplificações.
>
> por outro lado estamos nesse momento pensando em tornar o maps mais
> modular. queremos ter um servidor de dados georreferencidados (uma
> API) - nessa API você poderá conectar as mais diversas interfaces,
> aplicativos e visualizações e acessar os dados via json e visualizar.
> também já desenvolvemos um outro tema visual para o maps - um projeto
> para City University of New York City
> (http://childfriendlyplaces.org). nesse tema, algumas opções de menu
> não aparecem. por exemplo, o mapa geral ... então, é possível vc fazer
> outros temas visuais pro maps.
>
> segunda quinzena de fevereiro: pra mim pode ser 18/02 ou 21/02. à
> tarde? reunião entre os desenvolvedores do maps, marcamos para o dia
> 19/02. se quiser colar lá, tá bem-vindo :)
>
> abraços
>
> Daniela
>
>
>
>
> bjs
>
> Daniela
>
> Em 31 de janeiro de 2014 01:10, Andrés Martano <andres em inventati.org>
> escreveu:
> > Oi, gente! Obrigado pelas respostas!
> > Vamos lá...
> >
> > Iuri, se você pudesse esclarecer melhor do porquê desses plugins serem
> > ruins para a comunidade, eu agradeceria. =)
> > Detesto desenvolver usando-os, mas acredito que seja mais porque, como
> > programador, tenho muito mais liberdade trabalhando em um código do que
> > encaixando plugins que vão me limitar nas opções pré-programadas dos
> mesmos.
> > Mas, uma pessoa que não saiba programar, não possui essa segunda opção...
> >
> > Oi, Daniela, lembro de você de outros emails. =)
> > Sim, seria muito bom unir esforços, mas é incrível como a área de
> > desenvolvimento web é extremamente fragmentada, com zilhões de
> > tecnologias, linguagens e bibliotecas incompatíveis entre si...
> > Sobre o Mootiro, o fato dele permitir que as pessoas adicionem pontos no
> > mapa é muito importante. Porém, já ouvi várias reclamações sobre a
> > interface ser difícil de usar... Pessoalmente, depois de usar algumas
> > vezes, até consigo me virar, mas acho que usuários novos ao site, ainda
> > mais quando pouco experientes digitalmente, podem ficar confusos. Ele
> > tem muitos recursos e elementos no mapa principal, então uma interface
> > simples e limpa torna-se um desafio, mas talvez fosse o caso de permitir
> > algumas interfaces alternativas...
> >
> > Anderson, quais seriam as vantagens dessa nova arquitetura?
> > Você falou que a escolha de linguagem/framework não é tão importante,
> > mas você não acha que há um custo considerável em trocá-la depois? Seja
> > pelo retrabalho de código, seja pela curva de aprendizado?
> > Eu sempre fico com aquela maldita dúvida de se escolhi ou não a melhor
> > ferramenta para o trabalho, o que, no caso da web, parece ser impossível
> > de sanar, já que existem tantas tecnologias, cada pessoa fala uma coisa
> > na hora de avaliá-las e é inviável experimentar todas para ter sua
> > própria opinião... =/
> >
> > Estamos pensando em marcar uma reunião para discutir tudo isso e ver se
> > encontramos um caminho conjunto a trilhar. Estarei fora na primeira
> > metade de fevereiro, então proponho que escolhamos uma data na segunda
> > metade. Alguma sugestão?
> >
> > Abraços!
>
>
>
> --
> Daniela Mattern
> Coordenadora Geral
> IT3S - Instituto de Fomento à Tecnologia do Terceiro Setor
> Fone: 0055-11-36285787
> Celular: 0055-11-987 356 563
>
> Siga nosso Twitter | Acompanhe nosso Facebook
> prestandocontas.org
> maps.mootiro.org
> it3s.org
>

-- 
Anderson Pierre Cardoso
Software Engineer - IT3S / University of Sao Paulo

*http://www.apierrecardoso.com <http://www.apierrecardoso.com>*
twitter: *@apierre_cardoso* <https://twitter.com/#%21/apierre_cardoso>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20140131/231f732e/attachment-0005.html>