Scrum - Referências Úteis 28/Sep/2007
Na empresa onde sou colaborador iniciou-se uma não-oficial investigação sobre a adequação da metodologia ágil Scrum.
Numa rápida investigação que fiz, encontrei as seguintes referências ou artigos.
(more…)Editores WYSIWYG para TextAreas 18/Mar/2005
Retomei a análise das melhores soluções FOSS que substituem TextAreas por editores WYSIWYG - What You See Is What You Get. Não considero soluções comerciais, apenas analiso soluções livres e abertas que:
- Sejam independentes do Browser HTML usado.
- Produzam XHTML válido.
- Apresentam dois modos de funcionamento: simples/básico e completo/avançado.
- Permitam a escolha de estilos definidos em ficheiros CSS.
- Integrem um Wizard para inserção de tabelas.
- Integrem um Wizard para inserção de imagens.
- Possibilitem a escolha do idioma da interface, para pelo menos Inglês e Português.
- Possibilitem copiar-se directamente conteúdo do Word, que é “limpo” para XHTML válido.
Estas são as soluções que estou a avaliar, mediante o cumprimento dos requisitos acima apontados e que em caso de “empate técnico” apresentam o menor tamanho de código-fonte e sejam facilmente integradas na soluções Web doSolutions:
- RTE.
- TTW Rich Text WYSIWYG Editor.
- BitFlux Editor v1.0.0.
- Kupu v1.2RC2.
- TinyMCE v1.43.
- FCKEditor v2.0RC3.
- SPAW v1.1b.
A solução que ocupa menos espaço é o RTE, com menos de 100KB. De seguida, o TTW ocupa pouco mais do que 100KB. No entanto, nenhum destes dois integra um wizard para inserção de imagens, tendo sido esta a principal razão para não serem escolhidos. Segue-se o SPAW, com cerca de 900KB, e depois todos os restantes, que ocupam pelo menos 1MB. No entanto, após um básico cleanup de ficheiros não necessários, verifiquei que o FCKEditor ocupa menos de 900KB.
No entanto, não foi este requisito que coloquei em primeiro lugar. Qualquer um parece-me adequado para cumprir os requisitos essenciais, no entanto acabei por comparar o TinyMCE somente com o FCKEditor e o SPAW. Estes dois últimos, não sendo ainda versões oficiais, deixam-me um pouco menos à vontade do que com o TinyMCE. Este, além de uma documentação muito adequada, parece-me o mais fácil de integrar e o mais indicado para os objectivos que tenho em mente.
Chego por fim à conclusão que após serem disponibilizadas as versões oficiais do FCKEditor e do SPAW que tenho de novamente re-analisar este tipo de solução.
Esquema de Nomeação de Revisões 16/Mar/2005
Após diversas revisões ao código-fonte das doSolutions, compreendo que o esquema de nomeação que uso não é prático.
Actualmente, para trabalhar numa nova revisão, uso uma das ramificações criadas após a importação inicial (v0.0.00). Estas ramificações procuram ser estanques e usam números incrementais:
- v0.0.nn/ – Limpeza e Emagrecimento (Cleanup & Streamlining).
- v0.1.nn/ – Localização pt_PT.
- v0.2.nn/ – Minor/Major Fixes & Patches.
- v0.3.nn/ – Contribuições para Back-End.
- v0.4.nn/ – Contribuições para Front-End
O problema reside no facto de a numeração ser sequencial mas sem acompanhar temporalmente o trabalho, que pode ser efectuado em qualquer uma das ramificações. Assim, por exemplo, aconteceu saltar da revisão v0.0.07 para a revisão v0.3.01 e desta para a revisão v0.1.01. Esta ordem aqui apresentada é temporal mas o esquema de nomeação não consegue apresentar uma numeração sequencial no tempo.
Tenho que abandonar este esquema de nomeação e adoptar um esquema mais prático, com numeração sequencial, que mantenha na mesma este facilidade “estanque” entre ramificações.
Pootle 17/Feb/2005
O portal Pootle é um simples portal que ajuda a comunidade FOSS a traduzir (localizar) software FOSS em diversas linguagens (idiomas). O projecto em si está alojado no SourceForge, em translate.sourceforge.net, que por coincidência usa o motor DokuWiki.
O nome Pootle é uma abreviatura para PO-based Online Translation / Localization Engine. Para participar de forma aberta e livre, é necessário inscrever-se e depois seguir os procedimentos de Abertura de um Projecto ou Adição de Nova Linguagem.
Para ajudar nas traduções, existe um TranslationToolkit que converte diferentes formatos no formato PO (baseado em Gnu GetText), de maneira a uniformizar os esforços de tradução dos diversos projecto. Nem todos os projectos são baseados em ficheiros .po, pelo que é importante este Toolkit.
Textile vs Markdown vs Wiki 04/Feb/2005
A edição de conteúdos, de forma usual, é feita através do recurso a TextAreas que na sua maioria permitem somente um conjunto de tags HTML consideradas “seguras”. A maior parte dos sistemas de gestão de conteúdos além de disponibilizar de raíz esta funcionalidade também permite alguma forma de plugin a editores WYSIWYG. Estes editores são excelentes para diminuir a curva de aprendizagem necessária aos utilizadores iniciados para produzirem conteúdo de forma rápida e fácil. No entanto, qualquer uma destas funcionalidades não é prática, pelas seguintes razões:
- As tags HTML introduzem muito “ruído” no conteúdo em bruto.
- São tantas as tags HTML e as regras de sintaxe que a aprendizagem da linguagem apresenta uma curva íngreme.
- Poucos são os editores WYSIWYG que passam os testes de validação XHTML.
- Os editores ocupam por vezes mais espaço que o próprio sistema. De qualquer maneira, um editor WYSIWYG é sempre uma adição pesada ao conjunto de funcionalidades de um sistema.
- Muitas vezes, o código extra inserido pelos editores WYSIWYG não produz qualquer efeito visível, existindo mais por causa das diversas situações que devem ser lidadas de forma correcta pelo editor do que pela necessidade real de um caso específico.
Por essas razões, têm sido desenvolvidas algumas soluções de filtros de texto (TextFilters) que procuram também minimizar a curva de aprendizagem necessária ao mesmo tempo que simplificam a própria edição do conteúdo através de tags mais simples que as do HTML:
- WikiMarkup.
- Textile.
- Markdown. O original é codificado em Perl, mas tambéme existe uma versão em PHP.
Um filtro de texto é pouco mais do que um conversor que transforma texto com simples tags de formatação em conteúdo com tags HTML/XHTML. Qualquer um dos filtros de texto acima mencionados existe em PHP e permitem que os utilizadores iniciados no papel de editor de conteúdos online se concentrem mais no próprio conteúdo do que na sua apresentação. Além disso, no caso do WikiMarkup, é muito mais fácil, simples e rápido estabelecerem-se ligações entre páginas do mesmo site ou mesmo ligações a sites externos bem como é muito prático criar novas páginas. O Textile e o Markdown são mais abrangentes em termos de regras possíveis de formatação do conteúdo, mas o WikiMarkup cobre o essencial e torna muito fácil e rápida a produção de novos conteúdos e ligações entre páginas.
Irei criar um documento no SiteWiki da DoWeDo-IT para comparar as semelhanças e diferenças entre estas 3 soluções. O objectivo desse documento Wiki (WikiDoc) é o de recomendar qual a solução a integrar na generalidade dos sistemas de gestão de conteúdos, baseados em PHP.
Unison e Desenvolvimento Web 31/Jan/2005
Um dos problemas que tenho tentado resolver é o da sincronização de alterações ao código-fonte distribuído por diversas máquinas.
O ambiente de desenvolvimento e de proução que uso é composto pelas seguintes máquinas:
- Servidor Offline – este servidor é uma cópia do servidor online (de produção) e actua como elemento central de todo o desenvolvimento. Enquanto não for implementado um sistema de desenvolvimento distribuído, este servidor é essencial para consolidar todas as alterações num ponto central a partir do qual as outras máquinas da rede local se possam sincronizar.
- Laptop – esta estação de trabalho actua como elemento principal de todo o desenvolvimento, e é também o sistema de suporte a apresentações e demonstrações das soluções para os clientes. É preciso actualizar o servidor central (offline) com as alterações efectuadas, e caso existam mais estações de trabalho devem cada uma das outras se actualizar com o servidor central para que tudo esteja correctamente sincronizado.
- Servidor Online – este servidor é o servidor de produção, e tem a versão estável mais recente do site. É preciso após cada nova versão actualizar o código-fonte do servidor online através da sincronização com o servidor offline. É também necessário efectuar backups aos dados do servidor online para o servidor offline.
Manter estas 3 máquinas sincronizadas, manualmente, é uma tarefa árdua. Com o recurso ao Subversion, foi possível simplificar as actualizações e sincronização das alterações ao código-fonte entre as máquinas da rede local. Falta uma ferramenta capaz de sincronizar o servidor online com qualquer uma das máquinas da rede local, e que também facilite a sincronização do código-fonte que poderá vir a estar distribuído pelas diversas máquinas locais.
Essa ferramenta foi, à primeira vista, encontrada. Designa-se por Unison e é uma ferramenta de sincronização de ficheiros distribuídos por diversas máquinas que se encontram ligadas com recurso ao protocolo TCP/IP. Já existiam outras ferramentas idênticas, mas o Unison apresenta as seguintes vantagens face às ferramentas mais conhecidas:
- Corre em diversos sistemas operativos: Linux, Windows, OS X, ...
- Sincroniza ficheiros existentes em máquinas que correm diferentes sistemas operativos.
- Consegue lidar com actualizações a diversas réplicas numa estrutura de pastas distribuída.
- Não é um sistema de ficheiros distribuído, não requer por isso modificações a baixo-nível ao núcleo do sistema operativo nem precisa de previlégios de super-utilizador do sistema.
- É resiliente à falha: deixa cada réplica num estado estável bem definido, mesmo em casos de terminação abrupta ou erros de comunicação.
Irei por isso começar a utilizar o Unison para sincronizar alterações entre os diversos ambientes.
Import-Commit-Export em Subversion 28/Jan/2005
Este post foi migrado para o SiteWiki da DoWeDo-IT.
Portal de Projectos FOSS 14/Jan/2005
Seria óptimo se existisse um sistema que integrasse as seguintes funcionalidades, essenciais a qualquer projecto e em particular a projectos que envolvam aplicações online:
- Gestão de Documentação, de forma colaborativa – motor Wiki.
- Publicação de diários ou jornais – motor Blog.
- Partilha de ficheiros e discussão comunitária – motor Fórum.
- Controlo de Verões – recomendo Subversion.
- Interface Web aos repositórios – recomendo WebSVN.
- Gestão de Incidentes, sejam Bug Reports, Feature Requests ou Support Requests.
Este sistema, online, deveria disponibilizar espaço de armazenamento e largura de banda suficiente para todos os projectos Open-Source (Software Livre e Aberto) em Portugal, em especial a título universitário.
Na realidade, do que conheço, a integração das funcionalidades do Drupal com o GForge, de forma a que o sistema além das funcionalidades essenciais também apresentasse como mais-valias a disponibilização de canais RSS internos a cada projecto, agregação de canais RSS externos com assuntos no âmbito de cada projecto, e que passasse os testes de validação XHTML/CSS seria o que mais se aproxima da ideia acima descrita.
Registro aqui alguns dos sites/soluções mais interessantes: