• screen
• ssh
• vim
• skype

Destas, só o skype não é open-source. Mas é interessante manter uma conversa verbal, pois conversas escritas podem desviar o foco da programação, que é bem mais rápida e precisa do que a escrita, que pode deixar brechas para má interpretações. A conversa verbal consegue interromper o programador ao mesmo tempo em que escreve, corrigindo-o ou questionando-o.

Conectados no skype, basta decidir em qual máquina será o desenvolvimento. Esta, por sua vez, terá que ter um servidor ssh. Ela será o host da programação. Será necessário, também, nesta máquina, ter instalado o screen, que é um programa que possibilita criar ’sessões’ no terminal.

Host

screen -S PairProgramming

Parece que nada mudou, mas você está numa sessão do screen chamada PairProgramming.

Precione CTRL+a e digite:

:multiuser on

Pressione CTRL+a novamente e digite:

:acladd usuarioclient

Tudo que você ver nesta sessão, será visto pelo outro usuário (usuarioclient) que se conectará nela.

Então, abra o vim, pois será necessário um edito de textos de verdade , e se divirta:

vim /caminho/arquivo

Client

ssh usuarioclient@host
screen -x usuariohost/PairProgramming

Pronto! Agora você está acessando a mesma seção! Tudo que o usuáriohost fizer, o usuárioclient enxergará e vice-versa.

Agora, basta descutir a tarefa via Skype e programar. As atualizações são em tempo real, ou seja, aparecem ao mesmo tempo que são escritos, digo… depende da conexão, mas não é um grande problema.

Caso seja necessário que o usuarioclient não possa modificar o código, apenas assitir e dar pitacos, o usuáriohost deve pressionar CTRL+A e digitar:

:aclchg usuarioclient -w #

Eu ainda vou programar assim, depois digo a experiência.

Referências

• Linux.com
• Jason Haruska

Inaugarado o blog da F1 Soluções, que não é a empresa na qual trabalho, mas é do mesmo sócio e ainda tenho grande participação no processo de desenvolvimento de software da mesma, eu resolvi postar algumas coisas lá. Fiz, então, meu primeiro post sobre engenharia de software. O post se chama Filosofando sobre Engenharia de Software.

Críticas aqui ou lá, lerei os dois comentários. Até mais!

Parece radical, mas a produtividade aumenta, de certo modo. Não só na hora de programar e testar, sempre que edito arquivos no Vim, tento não usar o mouse. Claro que sempre vai ter alguma aplicação que vai te obrigar a usar o mouse, mas se pudermos evitar, melhor!

Eu continuo com esta idéia. Coisinha bonita é para cliente final. Desenvolvedores devem trabalhar com ferramentas que proporcionam o melhor uso do tempo possível, pois o bom profissional é aquele que esbanja do ócio, eis o fluxo:

• Concluir as atividades rapidamente com eficácia e eficiência está diretamente ligado ao ócio, pois se ele tivesse feito algo mal feito, estaria corrigindo os bugs e não vendo vídeos no youtube.
• Com tempo livre, o cérebro humano fica mais descansado e mais propício a receber insights/intuições para resolver problemas difíceis, que – e estes merecem – precisam de mais tempo e necessitam ser bem planejados.
• Resolvendo problemas de forma criativa – talvez até inovadora -, faz com que se evite problemas futuros. Logo, se poupa tempo. Se poupando tempo, voltamos a cláusula anterior.

Parece utópico, mas eu acredito nisso. Eu acho que é possível. Basta saber onde conseguir ganhar tempo em atividades, automatizando com scripts, programas e etc, o tempo é consequência.

Todo Desenvolvedor Web já foi ou ainda é DBA. É inevitável aprender a utilizar banco de dados sem modelar os dados. Geralmente, para isso, é utilizado alguma ferramente gráfica que auxilia na visão do modelo. Não vou citar, mas existem várias para isso.

Porém, há um detalhe que muitos não se atinaram ainda. Me dei conta disso assistindo uma palestra no FISL10, na palestra do Leandro Dutra (se for parente, é primo de muitos graus :S) chamada O elefante ilustrado: modelagem literária e documentação automática em PostgreSQL e outros SGBDs livres.

SchemaSpy

O que é?

É uma ferramente que varre um banco de dados e gera um documentação em HTML nevegável. Ela gera gráfico de chaves estrangeiras utilizando o GraphViz (.dot), como se fosse uma dessas ferramentas que terminam com Designer.

Esses gráficos gerados, são visivelmente bonitos e dispostos. Ou seja, não é mais necessário sofrer arrastando caixinhas de modo com que fique bem arrumado. O programa tem um bom algoritmo para organizar. O que possibilita que o DBA, ou o desenvolvedor mesmo, use este tempo para repensar uma constraint, uma foreign key, etc.

O HTML gerado também tem abas que diferenciam os conteúdos: abas para relacionamentos, abas para tabelas auxiliares, abas para listagem de colunas/tabelas, etc. Mostra os campos, o tipo dos campos, os comentários, valores em comum e as CONSTRAINTS. Ou seja, uma solução completa para documentação de bancos de dados e modelos de ER. Vem junto o jQuery, que da uns efeitos e toggleia algumas colunas das tabelas de exibição.

Onde conseguir?

O site oficial deles é http://schemaspy.sourceforge.net. Pode ser baixado de lá. Apenas o driver jdbc para o banco de dados que for ser usado deve ser encontrado separadamente.

Quem usa ArchLinux, pode baixar os repositórios do AUR. Eu mesmo sou o mantenedor do pacote, então, qualquer dúvida ou problema, comente lá que tentarei responder/resolver o mais rápido possível. O link do repositório é http://aur.archlinux.org/packages.php?ID=28022

Como usar?

Para usar é muito simples. Depois de baixar o .jar, apenas execute

$ java -jar /path/to/schemaSpy.jar --help

Ou, se você instalou o do repositório do ArchLinux, basta usar:

$ schemaspy --help

Ele vai listar os parâmetros, é bem simples. Não vou me deter a isso. Qualquer dúvida comente no post abaixo.

Um exemplo de output pode ser encontrado na própria página do SchemaSpy: http://schemaspy.sourceforge.net/sample/

Sugestoẽs

Se existe algum defeito nele, com certeza é o template. O HTML gerado não é o mais bonito. Não obstante, me parece que o template não é customizável, para isso seria necessário hackear a classe que gera o template. Mas, quem sabe não é implementado algo nas próximas versões? Quem sabe VOCÊ não implementa?

Mas bem, falando em sugestões, aqui vai algumas:

• Integrar com a documentação do phpDocumentor, javaDoc ou outro similar.
• Versionar a documentação gerada para avaliação de crescimento da aplicação: poder comparar como era há certo tempo atrás e como está hoje.
• Programar os SQL’s utilizando algum editor de texto, fazendo você ganhar desempenho e analisar mais facilmente para comentários, constraints, triggers, procedures e views, que são geralmente mais complexas de serem vistas em programas gráficos.

Mais alguma sugestão? Críticas? Deixem nos posts abaixo!