Mas concordo que deve-se tomar o cuidado de não adotar tecnologias só porque é modinha. Estou notando que isso parece ser uma tendência entre programadores mais inexperientes.
Em 10 de junho de 2014 12:22, Everton Zanella Alvarenga <[email protected]> escreveu: > 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 > -- 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
