curl -sS -T ${FILE_PATH}/${FILE_NAME} --ftp-pasv \
ftp://${FTP_USER}:${FTP_PWD}@${FTP_URL}/${FILE_NAME}

This example is uploading the file to the ftp server using silent mode (-s) and showing errors when they occur (-S), while connecting to the server in passive mode (–ftp-pasv).

In case you haven’t, it is a Ruby gem that (among other things) automatically runs your tests whenever it notices that a file in you project has changed. It’s a great productivity boost, because it saves you from having to run your tests each time you make a change to your program. The perfect tool if you are doing TDD.

So I wanted to get this autotest functionality going for projects in other languages - like PHP, for example - but apparently ZenTest/Autotest only works within Ruby projects.

Talking to the EnvyLabs’ guys I was told about Watchr, a Ruby gem that monitors files matched by a regular expression and triggers a user defined command whenever a file changes. That’s enough to get you started in an autotest-like tool for PHP - or just about any other language.

I’ve setup an example PHP project of Watchr playing an autotest role in a PHP project:

View on Vimeo.

The source code from this example can be seen at http://github.com/caike/watchr_running_php

1. spork server
2. autospec
3. ./script/server
4. command line stuff (generators and general shell commands)

Setting up the tabs all the time is kind of a boring and repetitive task. This truly deserved some automation and it was the perfect excuse for writing my first AppleScript.

After some googling around I came up with this bash/AppleScript to do these tasks for me (and also open up TextMate):

#!/bin/bash

if [ $# -ne 1 ]; then
    PATHDIR=`pwd`
else
    PATHDIR=$1
fi

/usr/bin/osascript <<EOF
on new_terminal_tab()
	tell application "System Events" to tell process "Terminal" \
        to keystroke "t" using command down
end new_terminal_tab

set actions to {"spork rspec", "autospec", "./script/server"}

tell application "Terminal"
	do script with command "cd $PATHDIR && mate . && clear" \
	in selected tab of the front window
	repeat with action in actions
		my new_terminal_tab()
		do script with command "cd $PATHDIR && " & action \
		in selected tab of the front window
		if action contains "spork" then
			delay 7
		end if
	end repeat
end tell
EOF

If only I had used the right search words I would have found Nick Rutherfor had been through the same situation.

class User < ActiveRecord::Base

  acts_as_authentic

end

That’s it for the user model and its registration field validations (login, email and password).

But what if you have some other model in your application with an email field that you also want to validate ? You could just get your favorite email format regexp and use it with the validates_format_of method:

class Band < ActiveRecord::Base

  validates_presence_of :manager, :description
  validates_format_of :email, :with => /SomeRegexpYouGotFromGoogle/

end

But that would be decentralizing the email validation concern - totally anti-DRY and error-prone.

A better solution would be to use the email regexp that’s in Authlogic, which is the same that’s already validating your user model email field.

class Band < ActiveRecord::Base

  validates_presence_of :manager, :description
  validates_format_of :email, :with => Authlogic::Regex.email

end

That’s it. Hope it helps someone keep their code clean.

Code written once, will be read millions of times. For the most part, it will be read by a compiler who doesn’t really look for anything but correct syntax. Compilers are not into reading stories. They are too busy for that. Just like assembly-line workers, they follow a plan and do exactly what they were told. As soon as they pass things over to the runtime, they are done. On the other hand, we developers are not like that, are we ? No, we are not!

We are software craftsmen. We like to read stories and even get paid to write some every once in a while.

http://www.flickr.com/photos/dhammza/91435718/

Think about it the next time you hack that magic one-liner in an application. Do you think you will be able to read that code-golf champion piece of code the next time you look at it ? What if it is not you, but someone else reading it ?

“Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live (…) Alternatively, always code and comment in such a way that if someone a few notches junior picks up the code, they will take pleasure in reading and learning from it.” - Ward Cunningham, CodeForTheMaintainer

An example I like to use for expressive code is method parameters in Ruby. Let’s say you want to stay fit and write a method to calculate a body fat percentage. You write the following:

def body_fat_percentage(name, age, height, weight, metric_system)
end

Apparently it looks nice. Let’s see how it could be invoked:

# fred's height in meters and weight in kilograms
body_fat_percentage("fred", 30, 1.82, 90, 1)

# barney's height in feet and weight in pounds
body_fat_percentage("barney", 32, 5, 300, 2)

In order to write those two calls you would probably have to check the right order for the parameters in the method’s signature. Even worse, every time you read that line you would have to check back its signature just to make sure that the last argument determines the metric system or that the third argument is actually the height and not the weight.

That sounds like a pretty boring story to read!

Let’s make this piece of code more expressive:

# fred's height in meters and weight in kilograms
body_fat_percentage("fred", :age => 30, :height => 1.82,
  :weight => 90, :metric_system => MetricSystem::METERS_KG)

# barney's height in feet and weight in pounds
body_fat_percentage("barney", :age => 32, :height => 5,
:weight => 300, :metric_system => MetricSystem::FEET_LB)

All we need to do to the method signature is to replace the standalone arguments for a hash.

def body_fat_percentage(name, params={})
end

From the method body, the values can be accessed using the keys, like params[:age], params[:height], etc.

In a real life situation, this expressiveness would be achieved from writing our expectations as unit tests. We would first write our failing tests as how we wanted our code to look and act like. From that, we would head towards making the tests pass. When all is green, the tests would turn out to be the reference for how to call the method (running and never-obsolete documentation) so there’s no need to go back to the implementation of the method itself to learn how to to use it.

Writing expressive code often means writing more code, but it also means writing better code. It’s not about making things work, it’s about making things right.

“Certo dia, um rapaz que caminhava pelo bosque avistou um lenhador tentando derrubar uma árvore. Observou-o por alguns instantes e notou que, mesmo investindo cada vez mais força em suas machadadas, não estava obtendo muito sucesso em derrubar a árvore.

Então o rapaz sugeriu ao lenhador:

- ‘Por que você não descansa um pouco e, enquanto isso, aproveita para amolar o seu machado ?’

O lenhador respondeu:

- ‘Não posso perder tempo! Tenho que derrubar logo esta árvore!’”

Desenvolvimento de software é um processo contínuo de aprendizagem. Diariamente nos deparamos com árvores a serem derrubadas. No caso das mais difíceis, pense em parar e refletir sobre o que está fazendo enquanto amola seu machado ao invés de ficar repetindo incessantemente a mesma coisa, esperando resultados diferentes (a definição de estupidez, segundo Einstein).

http://www.flickr.com/photos/shedboy/3610432084/

Você reserva algum momento de sua semana para a leitura de blogs de referência da sua comunidade ?

Participa de alguma comunidade ?

Participa de pelo menos uma grande conferência por ano ?

Está lendo algum livro técnico ?

Estar atualizado é responsabilidade de qualquer profissional de tecnologia.

Dev in Rio 2009 !

Texto copiado do blog do Henrique:

Finalmente o Rio de Janeiro ganhou um grande evento de tecnologia focado no que é mais importante: Pessoas!

É com muito orgulho que apresentamos o Dev in Rio 2009, uma conferência bombástica sobre desenvolvimento de software que acontecerá no próximo dia 14 de setembro no Centro de Convenções SulAmérica, no Rio de Janeiro!

O Dev in Rio 2009, contará com palestrantes nacionais e internacionais que falarão sobre Java, Ruby e Ruby on Rails, Python, Django, Open Source, Joomla!, Métodos Ágeis, e muito mais. Nomes como Fábio Akita, Vinícius Manhães Teles, Jacob Kaplan-Moss, Guilherme Silveira, Nico Steppat, Ryan Ozimek e Jeff Patton agitarão um dia inteiro de muita tecnologia e diversão. Veja a programação detalhada no site da Dev in Rio 2009.

Mas não é só isso. Como eu disse no início, este é um evento focado em pessoas. Toda a organização do evento está voltada para promover ao máximo a interação e integração entre os presentes.

Por isso, o Dev in Rio 2009 contará com uma Arena DojoRio onde participantes e palestrantes poderão programar lado à lado, experimentando diversas linguagens e técnicas, buscando juntos as melhores formas de desenvolver software.

O evento está sendo organizado por mim (Henrique Bastos) em parceria com o meu amigo Guilherme Chapiewski, contando com todo o apoio dos membros da PythOnRio, DojoRio e #Horaextra.

A realização está sendo coordenada pelas nossas experientes amigas da Arteccom. E tê-las ao nosso lado já garante que este será um evento para marcar o circuito carioca.

Você não pode perder esta incrível oportunidade de participar desse mega evento, interagir com grandes nomes do cenário mundial de tecnologia, conhecer pessoas interessantes que compartilham a paixão pelo desenvolvimento de software, e ainda por cima começar sua semana só na terça-feira. Inscreva-se já!

Nos vemos por lá!

[]’s!

Em se tratando deste grupo de feras na organização e nas palestras - e finalizando com um super-sized #HoraExtra deluxe edition - com certeza este será um daqueles eventos memoráveis dos quais vocês não podem deixar de ir!

Ao todo, nove pessoas estavam presentes. Paulo Igor, Marcos Venicius, Aldrin Leal, Gustavo Pinto, Igo Medeiros, Mateus Miranda, Danilo Cunha, Rafael Santana e eu nos reunimos as 16 horas (horário mais conhecido como “depois da chuva”) no campus José Malcher, sala 4F, munidos apenas de um pc e um retro-projetor.

Enquanto aguardávamos o resto do pessoal chegar, Paulo Igor, Aldrin Leal e eu conversamos sobre Ruby, Python, FISL e sobre o Project Zero, um projeto ao qual o Aldrin pertence.

Após uma pequena apresentação do que é o Coding Dojo, sugeri alguns problemas que poderíamos resolver. A maioria optou pelo problema do jogador de futebol, que já havia sido resolvido em Ruby no último Dojo Rio mas que desta vez seria resolvido utilizando Java.

O problema mostrou-se mais uma vez de fácil compreensão e não precisamos de muito tempo para a definição das estórias. Gosto do formato de user stories para fechar o escopo de problemas como este (e como o wowspec) para um Coding Dojo, uma vez que são idéias muito gerais e com possibilidades  de implementação quase que infinitas.

A utilização do Netbeans como IDE não foi uma boa escolha. Com apenas duas classes, o Netbeans foi capaz de se perder e exibir testes falhando mesmo quando corretos. A solução foi dar ‘clean’ no projeto de tempos em tempos.

Após 40 minutos de codificação, conseguimos completar as quatro estórias criadas mas não tivemos tempo para refatorar nosso código. Como o objetivo do Coding Dojo não é completar os problemas, mas exercitar ao máximo as técnicas de programação e comunicação durante o time-box estabelecido, paramos de trabalhar no código e passamos para a retrospectiva.

Realizamos nossa retrospectiva e trocamos muitas idéias sobre, claro, metodologias e práticas ágeis e também sobre a situação do mercado de desenvolvimento de software em Belém, que carece de profissionais que pensem ‘out-of-the-box’.

Obrigado ao CESUPA pela disponibilidade da sala e equipamentos e também aos que estiveram por lá e participaram do Dojo. Espero que tenham gostado e que possam levar a prática do Coding Dojo a diante!

Minhas impressões do evento foram as melhores possíveis. Excelentes palestras aconteceram durante os quatro dias de conferência mas assisti a pouquíssimas. Passei a maior parte do tempo revendo amigos, conhecendo novas pessoas e conversando com mentes brilhantes que passaram por lá.

Com a proposta de tentarmos mostrar o “espírito” do FISL para os que não puderam estar presentes, o Henrique Bastos e eu relatamos os acontecimentos em forma de podcasts. Todos encontram-se disponíveis no site da PythOnRio (primeiro dia - parte I, primeiro dia - parte II, segundo dia, terceiro dia, quarto dia).

Junto a PythOnRio e Python Brasil, tive a honra de poder contribuir com a comunidade ao colocar em prática um plano para entregar uma camiseta da PythOnRio ao presidente Lula e contar a ele sobre a iniciativa PythOnCampus.

A Python Brasil realizou duas sessões de palestras relâmpago. Ao assistir a primeira sessão, achei o formato tão legal que preparei ali mesmo uma apresentação rápida para a segunda sessão. Em apenas cinco minutos falei sobre técnicas para melhorar sua orientação a objetos - PyListhenics. As palestras podem ser vistas no site da PythOnRio.

Ainda exausto e meio gripado por conta do frio em Porto Alegre, gravamos o último podcast quase que de saída para o #horaextra da primeira segunda-feira pós-FISL - que bateu o record!

Esta última semana pode ser resumida com o título da apresentação do Henrique Bastos nas palestras relâmpago: pequenos atos fazem grandes revoluções. Assista a palestra e saiba a razão.

Iniciam-se já os preparativos para o FISL 11!