Musashi

Se você é daqueles que só compra livros de auto-ajuda e tem a esperança de um dia tornar-se tão rico e tão bem sucedido quanto a maioria dos caras ricos e bem sucedidos que escrevem esse tipo de livro, vou dar uma dica: Pare de comprar estas porcarias agora e compre Musashi. E não, eu não fiquei rico lendo esse livro, mas ele me deu alguns "insights" que ajudaram muito.


O livro conta a história de Myamoto Musashi. "O mais famoso samurai de todos os tempos" , que viveu nos ultimos anos do Japão feudal e virou lenda por seus feitos.

Embora Musashi tenha realmente existido (e até escrito alguns livros) o livro é uma obra de ficção, e conta a história de Musashi desde os seus 16 ou 17 anos, até a idade adulta, cerca de 30 ou 40 anos, se não estou enganado (li o livro à 7 anos atrás, perdão).

Musashi é um adolscente rebelde quando o livro começa. Filho de um famoso samurai, alista-se no exército e luta na batalha de Sekigahara. Depois disso volta para a vila e acaba sendo expulso pelos aldeões. Cai no mundo procurando por duelos e adversários que o tornem mais forte. Torna-se um rounin, um samurai sem mestre.

O que acontece nessa trajetória é a essência do livro. Um jovem que acredita apenas em sua força descobre que não é apenas isso que basta para vencer um duelo. Também são necessários concentração, estratégia, disciplina e um espírito preparado.

Durante a jornada, Musashi conhece a literatura, desenvolve gosto pelas artes, aprende técnicas de agricultura e por fim desenvolve um novo estilo de esgrima (com duas espadas, o que lhe deu a fama).

A história de Musashi mostra que não há atalhos no caminho do aprimoramento. Você deve aceitar que leva tempo até dominar determinada habilidade. E que no caminho você vai errar diversas vezes. O importante é refletir sobre cada derrota ("Porque perdi?") e não se vangloriar demasiadamente depois de uma vitória.

Também mostra que, para nos tornamos "completos" devemos adquirir e aprimorar várias habilidades ao longo da vida. Musashi aprendeu agricultura por necessidade. Numa analogia atual, imagine o que acontce com alguém que é muito bem remunerado pelo que faz, mas simplesmente não sabe como poupar ou investir esse dinheiro. Ou alguém que é muito bom tecnicamente, mas não consegue se relacionar com os colegas de trabalho.

Musashi inovou ao criar um novo estilo de esgrima que utilizava duas espadas. Mas isso só depois de muitos duelos com espadachins com estilos de esgrima variados e até contra outras armas diferentes da espada. Onde eu trabalho, buscamos inovação. Não basta acordar numa bela manhã de sol e dizer "Ah, hoje vou inventar algo novo!", ou correr até a livraria mais próxima e comprar "Inovação for dummies". É preciso vivenciar o processo, fazer parte de algo, só depois se consegue partir para novas idéias, e mesmo assim é difícil.

E finalmente, algo que acalmou muitos dos meus temores: "Quando achar que deve ser um general, seja um general. Quando achar que deve ser um monge, seja um monge". O significado disso eu deixo como exercício para o leitor.

Enfim, o que quero dizer com tudo isso é que muitas vezes saimos como loucos tentando aprender algo novo rapidamente ("Eu preciso aprender isso em um mês!"), porque algum babaca disse que a nova moda agora é o método-foobar-porque-fulano-fez-assim-e-ficou-rico, e acabamos desistindo no meio do caminho, ou adquirindo apenas um conhecimento medíocre e superficial sobre alguma coisa. Quando na verdade deveríamos estar tornando tal coisa um hábito, e praticando-a, em nosso próprio tempo, observando cada detalhe e aprendendo com cada erro.

A literatura pode até ajudar, mas não se esqueça de que você é quem tem que definir o seu estilo de esgrima.

O Dia D

Divisões aeroterrestres (pára-quedistas) e de infantaria, dos exércitos da Segunda Guerra Mundial eram compostas de

Grupos de combate (geralmente de nove a doze homens);
Três grupos de combate formando um pelotão;
Três ou quatro pelotões, formando uma companhia;
Três ou quatro companhias, formando um batalhão;
Três ou quatro batalhões formando um regimento;
Três ou quatro regimentos formando uma divisão;
Acrescidos de engenheiros, artilharia, serviços médicos e pessoal de apoio.

As divisões de infantaria norte-americans, britânicas e canadenses tinham o efetivo de 15.000 a 20.000 homens no Dia D.
As divisões aeroterrestres aliadas tinham cerca da metade desse efetivo.
A maioria das divisões alemãs tinha menos de 10.000 homens.

É assim que começa o livro "O Dia D", do escritor norte americano Stephen E. Ambrose.

Há exatos 63 anos, em 6 de Junho de 1944, a maior operação militar realizada em toda a história acontecia nos mares da Europa: O desembarque de milhares de homens, armas e equipamentos sob pesada artilharia alemã nas praias da Normandia.

A investida era composta por 175.000 combatentes - a maioria jovens entre 18 e 20 anos - 50.000 veículos, 5.300 navios de tipos variados e cerca de 11.000 aviões. Durou um dia e uma noite.

No lado dos Aliados, estavam o presidente Roosevelt, o primeiro ministro britânico Winston Churchill e o general Eisenhower, no comando da "Operação Overlord", cujo objetivo era atacar Hitler com toda a força e efetivo existentes de uma só vez, retomando regiões ao norte da França.

Do outro lado estavam Hitler e o Marechal-de-Campo Erwin Rommel. A esta altura da guerra, a Alemanha havia conquistado mais território do que podia defender, o cerco se apertava (os russos em Estalingrado e Kursk) e Hittler já estava surtando. Tinha obsessão por bombardear a Inglaterra e enviava ordens inusitadas à seus generais, que tinham que improvisar para conseguir atendê-las. À Rommel coube a tarefa de tentar descobrir onde e quando a invasão aliada aconteceria, ele apenas sabia que o ataque era iminente. Para se precaver, construiu bunkers e canhões ao longo de toda a costa francesa e encheu as praias de minas e barreiras para dificultar o desembarque.

A operação levou 3 anos para ser preparada. Os detalhes eram ultra-secretos, e apenas poucas pessoas do alto escalão político-militar sabiam de todos os detalhes. Os soldados foram treinados durante várias semanas sem saber para onde seriam enviados ou quando tudo ia acontecer. Tropas americanas, britânicas e canadenses e um número extraordinário de veículos e armamentos foram reunidos na Inglaterra. As praias onde o desembarque ocorreria receberam os codinomes como Omaha e Utah, Gold Juno e Sword, para evitar que as verdadeiras locações fossem reveladas.

Os primeiros à chegar foram os pára-quedistas. Seu objetivo era saltar atrás das linhas inimigas e atingir alvos estratégicos, tais como pontes, trilhos de trem e instalações elétricas, e também localizar os bunkers de artilharia para que os destróiers aliados pudessem fazer o seu serviço. Aviões C-47 e planadores carregando tropas e Jeeps entraram no espaço aéreo inimigo horas antes do Dia D e foram recebidos pelo chumbo grosso dos "flak" alemães. A artilharia atrapalhou os planos de salto e muitos pára-quedistas saltaram fora da zona determinada. Muitos morreram antes de conseguir saltar, e muitos outros morreram afogados ao aterrizar em campos alagados ou por fogo inimigo. Os que conseguiam chegar ao solo com vida tentavam a todo custo se localizar e reagrupar-se com seu pelotão. Caos total. Apesar da confusão, a campanha dos pára-quedistas foi bem sucedida.

Horas depois iniciou-se o desembarque das tropas. Diversos veículos foram projetados e produzidos específicamente para o Dia D, tais como o famoso LCVP (barco feito para o desembarque das tropas do navio até a praia, capaz de carregar 36 soldados), diversos tipos de tanques, tratores, motos e veículos anfíbios. Muitos afundaram antes mesmo de chegar à praia. Hora por causa da artilharia, hora pela imperícia dos navegadores e pelo mar revolto.

Para desembarcar a artilharia auto-propulsada, era necessário antes ganhar a praia. A unica maneira era desembarcar à pé. A vantagem do terreno e a força da artilharia causaram inúmeras baixas. A batalha mais sangrenta ocorreu na praia de Omaha, com cerca de 2.400 baixas. Pelotões inteiros foram dizimados. Quando os comandantes cogitaram recuar, soldados conseguiram se reunir em pequenos grupos e tomar a praia.

O Dia D provavelmente foi o começo do fim da guerra. Mas antes de serem postos em prática, os planos foram severamente questionados. Muitos achavam que Hitler, cercado e com os estoques de combustível se esgotando, não conseguiria manter suas posições fortificadas por muito mais tempo, sendo apenas uma questão de tempo. Essa opinião é mantida até hoje por muitos historiadores. Seja como for, a Overlord atingiu seu objetivo, ao custo de cerca de 10.000 vidas.

Bom, isso é só o resumo do resumo. O livro de Ambrose relata em mais de 700 páginas o planejamento, o treinamento dos soldados e e os combates travados por cada divisão. Ambrose mistura muito bem os fatos históricos e os relatos dos veteranos na narrativa. Recomendo à todos que gostam de ler sobre a segunda guerra.

Costuma-se dizer que "a história é escrita pelos vencedores". É verdade.

10 Lições Aprendidas

Trabalho com Linux e sofware livre de maneira profissional desde 1998. Mas nunca havia trabalhado de maneira tão direta e intensa como trabalhei no Tapioca nestes últimos dois anos.

Nesse tempo, recuperei minha fé no código aberto, que devo admitir, ficou um tanto abalada devido à certas experiências ruins (ou talvez pela minha falta de experiência). Tudo bem, quem trabalha com isso diariamente deve saber do que estou falando. Mas o importante é que de um jeito ou de outro, trabalhar em um projeto de software livre te ensina muitas coisas. Há muitas lições a aprender, e eu vou falar sobre algumas que aprendi nos ultimos anos.

1. Ame o seu projeto: É mais fácil quando a idéia foi sua e você começou a coisa toda. Mas as vezes você é simplesmente designado para trabalhar nele. Não importa. A única maneira de produzir algo com qualidade é abraçar a causa. Acredite no que está fazendo, codifique, revise o código feito, teste e refaça o que achar ruim. Pense no que pode ser melhorado. Procure features novas, organize o código, organize o projeto. É como estar à bordo de um veleiro. O trabalho nunca acaba, há sempre algo que deve ser feito ou observado, caso contrário perde-se o rumo.

2. Aprenda com ele: Na minha opinião, a oportunidade de aprender algo novo é a melhor parte do trabalho.

3. Estabeleça metas: "Quem não sabe o que procura, não vê o que encontra". Procure definir bem o que seu programa vai fazer. Feche o escopo, defina as funcionalidades prioritárias e estabeleça prazos para terminá-las. Aprenda a priorizar. Deixe estas metas claras para todos os desenvolvedores e usuários, em algum lugar que todos possam ver. Muitos projetos simplesmente não dão certo porque querem abraçar o mundo. Veja o Emacs, por exemplo. :)

4. Integre: De nada adianta todo o esforço se o que você fez não pode ser instalado em lugar algum. Uma interface gráfica que não segue as "UI guidelines" do Gnome ou do Kde, uma biblioteca compartilhada que sobrescreve uma previamente instalada por outro pacote, um framework distribuído que derruba o D-Bus, e por aí vai. Tenha em mente que você deve preservar a harmonia do sistema, e tentar ao máximo usar os recursos existentes no sistema antes de reinventar a roda. Por exemplo: use o D-Bus para trocar mensagens, o GStreamer para tocar músicas, o GConf para guardar suas configurações... Faça parte do todo.

5. Evite "forks": "fork" nesse contexto significa baixar o código de um projeto em um determinado momento e começar um novo projeto a partir do original. Os forks começam geralmente porque desenvolvedores ou empresas que trabalham com software decidem transformar um projeto em um de seus produtos e tem pouca experiência com comunidades de software livre. Até aí tudo bem, só que as alterações feitas nesse novo produto muitas vezes não são devolvidas como melhorias ao projeto inicial. No longo prazo, o projeto original tende a ganhar mais adeptos e a se desenvolver mais rapidamente. O projeto derivado acaba ficando para trás, porque a empresa ou o desenvolvedor não tem "fôlego" para acompanhar as mudanças. Dividir é enfraquecer.

6. Não corrija só os seus bugs: Você certamente vai utilizar componentes externos, e muitas vezes vai se deparar com bugs nestes componentes. Seu primeiro impulso é fazer algum tipo de contorno no seu programa para evitar o bug. Antes de fazer isso, tente outra coisa. Investigue o problema, se você se sentir capaz de consertar, o faça. Mande o patch para os desenvolvedores, sugira melhorias, ou ao menos relate o bug. Desta forma você vai ganhar parceiros importantes para o seu projeto.

7. Documente: Se você não souber explicar muito bem o que você fez, ninguem vai usar.

8. Ouça os usuários: Saint-Exupery disse que "Tu te tornas eternamente responsável por aquilo que cativas". Se seu projeto evoluiu o bastante a ponto de ter usuários, você está no caminho sem volta. À partir de agora você tem a responsabilidade de mantê-los satisfeitos, responder às suas perguntas e atender às suas solicitações. Aceite as críticas e avalie a viabilidade das sugestões.

9. Termine o que começou: Não deixe o projeto parado. Lance versões novas, conserte os bugs, responda às listas de discussão. De fato seu programa nunca vai ficar "pronto", mas deve haver sempre uma versão funcional estável.

10. Ninguém é santo: O open source é uma causa nobre, revolucionária, idealista. Mas isso não quer dizer que só existem pessoas bem intencionadas e dispostas a te ajudar de maneira incondicional. Tome cuidado com oportunistas. Libere o código, mas proteja suas idéias. Não permita que decisões chave para o seu projeto acabem em mãos erradas antes de você implementá-las. Nesse caso um projeto igualzinho ao seu pode aparecer muito rapidamente, e você não levará crédito algum por isso.

Nerds, o Juízo Final está próximo!

Você também é daqueles que vê todas essas atrocidades acontecendo mundo a fora e acredita veemente que o fim do mundo como o conhecemos está próximo. Você acha que nossa civilização já foi longe de mais? Você é nerd?

Então não perca a dica que o Marcelo Lira deixou para você, bem aqui.

Sacudindo a poeira

Depois de ler o post do meu amigo Aurélio, insinunando que meu blog estaria coberto de teias de aranha, me senti compelido a fazer alguma coisa a respeito.

Então, cá estou eu, escrevendo o que me vem na cabeça.

Ah Aurélio... aquela viagem foi massa. Tão boa que você a repetiu no ano seguinte, e eu e a Tereza fizemos um trajeto parecido 3 anos depois. E pra falar a verdade, acho que já é hora de viajar novamente.

Este mês faz 2 anos que estamos na Manguetown. Quando volto para o Sul? Não sei. Abandonei todo e qualquer plano de volta.

Para quem pensa em se mudar e morar em outra cidade, posso dizer que o período de adaptação é lento e muitas vezes doloroso. O choque cultural, o clima diferente, a distância dos amigos e parentes vão fazer você se sentir menor, mas não deixe a cidade vencer você.

A Família vai bem. O Vinícius completa 1 ano esta semana. É nesta semana também que comemoro um ano de noites mal dormidas.

No trabalho, um dos meus desafios tem sido tentar equilibrar a equação família / trabalho. Crianças pequenas nos exigem muito tempo, e o fato de sermos pais de primeira viagem faz esta parcela de tempo aumentar ainda mais. Por esse motivo, tenho realizado uma cruzada em busca da maior produtividade no trabalho e mais efetividade nas coisas que faço.

Passei boa parte destes 2 anos trabalhando no Tapioca. O que me foi muito gratificante e me deu a chance de aprender muito. Outra coisa legal foi o tempo no projeto. Trabalhar em algo por muito tempo te dá a chance de aprimorar, de pensar por vários ângulos, de entender o papel de cada parte, cada módulo. É muito diferente de fazer pequenas coisas em pouco tempo e nunca mais voltar a olhar para o que foi feito. Recomendo a experiência a todos os desenvolvedores.

Algumas mudanças aconteceram no início deste ano, e agora além do Tapioca, também estou cuidando de outros projetos, que vou deixar para comentar em outros posts.

Com estas mudanças me afastei um pouco (bem mais do que eu gostaria) do desenvolvimento, e tenho exercido tarefas mais administrativas. Tenho aprendido muito com isso, mas sinto falta do tempo em que os problemas eram apenas lógicos.

Falando um pouco de projetos, já trabalhei em uma empresa onde controle de projetos era rígido, pesado, complexo, estressante - Um amigo o classificaria como "soviético", mas "britânico" seria um termo mais apropriado.

Também já trabalhei em uma empresa onde não havia qualquer tipo de controle. Caos total e demandas paralelas nos matinham patinando no mesmo lugar por meses.

O grande desafio, acredito eu, está em encontrar uma forma que se encaixe no tamanho de sua empresa ou equipe, e depois lutar para transformar isso em um hábito. Não acredito que nada feito sem um planejamento e um método tenha algum futuro.

OK, chega. Isso foi suficiente para acabar com as teias de aranha.