Documentação e rankk.org

Correria do cão, sumiço temporário, deadline de projetos se aproximando, mas o mundo não pára... então antes de continuar com dicas sobre o Plone 3.0 (que entrou em rc2 na sexta passada), vou falar sobre uma área importante do projeto: documentação.

Também aproveito a oportunidade para divulgar um novo site (novo para mim!) de desafios, num estilo semelhante ao já tradicional PythonChallenge, o Rankk!

Geralmente os desenvolvedores de software livre fazem aquilo que eles gostam, ou seja, programar, escrever código. Alguns abençoados vão mais longe e escrevem os testes antes do código. Mas são poucos os que se preocupam realmente com documentação... (só para constar: eu não sou um deles...)

Isso praticamente não gera problemas quando o projeto é pequeno, afinal basta ler o código... mas na medida em que o projeto vai ficando maior, mais complexo, é que os primeiros sinais ficam evidentes.

Agora imagine o caso de um projeto cujo núcleo possui cerca de 240 mil linhas de código, segundo as métricas do Ohloh (a propósito, o que você está esperando para criar a sua conta lá e relacionar os seus projetos?). Isso desconsiderando o resto da pilha, composta pelo Zope, CMF e dezenas de aplicações adicionais que estão disponíveis para uso através do Collective...

Durante muito tempo o Plone foi criticado exatamente pela sua falta de documentação. Com o tempo, num esforço conjunto de diversos desenvolvedores, capitaneados pelo Alexander Limi, foi desenvolvido o Plone Help Center (PHC) para ser utilizado na resolução dessa questão.

O PHC entou em operação no final de 2004 e rapidamente se tornou um grande sucesso. A quantidade de documentação do Plone cresceu em um ritmo quase que exponencial, abrangendo diversos tipos de audiências, desde aqueles que apenas procuram saber o que significa algo, passando por informações de como usar e até mesmo tutoriais passo-a-passo e completos manuais de referência.

Porém, como tudo o que existe em excesso, a área de documentação começou a apresentar problemas. Os usuários começaram a reclamar da enorme quantidade de documentação que estava sendo gerada! Isso acabava atrapalhando na hora de decidir o que era preciso ler a respeito de determinado assunto.

No mês passado, pela primeira vez na história do Plone, tivemos um sprint focado na questão da documentação (e também e-commerce): DocComm. Ele ocorreu nas dependências do Google, em Montain View, na California. A repercussão foi ótima, muitos posts a respeito das atividades que estavam sendo realizadas, entre elas a revisão da documentação existente e a classificação dela, através da técnica de card sorting , onde uma parede inteira acabou sendo preenchida... :-D

Com o sucesso obtido no sprint, onde o próprio PHC também foi atualizado, hoje podemos dizer que o Plone tem uma área de documentação da qual possa se orgulhar! Poucos projetos estão nessa condição, mas vale a pena citar também o SQLAlchemy pela freqüência de atualização e clareza da sua documentação.

Bom, mudando um pouco de assunto, ninguém é de ferro e como eu disse durante algumas entrevistas depois da Arena de Programação, nada melhor do que alguns desafios para desestressar depois de um dia (ou uma noite, ou de vários dias...) de trabalho! A propósito, atualizando o recorde de uptime: 44 horas (das 11:00 de domingo até às 07:00 de terça-feira)... ;-)

Uma das coisas mais interessantes do Rankk, fora a lenga-lenga sobre o Egito, pirâmides e tal..., é que ele não se resume a desafios envolvendo apenas uma única linguagem, ou foca diretamente em programação, e ainda nesse sentido, ele se quer está diretamente ligado a computação! Ter uma base sólida em matemática e lógica é muito mais importantes neste caso.

Obviamente existem problemas específicos de programação, ou melhor, de computação. Prepare seu repertório, pois pelo caminho você vai encarar Javascript, PHP, Perl, Prolog, SQL, Java, Lisp, Brainfuck, Python, código morse e mais alguma coisa que eu ainda não consegui identificar... :-D

Apesar de tudo, é diversão na certa, eu aguarantcho! ;-)

Atualizações:

• O esperto aqui conseguiu a façanha de errar o nome do site... o correto é rankk.org e não rankk.com, como ficou no título por algumas semanas... e o pior é que só descobri isso quando o Sphinx citou este humilde blog... :-/
• Acabei de chegar ao posto de Vizir, na quarta posição... daqui para cima vai ser pedreira! :-)

Leia mais...

Linguagens de Programação: Suckage Ratio

Hoje na lista da maratona, onde (ex-)participantes das maratonas de programação da ACM se encontram, surgiu mais uma daquelas threads sobre qual é a melhor linguagem...

Esse é o tipo de discussão que nunca leva a lugar nenhum, mas hoje tive uma idéia que pode ser, no mínimo, bem humorada... :-)

Geralmente quando se compara as linguagens de programação, comparamos uma em relação a outra. Isso sempre acaba gerando grandes distorções ou, no melhor caso, uma certa tendência para um dos lados...

Para evitar esse tipo de coisa, vamos 'comparar' uma linguagem com ela mesma. Meu critério foi bem simples: uma busca no Google, contendo o nome da linguagem de programação e mais as palavras 'sucks' ou 'rocks'. A linguagem que tiver o menor percentual de 'sucks', proporcional ou número de 'rocks', tem o melhor desempenho.

O ideal seria ficar o mais próximo possível de 0. Com 0,5, para cada pessoa falando mal da linguagem, temos duas falando bem. Qualquer coisa acima de 1 significa que existe mais gente falando mal do que bem, e assim vai...

Bem, vamos aos resultados então, considerando as 10 primeiras colocadas no índice TIOBE, pela ordem:

Linguagem	Sucks	Rocks	Suckage Ratio
Java	26300	11500	2,286956522
C	9150	24600	0,37195122
C++	783	67	11,686567164
Visual Basic	4570	591	7,732656514
PHP	24900	956	26,046025105
Perl	931	1620	0,574691358
C#	844	1390	0,607194245
Python	562	13700	0,041021898
Javascript	1239	773	1,602846054
Ruby	534	17900	0,029832402

Analisando-se rapidamente o Suckage Ratio™ das linguagens, podemos fazer as seguintes observações:

• Python & Ruby caíram mesmo no gosto dos programadores, impressionante!
• PHP também caiu no gosto, mas pelo outro lado... :-P
• C++ é muito mais mal amado do que eu imaginava
• Java não é tão ruim, pelo menos quando comparado ao Visual Basic! :-D
• C ainda possui uma popularidade realmente incrível
• C# pode ter futuro, veremos o que nos reserva os próximos capítulos
• Javascript ainda desperta o ódio dos programadores web
• Perl continua forte na sua comunidade de masoquistas visuais... :-)

Atualizações:

• Antes de publicar esse post, fui acrescentar algumas referências e acabei encontrado um serviço dedicado apenas para isso, o sucks/rocks! Os resultados foram um pouco diferentes (C++, por exemplo), já que eles consideram diversas expressões, mas no geral parecidos...
• Apenas esclarecendo: a relevância/disseminação/popularidade/número de hits ou qualquer outro fator não são levados em conta. O Suckage Ratio leva em consideração apenas quem falou bem ou mal da linguagem, através de sucks/rocks. A proporcionalidade disso garante que o resultado será o mais justo o possível, independente dos demais fatores.

Leia mais...

Content Providers e Viewlets no Plone 3

Este é o início de uma série de pequenos artigos introdutórios sobre as novidades da próxima versão do Plone. Para deixar claro, a intenção não é detalhar o funcionamento, nem explorar todas as possibilidades, apenas tornar um pouco mais visível alguns dos muitos recursos interessantes que já estão disponíveis.

Exatamente... é para você não fazer aquela cara de 'WTF?!?' quando estiver conversando com o pessoal do Plone na próxima PyConBrasil, aliás, o que você está esperando pra fazer a sua inscrição agora mesmo? :-)

Para começar, o Plone é um sistema de gerenciamento de conteúdos (CMS). Se você conhece algumas das outras 775 soluções CMS atualmente listadas no site CMSMatrix, faça uma rápida comparação delas com a versão anterior do Plone, a 2.5 (lembre-se, a 3.0, está saindo do forno!) e veja se você também se surpreende com os resultados... ;-)

Bom, mas vamos ao que interessa... um dos recursos mais solicitados era a possibilidade de gerenciar os elementos que compõem o visual de um Plone site, como por exemplo a caixa de buscas, as ações de um documento ou a barra pessoal de cada usuário, só para citar alguns casos. Quando eu digo gerenciar, me refiro a possibilidade de adicionar e remover, além de alterar a ordem em que os elementos aparecem, sem precisar ficar personalizando os templates, especialmente o main_template... que é o ponto central de toda a identidade visual do site.

O Plone 3 usa extensivamente os conceitos de content providers e viewlets para resolver essa e outras questões (como os portlets, mas isso fica para o próximo post). Se você olhar com atenção, notará que muitos dos templates agora possuem fragmentos do tipo:

<tal:block replace="structure provider:foo" />

Note o novo namespace provider introduzido pelo pacote zope.contentprovider do Zope3. Ele renderiza o conteúdo do viewlet manager especificado. Para saber mais sobre como criar e registrar seus próprios viewlet managers, bem como especificar a ordem e quais viewlets aparecem e onde, consulte o tutorial na seção de documentação do Plone. Essa personalização pode ser facilmente feita num perfil do GenericSetup, bastando fornecer seu próprio arquivo viewlets.xml.

Obviamente que se você não possuir acesso ao sistema de arquivos do servidor Zope, as coisas podem complicar. Entretanto, isso não significa que não possa ser feito. Você pode editar as definições das viewlets em cada uma dos viewlets managers registrados, basta acessar a view /manage-viewlets na raiz do seu Plone site. No momento ainda não existe um link visível onde você possa clicar para ir nessa tela, mas isso deve ser resolvido em breve.

Infelizmente nem tudo é perfeito no mundo TTW. A adição de novas viewlets aos viewlet manager existentes só pode ser feita através de código Python irrestrito ou por um perfil do Generic Setup...

Isso resume a primeira dica sobre o tema, assim como (espero) deixa o prezado leitor na expectativa do próximo tópico... ;-)

Leia mais...