If you have ever felt the need to do remote pair-programming and didn’t know of any tools around to help you do that, here is a quick tip using Screen.

Screen is a window-manager that makes it possible to share a single session among users logged onto the same machine, allowing them to interact with each other in real time.

This assumes that you:

a) have access to at least one Linux/Unix box with Screen and SSH enabled.
b) are comfortable working with a command line editor (vi, vim, emacs, etc).

For this example we will be using Screen 4, which is probably already bundled with your favorite Linux distro or OS X. If you happen not to have it, apt-get/yum/port/whatever to install it.

In order to have multiusers on one Screen session, some file permissions need to be changed. Screen needs to be able to be run as root and the /var/run/screen folder needs some executing permission.

sudo chmod +s /usr/bin/screen
sudo chmod 775 /var/run/screen

Now the first user – let’s call it foo - can log in to the Linux box via SSH and start a Screen session named pairprog.

[foo@linuxbox ~]$ screen -S pairprog

The user foo, now on Screen, needs to turn on multiuser mode and grant access to his friend, the user named bar.

^A :multiuser on
^A :acladd bar

(^A means ‘control + A’, which is the way commands are passed to Screen)

Now it is time for the user bar to log in to the same Linux box and join foo‘s Screen session.

[bar@linuxbox ~]$ screen -x foo/pairprog

Now both users should see each others’ activities.

Fire up your favorite command line editor, start a voice chat (using Skype or something) and you’re good to go in no time!

Update! It is worth mentioning that the user foo actually shared everything. This might cause security implications, since the guest user (bar) will act as the host user. You can give the host user read-only permission by:

^A :aclchg bar -w "#"

Probably the best way to use Screen for session sharing would be to create a new “public” user and use it as the host for the session. Place all the files under this public users’ directories or other public directories.

Thanks for pointing it out, Pigor!

A keynote do DHH na RailsConf deste ano me causou uma boa impressão. Segundo ele, mesmo havendo muitas mudanças incorporadas ao código do Rails desde que o projeto foi iniciado há 6 anos, no geral não mudou muito.

Das vezes que pude assiti-lo falar, ele sempre deixou bem claro que o Rails “básico” é tudo o que ele realmente usa ou sabe a respeito. Nada supreendente, uma vez que ele escreveu o framework para seu próprio uso e exatamente da maneira como ele precisava que fosse.

Então veio um “core team” e estendeu a ferramenta. Legal. Agora temos pessoas cavando nas profundezas para melhorar sua performance, que será visto na versão 3 do Rails. Excelente!

Sua convenção sobre configuração nunca pretendeu agradar a todos ou servir a todas as situações. O Rails nunca será a bala de prata e eu realmente espero que permaneça desta maneira. Caso você precise mudar alguma coisa no comportamento do Rails, na maioria das vezes esta mudança é tão simples quanto escrever um plugin ou gem. 

Toda a hype em torno de frameworks (do próprio Rails e outros ‘auxiliares’) que vemos hoje é muito mais do que vamos realmente precisar algum dia. O segredo que DHH fala sobre a alta produtividade não é nada relacionado a tecnologia. Mesmo tendo desenvolvido o Rails para aumentar sua produtividade, o seu real segredo é saber renegociar requisitos.

Se você está desenvolvendo software profissionalmente para a indústria e ainda utiliza a maneira hacker, nenhuma plataforma será produtiva o suficiente para você. Caso não haja comunicação envolvida no seu processo de desenvolvimento, você irá certamente falhar ou então gastar muito mais tempo para desenvolver algo que – a princípio – resolva o problema do seu cliente.

Cinco anos se passaram desde que o Rails foi lançado. Tudo o que ele oferece e mais todos os outros zilhões de frameworks de teste e gems são totalmente inúteis, a não ser que você preocupe-se com o que essencialmente precisa ser feito.

Seu cliente pode não saber o que ele quer, mas certamente sabe o que não quer. 

Ele pode chegar para você e pedir algo que levará duas semanas para ser desenvolvido. Como um desenvolvedor profissional, cabe a você começar da onde ele quer e chegar aonde ele precisa. Talvez o resultado seja resolver problema do seu cliente com uma solução completamente diferente da que foi sugerida por ele, mas uma muito mais simples e que levará você muito menos tempo para desenvolver.

Como DHH falou, quando você quiser um chocolate, talvez um Twix que esteja no seu bolso seja tudo o que precise, ao invés de dirigir até o centro da cidade e gastar muito mais dinheiro com uma caixa de chocolates belgas.

Antes de dar início a qualquer projeto, é necessário eleger um responsável pela priorização dos problemas e avaliação das soluções apresentadas pelo time. O Scrum, por exemplo, chama este papel de Product Owner. Independente do nome, esta é a pessoa que irá aprovar ou não o trabalho da equipe ao final de cada iteração.

Ao meu ver, é essencial que exista uma única figura representativa. Dependendo do cenário, esta figura pode ser um grupo de pessoas. O mais importante é que elas sejam capazes de chegar a um consenso e opinar como se fossem uma pessoa só. Quem cobra é quem pede. Já participei de projetos onde Fulano pediu/priorizou no Planning e Ciclano avaliou no Review. Não dá certo.

É preciso deixar claro para todos os envolvidos a razão pela qual o esforço está sendo feito. Um ano de atraso em um projeto não deveria pegar ninguém de surpresa, pois seu atraso na verdade aconteceu um dia de cada vez. A criação de espectativas e um ciclo de entregas obedecendo a prazos curtos são formas de evitar isto. Alguns investem tempo, outros investem tempo e dinheiro. Todos possuem algo em jogo.

Um grande equívoco é ter o problema ofuscado por uma possível solução, como na história do shampoo para o rapaz careca que queria seus cabelos de volta. Ele estava disposto a pagar qualquer preço por isto. Um belo dia encontrou-se com um cientista que aceitou o desafio. O cientista desenvolveu um shampoo que fez com que o rapaz voltasse a ter cabelos.

Passadas duas semanas, o rapaz retornou ao cientista dizendo que ainda não havia arranjado uma namorada, portanto o shampoo que o fez ter cabelos novamente não havia ajudado em nada! Ele sequer parou para pensar no que o impedia de arranjar uma namorada e supôs que seu problema fosse a calvice. Talvez o problema do rapaz fosse a falta de um bom papo ou apenas ausência de carisma (leia-se: ele é feio que dói).

Uma prática bastante interessante é a dos “5 Whys”, utilizada no Sistema Toyota de Produção e que hoje faz parte também de Lean e Kaizen. Segundo esta prática, através de apenas cinco questionamentos seguidos é possível tornar mais claras a raíz do problema e sua solução.

No exemplo do rapaz careca, caso o cientista tivesse procurado entender um pouco mais sobre o real problema de seu cliente, talvez notasse uma dúvida entre um shampoo, uma peruca ou um chapéu. Indo um pouco mais além nas perguntas, descobriria uma certeza quanto a não querer ficar sem namorada. Desenvolvedores experientes são igualmente responsáveis por descobrir junto ao cliente o seu real problema.

Motivação também é peça-chave para o andamento de qualquer projeto. Parte da motivação do desenvolvedor está em implementar a solução para o problema do seu cliente, pois um sistema nunca é igual ao outro e desenvolvedores adoram novos desafios. Outra parte da motivação é, obviamente, uma boa remuneração. Bons profissionais custam caro. Mais caro ainda são os profissionais ruins, pois fazem com que seu cliente gaste com o projeto muito mais do que o necessário e sem a garantia de que seu problema será resolvido . A frase “na verdade, não era bem isso que eu queria” soa familiar ?

Outra característica marcante de bons profissionais é o fato de serem, ao mesmo tempo, especialistas e generalistas. Além de sentirem-se confortáveis dentro de suas especialidades, quando fora delas, sabem aonde (ou a quem) recorrer. A partir de referências sobre algum assunto no qual são generalistas, são capazes de avaliar e trilhar caminhos necessários para suprir suas necessidades.

Não perca seu tempo começando um projeto sem perguntar-se antes se existe a) um bom motivo para investir seu tempo,  b) alguém para prover feedback constante e c) uma noção dos meios através dos quais o resultado pretende ser atingido.