C seria Judaismo: É antiga e restritiva, mas a maior parte do mundo está familiarizada com suas leis e as respeita. A pegadinha é que você não pode se converter para ela – ou está lá desde o início ou vai pensar que é insanidade pura. Além disso, quando as coisas dão errado, muitas pessoas estão dispostas a colocar nela todos os problema do mundo.

O texto completo, em inglês, aqui.

Pior ainda quando você precisa que alguém com menos experiência ou conhecimento (aka suporte nível 1) verifique para você o estado do servidor.

A idéia é então centralizar essa checagem num único script, simples e funcional, para facilitar a sua vida e a dos outros admins.

Tenho certeza que já existem por ai trocentos scripts/programas/whatever para fazer isso, mas eu estava entediado e precisava usar um pouco de Perl para não enferrujar completamente (É… ando usando só Python e Bash).

O script está disponível aqui e está bem documentado e é de simples entendimento.

Basta criar um arquivo /etc/checks.txt contendo o que você esperaria ver rodando normalmente e está feito.

Segue a versão primo-pobre para bash:

function die () { echo "$progname: $1"; exit ${2:-1}  ; }

Exemplos de uso:

[ ! -f /tmp/teste.txt ] && die "Arquivo não existe"

ou

[ "$A" -ne 0 ] && die "Nao encontrei o zero" 99

Estou indo trabalhar para uma universidade.

Meu atual emprego até que foi interessante até um determinado ponto. Aprendi muito e vi como é infra-estrutura de IT de gente grande. E aprendi como é que se implementa Linux no que se chama “enterprise class” e entendi porque wall-street ama open source.

Também me mandaram pra Nova York e me deram curso de Perl. E só de birra, resolvi aprender Python. Além de que a famosa frase “a prática leva à perfeição” se mostrou real com o tanto que tive que colocar minha experiência com Bash pra funcionar.

Porém, como é obvio pelo fato eu estar mudando de emprego, resolvi que era hora de juntar minhas tralhas e mudar de emprego. Basicamente dois motivos me levaram a isso.

Primeiramente eu sou workaholic, viciado em desafios e fico entediado muito, muito fácil. Ai meu emprego basicamente era das 09:00 às 17:00hrs, sem on-call. O foco do meu time era “resolução pró-ativa de problemas”. Ou seja: análise de logs e resolução de problemas secundários que (ainda) não afetaram a produção.

A coisa funcionava mais ou menos assim: Tudo que era trampo CHATO ou repetitivo, o time de unix do cliente passava pra gente. E todo mundo sabe que trampos chatos e repetitivos tem apenas um destino: script. Então mesmo as mais complexas auditorias podiam ser quebradas em pequenas partes que podiam virar um ou dois pequenos scripts para facilitar a vida. Ai cada um destes pequenos scripts vira uma função de um script maior que chama essas funções baseadas em um padrão… E ai você usar regex pra fazer uma análise de padrões… you know the drill. Depois de um tempo tudo o que eu fazia ao chegar no serviço era abrir 3 ou 4 consoles no screen e rodar meus scripts. E dá-lhe Slashdot e BR-Linux o dia inteiro.

Como a infra-estrutura lá é show e o grupo de engenharia pertence ao cliente (e não à empresa de outsource que eu trabalhava), eu nunca ia chegar na parte divertida do trabalho.

Resumindo, a explicação é o seguinte: Eu gosto de problema. Quero mais é pegar um ambiente todo podre e detonado e fazer ele ficar bonitão, com uptime de 99,99%.

O segundo motivo é banal: dinheiro. Mim querer mais. E os funcionários mais antigos da empresa me contaram que ninguém tem aumento há três anos. Como a maioria das empresas não são sindicalizadas (e lá não é), não rola nem aquele aumento apenas para cobrir a inflação. Nada. Zip. Zero. Em três anos. Dá licença, né? Deixa eu vazar logo dessa furada.

Por enquanto não sei exatamente o que vou fazer, apenas que vou atuar com servidores Linux, Solaris e AIX. Mas assim que começar lá no dia 23 deste mês, coloco um post aqui.

Fico devendo, se possível para este final de semana, um resumo das técnicas que utilizei para escrever a carta de apresentação e para mandar bem na entrevista.

Então minha volta pra universidade não é exatamente o que meus pais gostariam que fosse, mas espero que quebre o galho.

Não posso deixar de citar também que tenho uma experiência considerável com bash script e que esta era oficialmente a única “linguagem de programação” que conhecia até os eventos anteriormente citados.

Nem me arrisco a dizer que conheço bem Perl ou sequer um pouco de Python, então por favor entendam minha opinião apenas como isso: Minha opinião.

Cheguei a conclusão de que se você precisa interagir com o sistema operacional com freqüência – o que é o caso em 95% dos scripts que eu faço – Bash e Perl me parecem as melhores opções.

Exemplo pra deixar claro, um script que salve o nome do host numa variável e depois mostre essa variável:

BASH:

#!/bin/bash
echo $HOSTNAME

Pois é… o Bash já deve ter esta variável por default…

PERL:

#!/usr/bin/env perl
$hostname = `hostname`;
chomp($hostname);
print "$hostname\n";

Não muito ruim também, mas ODEIO ter que colocar newline no final.

PYTHON:

#!/usr/bin/env python
import socket
host = socket.gethostname()
print host

Pô… precisa importar coisa..?

Os exemplos acima podem não ser os melhores e alguém mais safo nestas linguagens podem ter idéias melhores, mas acredito que deu pra ilustrar.

Em compensação scripts que fazem outras coisas me parecem bem mais simples em Python. Principalmente se preciso olhar o código de outra pessoa como exemplo.

Estes dias queria ver como se gerava RSS em Python e usei como referência um código feito por alguém do Debian. O código não tinha nem uma linha de comentário pra facilitar a vida, mas Python deixa a coisa tão limpa e clara que não tive a menor dificuldade de entender o que estava sendo feito e usar o código.

Então a ordem do dia agora será: Perl o tempo todo no serviço. Primeiro para me forçar a usar Perl, senão eu acho mais simples em Bash e nunca vou colocar a mão na massa. E segundo porquê lá é basicamente um “Perl Shop” mesmo e os dois caras à minha direita e os dois à minha esquerda manjam um bocado de Perl. Então não vai ser difícil achar ajuda.

Mas em casa, no Just-for-Fun vou continuar brincando com Python.

foreach $n (0..9999) {foreach ("AAA".."ZZZ") {printf "%s-%04d\n", $_, $n;}}

A sua pergunta no momento deve ser: “Que m* é essa??”.

Pois é. Este é o “problema” do Perl, na minha opinião. Qualquer mané (aka /me) com 2 dias de curso consegue fazer um código, que funciona, mas não faz o menor sentido pros demais habitantes do planeta.

Vamos refazer este código igual gente:

@numeros=(0..9999); # Numeros de 0 a 9999
@letras=("AAA".."ZZZ"); # Letras de AAA a ZZZ

$mostra_letras='%s'; # Lugar onde serao colocadas as letras
$mascara='%04d'; # Preenche os numeros menores que 1000 com zeros na esquerda

foreach $numero (@numeros) {
foreach $letra (@letras) {
printf "$mostra_letras-$mascara\n", $letra, $numero;
}
}

Voilá. Agora está limpo, legível e qualquer um que resolver gastar alguns segundos olhando pra ele sabe exatamente o que este script faz. Mesmo sem conhecer Perl.

Agora, se os dois tem exatamente o mesmo resultado, porquê raios alguém vai preferir fazer o primeiro? Um script assim é igual filho.

Eu fico puto da vida quando preciso dar manutenção em um script Perl (eu já fazia isso antes de começar a estudar Perl) e me deparo com um treco igual o do começo.

A vontade é de virar pro desenvolvedor e falar: Amigão, qual o seu problema? Você quer provar que você é melhor que os outros ou coisa assim?

Meus scripts bash são tão extensamente documentados que não raramente tem o dobro de documentação do que linha de código. Tudo bem espaçado, identado e o caramba. Ninguém tem obrigação de saber o que estava na minha cabeça na hora que fiz o script. E pior: Não quero ninguém me enxendo o saco quando precisar dar manutenção nele. Quero que o nego abra, entenda, modifique e suba pro CVS. Mais nada.

Mas o post é só pra dizer que não tenho raiva do Perl, mas dos programadores que se acham.

Entra dia, sai dia e finalmente, neste final de semana, fiz meu primeiro script Python completo e com utilidade. Digo isso porquê “Hello World” e tradução de script que eu já tinha em Bash pra Python não conta.

Apanhei um bocado, principalmente em sintaxe de comando. Eu ficava imaginando coisas mirabolantes para só depois descobrir como as coisas são mais simples em Python. Sensacional.

Peguei também na biblioteca o livro “Learning Python” e passei a ter uma referência mais rápida de consultar que o Google.

Mas entre o post que falei que ia aprender Python e hoje a empresa apareceu com um curso de Perl na manga!

Vão ser 4 dias, full time com um professor que veio do Texas especialmente pra esta turma, que é composta só de funcionários que atendem a conta que eu atendo.

O livro-base do curso é “Perl by Example” e tem uma abordagem interessante. A autora fala meia dúzia de palavras sobre o tópico e depois senta o dedo em trocentos exemplos de uso.

Pessoalmente acho que seria horrível ter este livro como única fonte de informação, mas com o instrutor junto fica bacana, já que ele explica mais a fundo e depois entra nos exemplos fazendo com que eles sejam entendidos e não apenas lidos.

Mas com certeza depois de assimilado o conteúdo do curso vai ser uma ótima fonte de referência.

No momento só não consigo decidir se continuo estudando Python ou se as duas ao mesmo tempo vai ser demais pra massa cinzenta.

UPDATE: Para os non-tech que freqüentam o blog, claramente meu pai e minha esposa até o momento, o título “camelando” é uma referência ao Camelo (na verdade dromedário) que estampa o famoso livro “Programming Perl“, conforme conta a história.
Eu não estou camelando de verdade…

.

Quer dizer, eu me viro muito bem com shell script e fiz/faço muita coisa nervosa com Bash.  Inclusive já tirei muito barato de nego que trabalhou comigo porquê enquanto eles abriam o Eclipse (ou outro IDE que o valha) para criar um programa pontual, eu já estava rodando o dito cujo em shell.

Mas tem coisas que simplesmente forçam muito a amizade do Bash e o bichinho não tem features para resolver o problema.

Some isso ao fato de que na empresa Perl é largamente utilizado, diversas APIs desenvolvidas in-house estarem disponíveis e também o fato de que 4 dos 6 membros do meu time conhecerem Perl e você chega na mesma conclusão que eu: Melhor aprender Python.

Já comecei a brincar e hoje resolvi um problema imenso que eu tinha num dos meus scripts de auditoria.

O dito é feito em Bash, mas em um determinado momento ele precisa acessar alguns dispositivos via telnet e interagir com eles.

Usei uma gambiarra MUITO MUITO feia, com telnets encadeados com pipes, sleeps e echos de dar até medo.

Uma possível solução seria usar o expect, mas como eu pude verificar ele não é nada amigável e foi confirmado por diversas pessoas que é bem bugado e não digno de confiança.

Hoje substitui a parte feia do script por uma chamada a um script Python que passei o dia desenvolvendo e o resultado foi sensacional.

Certo que perdi boa parte do dia no Google, procurando exemplos de sintaxe, módulos, etc, etc. Mas isso é normal até “pegar a mão” da linguagem.

Aliás, fica aqui um pedido de ajuda: Alguém sabe um lugar onde eu possa achar uma lista extensiva de todos os módulos pro Python? Tipo o CPAN (putz… dei na cara agora, hein?)