Eu sei que estou atrasado, eu sei que isso já deveria estar pronto há anos, e é deprimente perceber quanto tempo passou sem eu ter feito um livro novo. O Shell Script Profissional é de abril de 2008! Mas é assim que funciona, durante estes anos não deu o tesão de escrever, e sem tesão não tem ação, é um loop infinito de escreve-apaga-escreve-apaga e nunca sai do lugar.

Felizmente a abstinência terminou e agora estou aqui, empolgadíssimo para ficar semanas (meses?) enclausurado, escrevendo um livrinho novo. A escolha do tema favoreceu muito a volta da inspiração, pois o sed é meu comando Unix preferido e posso ficar horas falando sem parar sobre ele :)

O sed é uma ferramenta que, após uma década, continuo usando quase que diariamente. Sempre tem algum texto pra limpar, pra reformatar, pra apagar algum pedaço e quando vejo lá estou eu na tela preta digitando algum comando sed. Esse é um filme mais repetido que Curtindo a Vida Adoidado na Sessão da Tarde :)

Uso o sed porque é útil e porque eu gosto. Ele é um bichinho estranho, que parece alienígena, mas esconde uma simplicidade bela, que só quem o conhece bem sabe admirar (tipo o Vim). E quando combinado com expressões regulares, mostra seu verdadeiro poder e faz mágicas.

Já cheguei ao cúmulo de fazer joguinho com sed, mas hoje sou mais moderado :)

O sed foi importante desde o ínicio de minha carreira: foi a primeira ferramenta do Unix que aprendi a dominar, quando ainda era estagiário. Ser o “guru do sed” dentro da empresa (Conectiva) significou muito para mim na época. Foi por causa do sed que tive que aprender expressões regulares, as Funções ZZ usam sed no lugar de outras ferramentas para garantir compatibilidade entre sistemas e o txt2tags só existe porque um dia eu quis escrever um sed-HOWTO em SGML. Mais detalhes sobre essas histórias no post 10 anos: Sed.

$ ls -1 zz* | wc -l             # Nas 125 funções ZZ...
     125
$ grep -w sed zz* | wc -l       # ...o sed é usado 331 vezes!
     311

Enfim, o sed estava lá desde o começo, participou das minhas criações mais importantes e continua firme e forte na minha rotina. Fazendo esse retrospecto, fica claro que é minha obrigação moral retribuir e fazer esta homenagem à ferramenta, fechando a trinca de livros: Shell + Sed + Expressões Regulares.

• Eu sei que sed é um assunto de nicho.
• Eu sei que o público é restrito.
• Eu sei que vai vender pouco.

Mas tudo bem, quero fazer este livro de qualquer jeito. Não quero morrer com este conhecimento guardado na cabeça. Quero poder “mostrar a luz” do sed para outros nerds.

Já fiz vários documentos sobre o sed, inclusive um livro inacabado, mas falta a obra definitiva: um texto completo, coeso, que parte do zero e ensina como funciona e como usar. E claro, o mais importante: o texto tem que ser leve e divertido, como uma conversa entre amigos. Detesto livros técnicos chatões.

O trabalho começou ontem, mas a escrita de verdade ainda leva um tempo. Esta fase inicial é de ambientação e planejamento. Estou definindo a forma do livro e sua didática: que assuntos vai ter, em que ordem, como será a narrativa, os exemplos, qual será o nível técnico, o público-alvo, essas coisas. Preciso primeiro “enxergar” o livro todo, do início ao fim, e quando essa massa imaginária de ideias toma forma e fica consistente, formando um ensinamento coeso de complexidade crescente, então estarei pronto para começar a escrever. Considero esta parte inicial a mais importante e difícil. Escrever o texto é a parte fácil.

Então, agora, mais do que em qualquer outra parte o processo, é a hora certa para você ajudar. Como a forma final ainda não foi definida, esta é a fase em que estou mais influenciável :) Por favor, use a caixa de comentários para dar sua opinião e suas ideias:

• O que você gostaria de aprender sobre o sed?
• Quais suas dificuldades?
• Quais tarefas você gostaria de usar o sed mas não sabe como?
• O que te impede de aproveitar melhor o sed?
• Como é seu uso atual do sed? Usa para quais tarefas?
• Fora o s///, usa outros comandos?
• Em qual sistema você usa(ria) o sed: Linux, Mac, Windows, Unix, outro?

Tá, é bizarro, eu sei :)

Nos artigos anteriores do blog, falei sobre os equipamentos da Apple e várias vezes precisei citar os três brinquedos pretos: iPod, iPad e iPhone. Ao escrever estes nomes, um alerta apita aqui dentro: Epa! Repetição e variação detectados!

There’s a regex for that :)

Compor uma expressão regular que case os três nomes não é difícil. Uma primeira alternativa, mais simplista, seria usar o metacaractere ou para fazer a lista de palavras permitidas:

iPod|iPad|iPhone

A barra vertical indica que esta expressão casa iPod ou iPad ou iPhone. Simples, não? Fácil de ler e entender. Mas podemos tornar esta expressão menor e mais eficiente.

O segredo para fazer uma boa expressão é saber identificar padrões. Ao olhar com atenção para estas três palavras, percebemos que todas possuem o mesmo prefixo, ou seja, todas iniciam com as letras “iP”:

• iPod
• iPad
• iPhone

Assim, podemos tornar nossa expressão mais eficiente deixando claro que o padrão começa com “iP”, e depois disso, há três alternativas:

iP(od|ad|hone)

Essa nova expressão continua casando as três palavras, mas agora ficou menor e mais rápida. Porém, agora ela ficou mais difícil para ler e entender. Trocamos legibilidade por eficiência.

Aplicando mais uma vez a mesma técnica de identificar padrões e melhorar a expressão, podemos perceber que tanto iPod quanto iPad terminam com a letra “d”. Podemos isolar esta letra, trocando o trecho od|ad por [oa]d:

iP([oa]d|hone)

Continuamos casando as mesmas palavras, porém agora a legibilidade foi pelo ralo. É preciso interpretar a expressão mentalmente para saber quais são as palavras que ela casa. Será que fomos longe demais?

Você sempre deve avaliar se esse tipo de melhoria é mesmo uma vantagem.

• Era necessário otimizar a expressão?
• A expressão anterior estava lenta?
• Todos que darão manutenção nesta expressão saberão entendê-la?
• O que é mais importante: velocidade ou legibilidade?

Acostume-se a sempre fazer estas perguntas a si mesm[ao] cada vez que for melhorar alguma expressão regular. Você pode se surpreender com as respostas :)

Às vezes, é possível encontrar um meio termo que não prejudica tanto a legibilidade, mas resulta em um ganho na performance.

i(Pod|Pad|Phone)

Nesta expressão, isolei somente a letra “i”, que é um prefixo muito conhecido para os produtos da Apple. Deixei o “P” repetindo em todas as alternativas para não quebrar as palavras. Assim fica clara a separação entre o prefixo “i” e o nome dos produtos: Pod, Pad e Phone.

i(Phone|Pod|Pad)

Como última melhoria, movi o trecho “Phone” para o início das possibilidades, para deixar mais claro que esta é uma lista de palavras com produtos da Apple. As alternativas Pod e Pad são muito parecidas e podem gerar confusão. Deixando o “Phone” no início, ali bem pertinho do “i”, fica mais fácil do leitor enxergar “iPhone” e deduzir o iPod e iPad com mais facilidade.

Agora, comparemos as duas expressões:

iP([oa]d|hone)

i(Phone|Pod|Pad)

A primeira seguiu somente o caminho da eficiência, enquanto a segunda fez um balanço entre eficiência e legibilidade.

Nos meus primeiros anos de expressões regulares, eu faria sempre a primeira, pois é a menor e mais eficiente. Hoje, depois de já ter sofrido muito dando manutenção para minhas próprias expressões enigmáticas do passado, valorizo mais uma expressão legível, melhorando a velocidade somente quando estritamente necessário.

Quem já usa as Funções ZZ há tempos, sabe que seu código era afetado por essa mentalidade do “menor é melhor”. Ainda bem que evoluí :)

Aprenda mais sobre os tópicos deste texto:

• http://guia-er.sourceforge.net/ou.html
• http://guia-er.sourceforge.net/grupo.html
• http://guia-er.sourceforge.net/lista.html
• http://guia-er.sourceforge.net/nao-complique.html

Funções ZZ é uma coletânea com mais de 100 miniaplicativos de utilidades diversas, prontos para serem usados na linha de comando do Linux, BSD, Mac e Cygwin. Software livre 100% nacional e maduro, que já completou 10 anos de existência.

Neste finalzinho de 2010 foi lançada a versão de Natal das Funções ZZ, com a impressionante marca de 37 miniaplicativos novos. É um trenó cheio de presentes para os usuários do shell, com novidades para todos os gostos:

• Vai encurtar uma URL no migre.me? zzminiurl.
• Não sabe o que pedir no Subway? zzsubway.
• O que vai passar na TV nas próximas horas? zzglobo.
• Quer o Google Tradutor ao alcance de um Enter na shell? zztradutor.
• Cálculos complicados com porcentagens? zzporcento.
• Que tal uma piada? zzpiada.
• E aquela sua encomenda do DX que não chega nunca? zzrastreamento.

Tudo muito prático, basta digitar o comando e ver o resultado. Sem perda de tempo com navegadores, janelas, botões… Por falar em praticidade, saiba que o programa todo está em um único arquivo de texto, é só baixar e usar: http://funcoeszz.net/funcoeszz.

Saiba mais sobre as funções no site http://funcoeszz.net.
Divirta-se!

Após um longo período intocado, o site www.COISINHA.com.br ganhou uma atualização merecida.

O quê, você nem se lembra mais que site é esse? Tá, eu refresco tua memória: é a casa do MiGuXeiToR, do Engripeitor e do Embriagueitor. Refrescou? :)

Eu fiz esse site para abrigar alguns brinquedos que eu faço em JavaScript (e poder ganhar uns trocos com o AdSense, claro). Mas como apareceram outras coisinhas mais importantes para fazer neste meio de tempo, sabe como é…

Mas tá, lamentações à parte, o que importa é que temos três brinquedos novos* no parquinho.

* Seminovos na verdade, pois eu fiz todos eles em 2007/2008 e os coitadinhos ficaram na fila esperando a sua vez de serem apresentados ao mundo :)

SUBWAYTOR

Esse os leitores antigos do blog já conhecem! Quer dizer, pelo menos a versão inicial dele.

Lembra daquele texto que contei que fui com a Mog no Subway, e de como é complicado escolher seu sanduíche? Com o bate-papo nos comentários surgiu a ideia de fazer um programinha que montasse o sanduíche automaticamente, escolhendo os ingredientes ao acaso. Surgiu então a zzsubway.

A evolução do programa é o Subwaytor, que também mostra fotinhos de sanduíches apetitosos :)

Além disso o programa possui uma inteligência artificial avançada, que com o mero contato de seu dedo na tela do computador, consegue analisar suas características biológicas e escolhe a melhor combinação de ingredientes para manter a sua saúde em dia.

Mais informações lá no site do Subwaytor. Ah, e leia o rodapé ;)

TABUADA

Uma tabelinha interativa que mostra a tabuada dos números de 1 a 10.

Não consigo me lembrar porque fiz esse programa, se foi uma ideia que tive ao acordar (dessas ideias tolas que na hora do almoço já foram embora) ou eu estava testando alguma coisa com CSS+JavaScript.

O fato é que eu achei legal destacar linhas e colunas com o movimento do mouse, então a tabuada veio de lambuja :)

De qualquer forma, talvez possa servir para crianças como uma alternativa aos livros chatos. Talvez não. Sei lá. Enfim. Se você achar um uso pra isso me avise :)

RELÓGIO

Esse eu fiz em novembro de 2007 (!!), o coitado ficou mais de um ano esquecido na geladeira. Mas é meu brinquedo preferido.

A ideia não é minha, eu lembro de ter visto algo parecido em algum blog ou site ou… Nunca vou saber. (o Diogo achou, era um screensaver joiado!) Mas como todo bom programador, ao ver o brinquedo a primeira coisa que pensei foi: como eu faço um desses? :)

O mais complicado foi aprender como definir um timer em JavaScript (obrigado Google), pois o código mesmo acabou saindo em poucos minutos. Nada de mais: colocar e apagar classes nas palavras, cores no CSS e tá feito. Veja o fonte da página se ficou curioso(a).

Mas é incrível como essas coisinhas (taí o porquê do nome do site!) são prazerosas de fazer. É um desafio que aparece do nada no seu dia, cai no seu colo e você simplesmente não consegue dizer não. Parei tudo o que estava fazendo para poder programar o brinquedinho. Isso é tãaaaao legal :)

Veja lá o resultado: relógio com palavras.

Eu gostei, achei bonito e chique.
E nerd, claro :)

Bem era isso.

Aceito sugestões de melhorias, e de coisinhas novas também!

O texto anterior feito pela Mog gerou uma avalanche de comentários! E legal que são vários assuntos acontecendo ao mesmo tempo, graças à novidade de poder responder a um comentário específico (basta clicar em “Responder”, ao lado da data). Como a resposta aparece logo após o comentário e não lá no final, fica fácil de acompanhar o bate-papo. Quer participar também? Vai lá agora e também assine o feed de comentários!

O que mais gostei foi da sinceridade e conteúdo de muitos dos comentários. Tomei um puxão de orelha (aliás, vários) que estava precisando, afinal, o blog acabou ficando meio de lado nos últimos meses.

Mas em vez de desculpas e lamentações, prefiro acatar a vontade popular e… escrever. Você pediu, agora aguenta! :)

Então, vamos falar de nerdices. Hoje lancei uma versão nova do programinha AdiumBook, que serve para organizar seus contatos no Mac. Mas esqueça o programa, ele não é importante agora. O que quero é falar sobre desenvolvimento de software. Olha só:

Clique na foto para aumentar

Dica: Faz o seguinte, abra essa imagem em uma nova janela e deixe à vista, pois todo o texto falará sobre ela. Assim vai ficar mais fácil de entender.

Agora vem uns quatro parágrafos bem chatos, mas aguente firme que é necessário para acompanhar o resto do texto. Eu prometo que depois melhora, tá?

Esta é uma foto do programa Billable, que uso para contabilizar as horas que gasto em cada tarefa durante o trabalho. Ele tem um relojinho que eu disparo quando começo e depois paro no final. No lado esquerdo estão os projetos e na tabelinha estão as tarefas. As linhas em azul estão selecionadas. Então o que estamos vendo são as tarefas do projeto AdiumBook.

Dentro da tabela, selecionei apenas as tarefas mais recentes deste projeto, que mostram todo o trabalho feito nesta versão nova lançada hoje.

Aquele total em reais no canto direito da tabela indica o valor de cada tarefa. Mas eu coloquei o valor/hora como R$ 1,00 para ficar fácil ver a quantidade de horas de cada tarefa. Então um valor de R$ 2,50 na verdade indica que a tarefa demorou duas horas e meia para ficar pronta.

Eu também sempre arredondo o tempo de cada tarefa, usando intervalos de no mínimo 15 minutos. Assim fica melhor de ter uma visão geral das coisas, valores muito picadinhos apenas confundem.

Bem, mas então tá. Agora você já sabe achar as informações ali :)

Eu gosto de sempre analisar os dados sobre as coisas que faço, para avaliar se tudo correu bem e para poder tomar decisões para o futuro. Dessa vez quero fazer a análise junto com vocês, para mostrar um pouco como é essa rotina de ser programador e lançar programas.

Primeiro vamos às datas. A versão anterior do AdiumBook (1.4) foi lançada em 29 de julho de 2008. Tá lá, na primeira linha da tabela, que não está selecionada. Esse lançamento tomou quase oito horas para ficar pronto! Vejamos quais tarefas foram feitas neste dia:

• Testes no iBook (Tiger)
• Atualização SVN
• DMG feito
• site atualizado
• anúncio nos sites (Xtras, Apple, ScriptBuilders)
• anúncio no blog do aurélio
• anúncio no blog aureliosoft

Nada de substancial, certo? Eu nunca diria que essas tarefinhas iriam levar oito horas… Mas cada uma tem vários passos a seguir e os famosos “5 minutinhos” acabam virando horas.

A Mog, depois de um tempo comigo, instituiu a regra do “vezes dois” para os meus prazos. Cada vez que eu digo algo como “só vou levar mais meia hora para terminar esse texto do blog”, ela responde: “vezes dois”. E não dá outra: acabo levando pelo menos mais uma hora para terminar. Sabe o que é? Ou eu sou otimista demais nos meus prazos, ou o universo conspira para sempre dar alguma coisa errada no meio do caminho ;)

O lançamento de hoje foi mais rápido, demorou apenas quatro horas. Já estou mais familiarizado com o SVN, por preguiça não fiz os testes no Tiger (sistema anterior, já antiquado) e o anúncio no blog é este texto que estou escrevendo agora, mas dessa vez contabilizando no projeto “Blog”. Vejamos, já deu uma hora e oito minutos até aqui. Será que conseguirei terminar em menos de três horas? Duvido :)

Primeira lição que os dados nos ensinam: leva tempo!

O lançamento de uma versão nova de um programa não é feito em 15 minutos, nem em uma hora. É um processo trabalhoso e desgastante, onde você deve ter atenção máxima para não errar. Concentração é tudo.

E cansa mesmo, mental e fisicamente. Hoje, logo que terminei o lançamento do AdiumBook fui tomar um banho para relaxar, pois estava acabado. O bom é que no banho tive a ideia de um livro sobre desenvolvimento de software, mas isso eu deixo para falar outro dia… :)

Voltando à fotinho e à tabela, a segunda linha mostra que no dia seguinte ao lançamento da versão anterior, gastei somente uma hora e pouco fazendo faxina (todos = “to do”s, do inglês, a fazer) e cadastrando o programa no site Freshmeat. Nada glorioso, trabalho de peão.

Só fui mexer no programa novamente um mês depois, em agosto, que levei uma hora para arrumar alguns probleminhas que apareceram ao instalar a versão nova do Adium (1.3).

Em setembro mexi mais uma única vez para resolver outro problema que os usuários relataram, que deu muito trabalho levando mais de cinco horas para resolver. E depois mais nada, esqueci do programa por vários meses.

Eu gosto assim. Passar um bom tempo sem mexer no programa, que quando eu volto, a disposição é grande. Se mexer todo dia um pouquinho enche o saco rapidinho.

Segunda lição:
Relaxe! Só mexa no programa quando tiver tempo e disposição.

Vieram as festas de fim de ano, a praia, o Carnaval, e nada de vontade de mexer no programa. Porém, os e-mails de usuários começaram a acumular e comecei a ficar incomodado. Geralmente é neste momento que decido que é “hora de fazer alguma coisa”.

Ei, txt2tags, estou olhando pra você.

Depois que terminei as tarefas mais importantes do UmPortugues, me programei para “dar um jeito” no AdiumBook. Eu sabia que essa pegada iria resultar em uma versão nova, pois haviam muitas pendências a serem resolvidas. Então era preciso de bastante tempo reservado para poder mergulhar no código.

Aí começou o trabalho de verdade, no dia sete deste mês, sábado passado, num final de semana que excepcionalmente eu não iria ver a Mog. Veja na foto as cinco últimas linhas selecionadas na tabela, que mostram cinco dias seguidos de trabalho no programa, de sábado até hoje.

Eu preciso dessa imersão quando tenho algo maior a fazer. Trabalhar meia hora por dia em uma coisa não dá certo. Eu levo esse tempo somente para me concentrar 100% e “mergulhar” no código. Sabe aquele estado de atenção em que você não sente fome nem vontade de ir ao banheiro? É isso :)

Terceira lição:
Prepare-se para trabalhar pesado quando for finalizar um programa para lançamento de versão nova.

Mas tive alguns problemas não planejados.

Dias atrás instalei o Safari 4 Beta e gostei que ele está mais rápido e consome menos memória (nem preciso mais encerrá-lo diariamente!). Porém, ele quebrou o Xcode, que é o programa que uso para mexer no AdiumBook. Tive que atualizá-lo. Foram horas até os seus malditos 900 e poucos megas serem baixados pela minha conexão barata. Uma baita água fria em quem achava que já ia colocar a mão no código naquele momento.

Com o Xcode atualizado, o próximo que me deu dores de cabeça foi o Sparkle. Ele é um carinha muito bacana que você enfia no teu programa e ele faz a mágica da atualização automática. Funciona assim: a próxima vez que eu lançar uma versão nova do AdiumBook, vai aparecer automaticamente uma janelinha para o usuário, dizendo: “tem uma versão nova desse programa, quer baixar e instalar?” e então ele faz tudo sozinho. É lindo de ver. Mas… Levei horas para fazer ele funcionar. E nem posso xingar o carinha, pois o erro foi meu. A maneira que eu informava a versão do AdiumBook no Xcode estava errada. Arrumei isso e o Sparkle começou a funcionar. Coisas da vida…

Janelinha do Sparkle atualizando o AdiumBook

Estou há duas horas escrevendo esse texto já. Isso que nem revisei nada ainda. É, vai demorar…

Já que fui forçado (para o bem) a mudar meu esquema de versões, resolvi por o número de revisão do SVN ali também, para ficar igual software de gente grande. A versão de lançamento ficou “1.5 (50)”, ou seja, versão 1.5, revisão 50 do SVN. Mas como eu não ia ficar mudando a revisão do SVN “na mão” a cada alteração, procurei uma maneira de fazer isso automaticamente. Achei um script em Python que deu erro aqui mas consegui arrumar. No fim, todo esse problema acabou deixando o programa mais profissional e ainda pude automatizar a geração do ZIP para lançamento.

Ah é, o ZIP. Antes eu usava o formato DMG (Disk Image) para “empacotar” e distribuir o AdiumBook. Esse tal DMG é um treco que só tem no Mac. É bacana, imagine um arquivo ZIP que quando você abre aparece uma janelinha bonitinha, com desenhos, cores, tudo bem personalizado para o seu programa. Só que o Sparkle tem algumas pegadinhas para usar com o DMG. Então para simplificar as coisas para mim, mudei para o ZIP, que é mais padrão.

O DMG do Adium é tãaaao bonitinho

Percebeu o tamanho das encrencas não-planejadas que aparecem quando você só quer mexer sossegado no seu programa e nada mais? Recapitulando: baixar e instalar o Xcode, Sparkle com problemas, mudar o esquema de versionamento, script para versão automática, mudar de DMG para ZIP. Por isso ocorre o “vezes dois”, que nesse caso foi um “vezes quatro” pelo menos :)

Quarta lição:
Prepare-se para enfrentar problemas inesperados. O ato de “programar” envolve muito mais do que sentar numa cadeira e digitar códigos. Ah, se não fosse o Google…

Bem, resolvidos estes contratempos, pude finalmente fazer aquilo que gosto: criar códigos. E assim foram corrigidos os bugs e implementadas as funcionalidades novas.

Se você quiser acompanhar “ao vivo” a evolução de um software, assine meu feed no Google Code. Assim você fica sabendo na hora sobre as mudanças mais recentes no AdiumBook, no txt2tags e nas Funções ZZ.

Com tudo pronto, hoje atualizei o texto de ajuda (Help), rodei o programa e testei todos os botões e itens de menu, fiz o ZIP final e mandei para o servidor. Contemplei por alguns segundos o arquivo na tela, mostrando zero downloads. É o nascimento.

Dá uma emoção ao enviar o arquivo, sabia? Uma vez no servidor, seu “filho” vai para o mundo. Ali é o ponto sem retorno, onde você declarou publicamente que fez o seu melhor. Encontrar uma falha logo após enviar o arquivo é motivo de vergonha para três gerações futuras de sua família.

Depois foi aquela novela de atualizar o site do programa, atualizar o arquivo PAD e anunciar a versão nova para os principais sites de download. Vou colar aqui um pedaço do meu arquivo release-checklist.txt, que lista todas as tarefas obrigatórias de cada lançamento (em ordem de execução):

———————-8<——————————
upload ZIP pro Google Code
baixar ZIP e testar
deprecate release anterior no Google Code
atualizar Changelog no Google Code (wiki)
atualizar issues (“closes issue #12″ no Changelog)
fazer Changelog mini (<300) para PAD e sites
screenshot novidades
atualizar site
atualizar appcast.xml (e changelog: 1.5.html)
atualizar PAD file (editar, upload, validate, enviar repositório)
atualizar no Adium Xtras http://www.adiumxtras.com/?a=xtras&xtra_id=2069
atualizar no ScriptBuilders (Upload your Scripts! > Update Existing)
atualizar no VersionTracker (MacUpdate segue, acho)
atualizar no Freshmeat http://freshmeat.net/projects/adiumbook/
atualizar no site da Apple https://adcweb.apple.com/downloads/
atualizar no i use this (textile: listas com * e **)
post blog aureliosoft
post blog aurelio
———————–>8—————————–

Ufa! Pensou que era fácil lançar um programa? :)

Quinta lição:
Codificar é divertido, lançar é estressante. Por isso não compensa fazer muitos lançamentos em um curto período.

De volta à foto, veja que logo abaixo das linhas azuis da tabela, há uma linha mostrando os números totais. Ali no meio é possível ver no item “Time-based” qual foi o tempo total que eu levei para fazer todas as tarefas dessa versão nova do programa: mais de 30 horas.

Pena que faz pouco tempo que eu comecei a contabilizar as horas do AdiumBook, mas como eu apanhei muito lá no início (em 2005) por não saber AppleScript direito, acredito que o total já investido nesse programa passa das 200 horas de trabalho.

Lembrando: o AdiumBook é um programa gratuito.

Se você me perguntar “por quê?“,
eu respondo “porque vale a pena!“.

É uma ótima idéia, pois além de ela me ajudar com tudo lá no evento, no tempo que sobra podemos passear juntos pela cidade, com calma, aproveitando de verdade a viagem, que fica sendo meio trabalho e meio passeio.

E foi exatamente isso o que fizemos neste final de semana: fomos à Porto Alegre para passear e participar do Tchelinux 2008.

Nosso avião era sábado às 7h30 da madrugada, e como o aeroporto de Curitiba é BEM longe do centro da cidade, tivemos que acordar às 5h30. Como se esse horário já não fosse desumano o bastante, tínhamos ido dormir à 1h30, totalizando incríveis quatro horas de sono. Isso explica as caras de sono na maioria das fotos :)

Não teve jeito de ir dormir antes, pois a Mog veio lá de Joinville, acabou pegando a rodoviária lotada e o ônibus atrasou um monte.

Já no avião, voando acima das nuvens e admirando aquela incrível paisagem de sonho, de um mar de algodão-doce que ia até onde os olhos não alcançavam mais, colocamos nossas alianças pela primeira vez. O noivado aconteceu em junho, com um anel provisório, porém agora tínhamos nos dedos nossas alianças de verdade. Viva! \o/

Aliança nas nuvens

O evento foi na PUC, mesmo lugar do FISL. Chegando lá, a grata surpresa de ver vários amigos que há tempos não conversava. Amigos da Conectiva, da Internet, de outros eventos e até alguns leitores aqui do blog.

Depois do almoço eu e a Mog demos uma descansada na grama, pois a noite curta de sono ainda estava pesando muito as pálpebras. Aproveitei também para dar uma última olhada nos slides da palestra, pois eu ainda não sabia direito o que iria falar nas duas horas com o microfone na mão :)

Que que eu vou falar lá...

Sobre a palestra

O nome da palestra é “$oftware Livre como fonte de renda“, onde explico o que eu fiz para ganhar dinheiro como autônomo, desde que saí da Conectiva, no ano de 2005.

Pode ser encarada como a continuação da palestra “Como ser um desenvolvedor de Software Livre“, que eu fazia em 2004. Mas naquela época eu era empregado e tinha um salário, então o dinheiro não era uma preocupação. Hoje minha realidade é outra, e essa palestra nova reflete essa mudança.

Passei dois dias inteiros preparando os slides, deu um trabalhão. Mas valeu, foi revelador, pois primeiro precisei fazer todo um levantamento do que aconteceu nos últimos anos. Quanto gastei? Quanto vendi? Quanto ganhei? Em quanto tempo? De onde veio? Para onde foi? Fiz planilhas, gerei gráficos, comparei dados. Números, números, números.

Resumindo o assunto em uma palavra: $$$ GRANA $$$ :)

Nos slides eu tinha todos os dados. Exatos, porém frios. O calor e o humor viriam da minha história pessoal. Mas ainda faltava algo… Uma mensagem, um objetivo… A resposta veio rápido: a Mog e o Leo sugeriram que aquele público (jovens, estudantes) precisava mesmo era de motivação. Isso! Essa era a peça que faltava.

Como eu já não tinha mais tempo de preparar nada, foi tudo “ao vivo”, sem ensaio. Com o microfone na mão e slides no projetor, diante de 200 pessoas, a palestra nasceu.

À medida que eu ia contando as histórias e mostrava os dados dos slides, lembrava daquela época de dúvidas, e de como o futuro era incerto. Eu fazia as coisas sem saber onde iam dar. Hoje é fácil entender o processo, mas lá atrás tudo o que eu sabia era que eu precisava fazer. O resultado era uma incógnita.

E esse foi o grande recado: faça.

Não importa se não der em nada.
Não importa se não tem objetivo.
Não importa se ninguém te apóia.
Faça.
Simplesmente faça.
Pode demorar vários anos, mas o resultado vem.

Eu fiz, e o resultado veio.

E assim foram duas horas que passaram em instantes. Falei da camiseta das Funções ZZ, da apostila de shell, das doações via PayPal, dos anúncios do Google (AdSense) e dos livros que escrevi. Quer assistir?

Aqui tem a primeira metade:

E aqui tem a segunda metade (valeu Bruna!):

No final, um palestrante emocionado por perceber que hoje está vivendo o seu sonho de ontem e um público satisfeito que aplaudiu com vigor.

Missão cumprida.

O e-mendigo recebe doações :)

No meio da palestra o Leo me perguntou qual era o meu e-mail do PayPal. “É verde arroba aurelio ponto net” e voltei a palestrar. “Acho que ele vai por isso no site do Tchelinux“, pensei. Instantes depois, com um sorrisinho maroto no rosto, ele mostra a tela do notebook e diz que tinha acabado de me fazer uma doação. E mais, que também tinha quebrado o recorde de 100 dólares como a maior doação que eu já tinha recebido. UAU! Como assim? Massa!

No fim da palestra, recebi uma lista de nomes e um bolo de notas e moedas. “Que isso?“, perguntei. Eu não tinha percebido, mas por iniciativa do Leo e do Evaldo (UdontKnow), durante o “culto” eles passaram a “sacolinha” e colheram “ofertas” para este “pastor” que vos escreve :)

Pô, isso tocou fundo (no bom sentido, claro). Nos slides eu mostrei que os brasileiros contribuem muito pouco, apesar de serem os maiores usuários de meus programas livres. Mas ali, durante a palestra, o pessoal resolveu mudar essa realidade.

MUITO OBRIGADO MESMO!

46 pessoas doaram...

... R$160,75 durante a palestra...

... e o Brasil é campeão Galvão! \o/

Logo depois da palestra fizemos um painel (ou mesa, ou algo parecido…), onde o tema era carreira profissional no software livre, com apresentação do Carlos Santos (casantos), em que eu, o Arnaldo (acme) e o Fábio Olivé (leitinho) respondíamos perguntas. Eu não tenho carreira, então não tinha muito a falar :)

Depois veio o encerramento, com a mensagem final do Leo, sorteio de brindes e arremessos de bottoms assassinos do Firefox, mas felizmente todos sobreviveram :) Aproveitei para vender os livros que eu tinha levado, e felizmente eles sumiram rapidinho!

De noite teve um mega churrasco nerd, num lugar bacana onde cada mesa tinha uma churrasqueira “pessoal” na ponta, para o grupo assar sua própria carne. Ao redor várias quadras de futebol onde jogavam times femininos, todas uniformizadas, com “uns coxão” como disse a Mog. Eu já estava entorpecido de tanto cansaço e sono, mas acabamos ficando lá até perto da meia-noite.

Dia seguinte acordamos tarde, tomamos aquele café reforçado no hotel e fomos torrar todo o dinheiro que ganhamos no evento :D Passamos o domingo no Brique da Redenção, e lá compramos alguns apetrechos (e até um quadro!) para decorar nosso futuro apartamento em Joinville. Assim toda vez que olharmos para o quadro, lembraremos dessa viagem, do evento, dos amigos e daqueles que fizeram parte dessa história.

Ah, eu ainda não contei sobre Joinville? Tá, um dia eu conto então ;)

Para terminar, gostaria de fazer um agradecimento especial ao Leo, que é um cara mais do que especial, que fez tudo isso acontecer. O Tchelinux foi um evento que eu tive prazer em participar, feitos por nerds, para nerds, sem politicagem. Altamente recomendado! Irmão, muito obrigado pela experiência, eu e a Mog ficamos MUITO satisfeitos com a viagem!

Leo é o cara

— zZZzzzZzzZZzZzZZzZzzzZZz —

Exemplos para este ano:

$ zzcarnaval
05/02/2008
$ zzpascoa
23/03/2008
$ zzhorariodeverao
19/10/2008
15/02/2009
$

Exemplos para o ano que vem:

$ zzcarnaval 2009
24/02/2009
$ zzpascoa 2009
12/04/2009
$ zzhorariodeverao 2009
18/10/2009
21/02/2010
$

Que dia da semana é hoje?

$ zzdiadasemana
sexta-feira

Que dia da semana que eu nasci?

$ zzdiadasemana 07/10/1977
sexta-feira

Que dia da semana vai ser daqui 30 dias?

$ zzdiadasemana $(zzdata hoje + 30)
domingo

— zZZzzzZzzZZzZzZZzZzzzZZz —

 A zzajuda ganhou uma opção nova para listar todas as funções, com suas descrições. Agora ficou mais fácil encontrar o que você procura!

 $ zzajuda --lista
zzajuda         Mostra uma tela de ajuda com explicação e sintaxe de todas as funções
zzalfabeto      Central de alfabetos (romano, militar, radiotelefônico, OTAN, RAF, etc)
zzansi2html     Converte para HTML o texto colorido do terminal (códigos ANSI)
zzarrumanome    Renomeia arquivos do diretório atual, arrumando nomes estranhos
zzascii         Mostra a tabela ASCII com todos os caracteres imprimíveis (32-126,161-255)
zzbeep          Aguarda N minutos e dispara uma sirene usando o 'speaker'
...

Esqueceu-se como usa aquela função, ou quer aprender a usar várias de uma só vez? Então a zzajuda tem mais uma opção nova para o seu deleite visual:

$ zzajuda --uso
zzajuda [--lista|--uso]
zzalfabeto [--TIPO] [palavra]
zzansi2html [arquivo]
zzarrumanome [-n] [-d] [-r] arquivo(s)
zzascii [colunas] [largura]
zzbeep [números]
...

— zZZzzzZzzZZzZzZZzZzzzZZz —

Tem coisas que só as Funções ZZ fazem para você :)

Tá esperando o que?
Vai lá baixar a versão nova agora!

Também tem uma GRANDE novidade que é o diretório especial para funções extras, o $ZZEXTRADIR, mas sobre isso eu comento em um texto futuro. É importante demais para ser apenas uma nota de rodapé :)

• O programador passa horas de seu dia em frente ao computador, lendo, digitando e testando códigos. Os códigos começam simples mas rapidamente ficam complexos à medida que o programa cresce. É fácil se perder em meio ao código, é preciso constantemente reler algum trecho ou pular rapidamente para a definição de uma função, ver quais são seus argumentos, analisar seus algoritmos. O programador consegue reter em sua cabeça parte do funcionamento de um programa, mas os detalhes só são conhecidos com a leitura e análise do código.
• O cego não enxerga.

E como alguém que não enxerga pode programar códigos?

Para usar o computador, um cego precisa de um leitor de tela. Este leitor é um programa que dita, usando uma voz robótica, tudo o que está escrito na tela. É como se tivesse alguém ao seu lado lendo em voz alta tudo o que aparece no monitor.

Um dia, por curiosidade, instalei um destes leitores para ter uma idéia de como era usar o computador sem enxergar. Fechei os olhos e tentei escrever um texto e ler alguns e-mails. Eu fiquei deprimido. Demorava MUITO tempo para conseguir fazer coisas muito simples, e a voz digital rapidamente se tornou cansativa por sempre usar o mesmo tom. Um monólogo no escuro. Deu medo.

Um programador cego tem que esperar que o leitor dite a linha atual (cheia de pontuação como $ @ ; ! =) para saber onde está o cursor. Se quiser saber o que tem na linha anterior, ele move o cursor para cima e espera que a linha seja ditada. E assim, uma linha de cada vez, ele vai se achando em que parte do código ele está.

Quem já brincou com o editor de textos do UNIX (ed), sabe como é tenebroso enxergar somente uma linha por vez. A falta de contexto te deixa completamente perdido.

Quer sentir o quão difícil é saber em que parte do código você está, sem ter contexto?

• Abra o código de um programa seu, que você conheça bem.
• Peça para alguém ao seu lado te ajudar, essa pessoa será seu leitor de tela.
• Feche os olhos e NÃO ABRA MAIS.
• Peça para essa pessoa escolher uma linha qualquer, dentro de uma função/método qualquer.
• Agora a pessoa vai te ditar esta linha. Somente ditar, ela não pode dar nenhuma outra dica.
• Responda: Qual o nome da função/método?
• Não tem como saber? Então peça para a pessoa ditar a linha anterior.
• Ou quem sabe a próxima linha.
• Mas qual era mesmo a primeira linha que foi ditada? Poderia repetir?

E aí você percebe como é difícil ler um código sem contexto. Imagine analisar, editar, testar, depurar…

Por falar nisso, há algum cego que lê o blog? Deixe um comentário contando suas experiências! As Funções ZZ já são usadas por cegos há algum tempo.

Por curiosidade acabei de acessar o blog no lynx e os caras do WordPress estão de parabéns, pois o blog é muito acessível, com o texto do artigo já no início, sem poluição.

Por favor, leia os dois e-mails seguintes com muita atenção. O Ângelo conta um pouco de sua história e explica como ele faz para tornar menos impossível a tarefa de programar sem enxergar. O primeiro e-mail tem alguns trechos que cortei, o segundo está na íntegra (e muito bem escrito).

Atualização em 18 de outubro de 2008: O Ângelo conta que também dá aulas de PHP. Que tal convidá-lo para falar sobre programação em sua empresa? Tenho certeza que os funcionários ficarão bem motivados ao ver do que esse cara é capaz. Se quiser entrar em contato com ele, escreva para angelobeck (a) floripa com br.

_________________________________________________________________________

De: Ângelo Beck
Para: Aurélio Marinho Jargas
Data: 11 de setembro de 2008

Olá Aurélio,

Ainda não fazem dois anos que eu comecei a trabalhar com php. Estou construindo um gerenciador de conteúdos e é claro que eu preciso de um conversor de textos para html.

[...]

Estou com 27 anos. Fazem uns três anos que eu me tornei completamente cego e por isto decidi me voltar para a programação. Estou tendo que aprender tudo sozinho mesmo. E o mais chato é que não é fácil editar códigos. Eu inventei alguns truques para facilitar a minha vida, mas aproveitar o código dos outros nem sempre é possível e por isto acabei fazendo tudo a partir do zero.

[...]

Li teu livro sobre as expressões regulares e lhe dou os parabéns. Muito bom mesmo. E só não vou adquiri-lo pois não enxergo material impresso… então fico com o que está publicado na web.

[...]

Bem… obrigado pela atenção,

Ângelo Beck

_________________________________________________________________________

De: Ângelo Beck
Para: Aurélio Marinho Jargas
Data: 12 de setembro de 2008

Olá Aurélio,

Indentação atrapalha, comentários ajudam

A respeito dos truques de programação, o principal deles é a forma de formatar e comentar os blocos de comandos.

Indentar o texto, colocando espaços ou tabulações no início da linha gera um efeito visual interessante, mas completamente inútil quando não enxergamos. Além do mais, quando não utilizamos mouse, estes espaços e tabulações apenas atrapalham a movimentação, que deve ser feita pelo teclado.

Então, para que eu não me perca entre inúmeros blocos de comandos, que devem ser abertos e fechados, utilizo o seguinte método:

Primeiro, um bloco ‘{‘ sempre se inicia em uma nova linha, e após o início do bloco vem um comentário que descreve o conteúdo do bloco.

Ao final do bloco, seu fechamento ‘}’ é feito também em uma nova linha seguido do mesmo comentário da abertura.

Fica mais ou menos assim:

  if ($carro)
  { // possui carro
  print $carro
  } // possui carro
  else
  { // não possui carro
  print 'O carro sumiu!';
  } // não possui carro

Parece besta, mas em alguns trechos do código acabam por haver inúmeros blocos aninhados, e esta forma de comentá-los se torna extremamente eficiente:

Aqui vai um pequeno script como exemplo e logo abaixo seu código

array_sub_search

Retorna a chave primária de um array cuja chave secundária previamente conhecida contenha o valor pesquisado.

$key = array_sub_search ($find-me, $array, $secundary_key);

Exemplo:

<?php
$array[1]['fruta'] = 'banana';
$array[1]['salada'] = 'manga';
$array[2]['fruta'] = 'manga';
$array[2]['salada'] = 'alface';
$key = array_sub_search ('manga', $array, 'fruta');

// retorna 2, pois em 1 manga não é fruta
?>

Código de array_sub_search():

<?php
// *** Ecolabore Engine - Copyright 2008 Angelo Beck ***

function array_sub_search ($value, $array, $sub)
{ // array_sub_search
if (is_array ($array))
{ // is array
foreach ($array as $key => $item)
{ // find loop
if ($item[$sub] == $value)
{ // key found
$found = $key;
break;
} // key found
} // find loop
} // is array
return ($found);
} // array sub search
?>

Com tantos blocos aninhados seria muito fácil de se perder. Desta forma, ao correr para um trecho qualquer do código e ouvir o comentário dos blocos, podemos saber exatamente onde estamos. Como a leitura é feita linha por linha, imagine reduzir a sua janela para apenas uma linha de altura! Será impossível de reconhecer em que lugar do código estamos, não é? Por isto que colocar comentários e suprimir a indentação é tão útil!

Bem… é claro que eu não documentei tão detalhadamente todo o meu sistema. Mas pelo menos as funções eu fiz questão de documentar para poder utilizá-las adequadamente no futuro.

Dar nomes úteis para os caracteres

Outro truque é exigir que o leitor de telas, o sintetizador de voz que “fala” o que está escrito, pronuncie algumas palavras especiais ao encontrar certos caracteres ou strings.

Por exemplo, { e } devem ser ditos como “início do bloco” e “fim do bloco”, já que normalmente são utilizados para delimitar blocos de comandos.

• // = “nota”. Poderia dizer “comentário, porém, “nota” é mais curto para se pronunciar!
• ‘ = “As”, também por ser mais curto do que “apóstrofo”.
• ” = ‘nulo”, já que normalmente representa uma string vazia.
• $ = “var”, já que é utilizado para indicar uma variável.
• ; = “fim”, para indicar um fim de instrução (exigido pelo php)
• ! = “not”, já que é utilizado como negação – exemplo != ou if(!$carro)

Para ficar mais confortável de se ouvir, também fiz as seguintes exigências:

• elseif = elz if
• else = elz
• [ = colchete
• ] = fecha colchete
• ( = parêntese
• ) = fecha parêntese

A seguinte linha:

elseif ($carro != '')
{ // presente
print $carro;
} // presente

normalmente seria pronunciado assim:

elssêif abrir parênteses cifrão carro exclamação igual apóstrofo apóstrofo fechar parênteses
abrir chavetas barra barra presente
print cifrão carro ponto e vírgula
fechar chavetas barra barra presente

agora é pronunciado assim:

elz if parêntese var carro not igual nulo fecha parêntese
início do bloco nota presente
print var carro fim
fim do bloco nota presente

É meio esquisito “ler” o que se vê, mas com o tempo a gente se acostuma e, de tanto ouvir, var carro fim é o mesmo que $carro;

No fim não deixa de ser organizado e elegante também.

Blocos sempre iniciam em uma nova linha

Quando passamos o cursor de uma linha para a outra, o sintetizador passa a ler a nova linha. Nem sempre temos tempo de ouvir uma linha inteira para saber que no final haverá um início de bloco ‘{‘. Por isto a decisão de que qualquer bloco deve ser iniciado em uma nova linha.

Agora imagina o saco que é ler um código escrito por quem enxerga, onde blocos são abertos e fechados no fim das linhas… Ou pior:

  { else }

Mas isto é o fim!

Código HTML: Organização das tags

Também no html eu utilizo a mesma regra: tags que iniciam em uma nova linha, são fechadas em uma nova linha. Também podem ser abertas e fechadas na mesma linha.

Desta forma,

<html>
<head>
<title>Olá</title>
</head>
<body>
<center>
<h1>Bem vindo</h1>
<p><b><i>Obrigado por ter nos visitado</i></b></p>
</center>
</body>
</html>

Isto aí é válido.

Mas isto não:

<html><head>
<title>
olá
</title></head>
<body><center>
<h1>Bem vindo
</h1></center></body></html>

HTML: Dicas de pronúncia

Um truque também para o html é exigir a seguinte pronúncia:

• < = “menor” (ao invés de “menor que”)
• > = “maior” (ao invés de “maior que”)
• </ = “fecha”
• <!– = “comentário”
• –> = “fim do comentário”

CSS: Pode usar a mesma pronúncia do PHP

Com folhas de estilo css eu nem me incomodo, pois utilizo as mesmas regras de pronúncia do php:

h1.principal {
color:#880000;
}

é dito como:

hagá um ponto principal início do bloco
color dois pontos cardinal oitocentos e oitenta mil fim
fim do bloco

Curiosidades

Bem… acho que é isto.

Espero ter alguma coisa mais concreta para mostrar em breve.

Por curiosidade,

• :-) = “risos”
• ;-) = “piscadela”
• vc = você
• Angelo = Ângelo (e não Angêlo)
• microsoft = maicrossóft (e não microzôft)
• Rudolf Steiner = Rúdolf Stáiner (e não Rudôlf Steinêr)
• Google = Gúgol (e não gô-ôgle)
• skype = Scáipe (e não skipe)

e mais umas correçõezinhas assim.

Diferenças ao escrever um texto e um programa

Quando leio ou escrevo um texto (não um script) desativo a pronuncia da pontuação, parênteses, colchetes, etc. e também desativo o “eco” do teclado. De forma que eu não ouço o que eu digito. Apenas após a escrita eu repasso o texto para “ouvir” se algo está errado. Também, quando alguém coloca algo entre parênteses, na maioria das vezes eu não sei que eles existem.

Já quando estou programando, ativo o eco do teclado para ter certeza de que não vai faltar nem um colchete… e mesmo assim normalmente fica faltando uma aspa não fechada ou coisas deste tipo! Também ativo a leitura da pontuação, já que $cidade .= $país; não são duas frases mal escritas.

Até,

Ângelo Beck

E você leitor(a), qual era mesmo aquela sua desculpa para não programar?
:)

• Reforma: O primeiro passo você já sabe: o código das Funções ZZ passou por uma reforma geral e hoje é limpo, alinhado e recheado de comentários explicativos. Leia-o para aprender mais sobre shell script (Bash)!
   
• Google Code: O código agora está hospedado no excelente Google Code (programadores, recomendo!). Com isso ganhamos algumas coisinhas bacanas, que veremos à seguir.
   
• SVN: O código foi colocado no SVN do Google Code, assim o desenvolvimento das ZZ migrou do modelo caverninha-my-precious para a exposição total. Agora cada mudança é imediatamente disponibilizada à comunidade de usuários durante as entressafras das versões oficiais.
   
• Feed SVN: Você pode assinar o Feed do SVN das ZZ (que sopa de letrinhas!) e acompanhar em tempo real todas as mudanças. Tem curiosidade para saber como é o desenvolvimento de um programa? Quer aprender mais sobre shell? Acompanhe o feed!
   
• Feed de notícias: Se você só quer acompanhar os lançamentos de versões novas e novidades do projeto, assine o Feed das Funções ZZ. Se você já assina o feed daqui do blog, já está garantido(a).
   
• Downloads: Outra vantagem do Google Code é o contador de downloads. Agora é possível ter uma idéia de quantas pessoas baixam as funções. Estes números também são importantes para saber quantos usuários ainda dependem da versão ISO-8859-1 em vez da padrão UTF-8.
   
• Debian: O colaborador Eder Marques fez um pacote Debian para as funções. Se você não sabe o que isso significa, é porque você não precisa desse pacote, então fique sossegado(a).
   
• Zsh: O colaborador gallois fez um script para instalar as Funções ZZ no shell Zsh. Se você usa o Zsh em vez do Bash, aproveite! Novamente, se você não sabe o que Zsh significa, fique tranqüilo(a) que você não precisa deste script.

EOF

Esta é a versão 8.9, mas bem poderia ser chamada de “versão colorida”, pois traz duas funções novas que lidam com cores.

A primeira é a zzecho, que assim como o comando echo, mostra uma mensagem na tela. Mas não é aquela mensagem cinza sem graça, pois a zzecho pode mostrar texto coloridos, em negrito, com sublinhado e piscando!

Útil para usar em scripts, quando você quiser chamar a atenção do usuário para uma mensagem importante:

zzecho --pisca --fundo vermelho ATENÇÃO, vou apagar tudo

Ou a versão econômica:

zzecho -p -f vermelho ATENÇÃO, vou apagar tudo

Mas o legal mesmo é ver a função em ação:

Clique na imagem para ver a versão em texto, gerada pela zzansi2html.

A segunda função nova á zzansi2html. Nome estranho, não? Ela converte textos com códigos ANSI para HTML.

Não sabe o que são códigos ANSI? São os bichinhos que fazem o texto ficar colorido, são eles que fazem a mágica na zzecho que acabamos de ver. São como micróbios, você não consegue enxergá-los, mas eles existem :)

Com essa função você pode colocar em seu site ou blog a saída completa do terminal, incluindo as cores e atributos (sublinhado, negrito, pisca-pisca). Alguns exemplos bacanas são a saída da zzecho, da zzcores e do comando ls --color.

zzcores | zzansi2html > zzcores.html

Clique no link do exemplo para ver o resultado. Note que isso não é uma imagem, mas sim um texto formatado, que você pode copiar/colar.

Se quiser gravar a saída de vários comandos seguidos, preservando todas as cores, seu prompt joiado e tudo mais, use o comando script:

# Chame o comando 'script' e informe o arquivo
# onde ele deve guardar a saída: ls.ansi.

script ls.ansi

# Agora você está "dentro" do comando script,
# tudo o que você fizer será gravado.

ls /etc

# Para sair e terminar a gravação, use o comando exit

exit

# Já "fora" do comando script, converta para HTML

zzansi2html ls.ansi > ls.html

Novamente clique nos links para ver os resultados. Massa né? :)

Detalhe nerd: Estávamos aqui no blog estes dias comentando sobre um futuro livro de sed… Sabe o que é mais legal? A zzansi2html foi feita com um único comando sed. Claro, é um sed macho com trocentos comandos dentro, mas é um sed. Bom para ver que é possível fazer coisas complicadas com o sedinho :)

Tá esperando o quê? Veja a lista completa das novidades e faça o download da versão 8.9!