Ele é baseado nos biscoitos da sorte chineses (fortune cookies em inglês),  quando configurado pode mostrar uma mensagem de sua base de consulta ao fazer o login no terminal ou mesmo ao carregar o sistema operacional.

Para rodar o programa, caso ele esteja instalado claro,  basta chamar o comando:

$fortune
Você não precisa ser o melhor. Basta procurar fazer bem aquilo que faz, sem esperar recompensa ou castigo, simplesmente pelo prazer de fazer bem-feito, que se esgota no ato de fazer

--Adib Jatene

No meu caso instalei uma base de língua portuguesa e recebi como mensagem esta acima, minha máquina roda ubuntu e o fortune já estava instalado sendo assim para instalar a base de mensagens brasileira basta usar este comando:

$ sudo aptitude install fortune  fortune-mod fortunes-br

Para usar somente mensagens em português você pode indicar qual será a base de consulta ao chamar o programa.

$ fortune brasil
O trabalho e a perdicao das classes bebedoras.
-- Mike Romanoff

Como trabalho com alguns colegas que estão meio estressados pensei em colocar algumas mensagens estimulantes e divertidas nos servidores da empresa, então fiz uma pesquisa para encontrar o fortune para FreeBSD.

No FreeBSD encontrei o fortune instalado por padrão então bastava procurar por bases motivantes e divertidas

No repositorio  do BSD ( www.freebsd.org/ports/ ) encontrei algumas  como futurama, Bíblia Sagrada encontrei também em outras linguas como Russa e Italiana . Com as bases instaladas agora basta fazer aparecer quando o individuo logar por ssh/terminal criando um script shell

Quando fui editar o arquivo ~/.profile do FreeBSD já existia uma entrada para chamar o fortune.

#Padrão do BSD
[ -x /usr/games/fortune ] && /usr/games/fortune freebsd-tips

Ou de pode ser desta maneira também

if [ -a /usr/games/fortune ]; then
   echo " "
   /usr/games/fortune freebsd-tips
   echo " "
fi

Ótimo agora tenho como chamar o fortune passando como argumento uma base de dados. E você também pode criar sua própria base na comunidade viva o linux tem um post sobre isso explicando a criação e os argumentos que pode ser usados http://www.vivaolinux.com.br/artigo/Configurando-o-Fortune/ além é claro do man page http://linux.die.net/man/6/fortune.

Prontinho tudo instalado e funcionando.
Não posso me despedir sem mandar essa mensagem que recebi do fortune.

$ fortune -m 'win' brasil | less
P. Se o windows 98 fosse concessionária, que carro venderia?
R. BUG, é claro!!!
%
O windows 98 é o maior e mais mal feito vírus conhecido.
%
Se o seu windows não der problema, reclame com a Microsoft!
%
O windows não é ruim, esperem só ele ficar pronto...
%
Como transformar um Pentium em XT? Digite "win".
%
Chernobyl usava windows 95 para monitorar seus reatores.
%

heheheheh não foi eu quem disse nada disso foi os autores da base do fortunes hhehehehheheh

*Fontes

http://linux.die.net/man/6/fortune

http://www.vivaolinux.com.br/artigo/Configurando-o-Fortune/

http://www.freebsd.org/cgi/ports.cgi?query=fortune&stype=all&sektion=all

Os arquivos svn são pastas que contem a assinatura dos arquivos e seus conteúdos, ou seja tudo fica duplicado,  e algumas vezes quando vamos enviar esses arquivos para o servidor de produção não nos atentamos que estamos enviando junto os arquivos svn o que faz a transferencia ficar muito mais lenta pois tem que se enviar muito mais arquivos.

Hoje vejo que isso pode ser contornado de 3 formas diferentes:

Baixando as Atualizações via svn

Nesta modalidade o desenvolvedor envia todos os seus códigos para o servidor de svn “svnserver”,
mas antes verifica se algo entrou em conflito ou se ele próprio precisa fazer alguns updates.

svn status -u /url/pasta/raiz/projeto/

Imaginando que tudo esta correto e que somente ele tem arquivos a serem enviados.

svn commit -m "SEU COMENTÁRIO" /url/do/arquivo/a/ser/commitado/
svn commit -m "SEU COMENTÁRIO" /url/da/pasta//commitada/

Pronto tudo esta pronto e devidamente no seu lugar, agora vamos logar na máquina de produção e fazer o update que foi enviado.

svn update /url/pasta/raiz/projeto/

Neste modo nada se perde no caminho. Fim todo mundo feliz

Mandando pequenas atualizações que ainda não são a versão final do arquivo

Nesta modalidade o desenvolvedor envia todos os seus códigos para o servidor de testes, portanto não importa se vai haver svn ou não. O que importa aqui seria ser um pouco mais rápido.

Ai ele limpa todos os .svn para ficar mais leve o envio.

cp -R /url/pasta/raiz/projeto/ /tmp/projeto
find /tmp/projeto -iname *.svn -exec rm -rf {} \;

Assim foram apagados todos os arquivos .svn da pasta do projeto pois esse foi copiado para o /tmp/projeto
Assim só precisamos enviar os novos arquivos para o servidor TESTE , leia-se TESTE e não “DE TESTE”

scp -r /tmp/projeto/arquivo/ usuario@host:/url/pasta/raiz/projeto/

Os arquivos são enviados e todos quase ficamos felizes, pois essa não é a melhor prática.

Mandando pequenas atualizações que ainda não são a versão final do arquivo por rsync

Esta é a caracteristica do rsync que achei interessante pois não conhecia a syntaxe.
A opção -C do rsync exclui uma penca de arquivos que normalmente eu apagava na mão, e evita que se tenha que copiar para um segundo diretorio todos os arquivos para depois limpa-los.
Sendo assim enviando para o mesmo sever bastaria fazer o seguinte.

rsync -Cavz -e ssh /url/pasta/raiz/projeto/  usuario@host:/url/pasta/raiz/projeto

Todos os arquivos que foram modificados serão enviados e com a vantagem de ser descartados esses tipos de arquivo.

RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS .make.state .nse_depinfo *~ #* .#* ,* _$* *$  *.old  *.bak  *.BAK  *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core .svn/

Como tem alguns desenvolvedores que mesmo sob um sistema de controle de versão (svn) continuam usando o “.old” o rsync também os ignora, isso é simplesmente lindo!

Essas são algumas práticas que tenho observado no twitter e também com companheiros de trabalho.

Acho que essas dicas podem ajudar alguém por isso postei esses detalhes.

E existem também muitas outras maneiras de fazer esse deploy. Invente a sua ….

Seguindo a risca esses principios dificilmente seu projeto vai dar errado

Como os encontro?

Em sua linha de comando (estou assumindo que  você esta em algum Unix e que tenha python instalado) digite:

$ python

Neste momento você estará entrando no shell interativo do python depois é só fazer o import.

 import this

O resultado você visualiza abaixo

Python 2.5.2 (r252:60911, Oct  5 2008, 19:24:49)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Vou colocar também uma livre tradução que encontrei na internet e que cito o autor abaixo.

Bonito é melhor que feio.
Explícito é melhor que implícito.
Simples é melhor que complexo.
Complexo é melhor que complicado.
Plano é melhor que aninhado.
Esparso é melhor que denso.
Legibilidade conta.
Casos especiais não são especiais o bastante para se quebrar as regras.
Embora a simplicidade supere o purismo.
Erros nunca deveriam passar silenciosamente.
A menos que explicitamente silenciados.
Ao encarar a ambiguidade, recuse a tentação de adivinhar.
Deveria haver uma – e preferencialmente apenas uma – maneira óbvia de se fazer isto.
Embora aquela maneira possa não ser óbvia à primeira vista se você não for holandês.
Agora é melhor que nunca.
Embora nunca, seja muitas vezes melhor que pra já.
Se a implementação é difícil de explicar, é uma má idéia.
Se a implementação é fácil de explicar, pode ser uma boa idéia.
Namespaces são uma idéia estupenda – vamos fazer mais deles!

fonte da tradução

Básicamente são boas maneiras para se trabalhar com python.

Algumas coisas que senti falta e que vou acrescer ao texto

Marretas não são bem vindas, mas são necessárias.
O pior código é aquele que não existe, esse não dá dinheiro

Bem acho que é isso que tinha a dizer hoje.

Fui ….

Fontes:

http://www.python.org/dev/peps/pep-0020/

http://pipeless.blogspot.com/2008/09/o-zen-de-python.html