opɐqǝq ɹopɐɯɐɹƃoɹd oʇıpןɐɯ

Novo endereço do blog - feuteston.com

2010-01-24T21:57:00.005-02:00

Senhores,

Vou mudar o blog para a wordpress, vou por num dominio e vou parar de blogar em português. Escrever em inglês ter uma série de vantagens, tais como:

- Como não é minha lingua nativa, tenho mais desculpas para erros gramaticais ;-)

- Posso pagar uma de bonzão escrevendo em inglês, já que, como disse o @aldrinleal, eu fui alfabetizado em inglês ;-)

- Ok, agora o único motivo sério mesmo: percebi que muito material que eu leio é escrito em inglês por pessoas que não têm o inglês como lingua nativa.

Aahhh! Mas eu sou programador e não sei falar inglês! É raro, mas já conheci gente assim. Bixo, se alguém se encaixa nesta situação, vá estudar inglês. Pelo menos saber ler sem dificuldades é obrigação e facilita muito a vida!

Não que eu tenha escrito algo realmente novo ou bom neste, sei lá, mais ou menos 1 ano que escrevo aqui. Mas o analytics mostrou que tem bastante gente lê o que eu escrevo (e isso me deixa feliz pacas). Comprei o dominio feuteston.com já criei uma conta no wordpress para meus posts em inglês. Alias, o wordpress deixa o blogger morrendo de vergonha em termos de recursos e facilidade de uso. Sério mesmo.

Então é isso: atualizem seus agregadores RSS para http://feuteston.com (redireciona para http://feuteston.wordpress.com se o ip do godaddy.com não estiver na blacklist de seu firewall :D )

Ah, não tem nada de util ainda! Provavelmente só depois de fevereiro...

See ya!

Dead locks, programadores smarty pants e a api de concorrência do Java 5

2010-01-17T22:02:00.005-02:00

Antes do assunto do post, um pequeno "prefácio"

Trabalho faz algum tempo com Java e Java não é o tipo de linguagem que você precisa re-inventar a roda o tempo todo. Tem muita coisa pronta e muita coisa pronta é de qualidade. Os desenvolvedores Java de um modo geral trabalham em ambiente multi-thread o tempo todo e não percebem. Isto é ótimo na minha opinião, pois mostra que as frameworks estão fazendo um bom trabalho escondendo detalhes de implementação. Antes do projeto atual precisei usar threads poucas vezes em situações simples. Sem me dar conta, em ambas as vezes copiei objetos ao invés de compartilha-los e assim evitei problemas. Agora no projeto atual fui obrigado a estudar mais para evitar e/ou corrigir problemas. Vamos ao que interessa...

O que são os dead locks?

É quase um problema do tipo "ovo-ou-galinha". Imagine duas crianças chatas, uma falando pra outra: "só vou depois que ele for!". Da wikipedia:

"deadlock refers to a specific condition when two or more processes are each waiting for each other to release a resource."

Podemos pensar que se existir dois locks, A e B, e uma thread tentar adquirir os locks na ordem A, e depois B, e outra thread adquirir os locks na ordem B, e depois A, o risco de cagada é eminente! Vamos imaginar as duas threads trabalhando para adicionar uma nova linha em dois arquivos:

Thread 1: O arquivo lalala.txt é meu e ninguém mexe nele até eu terminar! Agora falta pegar o arquivo lelele.txt e adicionar uma linha a ambos. Alguém pegou o lelele.txt. Vou esperar até terminarem de usa-lo...

Thread 2: O arquivo lelele.txt é meu e ninguém mexe nele até eu terminar! Agora falta pegar o arquivo lalala.txt e adicionar uma linha a ambos. Alguém pegou o lalala.txt. Vou esperar até terminarem de usa-lo...

Repare duas coisas:

1 - Se estivessem mexendo em apenas um arquivo (um só lock envolvido), não teria problema; 2 - Se estivessem pegando os arquivos (ou locks) na mesma ordem, também não teria problema.

Ahhhh tá! Você como um bom programador "smarty pants" que é já pensou na solução para todos os problemas de concorrência do mundo: "Vamos usar um só lock global em tudo quanto é coisa que não tem perigo!".

Sinto dizer, mas você não foi o primeiro a ter esta "grande" idéia. No linux existia (ou ainda existe, não sei) o BKL, ou Big Kernel Lock, que foi criado para isso. Existia (ou existe, não sei) algumas linguagens de script famosas também fazem uso de mecanismos de lock global.

Tá, então, pensando de forma "smarty pants": Se todo mundo usa deve ser bom! Uma coisa é certa: evita problemas de dead lock.

A segurança vem com um preço: evita paralelismo. Todo mundo esperando um mesmo lock ficar disponível só irá deixar o ambiente menos paralelizável. Tá, então como fazer?

Um bom começo é evitar side-effects. Antes de falar mais sobre isso, é importante conhecer os locks envolvidos. Vamos falar de alguns deles agora:

Métodos e blocos sincronizados

Este é o lock intrinseco do Java. Num passo de mágica, ao adicionar a palavra reservada synchronized na declaração do método, ele não poderá ser chamado por mais de uma thread ao mesmo tempo. Assim ele irá usar o lock intrinseco da instancia atual. Se outro método tiver esta palavra reservada ele será sincronizado usando o mesmo lock. Outra forma, é usar o lock intrinseco de outro objeto. Por exemplo, sincronizando métodos:

class SynchronizedMethods{

public synchronized void doStuff(){

// lots of stuff...

}

public synchronized void doAnotherStuff(){

// lots of stuff...

}

E sincronizando usando o lock intrinseco de outro objeto:

class SynchronizedMethodsTwo{

private final Object lockDoStuff = new Object();

private final Object lockDoAnotherStuff = new Object();

public void doStuff(){

synchronized(lockDoStuff){

// lots of stuff...

}

public void doAnotherStuff(){

synchronized(lockDoAnotherStuff){

// lots of stuff...

}

Na primeira opção os dois métodos não podem ser chamados ao mesmo tempo. Na segunda opção cada método não pode ser chamado ao mesmo tempo, mas admite uma thread chamando o primeiro método e outra thread chamando o segundo. Isso por que eles não usam o mesmo lock. Estes locks são "nativos" do Java. Em uma situação de dead lock a JVM para e imprime uma stacktrace dos objetos locados envolvidos.

Importante lembrar que estes locks intrínsecos do Java são reentrantes. Ou seja, a thread atual pode adiquirir um locks quantas vezes quiser. As outras threads só irão poder adquirir aquele lock quando a thread atual libera-lo o mesmo número de vezes que o adquiriu.

Algumas novidades do Java 5

Este mecanismo de uso dos locks é bem simples e poderoso. Mas no Java 5 a api de concorrência melhorou bastante e ganhou novos integrantes. Grande parte graças ao Doug Lea (sou fã deste cara!). Existem objetos como ReentrantLock ou ReadWriteLock, sendo o primeiro deles um lock reentrante que consegue escolher (quando o parametro fair do construtor for true) qual a thread que irá adquirir o lock baseado no tempo que a coitada está esperando. O ReadWriteLock consegue liberar sempre quem estiver lendo, e locar todo mundo apenas quando alguém estiver escrevendo. Boa abstração essa para o problema dos arquivos citado acima, imaginando que existem algumas threads lendo os arquivos e outras tentando escrever.

Existem os semáforos, que são locks que só deixam um determinado número X de threads adquirir o lock ao mesmo tempo. Podemos pensar no lock "padrão" como sendo um Mutex, ou seja, um semáforo de apenas uma thread permitida. Imaginando um sistema que só pode abrir 3 conecções ao banco de dados, o uso de um semaforo na implementação do pool de conecções pode ser coerente.

Existe também o CountDownLatch, que é um mecanismo que você precise acionar X vezes para desbloquear quem estiver chamando o metodo await dele. Exemplo de uso: estas threads que estão esperando só podem começar a trabalhar quando eu deixar (acionar X=1 vez).

Existem collections CopyOnWrite no Java 5. Estas collections copiam toda a estrutura interna cada vez que ocorre uma alteração. Com isso, iteradores ativos não precisam serem bloqueados cada vez que outra thread mexe nesta collection.

Existem mais coisas interessantes na api de concorrência a partir do Java 5. Para quem programa em Java com coisas não triviais sugiro dar uma olhada na api de concorrência do java 5 ou então ler o livro JCIP (que inclusive estou acabando, e considero tão importante quanto o Effective Java).

Caramba! Você falou que sincronizar é perigoso e depois ficou falando sobre várias formas de sincronizar! Não entendi...

Ok. A falta de sincronização é mais perigosa ainda! Eu deveria ter explicado sobre ela no início do post para fazer mais sentido. Mas vamos lá: Imaginem só duas threads tentando atualizar o número de acessos de um site numa variável "global". Imaginem isso usando o código abaixo:

código das Threads 1 e 2:

long numeroDeAcessos = NumeroDeAcessos.get();

numeroDeAcessos = numeroDeAcessos + 1;

NumeroDeAcessos.set(numeroDeAcessos);

Agora veja como o código pode ser executado:

thread 1: pega o numero de acessos com valor 10

thread 2: também pega o numero de acessos com valor 10

Daí as duas incrementam e atualizam. O valor real deveria ser 12, mas fica sendo 11. Isto ocorre por que a operação de ler, atualizar e escrever não é atômica. Para ser atômica, uma estratégia possível é executa-la dentro de um lock.

Esta foi uma visão macro de como acontecem as race conditions. Uma forma de evita-las é usando locks. Mas isto acontece também em operações do tipo atribuir variáveis e outras coisas bem básicas. A JVM e o Hotspot otimizam algumas operações copiando os valores para cache no processador e coisas do tipo. Até é possível falar para a JVM não fazer uso de cache para algum atributo com a palavra chave volatile, mas nem sempre isso é suficiente.

Ok, já estou assustado o bastante! Como que eu me livro destes problemas?

O principal é evitar os side-effects que existem as dicas no mesmo link que citei acima, sempre copie objetos ao invés de compartilhar. Quando compartilhar for necessário, pense e teste bem sua estratégia de locking, inclusive escrevendo testes que simulem o acesso concorrente. Evite uma estrutura complexa de objetos. Quanto mais simples estiver seu código, mais fácil de cuidar dele será. Isto também funciona no mundo da execução paralela. Minha sugestão principal é: estude linguagens funcionais. Mesmo que você não trabalhe com elas, poderá aprender muito!

(Ah, desculpem erros de português! irei revisar quando der tempo! :D )

E é isso! See ya!

Filosofia de boteco - feliz ano novo

2009-12-30T23:17:00.007-02:00

Este é um post off topic. O blog é meu e me reservo o direito de escrever bobagens (apenas?).

Como diria o Eric Cartman: "Respect my authoritah" or "I kick you in the nuts".

Pois é. Não gosto das festas de fim de ano pela hipocrisia alheia que se propaga. Planejei meus objetivos para o dito "ano que vem" já em agosto, e já estou "implementando" parte das coisas que planejei para o ano que vem. Mas independente disso tudo meu ano que passou foi bom.

Algumas lições que aprendi:

As pessoas não tem palavra. Eu me esforço para ter. Perdi muito e me tornei uma pessoa mais chata e madura depois de aprender esta lição. Ganhei muito em maturidade.
"A jornada é mais importante que o destino." Li isso num artigo sobre o Knuth. Ele ainda não terminou os livros dele depois de 30 anos escrevendo e mesmo assim realizou muito.
"Liberdade é uma outra palavra para 'nada a perder'." Li ou ouvi isso em algum material sobre o Steve Jobs. Me sinto livre em muitos aspectos.
"Se treine para deixar ir embora tudo do que você tem medo de perder." Isto aqui é parte da filosofia "self-less" dos Jedis. O Yoda falou isso para o Anakin e ele não seguiu a sugestão. Deu em merda no filme e dá em merda na vida real.
"Muitos dos obstáculos que encontramos estão na nossa cabeça." Li isso em algum livro de filosofia chinesa. Ainda estou aprendendo isso mas já pude constatar que é verdade :-)
"As pessoas mentem por vários motivos. Mas sempre existe um motivo." Vi isso assistindo House MD. O mais próximo que tenho feito ao invés de mentir é omitir. Não sei mentir. Mas sofri consequencias de mentiras alheias.
"Estudo é a única coisa que ninguém vai poder tirar de você. As pessoas podem roubar o seu dinheiro, mas nunca irão tirar de você algo que você aprendeu." Minha mãe dizia isso. Talvez essa tenha sido a única coisa que aprendi com ela. Mas sem dúvida foi das coisas mais importantes que aprendi em minha vida.
O principal: não culpe ninguém pelo seus atos e assuma o controle e a responsabilidade pelas cagadas e coisas boas que você fizer. Fiz muito isso. E vi muita gente (umas 4 pessoas que gosto muito) jogar muita coisa fora por falta de coragem de assumir o controle de determinadas situações. Não é fácil mas o resultado compensa. Principalmente a longo prazo.
Estou mais Joselito do que antigamente. Estou sem paciência para algumas coisas e isso tem me poupado dores de cabeça. Também estou Joselito pelo simples ato de "joselitar" em situações idiotas. Fiz coisas memoráveis este ano como sair correndo de sunga dentro de um supermercado numa cidade de interior e também pulei bêbado em uma pilha de caixas de sapato fazendo montinho (ou bolinho) com mais um monte de malditos programadores bêbados. Não tenho mais 15 anos, mas a minha vida continua divertida como na época dos meus 15 anos.
A galera "do mau" do kung fu é gente boa pra KCT. Estava puto um dia destes e ainda tive que ir no amigo secreto do pessoal do kung fu. Este singelo amigo secreto despretencioso se transformou num bate papo regado a cerveja e cachaça mineira que valeu muito a pena! Ganhei novos e bons amigos! Eu escrevi "do mau" por que eles foram os únicos "não geração saúde" que aceitaram ir beber comigo :-)
A vida nunca foi fácil para mim. Isso não significa que ela precise ser sofrida. Isso vale para tudo. Tive uma equipe de uns 15 programadores iniciantes e pude mostrar para eles na prática que produtividade pode ser obtida com bom humor e em ambiente agradável.

No meio desta filosofia de boteco barata tenho o resumo do que o ano que passou representa para mim. Fiz muita merda, mas as coisas boas superaram em muito as merdas que fiz. Posso dizer que estou muito satisfeito com o ano que passou. O ano que vem promete? Para mim ele já está acontecendo faz tempo.

Feliz ano novo a todos!

Git tips

2009-12-30T13:45:00.003-02:00

So, a lot of times I see some people anxious to use git. I started to use git a few months ago after loosing a lot of local changes during a huge refactor. At the first moment I just used git together with svn. The problems I faced was all related to svn. After some time and a lot of talk I could see my project scm been changed from svn to git. Everybody liked that. The only thing git isn't good is Windows support. This is really weak. A good option to use at Windows should be mercurial. I won't write a post about git or how to use it. There's a lot of good posts about that. I just gonna put the links that was useful to me.

http://git.or.cz/course/svn.html

http://metypefunny.blogspot.com/2009/01/git-it-together-with-subversion.html

http://github.com/guides/git-cheat-sheet

http://stackoverflow.com/questions/629048/git-svn-dcommit-error-restart-the-commit

Just start to use without much study. After a while it will be natural. Git doesn't need to have a ui tool. The commands are really easy. I use at macos the GitX. But GitK (which comes with git) can be used as well.

A good friend just told me that "Linus gave the world a wonderful gift by developing git. Better than linux.". IMHO sometimes I agree. :-)

I hope you guys enjoy git as much as I do.

Relembrando velhos tempos...

2009-12-21T23:52:00.004-02:00

Este é um post off topic. O blog é meu e me reservo o direito de escrever bobagens (apenas?). Como diria o Eric Cartman: "Respect my authoritah" or "I kick you in the nuts".

Brincadeiras a parte, vou falar de alguns eventos engraçados que contribuíram tanto para a minha vida profissional quanto para a vida pessoal durante minha infância e adolescência.

Morava na praia e era bem moleque. O filho de um dos diretores do jornal da cidade da época era meu melhor amigo e eu vivia na casa dele. Sempre tive curiosidade de "mexer em computador". Embora eu não soubesse ao certo para que servia aquilo, eu me lembrava de filmes de ficção sempre que via um computador. O pai do meu amigo me emprestou um TK-85. Ele vinha com um tecladinho com teclas de borracha com a letra e um comando de BASIC escrito em cada tecla. Eu não fazia a menor idéia do que era isso, mas eu tinha que digitar um programa para poder escrever. Por default ele escrevia os comandos em BASIC quando uma tecla era pressionada, e para poder escrever meu nome eu precisava digitar um programa (mínimo). Para mim aquilo era uma eternidade. E, como eu diria na época: "é mór legal!".

Agora eu tinha um computador em casa! Consegui um livrinho de programas, que na época já era velho! Tinha até um joguinho o qual você controlava um tirinho que deveria impedir que uma navinha tosca pousasse e "invadisse a terra". O legal é que por default o tirinho já acertava a nave. Sou folgado desde aquela época: enchi o saco do primo de um amigo meu, que eu achava que era programador, para ele digitar o código do joguinho para mim. Na época eu não sabia gravar o código em fita cassete (e graças a Deus eu não me lembro como faz isso hoje em dia!). Então eu devo ter jogado aquele jogo uns 10 minutos e deixei o computador ligado para não perder o que estava digitado. Lógico que alguém que foi assistir alguma novela desligou o computador. Foi a primeira vez que eu perdi um trabalho não salvo. Mais tarde descobri que o primo do meu amigo foi trabalhar com manutenção de computadores. Por ironia, eu virei programador e ele não.

Um lindo dia o fio da fonte se rompeu. Eu morria de medo do pai do meu amigo, mas eu tinha que avisar a ele que eu havia quebrado o computador dele. Quando cheguei na casa do meu amigo, o pai dele não estava. A mãe dele pegou o saco plástico preto que eu havia colocado o computador e colocou direto no lixo. E ainda disse: "Ahhh não, ele não vai ficar guardando estas porcarias!". Hoje imagino que se fosse comigo eu teria ficado muito puto :-)

Passou algum tempo e podíamos brincar no 486 que tinha na sala. Meu amigo me ensinou a programar. Fazíamos scripts para Mirc para poder derrubar usuários por flood. ICQ ainda não estava pensando em nascer e MSN era apenas uma sigla que aparecia em um screenshot na instalação do Windows 95. Não, o MSN não era chat na época.

Alguns meses se passaram e eu ganhei um XT. Sim, as pessoas tinham 386, 486 e eu tinha um XT. Tinha drive de disquetes de 5,1/4''. Mesmo as máquinas atuais que possuíam "kit multimedia" tinham drives de 5,1/4'' e de 3,1/2''. Eu lembro que eu me achava novo por não conhecer os disquetes de 8''. Agora eu tinha DOS e um monte de disquetes com joguinhos, programas e afins. Como eu disse, eu morava na praia. Mofava tudo. Eu achava que apertar a tecla I para ignorar erros durante a cópia de arquivos era algo normal e já fazia isso sem pensar. Morria de inveja do pessoal que "sabia programar" e fazia aqueles arquivos autoexec.bat com menus numéricos para abrir programas.

Algum tempo depois, com uns 15 anos mais ou menos, comecei a trabalhar de office-boy. Pouco tempo depois eu consegui convencer sem querer um dos rapazes do meu serviço que abrir uma empresa de design gráfico seria um bom negócio. Colocar uma empresa na mão de um moleque de 16 (eu) e de outro de 18 não seria de qualquer forma uma decisão sábia. Mas a empresa não deu prejuizo. Conseguimos dividir os equipamentos quando a empresa foi fechada depois de 6 meses. 6 meses dormindo 3 horas por dia valeram a pena, apesar de eu ter repetido o colegial por falta. Então eu havia conseguido meu primeiro computador. Um MMX 233MHz com HD de 2gb e 32 mb de ram! A máquina do meu trabalho, que era ótima na época era um pentium 100MHz com 800mb de HD! Era como se hoje em dia eu tivesse um Macpro em casa!

Alguns anos antes uma mãe de um amigo meu me chamou para ensinar a mexer no computador dela. Era um Mac, mas infelizmente não me lembro o modelo. Eu expliquei a ela que ela tinha uma jóia em casa. Ela me insistiu para ficar com o computador e indicar um PC a ela. Eu convenci ela a, pelo menos, insistir mais, e não aceitei o Mac. Meus amigos queriam me matar quando ficaram sabendo. Me conhecendo eu teria feito a mesma coisa hoje em dia :-)

Voltando ao MMX. Agora eu poderia fazer o que sempre quis: instalar Linux nele! Na época as revistas de CD que vinham com distros do Linux não eram tão populares. Com 1/3 do meu salário mais ou menos eu encomendei pelo correio o envio do Connectiva Linux "Marumbi". Esperei um mês e voilá! Não funcionava o X. Bootava no Windows o tempo todo para fazer qualquer coisa quando precisava. Fiquei sem paciência e desinstalei o Windows, pois eu deveria me forçar a aprender o Linux. Pelo menos eu aprendi a trabalhar no terminal!

O detalhe é que minha irmã estava fazendo faculdade. Ela pegava 5hs de ônibus todo dia, pois não tinha faculdade perto de onde eu morava. Ela fazia os trabalhos de faculdade na partição Windows e precisava do computador. Eu, joselito desde cedo, simplesmente removi a partição sem a avisar e ainda dei bronca quando vi que o Linux foi desligado incorretamente. Alguém lembra da mensagem do FSCK? E os 010100101001010101 do Lilo? Bons tempos aqueles!

Nesta época li alguma sobre uma linguagem de programação que funcionava em qualquer sistema operacional. Chamava Java e tinha "muitos comandos". Não sabia o que significava aquele monte de palavras public static void main do exemplo do hello world. Sequestrei uma apostila de Java de um amigo meu e tirei xerox de tudo. Li e reli umas quinhentas vezes. Foi quando um outro amigo me disse: "pra quê você quer aprender Java? Isso é lerdo!". Lerdo ou não, o engraçado é que eu trabalho com isso até hoje... :-)

Mais digressões a respeito de imutabilidade e multi-thread programming

2009-12-20T21:38:00.006-02:00

Acho que estou com vontade de falar bastante de multi-thread e de linguagens funcionais nos últimos tempos, por que o assunto tem sido fonte tanto de alguns problemas que tive que resolver quanto de códigos animais no projeto em que trabalho.

Falei de side-effects no penúltimo post, mas ultimamente acabei me deparando com linguagens de programação, sistemas de controle de versão, banco de dados orientados a documentos, filesystems e outras coisas que me fizeram ficar mais curioso a respeito de alguns preceitos de imutabilidade. Inclusive eu achei este blogpost que comparava alguns dos itens citados. Vou falar um pouco como cada uma destas ferramentas fazem parte do meu dia-a-dia e depois vou falar das semelhanças.

Mudando de SCM

Faz alguns meses que consegui convencer o povo do meu serviço a abandonar o SVN e usar o GIT, mesmo eu não tendo testado sequer um plugin de Eclipse para GIT. Quem trabalha de fato com uma ferramenta que funciona bem em um ambiente que a produtividade é obrigatória sabe que não é fácil abandonar um recurso de uma IDE (o plugin de subversion funciona). A proposta que eu fiz (enchi o saco do pessoal) era que: "os comandos são fáceis, não precisa da IDE e o GIT é rápido". Com alguns exemplos de criação de branch de forma rápida e usando o GIT local e remoto consegui mostrar o quanto o GIT é bom. Infelizmente a implementação no Windows deixa bastante a desejar (na minha opinião isto é grave), o GIT está nos ajudando bastante!

Como diabos o GIT consegue tanto desempenho? Não conheço muito o funcionamento interno do GIT, e apesar de ter baixado o fonte, ainda não sou fluente em C. Mas parte da mágica do GIT está em estruturas append only onde ele guarda os conteúdos de arquivos e também as árvores dizendo quais conteúdos fazem parte de quais commits. Compactando os blobs e usando SHA-1 para identificar unicamente cada commit, o funcionamento interno é simples (perto do que poderia ser). Inclusive existe o comando git gc para eliminar blobs e outras estruturas internas não utilizadas (imaginando que algumas branches podem ter sido excluídas). Na parte "Implementation" deste link tem alguma explicação rápida das estruturas do GIT, e neste tech talk eles falam disso.

Erlang e CouchDB

Existe um ôba-ôba em torno do Erlang (acho que está acabando, mas kind of está na moda). É uma linguagem de programação concorrente, todo mundo acha legal e ninguém conhece. Eu adoro, mas eu estudei bastante para dizer isto e já fiz alguns testes de performance. É uma linguagem muito simples e que te obriga a pensar de maneira diferente. Em troca, o multi-thread programming fica mais fácil!

E agora o ôba-ôba mais recente está em torno do CouchDB. Definindo o CouchDB de forma rápida: ele persiste estruturas JSON e aplica map-reduce nelas para consultas. Está sendo feito para ser seguro e dar conta de uma demanda bem pesada. O legal é que ele realmente veste a camisa do HTTP.

O uso do CouchDB é simples demais. Inclusive aplicar map-reduce em estruturas JSON fica parecendo tarefa de criança. Gostei demais dele por estas questões.

O cara do Cassandra falou algumas questões pertinentes a respeito do CouchDB. Independente do uso de espaço em disco no CouchDB ser massivo, ou de ele contar com replicações em servidores, mas não necessariamente ser uma persistência distribuida de fato, o CouchDB tem suas vantagens e seus motivos para estes defeitos. O uso massivo de espaço em disco diz respeito a estrutura interna de append only para salvar itens novos, ou mesmo novas versões do mesmo item. Ele nunca escreve nada por cima de nada. Ou seja, o que foi salvo está seguro. Por isso o "relax" em seu slogan. A estrutura JSON é salva em uma B-Tree e isto tem suas vantagens, conforme descrito aqui.

Ou seja, no CouchDB as estruturas append only conseguem aumentar a performance (pelo não uso de locks) e manter os dados íntegros.

ZFS

O ZFS é o melhor sistema de arquivos que existe atualmente. Mesmo.

Eu lembro que a primeira coisa que ouvi falar do ZFS foi que o cara do Linux estava puto com o cara da Sun por problemas de licença que poderiam impedir que o ZFS fosse portado para o Linux. Eu pensei comigo: O ZFS deve ser do caralho. Sim. Ele é foda!

Fazem algumas semanas fui no Sun Tech Days e assisti algumas palestras enquanto trabalhava. Eu estava empolgado para ver a de D-Trace e também de ir no laboratório de ZFS.

O ZFS tem muitas facilidades. Comecei a me sentir no passado por ver que não estou usando ZFS na minha máquina. O ZFS não precisa de particionamento. Jogue seus dispositivos em algum ZPool e saia utilizando. Crie backups com o uso dos snapshots e durma tranquilo. Tem uma pasta de usuário padrão? Faça um clone. Os comandos são simples. Os snapshots e clones são feitos através de lógicas de escrita append only. É lógico de os dados antigos são desconsiderados, mas a escrita atômica é feita primeiro se escrevendo os blocos novos e depois mudando os ponteiros da estrutura de dados na HD dos blocos antigos para os novos. E um snapshot ou mesmo a estrutura de pastas atuais é definida através de ponteiros apontando para blocos. Os dados não são replicados em disco e os blocos possuem um contador de referência. O bloco que tiver zero referências pode ser desconsiderado.

Mais um LISP???

A primeira vez que eu vi um LISP eu fiquei assustado com os parênteses. Quando tentei estudar pela primeira vez, cada hora que eu entendia algo me sentia ficando mais inteligente. Este post do XKCD descreve um pouco do que eu sentia conforme eu ia entendendo alguns conceitos de LISP.

Toda a vez que eu vejo uma linguagem bem falada para a JVM eu fico com preconceito inicial, mas muitas vezes depois de ver os motivos envolvidos para a criação da linguagem eu começo a gostar muito. Foi assim com Scala e foi assim recentemente com Clojure. Este vídeo descreve alguns aspectos concorrentes do Clojure e as estruturas de dados persistentes.

Estas estruturas são imutáveis para conseguirem ser multi threaded. O persistente neste contexto não quer dizer que vai ser serializado no banco de dados ou em algum outro lugar. Mas sim que as estruturas são versionadas internamente. Por exemplo, os lists e maps do Clojure são imutáveis. Mas a cada inserção é gerado um list ou map novo. Este comportamento append only é possível com performance satisfatória pois os elementos internos são compartilhados entre as versões antigas e novas dos maps e lists.

Okay, você falou de um monte de coisas mas não falou de multi-thread ainda...

Pois é. Falei bastante de append only. De fato os programas e ferramentas que apresentei aqui não tem um multi-thread explicito. Mas muitas das coisas feitas nestes programas são boas práticas de multi-thread programming.

Programação concorrente consiste em ter várias linhas de execução acontecendo (ou parecendo acontecer) ao mesmo tempo. No entanto muitas estruturas de dados não são thread safe pelo fato de serem mutáveis. O legal de pegar problemas com estas coisas é que você roda um teste. Uma vez funciona e na vez seguinte não. É totalmente não-determinístico. O append only é uma forma de "simular mutabilidade" sem afetar as threads que estão usando a estrutura antiga. Isto funciona bem para o CouchDB, para o GIT, para os snapshots e clones do ZFS e para as estruturas persistentes do Clojure.

O cara do Clojure disse uma frase ótima: "Mutable objects are the new spaghetti code". Estes programas mostram ótimos exemplos de como estruturas append only podem ser usadas para atingir objetivos de código seguro, simples e side effect free.

E é isso! See ya!

Estudo de caso: servidor de objetos remotos do OSL

2009-12-10T21:39:00.008-02:00

Um rápido overview de um dos módulos do OpenSpotlight

Trabalho no OpenSpotLight. O OSL é um motor de busca TI, feito em Java, que faz o parsing de várias linguagens e captura metadados dos fontes e coloca isso dentro de um repositório de maneira organizada. Através destes metadados é possível descobrir as dependências entre os diferentes fontes, seja de uma aplicação ou de várias aplicações. Não vou entrar no mérito de explicar todo o processo do OSL neste post, mas sim em um post futuro.

Mas voltando: Falei dos metadados do OSL. Estes metadados são persistidos por uma API de Grafo que pode guardar os metadados e ainda efetuar selects, seja por chamadas fluentes do tipo select().all().from().nodes(), ou por selects feitas em SLQL (SpotLightQueryLanguage).

O módulo do Grafo foi desenvolvido por um de meus amigos do trabalho, o Vitor Hugo Chagas, e o parser foi desenvolvido por outro dos meus amigos do trabalho, Alexandre Porcelli, especialista em parsers, que diga-se de passagem, também é commiter do Drools, Hibernate e JBoss DNA.

Okay, mas onde diabos está o assunto do título do post? Cadê os objetos remotos?

Um módulo como estes é interessante demais para ser enclausurado em uma JVM. Aliás para o OSL ser usado de forma plena, é necessário que estes objetos e o engine de query estejam disponíveis para uso remoto.

Ficou na minha mão deixar este módulo ser usado remotamente. Um belo desafio!

Ooops! Por onde começar?

Pensei nisso muito mais do que se imagina. Quem me conhece sabe que eu tenho horror em tentar reinventar a roda. Possibilidades? Cadê as possibilidades?

EJB - precisa criar as interfaces e um monte de configurações na versão 2. Na versão 3 precisa de algumas anotações e também existem premissas de não usar coisas "não normais" como threads, native methods e coisas do tipo. Estas premissas são feitas para deixar possivel de clusterizar os EJBs.
RMI puro - Apenas invoca métodos. Não cuida de grafo de objetos retornados e coisas do tipo.
CORBA - Burocratico.
(re) Fazer o módulo pensando que ele seria usado remotamente - Já tava pronto e refazer tudo é inviável.
Fazer um servidor de objetos remotos e rezar para ele conseguir expor o Grafo.

Tentei a penultima opção primeiro. Tentei alterar o Grafo para que ele se tornasse um servidor de objetos. Meti o pé na jaca. Joguei minha branch do git fora e acabei ficando com a ultima opção por falta de escolha. No entanto ao invés de rezar eu tinha a premissa de que os objetos remotos deveriam responder aos testes do Grafo já prontos quando estes fossem aplicados aos objetos remotos.

Agora eu tinha que fazer um servidor de objetos remotos...

Eu deveria expor a árvore de objetos existente no servidor para um dado cliente. Não existe a necessidade de vários clientes enchergarem um mesmo objeto, ou de objetos stateless. A necessidade é simplismente que o cliente possa criar uma arvore de objetos dele no servidor, usar como se fosse local, e deve existir um critério para exclusão destes objetos. Começa o brainstorm...

Qual o critério para criação de referências remotas?

Eu tinha que pensar num critério. Fui pegando as classes e dando uma olhada: SLNode precisa ter referencia remota? Sim. SLGraphSession? Sim. String? Não. Number? Não. Date? Não. Rapidamente tive "o estalo". Os objetos com referência remota deveriam ser todos os não serializables. Então, cada um destes objetos não serializáveis devem estar disponíveis no servidor. Criei um DTO que contém estes objetos e um ID na forma de uma String gerada a partir de um random UUID do java.util. O legal da história é que se algum método retornar um DTO Serializável não será criada a referência remota. Se um método retornar um objeto que exista no cache remoto de objetos do usuário, basta retornar a mesma referência remota. Através deste mecanismo do objeto ser ou não serializável é possível controlar o fluxo de criação de objetos remotos.

Cada usuário/ip possui um cache de objetos remotos preenchidos por demanda. Um usuário não encherga objetos de outro usuário. Um usuário atingindo o timeout configurado tem todos seus objetos perdidos.

Legal, os objetos estão no servidor. Como que eu uso eles como se fossem locais?

Existem duas formas de resolver este problema. Caso estejamos trabalhando apenas com interfaces é possível usar o proxy do Java. Caso estejamos trabalhando com classes, para interceptar-las e extender-las em runtime deve ser usado o CGLib. Usamos a primeira opção, mas o uso do CGLib é bem semelhante ao uso do proxy do Java. Existe um interceptor que passa o nome do método invocado com seus parâmetros. Existe a liberdade de jogar exceptions e de retornar valores.

A lib do client simplismente cria uma intância da classe/interface será usada como um proxy. Este proxy solicita a chamada de um método remoto que pode retornar uma referencia remota. Caso ele retorne esta referência remota, a referência irá efetuar uma chamada remota (RMI por exemplo) em um objeto remoto cada vez que um método for invocado.

Ao invés de expor o objeto "como ele é" eu expus um command que recebe os dados da chamada em dados serializáveis e o retorno por sua vez é um DTO serializável que possui os dados de objetos locais caso o retorno seja local ou serializável ou então um DTO que possui os dados da nova referência remota, caso esta seja necessária. Assim, as invocações de método funcionam como no pattern command.

O que foi trabalhoso aqui foi cuidar dos retornos Collection ou Map, pois estes tem que funcionar bem tanto para objetos serializaveis como para referências remotas.

Para invalidar as referências remotas, os métodos como close(), remove() e outros foram anotados com @DisposeMethod, e estes métodos anotados eram tratados no servidor como para removerem seu objeto após o retorno do invokeMethod.

RMI?

Foi o que eu pensei no inicio. Descobri que existe um projeto opensource chamado CAJO que facilita um horror a invocação remota. Inclusive não foi necessário mexer naqueles arquivos properties da JVM para dar permissões, como seria no RMI.

E aí? Deu certo?

Os cenários de testes estavam passando todos. Árvore de objetos contendo objetos como referência remota e serializáveis, collections e tudo o que mais imaginar. Auto-relacionamento e coisas do tipo. Tava tudo verde no JUnit. Coloquei o Grafo no servidor de Objetos remotos e fui rodar os testes. Tudo vermelho. Deu aquele frio na barriga. Pensei na hora: "será que vou ter que jogar meu trabalho de duas semanas no lixo?"

Fui percorrendo a arvore de objetos e vi que nas entranhas da api tinha um return de Map.values(). No Java, o Set retornado de Map.values() não é serializável. Substitui este e outros códigos semelhantes por new HashSet(Map.values) e os testes foram ficando verde aos poucos. Funcionou. Não foi fácil, mas funcionou. Tive que arrumar depois uns problemas que não apareceram no Java 5 mas apareceram no Java 6. Mas agora está tudo verde!

Qual é o recado do post?

Não reinvente a roda a não ser quando necessário. Dizer não a tecnologias consagradas (como EJB) pode ser necessário caso ela não resolva o seu problema. Principalmente quando seu problema não é trivial.

Abordagem funcional de fazer as coisas

2009-12-04T00:18:00.007-02:00

O que são side effects?

Antes de falar de multi-thread, vamos falar de side-effects. Li um artigo ótimo que perdi o link no blog do cara do CouchDB. Vou condensar um pouco do que eu lembro que li no blog dele.

Imagine uma função na sua linguagem preferida que faz uma soma. Ela se chama soma(a,b) e recebe dois inteiros primitivos (por cópia e não por referência), não possui nenhuma variável estática e retorna um inteiro

primitivo. Simples não? Eu posso chamar esta função quantas vezes eu quiser que não acontece nada demais. Posso passar 2 e 3 que eu sei que ela vai retornar 5 (caso esteja correta). Ela é fácil de testar, certo? Imagino que sim, por que o dia que testar a função soma não for fácil eu vou deixar meu cabelo crescer...

Mas continuando... Vamos chamar "isso que estou falando" de "fácil de testar". A soma fácil de testar segue abaixo:

int soma_lucida(int a, int b){

return a + b;

}

Está soma é esperada funcionar bem e não influenciar o mundo externo. Podemos chamar ela várias vezes, em paralelo, com vários tipos de processador, com vários alinhamentos diferentes entre jupiter e venus que sempre vai retornar o mesmo valor para os mesmos parametros de entrada. Normalmente as funções definidas na matemática são assim.

O estado e seu mecanismo opressor

Agora vamos introduzir coisas que irão deixar nossa soma mais "difícil de testar" ou de prever o comportamento. A primeira delas é guardar estado. Estou usando Cê-zão para mostrar isso, mas guardar estado é algo que fazemos ao usar orientação a objetos. Aquela flag inocente, atributos mutantes e coisas do tipo. Depois de terminar de ler este artigo eu espero que algumas pessoas entendam por que diabos String, Integer e afins são imutáveis.

Nossa nova função soma "mais difícil de testar" é esta:

int soma_calendario_maia(int* a, int b){

int result = *a + b;

*a += 2012;

return result;

}

Repare que ela recebe um ponteiro. Alguém resolveu mudar o parametro de entrada. O legal é que na primeira chamada ela retorna certo, e se chamarem com outro primeiro parametro ela vai funcionar. Vai passar no teste. Mas em alguma outra parte do sistema vai estourar algum problema. E para achar onde diabos foi alterada a variavel é bem chato, para não dizer outra coisa. Este é o primeiro Side-Effect ou Efeito Colateral. Ele é causado por que o estado (e não o Estado) de algum ponto do sistema foi alterado. Para testar, é necessário simular o estado esperado na primeira chamada da função.

Vamos versar sobre o mesmo tema (a opressão do estado na previsibilidade do código) com outro exemplo.

static int estado_interno=0;

int soma_gulosa(int a, int b){

estado_interno +=a;

return estado_interno + b;

}

Este aqui é mais "parecido" com o que ocorre na orientação a objetos com atributos mutáveis. O estado interno muda durante a chamada da função a cada vez que a chamada ocorre. Ou então alguém pode mudar o estado interno e o comportamento da função também muda. Eu lembro que antes de aprender a programar OO eu sempre escutava que variáveis globais não são legais. E eu me enrolava quando o programa crescia na época por abusar de variáveis globais.

Aqui para quem quiser ver a chamdada das somas e como elas se comportam:

#include

int main(void) {

int a1 = 2;

int b1 = 3;

int res;

int b4_a1;

int b4_b1;

b4_a1 = a1;

b4_b1 = b1;

res = soma_lucida(a1,b1);

printf("antes \n a = %d , b = %d \n soma_lucida(a,b) = %d \n depois \n a = %d , b = %d\n\n\n", b4_a1, b4_b1, res, a1, b1);

b4_a1 = a1;

b4_b1 = b1;

res = soma_lucida(a1,b1);

printf("antes \n a = %d , b = %d \n soma_lucida(a,b) = %d \n depois \n a = %d , b = %d\n\n\n", b4_a1, b4_b1, res, a1, b1);

b4_a1 = a1;

b4_b1 = b1;

res = soma_gulosa(a1,b1);

printf("antes \n a = %d , b = %d \n soma_gulosa(a,b) = %d \n depois \n a = %d , b = %d\n\n\n", b4_a1, b4_b1, res, a1, b1);

b4_a1 = a1;

b4_b1 = b1;

res = soma_gulosa(a1,b1);

printf("antes \n a = %d , b = %d \n soma_gulosa(a,b) = %d \n depois \n a = %d , b = %d\n\n\n", b4_a1, b4_b1, res, a1, b1);

b4_a1 = a1;

b4_b1 = b1;

res = soma_calendario_maia(&a1,b1);

printf("antes \n a = %d , b = %d \n soma_calendario_maia(a,b) = %d \n depois \n a = %d , b = %d\n\n\n", b4_a1, b4_b1, res, a1, b1);

b4_a1 = a1;

b4_b1 = b1;

res = soma_calendario_maia(&a1,b1);

printf("antes \n a = %d , b = %d \n soma_calendario_maia(a,b) = %d \n depois \n a = %d , b = %d\n\n\n", b4_a1, b4_b1, res, a1, b1);

return EXIT_SUCCESS;

}

E o output:

$ ./soma

antes

a = 2 , b = 3

soma_lucida(a,b) = 5

depois

a = 2 , b = 3

antes

a = 2 , b = 3

soma_lucida(a,b) = 5

depois

a = 2 , b = 3

antes

a = 2 , b = 3

soma_gulosa(a,b) = 5

depois

a = 2 , b = 3

antes

a = 2 , b = 3

soma_gulosa(a,b) = 7

depois

a = 2 , b = 3

antes

a = 2 , b = 3

soma_calendario_maia(a,b) = 5

depois

a = 2012 , b = 3

antes

a = 2012 , b = 3

soma_calendario_maia(a,b) = 2015

depois

a = 2012 , b = 3

Okay. Os exemplos podem ser artificias mas na vida real achar um bug causado por um estado alterado é algo realmente complexo. Como minimizar os side effects então?

Tendo uma vida mais saudável, com menos efeitos colaterais

Basta evitar guardar estado. Para evitar guardar estado existem algumas formas:

Usar funções que não mudem o estado interno. As vezes isto fica incomodo de ser feito, pois a tendência de criar funções que recebem muitos parâmetros é enorme. Isto pode ser minimizado com o uso de estruturas para agrupar as variaveis ou VOs. O código fica previsível, uma vez que basta popular os 500 mil parametros da mesma forma para ter o retorno desejado. Mesmo sendo incomodo de fazer isso, ainda é mais fácil do que gerenciar um grafo de objetos complexo o qual é formado de vários objetos guardando estado.

A outra forma é copiar dados sempre em variáveis imutáveis (ou constantes). Isto pode ser usado de forma defensiva em alguns casos. Por exemplo, vamos retomar a nossa soma calendário maia:

int copia_a1 = a1;

int copia_b1 = b1;

int temp = soma_calendario_maia(copia_a1, copia_b1);

int res = temp;

Paranoico, não? Pois é. O calendário maia poderia ter exercido seu poder nas nossas variáveis. Como foi feito cópia das entradas, a1 e b1 estão intactas. E o retorno usado será a cópia do que foi retornado, pois vai saber se dentro do calendário maia não foi guardado um ponteiro para o retorno. Esta estratégia é paranoica mas funciona. A desvantagem é que é uma cópia de dados desenfreada. Esta estratégia protege contra side effects. Em Java por exemplo, todo objeto é passado por referência. Alguém pode estar usando ele enquanto você executa um método. Se o objeto for imutável não tem problema. Se o objeto for mutável, copie os parâmetros de entrada antes de usar estes mesmos parametros. Com as classes Wrapper não existe preocupação, pois todas elas são imutáveis. O fato de usar um imutável ser bom, é que como ele não muda, não vai exercer side-effects. Isto não é genial?

Assobiar e chupar cana ao mesmo tempo

Vamos pensar que estamos usando apenas funções "faceis de testar", ou seja, sem side-effects. Estas funções assim são chamadas de puramente funcionais e são a menina dos olhos das linguagens funcionais. Erlang por exemplo não tem variável e te obriga a copiar tudo.

Vamos pensar na dificuldade de executar nossa função soma_lucida em multi-thread. Humm... não existe dificuldade alguma nisso! Outra coisa: Vamos pensar em executar algum processamento multi-thread em objetos complexos. Se estes objetos forem copiados e distribuidos sem serem compartilhados entre as threads não teremos maiores dores de cabeça. Ou então se tivermos como objetos compartilhados apenas objetos imutáveis também não teremos motivos para preocupação . Nem sempre isto é possível, mas se pensar nisso durante a concepção de um software sua vida pode ser bem mais fácil com isso.

Reparem que eu não falei uma vez se quer sobre locks neste artigo. Os locks são necessários para assegurar que um valor não está sendo lido em um estado intermediário, antes de ser alterado por outra thread. Se você for compartilhar objetos mutáveis, ai sim, boa sorte com os locks!

Reparem que falei de conceitos simples que podem acelerar o processamento multi thread de forma absurda!

Ah, e não pensem que tudo o que é mutável, compartilhado, guarda estado e afim é ruim. Mas para multi-thread nem sempre é coerente. Aqui eu falei de coisas que considero simples e boas práticas para processamento paralelo. Devo abordar isso um pouco mais em artigos posteriores com exemplos em Java.

See ya!

O que diabos eu tenho feito?

2009-12-03T23:59:00.005-02:00

Okay, eu tenho feito ultimamente:

Ho studiato una nuova lingua. Questo me piace molto, ma bisogno di studiare di piú perche non sono veloce per parlare.
Continuo estudando novas linguagens (de programação).
Livros na amazon. Meu cartão de crédito está com a lingua pra fora. Acho que todos os livros que eu gostaria de ter comprado na época que eu estava enrolado acabei comprando. Sou uma pessoa mais feliz com uma pilha de livros enorme para ler.
Trabalhando para caralho. Encarei refactorings grandes para melhorar a qualidade do nosso código do OSL. Pelo o que parece logo logo teremos um release bem funcional. Vou postar com prazer sobre o que diabos o software misterioso que trabalho é capaz. Já tive até que ler specs do JCP! Quem diria ein!
Estou praticando esportes pela primeira vez em quase 10 anos. Estou treinando kung fu estilo louva-a-deus do norte e inclusive já estou pegando armas (e eventualmente me machucando sozinho com elas!). Já perdi 15 quilos e melhorei em muito meu humor e minha disposição.
Ainda não consegui dominar o mundo. Eu tenho problemas menores e mais idiotas para me preocupar e por isso ainda não tive nenhuma idéia genial.
Meus gatos (tenho 2) estão ótimos e não estão mais vomitando bolas de pelo desde que comecei a escovar-los duas vezes por semana. O incrível é que a casa está mais limpa (mas não significa que ela esteja limpa).
Estou cada vez gostando mais de linguagens funcionais. Lê-se Erlang. Ah, e também estou me empolgando com o CouchDB. Vou fazer umas provas de conceitos puxadas para ver se ele segura a onda :-)
Visitei meus parentes. Depois de 5 anos vi meus avós. Consegui ver meu pai antes de ele ser chamado para trabalhar denovo.
O povo do O'malley's já está falando oi quando eu apareço lá. Acho que preciso beber menos, ou pelo menos com maiores intervalos.
Pelo menos umas duas vezes por semana estou trabalhando usando o wi-fi de alguma starbucks. Ajuda a renovar os ares.

Sobra tempo? Eventualmente sim. Mas faz quase um mês que não pedalo e nem corro. Preciso voltar a fazer isso...

See ya!

Help Desk Gratuito

2009-11-02T10:33:00.003-02:00

Neste feriado aconteceu uma coisa que não acontecia a tempos. Peguei uma maquina para arrumar! Como assim?

Quem me conhece sabe que se estiver alocado no cliente e der, por exemplo, problema na rede, eu não perco tempo para arrumar e ligo direto para o help desk. Trabalho desenvolvendo software e me esforço para fazer isto bem. Agora sou péssimo fazendo serviço de help desk. Estresso a toda, me machuco quando preciso abrir a máquina e normalmente perco horas e não resolvo nada. Uso Linux desde os 15 anos (não significa que eu seja bom nisso, só que faz tempo que eu uso :D) e conheço o Mac OS desde a versão 7. Estou usando em casa o Mac OS X faz mais de um ano. O que é isso? Pagação de pau para coisas não Windows? Não. Simplesmente não estou mais acostumado no Windows e nem sei onde diabos ficam as telas do painel de controle no Vista/Win7.

Demorei mais ou menos uns 5 meses para instalar o Wi-Fi em casa por preguiça. Na casa da minha família eu não arrumei o computador da minha irmã quando deu pau. Enfim, dá para ter ideia do meu gosto por manutenção.

Como quase todo mundo que eu conheço eu comecei em empresas pequenas, onde você é um misto de programador/suporte/suporte ao servidor. Descobri bem cedo que eu preferia estudar igual a um condenado pelo resto da vida do que mexer com estes problemas de hardware...

Okay. Já fiz um resumo do quanto eu gosto de manutenção. Agora sobre o porteiro: Um dos porteiros do meu prédio é bem legal e já me ajudou em uma situação que eu estava com uma pessoa passando mal em casa (ligou para o Samu e foi ligeiro, pois eu, na época bem cabaço, estava totalmente sem saber o que fazer). Fiquei amigo dele depois disso. E isso fazem anos.

Ele me perguntou se eu "não dava um jeitinho no computador dele". Por consideração expliquei para ele que "isso não é a minha área, fazem anos que eu não faço isso, trabalho com programação, etc" ao invés de ser mal educado com um seco "NÃO!".

Uns meses depois (sério, ele esperou meses) ele se fez de besta e apareceu com o computador. Segundo ele "precisava dum cd para instalar a internet". Pensei comigo: nem fudendo vou instalar estes modems onboard, mas não custa ligar para ver o que que é. Relutei para ligar uns 5 dias, e quando o mal humor de olhar aquela máquina fazendo parte da "bagunça natural de casa" superou o mal humor de mexer na maquina, pensei: preciso me livrar disso!

Fui ligar o gabinete. Preciso de um cabo AC, teclado e mouse. Oooops! Uso macbook! Eu estressei faz mais ou menos um ano e joguei minha tralha fora. Sem cabos, teclados e afins em casa! Mais 3 dias para pedir os cabos/teclado/mouse para o porteiro...

Ok. Agora (ontem) tenho tudo! Vamos ligar a máquina...

pí, pí, pí... tac, tac, tac...

Nunca ouvi tanto barulho! O estalo típico de hd com pau estava assustando meus gatos. Dei graças a Deus que mesmo que eu tivesse com boa vontade não poderia ajudar (é bom que dai não se acostuma a fazer isso toda a vez). Levei a máquina para ele. Expliquei: "tá vendo, não consigo resolver o problema, tem que levar para um cara de manutenção, sou programador, blá, blá, blá...".

Depois voltei para casa e pensei: Quantas pessoas que tem um carro falam para o amigo mecânico "dar um jeitinho no motor"? Esta história do "povo de mais idade" que dizem que "não entendo destes negócios de computador" algumas vezes é bem coerente. Já acho falta de respeito colocar as linguagens de programação no mesmo saco, imagina colocar manutenção e programação no mesmo saco!

Mesmo quando eu encho o saco da minha amiga médica eu pergunto com respeito e entendo o quanto ela se fudeu para estudar medicina e conhecer doenças e afins. Nunca disse que "essa dor de garganta é rapidinha de diagnosticar". Depois de participar de projetos gigantes e de ter que ouvir gerentes de comercial falando que este "recurso é rapidinho de implementar" ainda tenho que ouvir o porteiro falando a mesma coisa do problema no computador dele! É complicado manter a educação de vez em quando. Sou fã desta camisa do think geek inclusive! Vou acabar comprando uma destas em português qualquer dia :D

Ótima opção para tomar cervejas na Zona Norte

2009-10-11T22:29:00.003-03:00

Sem papo furado de "estou muito tempo sem postar nada" por que isso já encheu o saco.

Apenas um post sucinto e rápido.

Hoje fui no Empório Laura Aguiar, ou Bar do Zé para os amigos. O Zé conhece cerveja e ir para lá para ficar conversando uns 5 minutos com ele e entender por que diabos uma cerveja se chama "Old Engine Oil" e por que tem um rato na tampinha já vale a pena!

Para quem olha de fora o lugar parece um boteco... Agora depois de entrar no lugar já se pode apreciar a quantidade absurda de cervejas para todos os gostos (mesmo). Experimentei 3 Stouts que eu nunca tinha visto na vida já na primeira vez que fui.

Os petiscos são ótimos! Peguei uma linguiça com provolone e azeitona e uma porção de bolinhos de carne estilo Bar Barão.

Mas vamos ao que interessa: O Bar do Zé fica na rua Gabriel Piza, 559 tel 6977-0471, próximo do metro Jardim São Paulo. Eu com certeza volto lá mais vezes :-)

Home office e meu projeto atual

2009-08-10T23:33:00.006-03:00

Primeiro desculpas e blá blá blá: Peço desculpas pelo tempo que não escrevo. Era realmente divertido olhar os gráficos do google analytics e ver a cada post publicado mais visitas.

Pois é! Perdi a conta de quanto tempo faz que eu não escrevo no meu Blog. Estou fazendo home-office full time, e isso na cabeça de 90% da população brasileira é motivo para eu ter mais tempo para fazer outras coisas, como escrever no meu blog, correto? Pois é! Meu trabalho tem sido bem divertido e eu tenho realmente me dedicado bastante para escrever código de qualidade (ou pelo menos um código que eu tenha orgulho de mostrar).

Eu lembro que havia lido um post no blog do Fernando Roberto falando sobre as situações que ele passava no home office, e na época eu dei risada. Mas estou sentindo na pele quando saio de casa, as vezes para almoçar, e vejo o porteiro e o zelador me olhando com aquela cara de "o que diabos ele faz para pagar o aluguel?". Ou o pessoal engravatado do restaurante do lado de casa com aquela cara de incomodado ao ver um cabeludo de chinelo no meio dos engravatados. Eu mesmo me cansei disso, e quando não almoço em casa, vou na padaria da esquina, que é mais a minha cara e ninguém fica me olhando :-)

Eu já havia feito um mês de home office em outra empresa que trabalhei, numa empresa "séria" mais JEE e menos ágil. Quando se mantém uma distância segura entre trabalho e diversão, realmente fica simples "bater ponto". Eu sempre tive excesso de bom senso neste ponto e trabalhei sempre minhas 8 horas diárias direitinho, salvo raras e necessárias excessões.

Possuo um perfil JEE avançado. Já entreguei projetos e resolvi problemas bizarros que o pessoal de negócio inventava. Também já vi projetos não serem entregues por motivos políticos. Já fiz módulos de auditoria automática de persistência ou mesmo geração de código. Automação de tarefas e outras coisas que eu enchia o peito para falar: "sou foda". Sempre disse a mim mesmo: "Não preciso estudar mais nada de Java". Realmente, para as coisas que eu fazia, estava bom demais o conhecimento que eu possuía.

Pois bem, tudo o que eu sempre quiz aconteceu: Tenho um projeto home office. Mas esse não é o melhor. O melhor é: Core development na veia. Tenho problemas de baixo nível para resolver. Tenho que me preocupar com um monte de coisas. Processamento paralelo, elegância no código, testes, BDD, e etc. Foi quando eu percebi: Preciso estudar Java!

Terminei recentemente o livro Effective Java e devo ler logo mais o Java Concurrency in Practice e também o Livro de Generics. É impressionante o quanto a qualidade do meu código melhorou em pouco tempo. O mérito é dos autores dos livros, que são realmente fáceis de ler!

O projeto que estou trabalhando é open source, e logo mais, quando estiver mais "usável" eu devo postar pelo menos algo falando que saiu o primeiro release. O software propriamente dito daria um post enorme :-)

Voltando ao ponto do "manter uma distância segura entre trabalho e diversão". Hoje em dia esta distância é zero. A empresa que trabalho possui uma filosofia diferenciada, permeada de bom senso e open source. Isto tudo aumenta a responsabilidade por fazer um trabalho bem feito. O fato do meu código estar exposto no SVN também é motivo para "caprichar um pouco mais". Mas existem prazos também. Documentar, testar e codificar (nesta ordem) são coisas que tem acontecido naturalmente. Refactors grandes podem quebrar muitos testes. Mas aos poucos o código que tenho feito tem ficado mais do jeito que eu quero.

Estou trabalhando num time foda. Muitas vezes a competência do time passa por osmose, e tem feito um bem enorme para mim trabalhar com o meu time, e também ter contato com outros projetos open source.

Li um post uma vez, que prefiro não colocar o link (sim, fiquei P. na época) o qual um desenvolvedor baixo nível citava Java como sendo algo newbe demais para "programadores de verdade". O mesmo post falava que o autor não era tão bom, pois tinha programadores melhores programando foguetes e naves. Passou um tempo, e eu estava olhando o fonte de um dos projetos open source que estou usando. Resolvi olhar o linked in de um dos caras do projeto e vi que um deles antes de mexer com Java já havia programado software para projeto de aeronaves. Mas a qualidade do fonte não deixava mentir também. É bonito, coeso e limpo. Algo que fica simples de dar manutenção e mesmo de entender.

Sempre gostei de ver discussões sobre linguagens, mas sei que isso nunca levou a lugar nenhum. Mas ao mesmo tempo, estou permeando cada vez mais no Java e ganhando mais fluência na linguagem. Já percebi que tem muita coisa que não é trivial fazer em outras linguagens. Minha toolbox está cada vez mais madura, e minha pilha de livros para ler vai aumentando...

E é isso! Conforme eu for ficando mais livre, vou postar mais (e dormir um pouco menos)...

Melhorando a qualidade do código

2009-05-28T22:11:00.003-03:00

Nada do que eu vou falar aqui é novo. Mas muita coisa do que eu vou falar aqui você provavelmente não pratica. Eu tenho que me policiar para praticar coisas como Javadoc, TDD, e etc. Coisas tidas como frescura, mas que funcionam para deixar o código mais coeso.

Vamos começar do começo: Nomeando suas classes e métodos

Teve uma época que eu achava "testes uma frescura desnecessária" e também que "Javadoc é para os fracos: o código tem que ser legível". Ok, uma coisa não exclui a outra, mas em se tratando de qualidade do código existem pequenas regras que são encontradas facilmente no google, como por exemplo as regras citadas aqui, aqui e aqui que recomendam algumas coisas, tais como:

Nomes de classes sendo substantivos, em CamelCase com a primeira letra maiúscula, como por exemplo DataStore, ProdutoEmEstoque e etc.
Nomes de métodos sendo ações, em camelCase com a primeira letra minúscula, como por exemplo saveInvoice, validarEntrada e etc.
Nomes de interface sempre que possível como adjetivos, seguindo as mesmas regras da nomenclatura de classes, como por exemplo Auditable, Serializavel e etc.

O que eu acho mais legal aqui é: não estamos mais nos anos 80 e é possível colocar nomes legíveis. Conheço muita gente que diz que os nomes não podem ser muito longos, e também sempre tem um DBA pronto para impor regras de nomenclatura de tabelas que encaixam naqueles nomes estilo DOS do tipo NFFNEN. Ou então pode-se dizer que "vai estar na documentação". Eu penso sempre no pior cenário: estão vendo os fontes de sua classe no JAD. Um nome de variável grande e explicativo pode ser grande, mas é explicativo.

Se o seu método faz uma validação e muda um pequeno status o nome dele não deve ser apenas validar, mas sim validarAlterandoStatus. O ultimo nome é feio, mas não deixa sombra de dúvidas sobre o que ele faz para quem o usa.

O ideal é que alguém que não saiba programar consiga pelo menos fazer idéia do que o seu código está fazendo. Por exemplo: new File("aaa.txt").open() é mais legível do que fopen("aaa.txt") :-) .

Tá bom, vou fazer o JavaDOC...

Pois é: este vício eu comecei recentemente. Mesmo! Um amigo meu (que desenvolve pro hibernate) recebeu uma dica de um amigo dele (do hibernate) que diz o seguinte: "no JavaDOC explique para seu amigo imaginário o que a classe/método que você está escrevendo irá fazer". O legal disso é que você pega problemas conceituais ao explicar para seu amigo imaginário o que você quer fazer e o código fica mais bonito e de fácil manutenção.

Da mesma forma, no meu antigo emprego o pessoal chamava sempre alguém para servir de "rubber duck", ou "pato de borracha". Você simplesmente chama alguém para ficar do seu lado sem fazer nada. Explica o que não consegue terminar para este alguém e pronto! Você mesmo achou a resposta para seu problema. Na pior das hipóteses a pessoa te ajuda, mas isto era raro, pois normalmente quem perguntava e explicava o problema já tinha a resposta.

Mas fazendo o JavaDOC com a explicação além de ajudar e servir de referência mais tarde não para o trabalho de ninguém :-) .

Li também um artigo no coding horror que falava sobre os benefícios do pseudo código, explicando que você desenvolve e melhora a lógica enquanto escreve o pseudo código. Mais coisas boas para o JavaDOC.

Principalmente, nas classes principais faça uma boa explicação e um tutorial de como usar as classes ou artefatos. Depois de tudo isso fica fácil e útil rodar o javadoc ou mesmo o doxygen em seu projeto. Comecei a fazer isso e tem sido bom para todos que trabalham comigo! Inclusive eu!

Para que testes? Meu código funciona!

Parabéns! Você além de ser o melhor programador do mundo ainda sabe prever o futuro! Na prática a história é outra: Num cenário OO muitas vezes uma alteração em uma classe utilitária acaba influenciando uma parte crítica do sistema. Nestas horas o teste mantém o sistema em produção sem dores de cabeça.

O primeiro tipo, e mais comum são os testes unitários. Eles testam uma pequena parte do código (normalmente uma classe) considerando que o resto do sistema funciona. O legal de desenvolver testes unitários é que a classe fica mais facilmente utilizável e coesa. Por exemplo, hoje eu escrevia uma classe com alguns métodos privados que cuidavam de coisas baixo nível que não poderiam ser expostas. Eu precisava testar esta parte mas não queria expor estes métodos como métodos públicos daquela classe. Fiz o refactor e passei os métodos de baixo nível para outra classe, e testei unitariamente as duas. O código ficou mais coeso, reutilizável e facilmente testável.

O segundo tipo são os testes integrados. Estes testes testam a comunicação entre todas as classes de ponta a ponta. Podem ser testes que comitem transações no banco de dados por exemplo testando desde o objeto de negócio até as DAOs ou mesmo testando a interface com o usuário. Suas classes podem cumprir o papel e executar os testes unitários sem problemas e ao mesmo tempo ter alguma falha em arquivos de configuração que invalidem o pacote em produção. Os testes integrados pegam isso.

Ambos os tipos de testes (unitários e integrados) devem ser feitos de forma automática. E devem ser executados como parte do desenvolvimento (no maven2 isso é natural). A grande questão é: falhou o teste? tivemos problemas então.

Deixar a maior parte dos problemas precoçes é a melhor forma de evitar problemas em produção. Lance exception e invalide o seu sistema o quanto antes quando der merda. Com certeza alguém vai perceber e arrumar logo :-)

Espero que mais gente pratique estas coisas no dia-a-dia. Infelizmente as pessoas desenvolvem software como quem anda pelado no meio de um tiroteio. O teste é uma garantia. Por mais ruim que seja o teste ele garante que seu código faz algo. E quando ele parar de fazer algo você vai ficar sabendo.

Mais pubs e bares...

2009-05-11T22:52:00.006-03:00

Estes dias muitos problemas vieram a tona... E para compensar resolvi dar uma relaxada e tomar um chopp com alguns amigos no O'malley's...

Old Splecked para começar, seguida por uma Guinnes, New Castle (ruim!), e para fechar com chave de ouro Strong Suffolk e Albot Ale, ambas da Greene King, minha cervejaria inglesa preferida!

E no dia seguinte fui relembrar os tempos de Bar Barão. O falecido Bar Barão possuía IMHO o melhor chopp de São Paulo. Era um bar alemão que possuía além do melhor chopp o melhor custo-benefício. Bebia bem a noite, e comia muitos petiscos, bolinhos de bacalhau e carne, e no fim da noite a conta ficava em menos de 40 reais normalmente!

Mas enfim! Onde diabos eu iria achar um chopp comparável ao do Bar Barão? Na av lavandisca, próximo a avenida ibirapuera existe o Joan Sehn bar (procure no google o endereço). O chopp na temperatura e cremosidades ideais, e comida típica alemã da melhor qualidade :D

Vou voltar mais vezes para ambos!

Humildade faz bem, obrigado!

2009-05-11T21:35:00.004-03:00

Com relação a humildade conheço programadores dos seguintes tipos (por ordem de importância): metido e incompetente, inseguro e incompetente, inseguro e competente, metido e competente e humilde e competente.

O programador metido e incompetente é o pior de todos. Não é necessariamente alguém que está começando, mas um cara que se perde em sua mediocridade. Pode ter anos de mercado inclusive. É dos caras que valorizam a frase "em terra de cegos quem tem um olho é rei". Adora dar broncas e criticar mas não sugere nada que fuja do "arroz-com-feijão".

Me deparei com uns 3 caras assim em quase 10 anos de mercado aqui em SP. O primeiro tinha um currículo melhor do que o meu na época. O cara era tão bom e fazia tudo tão bem, que gastou mais tempo explicando como fazia tudo muito bem e não deu conta do serviço simples que eu havia passado para ele. Ele não durou 1 semana.

O segundo se achava tão competente que não sabia que desenvolver a melhor framework do universo levava tempo. E lá foi ele desenvolver a framework... durante quase 1 mês a framework iria ficar pronta no dia seguinte... Ninguém me ouviu e lá se foi o projeto...

O terceiro sabia tanta coisa e já tinha mexido com tanta coisa que mal soube explicar como fez qualquer dos seus milhares de projetos... Só repetia que já havia mexido com tudo o que eu possa imaginar, mas não citou uma framework sequer...

O programador inseguro e incompetente muitas vezes é alguém com pouca experiência, e que, por ser inseguro pode estudar e recuperar o prejuízo, acaba virando um programador competente.

O programador inseguro e competente é um programador que nunca acha que sabe o suficiente. As vezes se desvaloriza achando que sabe pouco, mas resolve os problemas que vê pela frente. É um dos melhores de se ter na equipe. E muitas vezes o mais confiável. O único defeito é não se valorizar o suficiente. É dos caras que se as empresas cuidarem bem cultivam por mais de 10 anos e a própria empresa irá crescer junto com o programador...

O programador metido e competente tem o defeito que é se achar bom pelo fato de ser bom. Não que isso seja uma atitude louvável, mas pelo menos o cara resolve os problemas. E tem mérito. É do tipo que é melhor não ter mais de um na equipe. Muitas vezes é um cara com perfil de liderança e que resolve os principais problemas. É um cara que merece ser valorizado. Eu já fui assim! Hoje sou só metido, rsrsrsrs ;-)

O programador humilde e competente é de longe dos caras mais foda. Eu queria ser mais assim, rsrsrsrs... Mas voltando a falar sério: Os melhores programadores, arquitetos e afins que eu conheci são humildes. A primeira característica destes caras é que inevitavelmente eles não sabem tudo! Olha só que legal: se você realmente tem muita experiência e muito tempo de mercado você sabe mais do que ninguém que se você não sabe algo você tem condições de ir atrás caso seja necessário. Você é referência para muitas pessoas e você tem muitas referências. Se você nunca fez algo você simplesmente fala que não sabe para não dar informações erradas para amigos e/ou colegas de trabalho. E o melhor: você não se sente ameaçado por não saber algo.

O que eu acho mais legal de ter muito tempo de mercado é poder tomar chopp com estes caras, que muitas vezes são verdadeiras lendas vivas e nem por isso vivem de ego cheio... E conheço muitos caras assim! :-)

DI com Guice

2009-05-03T22:17:00.004-03:00

Eu estava assistindo alguns dos Google Tech Talks, quando vi um vídeo sobre o Guice. O Guice é a framework de Dependency Injection feita no Google. Me perguntava sobre por que diabos alguém não iria usar o Spring para fazer DI em um projeto. Existem no google algumas comparações do Guice com o Spring como por exemplo essa, então para não ficar falando a toa coisas que podem ser achadas no google vou as minhas concusões rápidas:

Spring com XML fica "chato de gerenciar" com o tempo. O Guice admite configuração programática simples e isolada. Gostei da abordagem. E fica mais gerenciável do que Spring Autowired.
O Guice pode ter sua configuração programática modularizada. Achei isso genial!
Não vi nada sobre o Guice usar JNDI por exemplo. O Spring com certeza é mais maduro para tarefas do dia a dia.
Por outro lado, o Autowired com identificador em strings do Spring fica atrás das annotations customizadas do Guice. Tem que ler algo sobre, ou assistir o vídeo para entender o que eu disse aqui. Achei genial esta abordagem também!
O Guice foca em performance, coisa que o Spring Autowired pena um pouco. Mas o Autowired do Spring é mais automático e poderoso. Fiquei imaginando um projeto "arroz com feijão" no Guice, com um monte de DAOs configuradas na mão. Seria mais chato.
As formas que o Guice aborda o gerenciamento de escopo parecem ser mais flexiveis.

Não vi nada de AOP no Guice, mas no geral eu não gosto de AOP para fazer mais coisas do que Logs e gerenciamento de transações. Isso é algo que eu queria ver na prática como que o Guice funciona. Gerenciar transações é algo "chato" que o Spring faz muito bem... Ok, preciso ler mais um pouco sobre... :-)

Programação numérica e as ferramentas que conheci nos tempos de IFUSP

2009-04-26T07:12:00.004-03:00

Hoje me atentei para algo que já deveria ter postado sobre: programação numérica.

Intro

Quem me conhece pessoalmente sabe que fiquei uns 5 anos tentando fazer bacharelado em física na USP. Tive um monte de problemas pessoais que foram a desculpa perfeita para trancar a faculdade e ficar estudando programação por conta própria. Mas ao mesmo tempo, nestes 5 anos (que andaram apenas 2 anos e meio) aprendi muita coisa e mandei bem em assuntos que incluíam programação e o uso de computadores para ajudar a resolver problemas.

Laboratórios de física - um primeiro desafio estatístico

Os Labs de física são feitos da seguinte forma no IFUSP: Você deve reproduzir uma experiência do passado nos laboratórios didáticos. O material disponibilizado para os alunos, apesar de ser dos melhores da américa latina é tosco. E é tosco de propósito, pois a ideia é mostrar para o aluno como usar as ferramentas matemáticas para eliminar erros de medição. As ferramentas matemáticas usadas são... bem, na verdade é só uma: estatística.

Apenas uma chance para adivinhar qual programa tinha a honra de tratar dados dados retirado em até 3 aulas de 4 ou 5 horas? Excel. Sim, para um primeiro contato tava bom né? Tínhamos até uma planilha feita por um professor que fazia "sozinha" o gráfico dos mínimos quadrados. Nas primeiras experiências como o pêndulo que devia ter apenas poucas centenas de medições e apenas um gráfico para ser feito a planilha funcionava bem. Quando tive que fazer trinta gráficos já vi que a planilha não funcionava e fui atrás de ferramentas novas.

Ferramentas de programação estatística

Eu sou fluente em Java faz algum tempo e quando estou com pressa e quero resolver um problema logo normalmente escolho Java. Mas as ferramentas que encontrei em outras linguagens foram show! Curva de aprendizado mínima se a pessoa souber programar em algo e tiver algum controle do computador.

Sci-Py foi a primeira ferramenta que me fez fazer algo útil de forma elegante. Ela gera gráficos e resolve mínimos quadrados, gera histogramas, plota os mais diversos tipos de gráficos, resolve equações e etc. Pensem em: 30 medições x 20 pontos, retiradas de 5 vídeos gerando 30 gráficos e mais um ultimo gráfico e MMQ feitos a partir destas 30 medições. Foi feito tudo no Sci-Py. Nada de ficar puto com o excel travando! Meus problemas foram mais elegantes, como por exemplo "por que diabos isso aqui não tá certo?"

O R foi a segunda e melhor ferramenta. Uma linguagem funcional (na época eu nem sabia o que diabos era uma linguagem funcional) focada em resolver problemas estatísticos. Na página de entrada do R já dá para ver os gráficos que o R gera. Além de gerar gráficos o R resolve muitos, mas muitos problemas de estatística. E um ponto curioso que eu só vi no R e em nenhuma outra linguagem de programação: O workspace do R guarda estado. Por exemplo, você abre o shell, abre o shell do R em uma dada pasta, e carrega um array de valores em uma variável. Depois que você vai para a mesma pasta e abre o R de novo, pimba! Sua variável continua lá! Isso foi muito produtivo, pois eu ia tentando resolver os problemas e quando resolvia, se estivesse com preguiça de reproduzir tudo, não tinha problema. Meus valores continuavam lá e o histórico da linha de comandos do R também!

Resolvendo equações de forma simbólica

Conheci o Maxima e o wxMaxima (estenção do Maxima em wxWidgets) em uma matéria do ex-professor do IFUSP, Mário Ferraretto. Este professor tinha as matérias mais úteis e divertidas do instituto. Foi uma pena para o IFUSP ele se aposentar e me arrependo de não ter feito mais matérias com ele. Deixando a agua-com-açúcar de lado, o Ferrareto apresentou o Maxima para mim. Ela resolve equações de forma simbólica (integral, derivadas, etc), transformadas de laplace, e mais um monte de coisas que eu não tinha visto até então. Meus relatórios de Lab ficaram mais rápidos, pois eu poderia resolver as equações ou mesmo confirmar se a resolução que eu tinha feito sozinho estava correta! Essa foi uma das melhores dicas!

Gráficos com GNUPlot

Um dos meus melhores amigos fez Cálculo Numérico em outra turma, e acabou pegando umas equações em 3 dimensões para resolver. A resolução foi feita em C mas os gráficos foram feitos no GNUPlot. E na boa, os gráficos ficaram legais pacas! Parecia coisa de filme de ficção!

Ferramentas que estudei pouco e vou dar mais atenção quando tiver tempo

Deveria ter estudado Octave (versão opensource que compete com Maple, que também não tive contato), e principalmente deveria ter brincado mais com o Root.

O Root é um projeto de bibliotecas físicas em C++ focadas em física nuclear e de partículas. Substituto do PAW, uma ferramenta antiga feita em Fortran, o Root é usado até para cálculos com dados retirados do LHC por exemplo, além de dados do CERN em geral.

Se você gosta de física, ou mesmo de ficção científica, vá no youtube e procure por CERN, LHC e coisas do tipo que será divertido!

Linguagens funcionais: uma ginástica mental

2009-04-20T21:46:00.005-03:00

Linguagens funcionais tem tido alguma prioridade no meu "scheduler de estudos". Não sou um especialista em funcionais, mas apenas um entusiasta... E tenho ficado cada vez mais entusiasmado com linguagens funcionais...

Estou lendo aquele livro de Erlang da série do Pragmatic Programmer... E o mais engraçado foi que uma vez um amigo meu que está usando F# faz algum tempo me disse que ao estudar linguagens funcionais você acaba mudando seu jeito de programar.

Uma característica de linguagens funcionais (pelo menos de Erlang) é que não existem variáveis, mas apenas constantes. E com isso percorrer listas tem que ser por recursividade, pois não temos como ir alterando as variáveis dentro de um while. Tail recursion aparece nestas horas.

Ao invés de:

for(int i=0;i<size;i++){
// faz algo com array[i]
}

temos

faz_algo([]) -> 0 ; %apenas para casar o tail recursion no final da lista
faz_algo([H|T]) -> % faz algo com H e chama faz_algo(T)

Não temos um loop explicito, mas sim funções que são chamadas recursivamente de acordo com os parametros passados... Por exemplo, o for vira duas funções: uma para aceitar lista cheia e outra para aceitar lista vazia. O barato é que o loop vira naturalmente chamadas de função. E inner loops viram chamadas de função. Não teremos milhares de loops alinhados, o que iria dificultar a leitura do código. Ou alguém gosta daqueles códigos que parece desenho de escadas?
O mesmo se aplica para os IFs:

Ao invés de:

if(i==0){
// faz algo
} else {
// faz outra cosia
}

temos

func(0) -> faz_algo;
func(N) -> faz_outra_coisa .

Naturalmente as linguagens funcionais evitam condicionais e loops pois a runtime acaba casando as chamadas de acordo com o padrão. Ele tem a inteligência de quando o input da função for 0 ele chama a primeira, caso contrário chama a segunda. E o código fica naturalmente legível mais uma vez.

Temos também as variáveis que não variam! Para que servem então? Ajudam a manter o código legível, mas por outro lado não deixam dúvidas sobre onde em que parte do código tal valor foi inserido e gerou mudança. Por exemplo: imagine um código comum de umas 2000 linhas. Imagine a variável x mudando N vezes no meio do código, e o bug sendo causado por um valor errado em x. Em Erlang, teremos que criar uma nova variável para cada atribuição de x. O ponto de erro ficara mais claro, pois o erro vai estar na x1, ou na x2, ou na xn.

O mais engraçado foi eu me pegar durante uma codificação em Java com navegação em árvores eu fazendo N chamadas de função e ainda por cima sentir falta de escrever uma função que recebesse null para economizar uns ifs.

Ah, e temos mais vantagens nestas abordagens: Com as variáveis constantes acaba sendo simples de distribuir o código. A abordagem do Erlang é usar mensagens entre Threads. Então não temos os locks explícitos no código, o que simplifica um bocado a programação multi-threaded.

Estudar funcionais tem sido uma ginástica mental. Novos pontos de vista acabam alterando para melhor a forma de codificar. Para quem não quer sair da JVM existe Scala. Também tem a OCaml que tem sido uma linguagem funcional de destaque.

Ah sim, se você não entender muita coisa, saiba que eu não fui muito didático neste post. Quem tem alguma noção de funcionais sabe o quanto de informação simples existe aqui! Começe a "ginástica mental" e procure alguma linguagem funcional para estudar.

COBOL ainda é bastante usado...

2009-04-20T06:41:00.005-03:00

Já tive algum contato com CLIPPER e Delphi em épocas que eu não sabia a programar, mas sabia fazer copy-n-paste. Mesmo sem saber programar desenvolvi software e dei manutenção durante meses. Assim que aprendi a programar fui "trabalhar com programação mesmo". De fato, existem ferramentas e linguagens com curva de aprendizado bem curta, o que é uma vantagem para quem contrata, pois o programador custa barato e não existe dor de cabeça para encontrar programadores.

O que existe é dor de cabeça para escrever software de qualidade. A partir do momento que um programador menos experiente é contratado ele não irá escrever software de qualidade. Já vi muita coisa boa escrita em VB e Delphi por pessoas que gostavam de estudar a fundo estas ferramentas. Para mim são ferramentas ou linguagens + ferramentas e não apenas linguagens. As IDEs são excelentes, e diga-se de passagem, mais produtivas do que muita IDE Java paga que existe hoje em dia.

CLIPPER eu realmente acho muito "old style". Apesar dos recursos que eu já vi programadores experientes em clipper usando serem realmente bons. Os mesmos programadores experientes que conheci não escreviam, digamos "bom software".

PL/SQL é outra linguagem fácil de aprender que já vi ficar em mão de estagiários sem base alguma e ver que eles escreviam "algo" (existem ótimos estagiários que não se encaixam neste comentário.). A questão é quando temos uma base com milhões de registros e relacionamentos complicados. Se o cara não souber ler o explain plan e fazer algo direito, problemas de performance irão brotar. Muitas vezes isso é diagnosticado apenas em produção e aí sim vemos que a economia na hora de colocar o programadores inexperientes não compensa.

O mesmo cenário é repetido muitas vezes: Os líderes acostumados com a curva de aprendizado nestas linguagens querem que os novos programadores aprendam Java na mesma velocidade. Para aprender Java direito (o que não é difícil, mas demorado) é necessário aprender a linguagem, OO, Design Patterns, Frameworks...

Agora vamos falar do tópico do post: COBOL

Não conheço muito COBOL mas inevitavelmente tenho que conversar com programadores COBOL. Já peguei programadores COBOL com mais de 20 a 40 anos de experiência (isso é sério) que mal sabiam mexer no Windows ou mesmo viraram péssimos analistas de negócio. Voltaram a trabalhar com COBOL assim que possível... Eu lembro que eu brincava "Programar COBOL é virar digitador de regras de negócio". Mas até então nunca havia ficado em ambiente misto com programadores COBOL.

Hoje estou numa sala com aproximadamente 14 caras de Java para uns 40 de COBOL e mais uma quantidade pouco menor de PL/SQL. Aliás quem mexe com PL nesta empresa mexe com COBOL. Mesmo que seja novo. E o pessoal aprende COBOL. Fácil.

Já conversei com gente vivida e depois confirmei o que disseram na internet sobre os Mainframes COBOL. Eles usam virtualização desde antes de eu nascer e são escalonáveis de forma bem fácil. Tem que pagar o preço, mas você consegue melhoras o mesmo servidor. Nada de se preocupar com clustering para melhorar performance. Melhorando a mesma máquina não temos problema de IO de rede. E ainda por cima uma linguagem que surgiu em meados de 1960 teve algum tempo para ter seu hardware e software evoluídos.

Vi a ferramenta que eles desenvolvem e parece ser algo produtivo. Navegam pelos fontes de forma bem rápida. Mas de fato ao ler o código tive uma sensação de nojo. Pode ser apenas preconceito meu, mas eu tive.

No artigo da Wikipedia sobre COBOL, vi uma frase do Dijkstra retirada deste link que achei bem interessante:

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence."

Concordo que milhões foram gastos para desenvolver o legado de COBOL existente hoje, e que as empresas precisam dar manutenção nisto tudo. Mas para o programador realmente a frase faz sentido. As soluções propostas pelos programadores COBOL para problemas sérios normalmente são gambiarras que não irão funcionar. Ter que ficar imerso neste mundo tão diferente do meu enquanto desenvolvo software tem sido um exercício e tanto!

PS: uma linguagem pode ter curva de aprendizado curta, ser rica em recursos e ainda ser elegante e útil mesmo para o programador experiente. Ruby, Groovy e principalmente a mais madura Python são ótimos exemplos.

Qual é a melhor [digite algo polêmico aqui]??

2009-04-15T23:47:00.002-03:00

Já vi e vejo muitas discussões, seja em listas de discussão, botecos e etc., sobre qual a melhor IDE, linguagem de programação, biblioteca, etc. Aliás, eu mesmo já iniciei discussões do tipo...

Existem algumas respostas padrão em cima do muro que são por exemplo: "use a ferramenta certa para resolver o problema certo", "a ferramenta certa é a que você sabe usar", ou a "estas opções são complementares e não concorrentes". A ultima resposta "default" é a melhor delas com certeza. Apesar de eu gostar de ver opiniões como "O Eclipse é melhor pelos recursos de refactor", "C é melhor por que você tem noção do assembly gerado enquanto Java carrega uma VM gorda" a resposta de "estas opções não são concorrentes" abre espaço para uso de tudo.

Minha preferência por IDE de longe é o Eclipse, seja para C, seja para Java. Em Java eu instalo sempre o Netbeans e o JDeveloper, e sempre mantenho um Emacs por perto. Já viram os diagramas ER com JDeveloper, ou mesmo os UMLs? São ótimos! Gerar JPA no Netbeans economiza um tempo de não precisar configurar o Hibernate Tools e configs JPA no Hibernate Tools no Eclipse (que é um pé no saco).

Em C tenho usado Eclipse na maior parte do tempo, e QtCreator, que é muito bom mas perde no code complete para o Eclipse CDT. O XCode é divertido para desenvolvimento plataforma Mac/ObjC/Cocoa e já brinquei com ele e gostei.

Resumindo, para IDEs estou sempre procurando "a melhor", mas instalo tudo. E sim, mantenho a opção que mais uso e domino, e tenho as outras como "cartas na manga".

Linguagens de programação já foram mitos para mim. Não conhecia C/C++ e achava melhor pelos problemas de performance que tive em alguns projetos grandes em Java. Conheci C e entendi as diferenças que C++ adiciona. Tenho noção do poder de C++, mas ao mesmo tempo curva de aprendizado é um "concern" a ser considerado. Adorei Qt. Gostei do Boost mas não sou produtivo com ele. Sou fã das linguagens funcionais, e se pudesse só usaria elas para server side. Mas para interface com usuário ainda não achei algo que gostasse 100% (Qt e Cocoa se aproximam mas não me convenceram). Linguagens de script me ajudam no dia-a-dia e vejo que as vezes sinto falta da tipagem. Especialmente quando preciso reutilizar algo que fiz de forma diferente...

Por um lado não parei de procurar a linguagem/ferramenta/framework ideal para resolver alguns problemas, mas por outro lado trabalho com Java e preciso usar as frameworks em Java para resolver meus problemas. Mas estudar outras formas muda constantemente meu estilo de programar para melhor, e me sinto de olhos abertos para o mundo. Como disse um amigo meu: "programar direito eu programo em casa" e "trabalho é para ganhar dinheiro". Vou praticar mais em futuros opensources ;-)

Ah, e adoro quando acho alguma Thread em lista de discussão sobre "qual é o melhor blablabla"! Ou aquelas infinitas "Vim vs Emacs". Sempre acho algo que não tinha visto no meio dos ataques! e independente de ataques sempre tem alguma coisa de útil para peneirar em tais Threads...

Ficando fã de maças

2009-03-31T21:16:00.003-03:00

Fiz minha melhor aquisição de todos os tempos no ano passado: um MacBook. Depois de arranjar desculpas para instalar o Linux nele (como todo bom Xiita de Linux, como eu iria usar MacOS?) usei Linux nele durante uns 3 meses. A bateria durava apenas umas 3 horas e era possível fritar um ovo no Mac durante o uso do Linux. Vi o MacBook de um amigo meu, e com Windows fica igualzinho.

Estava de saco cheio de cozinhar qualquer objeto que eu colocasse o MacBook em cima. Depois de refletir um pouco e ver que de fato quem projeta o hardware pode fazer um software melhor, acabei por tentar o MacOS. Desde então estou cada vez mais fã de MacOS.

Andei estudando Cocoa e Objective C. Uma framework de aplicações genial e bela. Uma prova de que softwares elegantes podem evoluir e ir para frente. Como um programador Java, apesar de algumas coisas que não gostei em Objective C, Cocoa mostrou que o comportamento dinâmico de uma linguagem, quando utilizado da forma correta, pode ser extremamente poderoso.
O único defeito de Cocoa é não ser multi-plataforma (até onde eu sei). Isto me faz pensar em Qt para desenvolver multi plataforma para códigos nativos. Mas estudar Cocoa mostra um uso interessante de programação OO e comportamentos dinâmicos.

Agora a ultima coisa que gostei pacas no Mac é o próprio sistema operacional!

O XNU (XNU is Not Unix), Kernel do MacOS foi feito de forma bem interessante: Foi utilizada uma arquitetura de MicroKernel (baseada em mensagem entre os componentes) retirada do Mach 3. A questão de mensagens entre os componentes tem uma coisa boa e uma coisa ruim. A coisa boa é elegancia e fácil manutenção pois o kernel fica baseado em componentes que enviam e recebem mensagens, da forma como o Tanenbaum prega. Ao mesmo tempo, o Kernel monolítico (apenas em um bloco) não tem o overhead de envio de mensagens entre os componentes, o que o torna mais rápido. Até teve a famosa discussão entre o Linus e o Tanenbaum que versava sobre as vantagens e desvantagens de cada abordagem. Este tipo de discussão nos dias de hoje em que os processadores evoluem de forma absurda perde um pouco (eu disse um pouco) a razão de ser.

Enfim, o XNU foi feito com partes do FreeBSD e partes do Mach 3. O FreeBSD tem licença mais flexivel que a do Linux e o código muda menos, o que o torna mais fácil de ser escolhido, correto? Não sei. O que eu vi no Sr Google é que a Apple chegou a ajudar o projeto mkLinux, que é um Linux com uso de MicroKernel. Não sei se eles já pretendiam fazer algo do tipo desde então, mas que o fato é interessante, ah, isso é!

Ok, o XNU tem MicroKernel com mesclas de FreeBSD. Tem algo a mais que eu achei que fechou com chave de ouro: A parte de Drivers é OO. Não posso arriscar a falar muito, mas o I/O Kit (arquitetura de drivers do XNU) é feito usando um sub-set do C++, o que torna o código OO de forma mais natural do que ficar preenchendo structs de ponteiros de função e coisas do tipo!

Adoro Macs!

Cervejas belgas em alto level

2009-03-31T21:04:00.003-03:00

Não me lembro ao certo quantos dias fazem, mas fui com uns amigos tomar cerveja e comer pasteis no Tortula. A princípio parece destas padarias frescas com muita variedade e produtos de primeiríssima linha. Além disso tudo, o cardápio de cervejas é dos mais variados que já vi! Deixa muitos empórios com vergonha, pois a variedade é absurda. Especialmente no caso de cervejas belgas! O único ponto negativo (porém justificável tanto pela variedade quanto pela região) é o preço. Muitas cervejas ráras com o preço justo de uma raridade.

Achei a variedade de Ales do The Joy melhor e mais barato para as cervejas de custo médio (entre 6 e 50 reais). A variedade do Tortula é melhor para cervejas com custo mais caro (entre 50 e 400 reais). Como ainda não ganhei na sena e não executei nenhuma das ideias possivelmente boas que eu já tive para ganhar dinheiro não pude desfrutar da variedade do Tortula. Mas para quem gosta de beber coisas boas vale a pena conferir! Ah sim, e lá tem coisas mais comuns como Skol (eca!), Bohemia/Original (argh!) e chopp de Erdinger e Guinness...

Sim, de volta a vida!

2009-03-31T20:51:00.002-03:00

Pois é! Ganhei uma equipe só depois que o prazo do meu projeto atual apertou um bocado! Mas enfim, os tickets do sprint atual estão andando mais rápido do que o esperado! O "sprint" para quem não está acostumado com scrum é um dos muitos ciclos curtos de um projeto. Maiores informações numa wikipedia próxima de você.

O legal não é exatamente os tickets estarem andando, mas sim estarem andando mais rápido do que o esperado, num cenário totalmente complexo tecnicamente e SEM OVERTIME!

Apesar de não ser pago para isso, eu fico revoltado de ver gente fazendo overtime sem o serviço render de fato. Fiz um discurso bonito dizendo que nenhum dos programadores Jr da equipe precisariam fazer overtime, nem que para isso eu e mais uns amigos fossem "sacrificados".

Discurso bonito a parte, eu tinha quase certeza absoluta que pelo menos eu precisaria fazer overtime neste sprint. Mas acabamos fazendo um "quase pair programming" para agilizar o mentoring. E acabou que a galera está evoluindo mais rápido do que eu esperava!

Aos poucos estou voltando a blogar e beber cerveja com os amigos com mais frequência!

De volta a vida?

2009-03-24T00:19:00.003-03:00

Postura profissional, ética, comprometimento e coisas do tipo podem ter um alto preço de vez em quando. Nas ultimas semanas tenho dado pouca atenção aos meus amigos, meu rolo e etc, pois estava (continuo) apagando incêndio no cliente. Tivemos uma semana para produzir um parser de fórmulas, desenvolver um monte de webservices em jaxws com muitas restrições e resolver inúmeros problemas técnicos graças a algumas imposições políticas. O gerador de códigos que eu fiz (e que dentro de algumas semanas estarei publicando) foi útil. Muito útil.

Muitas vezes se conformar com o cenário proposto não é suficiente. O cenário proposto não estava funcionando. Por outro lado, uma equipe de programadores competentes e porra-loucas só consegue confiança mostrando serviço. Foi isso o que fizemos nas ultimas semanas. Fizemos mantendo o bom humor, falando bobagens o dia inteiro e tirando sarro dos colegas de trabalho sempre que possível. Entregamos os tickets do sprint no prazo combinado. E agora acumulamos responsabilidades. Ter o controle do processo tem seu preço. Mas é melhor confiar em si mesmo do que nos outros, não é mesmo? :D

Passamos pelo menos 8h/dia no trabalho. Isso equivale a 1/3 do dia. Se considerarmos uma semana, podemos pensar em 1/3 de cinco dias por semana: 5/7 x 1/3 = 5/21 ~ 1/4. Aproximadamente 1/4 de nossa vida (para quem não tira férias) é passado trabalhando. E pretendo viver uma vida de bom humor. Não abro mão de 1/4 dela. Trabalhar não precisa ser um castigo. Certas horas é difícil lutar contra isso. Vivemos em um mundo com pessoas inesperientes e/ou incompetentes, que acreditam que para trabalhar direito e entregar projetos desafiadores é necessário se sacrificar. E ainda acreditam que ao pressionar programadores conseguirão entregas mais rápidas. Continuo não acreditando nisso.

Uma coisa que aprendi desde de cedo: Se passo tanto tempo em algum lugar tenho que fazer o que gosto. Por sorte escolhi e gosto de uma profissão rentável. Porém não trabalho carimbando papeis o dia inteiro. Programar significa a cada projeto ter que se adaptar a um cenário político e técnico considerávelmente diferente. Este tipo de coisa acaba consumindo muito a sua mente caso não tome cuidado. Mas este tipo de dinamismo é ao mesmo tempo desafiador e empolgante. Tédio é algo que dificilmente tenho trabalhando.

Tem uma história que sempre conto que éra de um projeto com prazo de 2 meses para entrega de um software desktop com servidor de aplicação customizado para empréstimos. Ele era razoavelmente complexo. Como sempre eu chegava atrazado. Mas dava o fora da empresa pontualmente, e muitas vezes fazia 2h de almoço. Entreguei todas minhas atividades pontualmente. E 30% das atividades dos meus colegas de empresa na época foram entregues por mim pontualmente. Eu fui o único funcionário que não fazia horas extras e apesar de ter entregue tudo o que eu devia e mais um pouco era taxado de folgado na empresa. Mas ao sair da empresa, recebi tudo o que foi possível de propostas para ficar.

O recado é mais para o pessoal que está começando na profissão: Você não precisa se sacrificar para mostrar serviço. Você precisa se dedicar. E é possível trabalhar com bom humor e qualidade de vida. Basta fazer uso de seu bom senso. Você não será mandado embora por recusar trabalhar aos sabados e domingos de graça. Você pode trabalhar 8 horas por dia ou menos e ser altamente produtivo. A produtividade do programador não é uma função temporal linear. Eu diria que é uma função de N variáveis caótica.

Hoje voltei a sair no horário, e estou voltando aos poucos ao normal com meu ritmo de estudos pessoal. Devo voltar a publicar artigos interessantes (e não um monte de blá blá blá off topic) logo mais.

Um abraço a todos!

Geração de código, a saga continua...

2009-03-13T06:42:00.003-03:00

Meu post anterior precisa de um "@Deprecated" por um simples motivo: XQuery precisa gerar XML válido. Quando fui amadurecer os templates em XQuery e precisei gerar uma simples lista de propriedades, vi que não tinha como gerar cada propriedade usando XQuery sem que cada item fosse um XML válido.

O problema estava na minha frente: projetei mal e tive uma péssima idéia achando que iria dominar o mundo (de geração de código). Mas ainda queria os metadados em XML e queria não meter a mão no código java para adicionar/modificar os templates. Descobri que o Freemarker lê os XMLs de entrada e transforma em metadados legíveis pelo template! Meu objetivo de gerar código a partir dos metadados de um XML ainda era possível com relativo "pouco custo".

O protótipo de meu futuro primeiro projeto opensource já está gerando código para algum projeto de alguma grande instituição financeira próxima de você. Logo mais irei publicar. Mas já dá para comentar algo sobre a abordagem de gerar código a partir de metadados em XML:

Funciona: funciona bem e está salvando minha pele. Tenho muitas entregar para fazer (meus amigos, rolo e leitores do blog que o digam! eu desapareci por um tempo :D)
Novos problemas: a manutenção dos templates fica difícil com o tempo. Eles ganham complexidade para gerar código complexo. Gerar DTOs, XMLs e coisas do tipo é tranquilo. Mas temos templates que geram chamadas delegadas de código!
Baixa curva de aprendizado: um grande amigo meu que trabalha comigo "tomou conta da criança" e está escrevendo e dando manutenção nos templates. Tudo bem que o cara manja, mas em menos de 1 dia ele estava metendo a mão nos templates e melhorando consideravelmente a qualidade do código gerado!
Não é só para Java ou código: É um gerador de arquivos texto baseado em entrada de metadados. Serve para qualquer coisa que seja uma tarefa repetitiva de escrever arquivos texto.

Pois é! Na próxima semana ainda devo estar off-line, mas logo logo publico o projeto. Falta escrever documentação e preparar bem os exemplos.