Rafael, usar PHP pois é mais fácil de instalar não é um bom argumento técnico para a decisão da tecnologia a ser usada. :)
Anderson, vou responder com calma seus argumentos depois. Ainda estou pouco convencido da necessidade de mudança e vamos mais a fundo nisso. O LocalWiki vai mudar algumas coisas na tecnologia. Vale a pena uma discussão com o Philip, que conseguiu deixar o projeto mais sustentável que o Mootiro e formou, de fato, uma comunidade. Vocês chegaram a pensar o que falhou no quesito comunidade em relação ao Mootiro? Quais as conclusões? Tom Em 10 de junho de 2014 12:13, Rafael Pezzi <[email protected]> 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 <[email protected]>: > >> @Daniela: Claro, quando pudermos te avisamos. =) >> []s! >> >> _______________________________________________ >> okfn-br mailing list >> [email protected] >> 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 > [email protected]https://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br > > > _______________________________________________ > okfn-br mailing list > [email protected] > https://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br > > -- Everton Zanella Alvarenga (also Tom) Open Knowledge Brasil - Rede pelo Conhecimento Livre http://br.okfn.org
_______________________________________________ okfn-br mailing list [email protected] https://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
