[okfn-br] Status do MootiroMaps

Terça Junho 10 15:53:34 UTC 2014

Sem qquer chance de eu mexer com php. Tanto eu qto o Luiz somos muito
exigentes qto a qualidade de código e tecnologia, o código do Maps que era
bom já nos frustava.
Instalar um servidor Ruby é absolutamente trivial, ainda mais se vc for
deployar no heroku.
Minha escolha de Ruby foi justamente por ser uma escolha sólida, que eu
tenho bastante experiência, e que me permite desenvolver rapidamente. Se eu
fosse escolher tecnologia arbitrariamente por gosto eu iria de Erlang,
Scala ou Clojure. Escolhi Ruby por ter experiencia e ter tudo a mão para
desenvolver rapidamente.
O Meppit não esta no começo, o projeto está avançado, e seguindo a uma
velocidade excelente.

Os principais pontos eram dificuldade com a interface e falta de features
"sociais" que permitissem o usuário a seguir e colaborar mais facilmente
nós seus projetos. Sistema rico de notificações, tageamento, coisas do
tipo.
Além disso tivemos uma curva de aprendizado em qual era nosso publico alvo
para fazer um marketing mais eficiente. Passando mto tempo fazendo oficinas
em comunidades, o que teve uma taxa de conversão de usuários ativos baixa.
Depois de um tempo vimos que organizações usando o projeto para mapeamento
de seus projetos, usavam muito mais a ferramenta.
Durante muito tempo, a ferramenta era somente em português o que limitou
nosso alcance tbm. Hoje em dia temos um suporte bem maior a multiplas
linguas, inclusive o http://childfriendlyplaces.org/ é uma instância do
Maps.

abs

Em 10 de junho de 2014 12:13, Rafael Pezzi <rafael.pezzi em ufrgs.br> escreveu:

>  Oi Pessoal,
>
> Fico muito contente que estão fazendo a transição para o OSM (Open Street
> Map). A sobreposição de dados não livres aos dados creative commons da
> comunidade no próprio site é algo realmente grave, pois a inconsistência
> legal já estava feita na fonte.
>
> Como o Abdo, também levanto o questionamento sobre reescrever o código do
> zero ao invés de colaborar com projetos existentes.
>
> Um projeto que pode servir de inspiração e referência é o SmartCitizen:
> http://www.smartcitizen.me/
> O código está todo disponível no github:
> https://github.com/fablabbcn/SmartCitizen.me
>
> Já que a questão de desenvolvimento ainda está aberta, gostaria de sugerir
> que o projeto fosse elaborado em php ao invés de ruby, pois php e muito
> mais fácil de instalar, estando disponível em qualquer serviço de
> hospedagem - o que pode facilitar a adoção.
>
> Abraço,
> Rafael
>
>
>
>
> Em 10-06-2014 11:13, Anderson Cardoso escreveu:
>
>
> Olá a todos,
>
> legal os questionamentos, vou tentar responder a alguns (a Dani pode me
> ajudar mais aqui já que sempre cuidou mais da parte de especificações e
> funcionalidades).
>
> Quando o MootiroMaps começou haviam menos alternativas do que tem hoje,
> uma das primeiras coisas que a Dani e o Edgar fizeram foi estudar
> alternativas, e eles chegaram a conclusão de que valia a pena na epóca
> construir o Maps. Dado o impulso que tomou vemos que foi uma decisão certa.
> Hoje em dia, com muito mais experiência na área nós vimos que nem sempre
> as funcionalidades que achavamos que os usuários gostariam são as que
> realmente são mais usadas.
>
> Por exemplo, hoje vemos claramente que dentro do Maps, as pessoas preferem
> trabalhar com projetos de mapeamento, não com dados isolados. No Meppit
> isso se torna a maneira padrão de trabalhar, seria algo como "Mapeamento
> Temático". Fazendo análogia com apps de música, seriam como playlists,
> assim como em apps como o spotify suas músicas deveriam sempre estar em
> playlists, e você reaproveita-las em múltiplas playlists. No Meppit seus
> dados fazem parte sempre de um mapa, e eles podem ser reaproveitados entre
> diferente projetos de mapeamento.
> Por exemplo, se quero fazer um mapeamento de pontos aonde posso treinar em
> São Paulo, e um outro mapa específico de ginásios de CrossFit, posso
> reaproveitar esse dados entre múltiplos mapas.
>
> Outra coisa que percebemos, é diferentemente do que achavamos, a forma
> principal de trabalho que os usuários fizeram dos mapas não foi mapeando
> comunidades (o que era o foco do MootiroMaps e é o foco da localwiki por
> exemplo). As pessoas fizeram mais uso de projetos, como mapeamentos de
> redes de conselhos tutelares e crianças em necessidade para ligar os
> tutelares a essas crianças de maneira mais eficiente.
> Daí vem a idéia de "mapeamento temático".
> Você pode criar mapas para quaisquer funcionalidaes, desde apps de
> restaurantes e comida, a esportes, conselhos tutelares, ou comunidades.
>
> Outro ponto, é o mapeamento em batches (importação massiva de dados). A
> grande maioria dos dados do Maps foram importados via planilhas e KMLs, e
> depois editados dentro da ferramenta. Boa parte dessas ferramentas
> vislumbra o mapeamento manual.
>
> Também estamos focando em suporte a dados não estruturados (ou
> semi-estruturados), por exemplo ter um campo aonde você pode inserir dados
> em yaml que podem depois ser indexados, procurados ou separados. Por
> exemplo posso subir um monte de bares, com informações de horário e preço,
> e mostrar um mapa interessantes levando em consideração isso (criar um
> heatmap de preços na cidade, ou sei lá).
>
> Outra funcionalidade, muito requisitada e sendo desenvolvida a principio é
> a definição de relações genéricas entre os objetos. Por exempo, dado um
> mapa de ongs quais ajudam quais, investem em quais, são parceiras e coisas
> do tipo. Essa é uma funcionalidade que apesar de parecer simples, se
> mostrou incrivelmente dificil de implementar num sistema legado que não foi
> pensado do principio para isso (você tem relações polimorficas, entre
> multiplos objetos, que não são pre-definidas).
>
> Quanto a facilidade de instalação e de modificar a interface. Estamos
> dedicando esforço adicional para a interface ficar separada em partials
> (tanto nos templates do Rails, qdo stylesheets do sass) para  que seja
> fácil de encontrar e modificar quaisquer elemento. A instalação do Meppit é
> substancialmente mais simples, desde o principio estamos mantendo um
> arquivo de bootstrap (que nós mesmo usamos em desenvolvimento, com o
> Vagrant) que deverá cuida disso. O MootiroMaps tinha uma ambiente realmente
> complexo, por exemplo para subi-lo precisamos ter no ambiente python, ruby,
> nodejs, java (ES) e erlang (rabbitmq). Nos estamos evitando adicionar
> quaisquer dependências externas pesadas, justamente para manter o sistema o
> mais simples possível.
>
> Como dito anteriormente, o Meppit deverá ser repositório de dados, que vc
> pode acessar a partir de qquer interface web ou mobile.
>
> Futuramente planejamos funcionalidades como harvesting para compartilhar
> dados entre multiplas instâncias do servidor. Formatos como o RDF para
> trabalhar com linked data. Camadas de visualização, hierarquia entre
> polígonos, embeding (um dos motivos para mantermos o código js do Mapa em
> uma lib separada) e etc.
>
> Um último ponto, e talvez o principal é manutenção e qualidade. Criar um
> projeto de mapeamento com escopo pequeno e tempo de vida curto é simples.
> Você junta qquer php, ou plugin de wordpress e voilá, vc tem seu mapa. Mas
> fazer um projeto de grande porte, suficiente genérico, que suporte uma
> quantidade massiva de dados (temos poligonos de um único objeto no Maps com
> mais de 10000 pontos!) e que seja fácil de manter no longo prazo, não é
> nada simples. Por isso escolhemos ferramentas "melhores" que encorajem boas
> práticas visando essa manutebilidade. A locawiki por exemplo, quase não tem
> testes automatizados (já passamos por isso, e sabemos o inferno que é
> manter um projeto assim no longo prazo), isso é algo que tem q ser feito do
> princípio. E boa parte dessas ferramentas não levam isso muito em conta.
> (Isso pq a localwiki é feita em Python que tem uma cultura um pouco melhor
> sobre testes e qualidade, agora projetos de php que o pessoal praticamente
> não testa, e tem um compromentimento mais baixo com qualidade, é ainda pior
> .. em dezembro e janeiro eu entrei no repósito da maioria dessas
> ferramentase, avaliando a possibilidade de extende-las e não foi mto
> agradável a experiência).
> Outro aspecto é escala de dados, o Luiz dedicou muito tempo otimizando o
> código de Mapa para suportar quantidades grandes de dados, boa parte dessas
> ferramentas trabalham com quantidades bem menores de geometrias do que
> temos hoje no Maps (e bem menor do que as importações que planejamos fazer
> no Meppit). Isso também influência na idéia de termos mapas temáticos e não
> um super mapão com tudo, pois com mtos dados, um único mapa gigante se
> torna inviável para o usuário.
>
> No Meppit nós temos um código continuamente análisado a cada PR no
> Codeclimate, continuamente testado no TravisCI, com cobertura de testes de
> mais de 96%. A cada PR, é avaliado automaticamente: qualidade, duplicação,
> brechas de segurança, cobertura de tests e por ai vai.
> Estamos fazendo dessa forma, pq não queremos ter que desenvolver outro
> sistema desses, e sim um sistema único e bem escrito que seja fácil de
> extender futuramente.
> https://codeclimate.com/github/it3s/meppit
> https://coveralls.io/r/it3s/meppit
> https://travis-ci.org/it3s/meppit
>
>
> Acho que expliquei mais ou menos algumas das razões.
>
>  abs
>
>  Anderson
>
>
>
>
> 2014-06-10 10:16 GMT-03:00 Andres MRM <andres em inventati.org>:
>
>> @Daniela: Claro, quando pudermos te avisamos. =)
>> []s!
>>
>> _______________________________________________
>> okfn-br mailing list
>> okfn-br em lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/okfn-br
>> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>>
>
>
>
> --
>  Anderson Pierre Cardoso
>
>  <http://goog_730476546>
> http://andersoncardoso.github.io  |  @apierre_cardoso
> <http://twitter.com/apierre_cardoso>
>
>
>
> _______________________________________________
> okfn-br mailing listokfn-br em lists.okfn.orghttps://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>
>
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>
>

-- 
Anderson Pierre Cardoso

<http://goog_730476546>
http://andersoncardoso.github.io  |  @apierre_cardoso
<http://twitter.com/apierre_cardoso>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20140610/144d4b1d/attachment-0005.html>