Problema: fatiar um arquivão em pedaços menores, com N linhas cada.

Solução fácil.
Um único comando.
split -l N arquivo.txt

Não conhece o comando?
Não conhece esta opção específica?
Problemas², vai ter que inventar.

sed, sempre ele.
sed que gera sed: avançado e poderoso.
paste + seq + seq? Quem diria!

Sem arquivos temporários.
Sem loop.
Sem design patterns.

Com mágica.
Com diversão.
Com salada de frutas.

Spoiler: a Mog dá “oi” tímido no final ;)

Resumo dos comandos:

• sed — edita linhas
• seq — sequência de números
• split — fatia arquivos
• paste — junta colunas

Histórico:

### split
seq 20
seq 20 > 20.txt
split -l 5 20.txt
ls
cat xaa
cat xab
rm x*
ls

### sed w
sed -n '1,5 p' 20.txt
sed -n '4,11 p' 20.txt
sed -n '4,11 w foo.txt' 20.txt
ls
cat foo.txt
sed -n '1,5 w foo1.txt' 20.txt
sed -n '6,10 w foo2.txt' 20.txt
cat foo2.txt

### paste + seq
seq 5
seq 1 20
seq 1 5 20
seq 5 5 20
seq 1 5 20 > a1
seq 5 5 20 > a2
paste a1 a2
paste a1 <(seq 5 5 20)
paste <(seq 1 5 20) <(seq 5 5 20)
rm a?

### sed constrói um script sed
paste -d , <(seq 1 5 20) <(seq 5 5 20)
paste -d , <(seq 1 5 20) <(seq 5 5 20) | sed 's/.*/& w foo.txt/'
paste -d , <(seq 1 5 20) <(seq 5 5 20) | sed 's/.*/& w foo-&.txt/'
paste -d , <(seq 1 5 20) <(seq 5 5 20) | sed 's/.*/& w linhas-&.txt/'
paste -d , <(seq 1 5 20) <(seq 5 5 20) | sed 's/.*/& w linhas-&.txt/ ; s/,/-/2'

### aplicação do script sed
paste -d , <(seq 1 5 20) <(seq 5 5 20) | sed 's/.*/& w linhas-&.txt/ ; s/,/-/2' > foo.sed
cat foo.sed
ls
ls
sed -n -f foo.sed 20.txt
ls
cat linhas-1-5.txt
cat linhas-16-20.txt<

### recapitulando: estes são os dois comandos
paste -d , <(seq 1 5 20) <(seq 5 5 20) | sed 's/.*/& w linhas-&.txt/ ; s/,/-/2' > foo.sed
sed -n -f foo.sed 20.txt

### agora num único comando, sem precisar de foo.sed
rm foo.sed
rm linhas-*
paste -d , <(seq 1 5 20) <(seq 5 5 20) | sed 's/.*/& w linhas-&.txt/ ; s/,/-/2' | sed -n -f - 20.txt
paste -d , <(seq 1 5 20) <(seq 5 5 20) | sed 's/.*/& w linhas-&.txt/ ; s/,/-/2' | sed -n -f /dev/stdin 20.txt
ls
cat linhas-6-10.txt

Tudo numa única página de uma folha A4.

Boa para colar na parede ou deixar dentro da gaveta do escritório, sempre ao alcance, para consultar e resolver aquelas dúvidas que sempre aparecem na hora de usar as expressões.

E além da folha impressa, que tal ter também uma cópia digital destas tabelas, no formato PDF, para guardar no seu computador e no seu smartphone, e poder consultar rapidamente, mesmo estando na rua?

E se eu te disser que é de graça?

Tá na mão:

Clique na imagem para baixar o PDF

Nota: Estas são as tabelas que estão no Apêndice B do meu livro Expressões Regulares – Uma abordagem divertida. Aquelas, lá no finalzinho.

Obrigado ao Lourival Silva Filho pela ideia de fazer o PDF, e à editora Novatec por permitir que eu liberasse de graça este conteúdo do livro!

Gravei este vídeo em maio de 2010, mas deixei para publicá-lo “dali alguns dias”, pois eu tinha acabado de publicar um vídeo nerd no blog.

Coloquei o item “publicar vídeo patch” já no topo do meu arquivo tarefas.txt. Mas nos dias seguintes outras tarefas apareceram, e, cada vez mais longe do topo, este item ficou acumulando poeira durante meses.

Hoje, faltando poucos dias para a gravação do vídeo completar dois anos, consegui finalmente resolver a pendência:

Vídeo rápido (5 min) em que explico o formato de um arquivo patch (diff) e mostro como aplicá-lo no código de um programa, usando o comando patch.

E pronto. Só isso. O vídeo já estava no YouTube desde 2010 (como privado), e levei dois anos para marcá-lo como público e escrever este parágrafo de descrição. Vai entender, é a vida…

Porém, cerca de uns 15 dias atrás, ele começou a fazer um barulho alto, um zunido. Sabe aquele barulho chato de ventoinha (o ventiladorzinho interno), tão comum num PC? Então.

Fui deixando pra ver se ele parava sozinho, achei que poderia ser por causa do calor de Joinville. Mas que nada, só piorou. Hoje ficou zunindo o dia todo, sem parar, então resolvi deixar a preguiça de lado e pesquisar como arrumar isso.

Pelos artigos que li, muita gente resolve o problema simplesmente limpando a fila de impressão. Nem impressora tenho, então não era o meu caso. Outra possível causa seria um uso excessivo de hardware, que aumentaria a temperatura da máquina. Isso poderia ser disparado por: falta de espaço em disco, falta de RAM, permissões incorretas nos arquivos, ou algum processo desenfreado comendo toda a CPU. Infelizmente para mim, eu não me encaixava em nenhum destes problemas fáceis de resolver.

Voltei à teoria inicial de que o problema era com a ventoinha. Possivelmente o excesso de sujeira, que acumulou durante os anos de uso. Só que para confirmar isso, e limpar a dita cuja, eu teria que abrir o MacBook.

MEDO.

Faz muitos anos a última vez que abri um computador. No PC é tudo mais espaçoso, mais fácil de fuçar sem estragar nada. Notebook é um saco, tudo apertado e frágil. E como esta é minha única máquina, o risco é grande: se eu estragar, fico sem computador.

Me animei a tentar fazer o conserto quando achei este vídeo, que mostra que não tão é complicado abrir o MacBook, basta uma chave de fenda:

Fui seguindo o vídeo e deu tudo certo. Aliás, a única coisa que não foi igual foi a parte final de puxar o teclado “gentilmente”. No meu caso tive que forçar para que ele saísse.

No vídeo não fica claro, mas os parafusos são todos diferentes, é uma festa. Se você for se aventurar pelo mesmo caminho, aconselho ir guardando um por um, na ordem de remoção, para depois não se perder na hora de fechar o bichinho.

Quando consegui finalmente tirar o teclado, fiquei feliz ao ver que havia muito pó ali dentro: na placa, nos fios, na ventoinha. Maravilha! Indício de que o problema poderia ser apenas sujeira.

Limpei por cima, com o que eu tinha aqui em casa: aspirador, esponja de louça, escova de dentes e papel higiênico. Mas dentro da ventoinha ainda tinha muita sujeira, eu precisava abri-la para limpar.

Por sorte foi fácil, bastou desconectar o cabo, desgrudar a fita metálica e remover os dois parafusos pretos. Mais uma forcinha e pronto, a tampinha saiu.

Com a ventoinha na mão, consegui limpá-la usando a escova de dentes. Tinha muito pó grudado em suas pás. Mas saiu fácil, coisa rápida.

Já que estava na faxina, resolvi colocar um pouco de lubrificante (WD-40) no miolo da ventoinha, para que ela deslize melhor. Não sei se isso é aconselhável (não é, veja os comentários deste post), mas de qualquer forma não coloquei muito. Uns giros para escorrer o excesso, mais uma limpezinha e pronto.

Agora era só montar tudo de novo e rezar para que:

1. O computador ligue.
2. O barulho tenha sumido.

Recoloquei a ventoinha, e fiz o caminho inverso do vídeo para recolocar os parafusos.

Felizmente para mim, esta história não teve um final dramático. Ao ligar, tudo funcionou de primeira e agora estou aqui digitando este texto em meu MacBook silencioso :)

Tem mais algumas fotos lá no Picasa.

Você tem um arquivo.
Você precisa extrair dados deste arquivo.
Linha de comando na cabeça!

Python, Ruby, PHP, JavaScript? Não.
C, C++? Fala sério!
Shell.

Um grep aqui, um sed ali.
Uma pitada de expressões regulares.
Problema resolvido.

Sorriso no rosto.
Dados no bolso.
Entoa o refrão:

Não precisa ser perfeito.
Não precisa ser polido.
Só precisa funcionar.

Resumo dos comandos:

• grep — extrai linhas
• cut — extrai colunas
• sed — edita linhas
• tr — troca caracteres

Histórico:

tail -n 50 changelog.t2t
grep ^: changelog.t2t
grep ^: changelog.t2t | sed 's/^: //'
grep ^: changelog.t2t | cut -c 3-10
grep ^: changelog.t2t | cut -c 3-
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]'
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | grep v
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | grep v | sed 's/^v/200/'
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | grep v | sed 's/^v/200/' | tr . -
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | grep v | sed 's/^v/200/' | tr . - | sed 's/./&x/'
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | grep v | sed 's/^v/200/' | tr . - | sed 's/./&x/2'
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | grep v | sed 's/^v/200/' | tr . - | sed 's/./&x/6'
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | grep v | sed 's/^v/200/' | tr . - | sed 's/./&x/7'
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | sed 's/^v/200/' | tr . - | sed 's/./&-/7'
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | sed 's/^v/200/' | tr . - | sed 's/./&-/7' | sed 's/--/-/'
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | sed 's/^v/200/' | tr . - | sed 's/./&-/7' | sed 's/--/-/' | grep ..........
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | sed 's/^v/200/' | tr . - | sed 's/./&-/7' | sed 's/--/-/' | egrep '.{10}'
grep ^: changelog.t2t | cut -c 3- | grep '[0-9]' | sed 's/^v/200/' | tr . - | sed 's/./&-/7' | sed 's/--/-/' | grep .......... > /tmp/lista.txt

Et tu, Brute?

Dos concursos públicos que ela estava vendo, um em especial fez seus olhinhos brilharem: FATMA 2011 (Fundação do Meio Ambiente – SC), que tinha vaga de Sociólogo em Joinville. Peraí. Sociólogo? Meio Ambiente? Aqui em Joinville? Perfeito! Uma ótima chance de a Mog finalmente poder exercer a Sociologia, pondo em prática sua brilhante e premiada formação acadêmica.

Decidida a não perder esta (rara) oportunidade, ela se empenhou para este concurso. Foram semanas estudando aqui em casa, diariamente, várias horas por dia. Nossa única mesa (de jantar, de almoço, de café) virou sua biblioteca. E lá estava a Mog, concentrada, em meio a pilhas de papéis: apostilas, provas antigas, leis ambientais…

Mas o esforço valeu. Ontem à noite saiu o resultado do concurso, e aqui em casa foi uma explosão de alegria. Adivinha quem encabeçou a lista dos aprovados?

A Mog é primeirona!
\o/
Ah, essa menina me dá tanto orgulho!

Como se não bastasse a alegria de ela ter sido a primeira, ainda tem mais. Tá vendo aquela coluna marcada em vermelho na tabela? Ali é a nota das questões de informática. Eram cinco, e a Mog foi a única que acertou todas!

É o orgulho do pai! Digo, do marido nerd :)

E o Linux, onde entra na história?

Agora! Olha só qual foi uma das questões de informática que a Mog acertou:

Como parte de meus estudos, fui ver como se comportam as Web APIs de serviços famosos, para ver nos exemplos “do mundo real” quais as melhores práticas de sua implementação.

Comecei por uma tarefa bem simples: o que o servidor responde quanto eu tento acessar uma URL inválida na API?

Eu esperava encontrar um padrão, e simplesmente usar este padrão na minha própria API. Mas veja só o que encontrei.

Dropbox

https://api.dropbox.com/1/foo

{
    error: "Not Found"
}

Flickr

http://api.flickr.com/services/rest/?format=json&method=foo

jsonFlickrApi({
    "stat":"fail",
    "code":112,
    "message":"Method \"foo\" not found"
})

Google

http://ajax.googleapis.com/ajax/services/foo

404

http://ajax.googleapis.com/ajax/services/search/foo

404

https://www.googleapis.com/language/foo

"Not Found"

https://www.googleapis.com/language/translate/foo

"Not Found"

Facebook

https://graph.facebook.com/foo

{
   "error": {
      "message": "(#803) Some of the aliases you requested do not exist: foo",
      "type": "OAuthException",
      "code": 803
   }
}

Twitter

A documentação me disse que eu encontraria esta mensagem de erro:

{
    "errors": [
        {
            "message": "Sorry, that page does not exist",
            "code": 34
        }
    ]
}

Eu juro que tentei, mas essa mensagem específica eu não consegui ver :)

https://api.twitter.com/1/foo

404

https://api.twitter.com/1/foo.json

404

https://api.twitter.com/1/statuses/foo.json

{
    error: "Could not authenticate you.",
    request: "/1/statuses/foo.json"
}

https://api.twitter.com/1/statuses/show.json?id=foo

{
    request: "/1/statuses/show.json?id=foo",
    error: "No status found with that ID."
}

Conclusão

Nenhuma :)

Ainda não sei qual é o “certo” a se fazer quando alguém tentar acessar uma URL inválida dentro da minha API.

O clássico jogo Sokoban, escrito em Sed

Eita, mas olhar para essa foto antiga, além do saudosismo do joguinho em si, me traz lembranças de toda uma época: eu usava Linux, fvwm como gerenciador de janelas (.fvwmrc), e ali está o inseparável xterm, com sua tela preta e sua fonte… peculiar.

Era bom, mas hoje é tudo melhor. E viva o progresso :)

Quer rodar o SedSokoban agora, em sua máquina? Tá fácil. Vá num terminal e cole estes dois comandos:

wget http://aurelio.net/sed/sokoban/sokoban.sed
sed -nf sokoban.sed

Já aviso que a jogabilidade é horrível. Você deve apertar a seta e depois dar Enter, para cada movimento. Este é um jogo que não serve para divertir nem para passar o tempo. O seu grande mérito foi ter sido escrito usando uma ferramenta limitada, o sed, que não é uma linguagem de programação, mas sim um editor de textos! Coisa de nerd :P

Dá uma olhada no código-fonte dele. A parte boa está no final, depois dos mapas. Dez anos atrás, quando fiz este código, eu entendia ele. Hoje ele me dá medo :)

Estou pensando em talvez dissecar este código em um apêndice no (ainda não iniciado) livro de sed, igual fiz com as Funções ZZ no livro Shell Script Profissional.

Mas uma lição importante que este joguinho me ensinou, e que depois reaprendi com o MiGuXeiToR e outros, é que fazer coisas sérias/úteis não tem apelo popular. O povão gosta mesmo é de futilidades.

http://aurelio.net/blog/2009/07/03/10anos-sed/

Em 2002 [...] vi meu nome no maior site nerd da época: o Slashdot. Mas o motivo foi meio frustrante para mim. Pra ver como as coisas são: o sedsed levou meses para ficar pronto e exigiu todo meu conhecimento de Sed, ao extremo. Mas o que me deixou “famoso” foi o trabalho de uma única noite: ter feito o jogo Sokoban em Sed.

http://aurelio.net/blog/2008/05/22/um-ano-de-miguxeitor/

O MiGuXeiToR correu o país pela Internet, divulgado pelo boca a boca, até chegar à mídia tradicional. Dei entrevistas, vi meu nome em jornais, até de um programa de televisão participei. Tudo muito rápido e inesperado, nada disso foi planejado. Sem querer eu tinha criado um viral.

Olha, esse negócio de comemorar 10 anos das coisas faz eu me sentir tão… velho.

Hoje, dia 15/3, exatamente dois anos e sete meses após o lançamento da versão 4, está saindo do forno a novíssima versão 5 do MoneyLog \o/

All your cloud are belong to us!

Eu estava desde o início de janeiro trabalhando nesta versão nova. Foram 300+ horas de trabalho, 400+ commits no SVN e muitos pepinos algorítmicos resolvidos. Este foi o maior pacote de mudanças desde o lançamento do MoneyLog em 2006.

• Quer interface nova? Tem.
• Quer integração com Dropbox? Tem.
• Quer interface pra smartphone? Tem.
• Quer relatório de tags? Tem.
• Quer somatório das linhas selecionadas? Tem.
• Quer proteger com senha? Tem.
• Quer plugins? Tem.
• Até site novo também tem :)

Se você nunca usou o MoneyLog, teste a demonstração online e veja se você gosta do jeitão dele fazer as coisas. Se gostar, você pode escolher usá-lo online ou offline. Aconselho também ler este pequeno texto, que explica a diferença do MoneyLog para outros apps financeiros. E não se preocupe, ele é gratuito :)

Se você já usa o MoneyLog, recomendo uma lida com calma no guia de novidades, para saber tudo o que há de novo. Você vai gostar! Não deixe de conferir também o MoneyLog Cloud, que é a grande estrela desse lançamento. Ah, e sabia que o Tab não é mais obrigatório?

Novatos ou experientes, também recomendo uma boa lida em dois guias novos que escrevi, dissecando dois assuntos quentes:

• Guia de Lançamentos
• Guia de Configuração

Ah, outra novidade. Agora estou usando um site para concentrar ideias. Teve uma idea pra melhorar o MoneyLog? Quer votar nas melhores ideias? Chega lá.

Bem, agora é contigo. Experimente, descubra, leia, atualize. Aproveite para renovar o assunto “finanças” em sua vida. Se você ainda não controla seus gastos, é uma boa hora para começar!

E se você gostar muuuito dessa versão nova, que tal fazer uma doação para este e-mendigo que vos escreve? :)

Fazer o software é uma delícia, mas aprontá-lo para o lançamento público, seja a versão inicial ou as posteriores, é um martírio.

Como neste exato momento estou passando pelo martírio, aprontando a versão nova do MoneyLog, quero compartilhar o que acontece.

A parte divertida

Toda a diversão de ser programador acontece antes, quando você tem a ideia em sua cabeça, amadurece ela, depois codifica o primeiro protótipo funcional, e vai aprimorando até chegar no ponto que o programa está bom para o seu uso.

Neste ponto uma decisão crucial: este programa viverá para sempre aqui no meu HD ou vou colocar no GitHub pra que outros possam usar também?

Àqueles que escolhem a primeira opção, eu entendo perfeitamente, pois publicar algo decente dá, muito, muito, MUITO trabalho.

Voltemos ao MoneyLog. Desde o início do ano eu comecei a trabalhar na versão nova. Todos os dias, várias horas por dia, totalizando 255 horas de trabalho até hoje. É um trabalho voluntário, não remunerado, que faço porque quero e porque gosto.

Foi cansativo, claro. Mas eu me diverti muito no processo, resolvendo os vários desafios que pipocam a todo instante. E o resultado me deixou muito orgulhoso, há várias novidades excitantes para anunciar.

Anunciar? Epa. Agora chegou a parte chata.

A parte chata 1: adaptar para uso geral

Para mim, para o meu uso, na minha máquina, no meu navegador, o programa está perfeito. Eu não precisaria mexer em mais nada. Mas como este é um programa que eu publiquei e lanço versões novas de tempos em tempos, ele não é mais só meu.

Ele tem vários usuários, cada um com a sua máquina, o seu navegador, as suas necessidades e o seu próprio nível de conhecimento sobre o programa e sobre as tecnologias que o cercam. Eu prezo pelos usuários e quero que eles tenham a melhor experiência possível com o software.

Assim sendo, não basta o programa funcionar na minha máquina. Eu tenho que conseguir testar em várias configurações e sistemas diferentes, para encontrar os problemas antes de lançar a versão nova. Não são problemas meus, eu não serei afetado por eles, mas isso será a diferença entre uma boa ou má experiência para um usuário.

Adaptar o programa para o uso geral leva tempo, é chato, e sempre vai faltar alguma coisa. Sempre vai ter um usuário com alguma configuração obscura que vai ter problemas, mas isso você só vai saber depois do lançamento.

A parte chata 2: documentação

Mas tá. Mesmo quando eu consigo testar tudo num número suficiente de ambientes e considerar que agora sim, o código está pronto, eu não posso simplesmente chegar e dizer:

“Daí galera, terminei a versão nova do MoneyLog, baixa lá no SVN”

Imediatamente, eu seria inundado com uma série de perguntas:

• Quais as novidades?
• Como usar as novidades?
• Alguma coisa foi removida?
• Tem uma lista completa de todas as mudanças?
• Vai funcionar no meu celular?
• Tem alguma incompatibilidade com a versão anterior?
• Se tiver incompatibilidade, como faço para resolver?
• Como faço a atualização?
• Se der pau, o que faço?
• Onde é o SVN?
• SVN?
• MoneyLog? :)

Entende? Não é assim que brincadeira funciona.

Não basta lançar somente o código. O programa não é somente o código. Deve haver documentação, você deve se antecipar às dúvidas dos usuários e colocar as respostas de maneira clara, seja no README, na tela de ajuda do programa, no manual, no website, onde for.

Se você não fizer isso, tudo o que vai ganhar é uma chuva de dúvidas, que terá que responder individual e repetidamente. Isso, é claro, se você conseguir despertar algum interesse. Um programa sem website, sem uma explicação ou demonstração de uso, dificilmente chama a atenção dos potenciais usuários.

Se você costuma “lançar” software desse jeito, apenas jogando o código no GitHub e achando que isso é suficiente, pare para pensar. Você não está lançando nada, só está salvando teu código num servidor público. Na prática, isso não significa muita coisa.

Mas eu só quero programar! :(

Eu também.

Mas isso só é possível se você fizer programas apenas para uso pessoal e nunca passar para nenhuma outra pessoa.

Porém, compartilhar é algo natural para o ser humano. Você teve trabalho fazendo o programa, é normal querer que amigos e outras pessoas usem ele também. Ou talvez você queira vender seu programa.

O fato é que, a partir do momento que você decide que seu código será usado por outra pessoa fora você mesmo, um universo de novas tarefas e novos problemas será colocado no seu colo e você terá que resolver.

Neste momento você entende que “ser programador” é muito mais do que digitar códigos.

Um exemplo real

Olhe a minha situação atual, de hoje. O código do MoneyLog está pronto no SVN. Não tem mais o que polir nem o que arrumar. Está tudo funcionando como deveria.

Então o que falta para lançar logo essa versão nova?

• Escrever a lista completa de mudanças desde a versão anterior (Changelog). Vou ter que ler todas as mensagens de log, de todas as mudanças, e fazer um resumão. Sabe quantas mensagens são? 500. FEITO
• Preparar um guia sobre as novidades, com fotos, demonstrando como usar. Ou quem sabe fazer um vídeo. Tanto para usuários novos quanto para os já existentes, demonstrar as funcionalidades é a melhor maneira de apresentá-las e ensinar seu uso.
• Escrever um guia de migração para usuários da versão anterior, pois há mudanças que quebraram alguns componentes. FEITO
• Escrever um guia sobre o Dropbox, que agora será possível usar para guardar os dados. Surgirão várias dúvidas, então um FAQ especial tem que ser feito. FEITO
• Escrever um guia sobre configuração, pois aumentou bastante o número de configurações disponíveis e não há documentação sobre elas. Se o usuário não souber o que há e como usar, que sentido faz haver configuração? FEITO
• Escrever um guia sobre os quatro “sabores” que o programa vai ter a partir de agora: Cloud, Browser, Portable, Beta. O usuário vai ficar confuso tendo que escolher uma versão para usar, então devo me antecipar e tornar essa decisão mais fácil. FEITO
• Atualizar o FAQ. As várias mudanças tornaram alguns itens obsoletos, outros ficaram mais simples e talvez alguns não funcionem mais. Preciso conferir um por um.
• Atualizar o website do programa. Ou melhor dizendo, refazer o website. Há muitas novidades, tenho que dar destaque para elas, e o site velho não vai encaixar. Também preciso “apresentar” o programa para quem não conhece. Serão muitos textos e screenshots novos, reestruturação de URLs, vai dar trabalho.
• Pescar o nome de todos que ajudaram a fazer essa versão, com código, com palpites e testes e fazer uma lista de agradecimento. Terei que vasculhar no Changelog, histórico do twitter, meu email e minhas anotações.
• Atualizar o arquivo PAD do programa, para que sites de download sejam notificados que há uma versão nova.
• Preparar as versões em inglês do programa e atualizar o minissite gringo.
• Escrever o texto de anúncio da versão nova, que será publicado aqui no blog, falando sobre os principais destaques e novidades. Uma vez publicado este texto, posso considerar a versão nova oficialmente lançada.

Essas são as tarefas maiores, que eu lembrei agora. Ainda tem as minitarefas tipo mudar o número de versão no código, gerar a versão final, marcar a tag no SVN, conferir links, anunciar no twitter, responder dúvidas pós-anúncio, entre outras.

Bem, mas é isso. Agora preciso voltar ao trabalho e dar um jeito nessa lista de tarefas, senão esse MoneyLog v5 não vai sair nunca :)