MecanicaMente

Arquitetura de Software: Performance

2011-02-12T12:57:00.000-02:00

Como garantir que seu software tenha Performance?

As pessoas da área de exatas normalmente se esquecem, mas a comunicação verbal não é uma coisa lá muito certinha, grande parte das palavras não possui definição exata e depende muito do contexto. Então, antes de começar, vamos evitar a confusão e a baderna e vamos definir direitinho o que é "Performance" no contexto desse artigo.

Quando digo "Perfomance" estou falando do tempo que leva entre o usuário disparar uma operação e o sistema retornar o resultado desejado. Quanto menor o tempo, mais "performance" [SAIP].

Outro conceito que quero deixar claro é o de "Tempo de Resposta", que defino aqui como o tempo que leva entre o usuário disparar uma operação e o sistema responder algo de volta. Quanto menor o tempo, menos "tempo de resposta". [WKRT]

Repare na importante diferença: "retornar o resultado" vs "responder algo".

Não é a mesma coisa? Não, não é. Eu posso ter uma operação extremamente lenta (baixa performance), mas se ela for respondendo de tempos em tempos "estou trabalhando" (responder algo), o usuário não vai ter a impressão que meu sistema está travado. O exemplo mais típico é o de cópia de arquivos, sem aquela barra de progresso, qualquer usuário acharia que a máquina travou.

Por que essa diferença é tão importante? Porque, dependendo do sistema que você está envolvido, "performance" não é o que você quer, e sim "tempo de resposta". Um dos casos mais típicos é o da aplicação web que demora para responder, o usuário pensa que travou e clica no botão "refresh", disparando a operação uma segunda vez. Encontre um usuário com o dedo nervoso e você terá dezenas de operações iguais concorrendo no servidor e um usuário cada vez mais frustrado do outro lado.

Então, antes de fazer a pergunta "como garantir que meu software tenha Performance", você deve responder "preciso de Performance ou de Tempo de Resposta?"

Um boa "thumb rule" é que sistemas para o público em geral devem perseguir primeiro Tempo de Resposta, já sistemas que são suporte a outros sistemas (APIs, Frameworks e Linguagens de Programação, por exemplo), devem perseguir Performance antes de qualquer coisa.

Esclarecido o ponto, vamos ver o que podemos fazer para garantir Tempo de Resposta e o que podemos fazer para garantir Performance.

Ambas são qualidades de software que podem ser garantidas com "táticas arquiteturais" [SAIP]. Uma "tática" é uma decisão de design, ou seja, uma diretiva de como o software vai ser feito.

Táticas para Tempo de Resposta

O importante do tempo de resposta passar para o usuário percepção de que o sistema não travou e continua trabalhando.

Segundo Jakob Nielsen [JNRT], o comportamento do usuário varia com o tempo de resposta:

até 0,1 segundos;
entre 0,1 e 1 segundo;
entre 1 e 10 segundos;
acima de 10 segundos.

Um tempo de resposta de até 0,1 segundo é o que o usuário espera de coisas em que ele está no controle, tais como bater uma tecla e ver a letra aparecer na tela.

De 0,1 até 1,0 segundo é o tempo que o usuário espera que o sistema esteja "fazendo algo". Operações como salvar ou apagar devem ter mais de 0,1 segundo, caso contrário o usuário vai pensar que nada aconteceu e tentar novamente. Em algumas operações AJAX, por exemplo, a resposta pode ser imediata (salvar em background ao clicar, por exemplo), então, uma tática interessante é adicionar um pequeno delay nessas operações se elas não ultrapassarem 0,1 segundo.

De 1 até 10 segundo, o usuário começa a perder o foco que você precisa indicar que está trabalhando. Grande parte das páginas web possui carregamento entre 1 e 3 segundos [MTBC], em sistemas web, esse tempo tende a ser maior devido a operações mais complexas. Ou seja, se você está trabalhando em sistemas web, conte com o "loading" do browser para ajudar, mas se você está usando AJAX, a tática recomendada é sempre colocar alguma dica visual ("loading" animado, por exemplo) de que o sistema está trabalhando, pois é quase certo que várias requisições levarão mais de 1 segundo para responder.

Acima de 10 segundos, o usuário pára de esperar a operação finalizar e começa a fazer outra coisa. A tática recomendada nesse caso é apresentar uma barra de progresso ou ao menos um "loading" animado. Uma tática interessante apresentada por Matt Kelly, é colocar algo divertido, como uma pequena animação não convencional ou algo que o usuário possa interagir enquanto espera.

Se a operação puder levar minutos para completar, a tática recomendada é dispará-la em background e avisar ao usuário para buscar o resultado mais tarde. Em tempos de internet, isso pode significar algo do tipo "mandaremos um e-mail (sms/twitter/IM) com o link para os resultados quando o processo estiver concluído". Essa é tática usada pela Pragmatic Programmer Bookshelf, por exemplo, quando se pede para baixar um e-book e ele ainda não foi gerado.

A apresentação de Matt Kelly da ZURB na jQuery Conference de Boston possui outras táticas muito interessantes de como lidar com esses tempos de resposta em sistemas web [MTBC]. Só tenha certeza de pegar os slides para assistir junto com o vídeo.

Táticas para Performance

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" - Donald Knuth

Um bom tempo de resposta pode não bastar para as operações mais frequentes no sistema. Como elas são muito utilizadas, o usuário pode ficar irritado se ficar esperando sempre até que a operação seja concluída. Em casos como esse, não há outra alternativa senão tentar melhorar a performance.

Performance ruim é frequentemente causada não pelo sistema como um todo, mas sim por pequenos trechos e operações. Esses são os famigerados "gargalos". O grande trabalho para a arquitetura de software não é evitar esses gargalos, mas sim providenciar maneiras de identificá-los rapidamente.

As táticas, nesse caso, serão focadas em sistemas web para o público em geral, e não APIs ou Frameworks.

Em primeiro lugar, uma boa parte dos sistemas web costumam seguir o modelo arquitetural de repositório [SAIN]. Ou seja, um banco de dados (o repositório) é o centro do sistema e a maior interação é entre banco e a página web (a parte) ao invés das páginas interagirem fortemente entre si.

Esse é um excelente modelo, pois é bastante desacoplado. É possível trocar a partes com relativa facilidade, desde que não se modifique muito o repositório. Ele possui um problema com o rastreio das informações, pois é difícil descobrir qual parte alterou um dado que outra parte precisa, ou seja, existe uma dependência indireta via dados.

Nesse tipo de sistema, os maiores gargalos de performance inevitavelmente se concentram ao se movimentar grandes massas de dados no repositório, seja criando, recuperando ou alterando. Em miúdos: o gargalo de performance está normalmente em operações pesadas de banco de dados.

Uma tática NÃO recomendada é tentar aliviar o banco de dados passando o processamento para a aplicação. Isso normalmente diminui a performance, pois toda a operação que seria feita diretamente agora precisa ser passada pela rede até a aplicação, carregada em memória (novamente, pois se ela foi recuperada do banco, teve que ser carregada na memória do banco também), processada e novamente serializada e enviada de volta para o banco de dados.

Outra tática NÃO recomendada é tentar otimizar o sistema enquanto não se sabe onde no sistema a performance é pior [DKSP]. Essa "tática" é conhecida como "otimização prematura" e aumenta a complexidade do sistema sem garantias de resultado.

A melhor das abordagens para problemas de performance é monitorar a execução do sistema para identificar quais operações são mais lentas e então remover o gargalo.

A primeira tática recomendada é monitorar o tempo de todas operações de banco de dados da aplicação, isso pode ser feito facilmente, bastando logar seu tempo de execução. Para isso, é preciso que todas as operações de bancos de dados (consultas, inserções, alterações), sejam executadas por um único mecanismo, dessa maneira, registrar o tempo de execução não custa mais quem meia dúzia de linhas de código.

Além de monitorar o tempo de execução da operações de banco de dados, é interessante monitor o tempo de execução das páginas (tempo entre a "request" recebida e "response" enviada). Assim, mesmo quando o gargalo não está no banco, ainda é possível identificá-lo. Ao se monitorar os ambos, é possível saber não somente em que parte do sistema está o gargalo, mas se ele é causado pela aplicação ou pelo banco de dados.

Uma prática controversa, mas que me deu excelentes resultados, foi logar a pilha de execução (stack trace) junto com o tempo de execução do banco de dados. Dessa forma, consegui identificar rapidamente em que parte do sistema o SQL estava sendo gerado, por vezes, o sistema gerava partes do SQL em lugares diferentes. Recomendo essa prática para os primeiros meses de vida do sistema e principalmente se seu sistema possuir muitas consultas dinâmicas.

Outra tática é usar "timeouts", para garantir que as operações de banco de dados não ultrapassem um limite tolerável [MNRI][SAIP]. Apesar dessa ser uma tática recomendada para "Estabilidade", ela é muito útil para impedir que uma operação pesada deixe o sistema lento para todos os outros usuários.

Ambas as táticas devem ser usadas não somente com o banco de dados, mas também com qualquer dependência que o software tenha com sistemas externos, tais como web APIs.

Uma tática extra ao se lidar com sistemas externos é o uso do padrão "Circuit Break"[MNRI][TRCB]. Apesar de não estar diretamente relacionado com performance, ele garante que o software não sofra com instabilidade de sistemas externos.

Uma vez identificado o gargalo, basta aplicar uma série de técnicas para tentar removê-lo. Coisas como "memoization", "buffers", "índices e planos de execução forçados" e principalmente melhoria de algoritmos. Infelizmente essas técnicas estão além do escopo desse (já longo) artigo. Por outro lado, recomendo muito que a equipe tenha pessoas bem versadas nessas técnicas para que os gargalos sejam removidos rapidamente assim que identificados.

Espero que tanto texto tenha sido de alguma utilidade!

[SAIP] - Software Architecture In Practice - http://www.amazon.com/Software-Architecture-Practice-2nd-Bass/dp/0321154959

[WKRT] - http://en.wikipedia.org/wiki/Response_time_(technology)

[JNRT] - http://www.useit.com/papers/responsetime.html
[MTBC] - http://events.jquery.org/2010/boston/video/video.php?talk=matt-kelly
[SAIN] - http://www.cs.cmu.edu/afs/cs/project/vit/ftp/pdf/intro_softarch.pdf
[DKSP] - http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf

[MNRI] - Release It! - http://pragprog.com/titles/mnee/release-it

[TRCB] - http://timross.wordpress.com/2008/02/10/implementing-the-circuit-breaker-pattern-in-c/

Compilando Vim 7.3 para Ubuntu

2010-10-30T12:29:00.003-02:00

Direto ao ponto:

Instale xorg-dev e libgtk2.0-dev. Sem isso, não rola o gVim.
./configure --enable-gui=gtk2 --enable-multibyte --with-features=huge --enable-rubyinterp
make
sudo make install

Os executáveis vão estar em /usr/local/bin

Se quiser suporte ao Python, ao invés de usar --enable-rubyinterp, use --enable-pythoninterp. De qualquer maneira, você vai precisar dos headers de ambas as linguagens.

Como instalei o Ruby via RVM, ele encontrou o source do Ruby facilmente. Mas um aviso: o interpretador do ruby dentro do Vim vai ser sempre aquele em que o RVM estava quando você compilou, mudar a versão do Ruby via RVM não tem efeito nenhum no interpretador usado pelo Vim.

O tiuzão metaleiro TaQ apontou esse instalador que ele fez: https://github.com/taq/viminstall que é muito bom. Mesmo que você não queira usá-lo e quiser instalar tudo na mão, o script é uma ótima referência!

---
Editado:
1 - A opção para interpretador do Ruby estava errada: --with-rubyinterp deve ser --enable-rubyinterp.
2 - Adicionada referência ao instalador do TaQ.

Qual o real papel de um Arquiteto de Software

2010-10-01T12:44:00.000-03:00

A questão apareceu em uma discussão da Tectura.

Comecei a escreve uma resposta, mas a coisa ficou tão longa que resolvi postar aqui =\

Versão para apressados:

0 - IMHO, acho que estamos respondendo na discussão como o arquiteto de agir, mas não o o quê (papel) ele deve fazer...
1 - Simplificando absurdamente um arquiteto de software cuida da arquitetura de sofware (duh, momento Homer)
2 - Infelizmente, Arquitetura de software NÃO é um conceito aceito universalmente, nem é um conceito bem definido, muito pelo contrário. Cada um fala o que quer sobre o assunto e ninguém está errado :)
3 - Um dos melhores trabalhos sobre o tema é de Bass et al.
4 - Segundo ele, uma das principais funções do arquiteto é cuidar das "ilities" do software e documentá-lo.
5 - Pessoalmente, acho que documentação de software é só uma tática para atingir "modificabilidade".
6 - Conclusão: se o raciocínio desses caras estiver correto e se a minha opinião estiver correta, o papel do arquiteto é garantir as "ilities" de software, e para isso, precisamos nos meter em tudo qto é buraco do desenvolvimento de software, da negociação ao código.
7 - Mas todos nós podemos estar errados ;)

Versão para pacientes:

Acho q estamos confundindo a resposta, ou talvez eu não tenha entendido bem a pergunta. IMHO, boa parte das nossas respostas estão indo no caminho "como um arquiteto de software deve se comportar" e não "o que um arquiteto de software deve fazer".

Digo, se ele é um ditador, um comunicador, um líder nato, se é up front, "ágil" ou whatever, isso é COMO ele faz, e não O QUÊ ele faz. (tá correto isso?).

Tentando colocar a questão de outra maneira: "O que (papel) um Arquiteto de Software faz?"

Resposta óbvia: "Cuida da arquitetura" (duh)

E aí caímos na questão do Guilherme Silveira: "Uma questão anterior ao papel do arquiteto é o que é arquitetura"

Consultando a wikipedia (http://en.wikipedia.org/wiki/Software_architecture e http://en.wikipedia.org/wiki/Software_architect) e mais algumas fontes (http://goo.gl/ucNC, http://www.sei.cmu.edu/architecture/start/community.cfm, por exemplo, mas vc pode procurar por mais) dá pra perceber rapidamente que não existe um conceito uniformizado sobre o que é a bagaça. Ou seja, cada um de nós tem uma concepção diferente do que é arquitetura, e nenhum de nós está errado, simplesmente pq não existe resposta certa aceita por todos.

Um trabalho sobre o assunto que é sempre citado é o de Bass et al, mesmo assim, se vc lê-lo atentamente, vai perceber alguns conceitos que vêm "from thin air" (ou seja, sem referência a outros trabalhos), embora sejam caras experientes com vários projetos de sucesso na bagagem.

Segundo esse trabalho, uma das preocupações do arquiteto é garantir as "ilities" de um software (http://en.wikipedia.org/wiki/Software_quality) e documentar a coisa toda.

Opinião pessoal, eu concordo com a parte de garantir as "ilities", mas acho que a documentação é só uma outra tática para se atingir "modificability" ou "manutenability".

E se isso está certo, desde "Time to Market" até "Performance" e "Usabilidade" são responsabilidade do arquiteto. Para poder garantir isso, então, o arquiteto deveria se meter desde a negociação do software até programação e interações com o usuário.

Por outro lado, podemos estar todos redondamente errados. Por quê? Bom, "arquitetura" de software e "arquiteto" de software são papéis que foram criados por similaridade metafórica com construção civil. Se você já trabalhou desenvolvendo software, sabe que essa metáfora é muito frágil. Ou seja, podemos estar tentando criar um papel que não faz sentido existir. Por outro lado, existe algo realmente de alto nível que precisa ser cuidado, e que está muito mais alto nível do que estamos acostumados a pensar.

Duvidando do óbvio: Gravidade?

2010-09-20T17:22:00.000-03:00

Não sou nenhuma sumidade no assunto, aliás, sou uma porta de leigo nessa bagaça... mas... e se ao invés de vivermos um mundo redondo, estivermos na verdade em um mundo chato, mas com a gravidade torcendo o espaço sobre si mesmo?

Ruby 1.9.2 - diferenças com expressões regulares

2010-09-18T15:43:00.000-03:00

O Ruby 1.9.2 veio com algumas poucas incompatibilidades com as versões anteriores. Duas delas me parecem um pouco "inconvenientes", a primeira comentei no post anterior. A segunda tem a ver com mudanças em expressões regulares.

Do ruby-lang.org (http://svn.ruby-lang.org/repos/ruby/tags/v1_9_2_0/NEWS)

* \d, \s, and \w are now ASCII only; use POSIX bracket classes and \p{} for Unicode semantics

O que significa que no Ruby 1.8.7, isso aqui funciona:

> irb -Ku
> "você" =~ /\w$/
=> 3

Mas não no Ruby 1.9.2:

> irb
> "você" =~ /\w$/
=> nil

Para que a coisa funcione corretamento no 1.9.2 é preciso usar "\p{Alpha}":

> irb
> "você" =~ /\p{Alpha}$/
=> 3

Perfeito, mas se você tenta a mesma solução no Ruby 1.8.7:

> irb -Ku
> "você" =~ /\p{Alpha}$/
(irb):1: warning: regexp has invalid interval
(irb):1: warning: regexp has `}' without escape
=> nil

Okay... nada que seja um absurdo, mas para quem trabalha com a língua portuguesa isso fica um pouco chato.

Ruby 1.9.2 primeiras experiências

2010-09-14T11:45:00.001-03:00

A versão final do Ruby 1.9.2 foi liberada mês passado (agosto/2010), e só agora comecei a meter a mão na massa nele pra valer.

Logo de cara, já tive alguns problemas menores, mas importantes:

O primeiro foi no "require", a partir dessa versão o diretório atual não está mais incluído no $LOAD_PATH. O que significa que essa construção passa a ter problemas:

require File.dirname(__FILE__) + '/algum_subdiretorio/algum_ruby'

Para resolver isso, duas soluções:

A primeira é expandir o caminho:

require File.expand_path(File.dirname(__FILE__)) + '/algum_subdiretorio/algum_ruby'

A segunda, mais sensata, é adicionar especificamente o diretório "raiz" da aplicação ao $LOAD_PATH, como sugerido aqui)

$LOAD_PATH << File.expand_path(File.dirname(__FILE__)) + '/../lib'

require 'algum_subdiretorio/algum_ruby'

require 'outro_subdir_dentro_de_lib/outro_arquivo_ruby'

Com algum esforço, dá até pra criar um script pra arrumar isso automaticamente ;-)

Eu tenho todo o conhecimento do mundo...

2010-06-21T14:09:00.001-03:00

Ontem estava no mercado com minha esposa e ela disse: "Queria fazer um molho de maracujá, como será que faz?"

Dei de ombros e continuamos pegando os refrigerantes, de repente parei e disse: "Peraí, eu SEI como fazer esse molho!".

Saquei o celular, abri o browser, Google, "molho de maracujá" e... bingo! Primeiro resultado já tinha a receita com todos os ingredientes. Compramos tudo e almocei um pelo pernil regado a molho agridoce.

Eu tenho todo o conhecimento do mundo...

...eu, e qualquer pessoa com acesso a internet. :)

Desde que comprei esse celular, e acesso a internet com ele, me pareceu que consigo fazer ou saber qualquer coisa que eu precise. Nós de gravata? Fácil! Receitas? Imediatamente! O que significa "nó cego"? Tá na mão! Algoritmos? Pra qualquer coisa que vc deseje...

Assinei o Safari (da O'Reilly), coloquei o Stanza e comecei a baixar livros gratuitos e comprar outros da Pragmatic Bookshelf (fazem meses que não leio um livro "físico"). E posso consultar toda minha biblioteca de conhecimento a qualquer momento.

Isso começou a me dar a impressão que consigo saber qualquer coisa que eu queira, de qualquer assunto, a qualquer momento.

Não bastasse isso, esse nossos pequenos e maravilhosos "gadgets" nos dão "super-poderes" (hmm... essa palavra ainda tem hífen?)

Memória fotográfica? Bom... o celular tem uma câmera e um gravador de som. Também tem uma agenda "buzina" meus compromissos.

Senso de direção? Viva o Google Maps e o TomTom.

Telepatia? Experimente SMS (boooommm... dá pra simplesmente fazer uma ligação :-p)

Pare um momento e pense como uma pessoa de 1980... "tudo isso é ficção científica!" =\

Acho que estou ficando velho...

Apanhando das expressões regulares no Ruby

2010-05-19T10:26:00.004-03:00

Estava eu brincando com o Ruby 1.9 e tentando fazer uma expressão regular bem simples:

#encoding: utf-8
puts "isso é inaceitável".scan(/\w+/)

resultado:

isso
inaceit
vel

Uh-oh... =/ nada bom.

Procurei por todo lado, tentando achar o que eu estava fazendo de errado. Achei vários posts dizendo que isso deveria funcionar e ninguém com o mesmo problema que eu. Não sei o que fiz de errado até agora, se alguém souber, por favor me avise =/

De qualquer maneira, tentei resolver o problema sem sucesso. Então, na documentação do Oniguruma, achei um "paliativo":

#encoding: utf-8
puts "isso é aceitável".scan(/\p{Word}+/)

E o resultado:

isso
é
aceitável

Ótimo!

Além disso, fuçando lá vi várias outras classes bastante úteis, como "\p{Alpha}", "\p{Alnum}, "\p{Upper}" e "\p{Lower}" entre outros. É possível também negar a classe usando um "\P" (maiúsculo) como prefixo.

Java missed the boat?

2010-04-14T09:15:00.002-03:00

Ontem eu estava dando uma olhada no JDK 7 para ver em que pé estava. Queria saber principalmente de closures que, a priori, iam ficar de fora.

Para minha surpresa (tá, tá... cheguei atrasado na festa), estava lá na página da Sun um pequeno artigo sobre closures de Dezembro de 2009 dizendo: "Vamos colocar uma versão de closures simplificada no JDK 7":

... It’s time to learn from the past debate and move forward. Sun will initiate the design and implementation of a simple closures feature, as outlined above, and add it to JDK 7 so as to enable broad experimentation. If all goes well then we’ll later submit a language-change JSR which would, in turn, be proposed as a component of the eventual Java SE 7 JSR. (ênfase minha)

Não entendi nada =/ Depois de tanto afirmarem que não ia, pra que a pressa agora? Colocar closures em Java vai ser um "puta trampo". Não pelos closures em si, mas muito da API deveria ser reescrita ou expandida.

Procurando um pouco mais achei um bug (ID: 5014235) na Sun Developer Network que acho que explica bem o que significa colocarem closures agora.

Closures are a great thing. Unfortunately, Java missed the boat in 1997. Since then, we've added a collections framework without closures (one of the prime uses), built graphics APIs around nested classes etc. We have tons of control constructs that could be defined using closures but aren't (assert and foreach, for example). So the advantage of adding closures now would be relatively small compared to the huge benefit you get if you add them from day one.

(ênfase minha de novo)

Resumo da ópera: o trampo de colocar vai trazer um benefício bem menor que o esperado, já que todos os lugares onde closure seria realmente bom já estão usando outros esquemas.

Se colocarem agora, para não tornar o código anterior incompatível, terão que adicionar vários métodos e maneiras "alternativas" de se fazer as coisas. Não sei vocês, mas acho que isso vai embananar o código, ora com closures, ora sem.

Não me leve a mal, adoro closures e acho que deveriam ser parte essencial de qualquer linguagem, mas colocar elas no Java agora vai dar um tremendo trabalho e quebrar a integridade conceitual da coisa (popular: "bagunçar o coreto").

Quer closures, gosta da JVM e de tipagem estática? Vai pro Scala que você vai estar mais bem servido e com uma linguagem conceitualmente consistente. De quebra, você ainda ganha type inference, currying, pattern matching, operator overloading (hmmm... na verdade é notação infix, mas dá na mesma), imutabilidade fácil e mais um paco de técnicas realmente úteis para programar.

Muito tarde para o Java.

Sobre a carreira

2010-03-31T00:52:00.005-03:00

Eu estava revisando meu currículo esses tempos atrás e comecei a ver no que já trabalhei, não em tecnologia, mas os negócios em que trabalhei, e fiquei surpreso com a quantidade de coisa que 'entuia os meu norônio'. Olha que beleza:

Comecei dando aula de DOS, WordStar, Lotus-123 e QuattroPro, depois seguem aulas de Windows, Access e 3DStudio (versão DOS!).

Largo as aulas e vou dar manutenção em um sistema auxiliar de uma indústria de celulose e papel.

Pouco tempo depois começo a mexer com e-commerce e um portal.

Mais um ano e vou pra bioinformática mexer com análise de DNA.

Saio e vou trabalhar com e-government na Secretaria da Fazenda do Estado de São Paulo.

Na sequência engata um sistema para configuração de equipamento de medição remota, e o front-end de um e-banking.

Fico 2 meses parado e vou trabalhar com replicação de autorização em catracas eletrônicas, middleware para transferência de dados entre fabricantes de móveis, CRM, e um site para corrida de cavalos.

Nesse meio tempo correm em paralelo: mais aulas e mais sistemas para bioinformática.

Saio e vou trabalhar com logística, segurança pública e análise de recursos hídricos.

E agora, fazem duas semanas, ~~tráfego de controle aéreo~~ controle de tráfego aéreo.

...

De DNA a burocracia, de caminhões e cavalos a aeronaves. Tenho certeza que tenho alguma lição pra tirar disso, mas não sei qual :D

O mais engraçado é que, no final de cada sistema, eu (e todo mundo que tinha trabalhado no projeto) sabia mais que muita gente da área. Acho que é efeito colateral de quando você tem que esmiuçar tudo quanto é regra para poder fazer o software. Depois que passa o projeto a memória faz seu trabalho e lentamente você vai esquecendo tudo que aprendeu. Eu me divirto no processo, mas às vezes me parece um tremendo esforço em vão, já que vou esqueçendo tudo. =/

Ginger - Scratch you own itch

2010-03-31T00:30:00.004-03:00

3 meses que não escrevo nada... não sei pq insisto em manter um blog :) Vai ver é pro meu ego ter algum lugar onde estravazar.

Já ouvi aquela idéia do "scratch you own itch"? Dizem que muitos produtos legais vêm disso, ou seja, quando o desenvolvedor fica incomodado o suficiente com algo e faz um programa pra resolver seu problema.

Bom, eu trabalho com Java 8 horas por dia (e Ruby nas outras 2 horas) e estou sempre reescrevendo os mesmos utilitários o tempo todo para todo projeto que entro. Então, resolvi "coçar minha coceira" e montar uma lib de uma vez com esses utilitários. Aproveitando para dar uma polida geral neles para ficarem bem bacanas.

Nasce então a "Ginger", uma pretensiosa biblioteca que promete acabar com todos os seus problemas (haha! Silver bullet!!! haha!). Brincadeira! Ginger ainda é pré-adolescente e vai levar um tempo até servir de algo. Mas ela está lá, para quem quiser apreciar e, principalmente, criticar.

Ginger hoje tem um objeto "DuckType", que facilita a parte de reflexão, e estou trabalhando em facilitar expressões regulares e manipulação de texto.

Acabou que me empolguei com umas idéias nessa parte e resolvi fazer umas experimentações. Acho que descobri um jeito de expandir expressões regulares para fazer algumas coisas "impossíveis" do tipo "encontre tudo que não for isso", e facilitar o uso de lookahead e lookbehind, que são sempre complicadas.

É isso aí, opiniões são bem vindas. :)

Sensatez não dá Ibope

2010-01-18T13:42:00.003-02:00

(Edição: arrumando acentuação [você não odeia quando essa bagaça zoa com os acentos?])

Eu estava conversando com um colega hoje sobre esse artigo sobre Injeção de Dependência e comentando sobre a polêmica levantada. A conclusão foi "O artigo é bom, mas bem que o Uncle Bob podia ser um pouco mais imparcial; existem casos onde Injeção de Dependência é bom, ele poderia ter falado neles também". Só que se ele tivesse sido imparcial, provavelmente o artigo não teria tanta popularidade :) A gente instintivamente vai atrás de polêmica. Moral da história: "Sensatez não faz sucesso". Taí uma coisa realmente preocupante...

Desenvolvimento de software é uma coisa irônica

2009-12-23T11:07:00.003-02:00

Engraçado como o desenvolvimento de software tem uma tend?ncia a ser irônico e tirar um sarro dos seus esforços: 1 - Quanto mais flexível você tenta fazer o software, menos flexível ele fica. 2 - Quanto mais rápido você tenta contruí-lo, mas demora terminá-lo. 3 - Quanto mais simples você o faz, mais robusto ele fica. 4 - Mas quanto mais você tenta fazê-lo robusto e escalável, menos ele fica. 5 - Se você faz direito, demora menos tempo. 6 - Se você faz nas coxas pra ganhar tempo, você perde tempo. 7 - E quanto mais você estuda, mais aprende que nâo sabe o suficiente. 8 - Mas se não estuda, tem absoluta certeza que sabe tudo o que precisa. Tem horas que acho que o negócio é pensar de ponta-cabeça =/

O mito da "recuperação do atraso"

2009-10-29T02:19:00.002-02:00

Não tem dessa de "recuperar o atraso" em um projeto de software... Boa referência aqui também: What Is the Cost of a Requirement Error?

Técnicas, não ferramentas

2009-10-26T15:36:00.004-02:00

Acho que nós da área de desenvolvimento temos um grande problema onde focamos nossos estudos. Normalmente estudamos demais a coisa errada, e as coisas certas não estudamos o suficiente.

Também é difícil dizer qual é o foco "correto". Cada um vai ter uma opinião diferente e não há estudos pra basear nenhum dos nossos "achismos". (Hmmm... já reparou como quase todo desenvolvimento de software comercial/corporativo tem esse problema?)

Pessoalmente, depois de ficar perdendo muito tempo estudando frameworks, descobri que o que interessa são técnicas, não ferramentas. Tenho hoje a nítida percepção que a ferramenta vêm naturalmente se você tem a técnica.

O que seriam as técnicas?

Idiomas das linguagens
Patterns dos mais variados
Modelos de arquitetura
TDD/BDD
Paradigmas de programação (OO / Funcional / Imperativo / Declarativo)
DSLs ou Interfaces Fluentes

Ou seja, independente da linguagem, os conceitos serão úteis.

E as ferramentas?

Qualquer linguagem (Ruby, Java, Haskell...)
Qualquer framework (Rails, Spring...)
Qualquer biblioteca ou API (REXML, JDOM...)

Hoje, eu foco o máximo na técnica e só estudo a ferramenta até o nível suficiente para o problema atual. O efeito que isso causa é bastante interessante, normalmente consigo responder se algo existe na ferramenta sem conhecê-la, porque, conceitualmente, a coisa deveria estar lá. :)

Estou certo? Sei lá. Pra mim funciona melhor do que antes, quando eu me matava pra ficar aprendendo ferramenta e a cada 3 anos vinha uma nova e todo o conhecimento era perdido. Agora o conhecimento acumula, e o que tenho que renovar é menor.

Metaphone em português para Java

2009-10-01T02:31:00.002-03:00

Custou um pouquinho para achar um banco com nomes para testar e acertar as rebarbas, mas finalmente está aí: codificação fonética em Metaphone para português (http://github.com/ruliana/MTFN) :) Se você quiser saber do que estou falando: http://en.wikipedia.org/wiki/Metaphone e http://www2.varzeapaulista.sp.gov.br/metaphone. Muito simples de usar, muito simples de customizar e vem com um banco de dados de teste, cortesia do Marco "Kiko" Carnut (http://www.postcogito.org/) e seu trabalho sobre descobrir o sexo da pessoa somente pelo nome (http://www.postcogito.org/Kiko/PlanilhaMascFemPtBr.html, trabalho muito legal, vale a pena conferir!) Só que, com a massa de testes e estudando um pouco melhor a fonética da língua portuguesa, deu pra perceber que a coisa pode ser melhorada. Como por exemplo, considerar "P" e "B" como equivalentes, assim como "M" e "N". Desconsiderar algumas consoantes nos finais dos nomes e assim por diante. Optei primeiro por liberar um algoritmo bastante similar àquele que me baseei, que já é muito bom! Agora começo a refiná-lo com meus próprios "achismos". Vamos ver no que vai dar. ;)

Functors? Hmmm... nhammy

2009-09-27T20:43:00.002-03:00

Ando estudando Haskell de farra ultimamente, confesso que ainda não entendi ainda qual é o barato dos monads, mas funções como cidadãos de primeira classe, combinação de funções e currying são conceitos bem legais. Dei uma checada no que havia para Java (é... Java) e esbarrei com alguns projetos interessantes, mas todos muito trabalhosos para minha preguiça. Então, como todo bom nerd, se você não acha uma ferramenta que goste, você cria uma. Então, com um pouco de Java Voodoo do Brabo, fiz o "Yo da Funkta!" pra satisfazer meu ego e minha preguiça. Acho que ficou bonzinho... Agora... estou muito interessado em... Metaphone...

Sims ensina

2009-06-15T13:24:00.002-03:00

Sou um jogador casual de "Sims", jogando ele acabei aprendendo algumas dicas boa para o dia a dia: - Compre uma boa cama (com um excelente colchão), vale a pena! - Não dá tempo de fazer tudo o que se quer. - Gastar todo seu tempo livre com diversão não te leva a lugar nenhum, mas é preciso gastar algum tempo só com diversão. - É possível aprender se divertindo, mas nem sempre dá pra se divertir aprendendo. - Investir na carreira é ótimo, e tem que ser feito com intenção. - Sozinho não se vai muito longe. E por aí vai...

A difícil arte de explicar o abstrato

2009-06-03T00:13:00.006-03:00

Tenho um problema básico de comunicação quando tratando com pessoal "não-nerd" como os gerentes (e a minha esposa). Toda vez que tenho que explicar "o código está ruim", eles me olham com aquela cara de tela azul do windows. Dá quase pra ouvir o somzinho no fundo: "pãm...!" Aí comento que é difícil dar manutenção, que leva mais tempo, que para fazer algo precisamos arrumar um pouco a coisa, que as estimativas não são confiáveis. "pãm...!?" Torna explicar que mexer ali pode causar problemas em outros lugares, que pode quebrar o que funciona, etc... etc... "pãm... pãm...!?" Finalmente, achei um jeito bom de explicar quando digo "o código está nojento" e eles entenderem a encrenca que é mexer naquilo. As imagens abaixo (do post http://www.tvsnob.com/archives/016683.php ) ajudaram muito: Primeiro, isso é um código bom: E isso aqui é "código ruim: Leia novamente as frases acima, mas observando as imagens... não fica óbvio? Agora, sempre que vamos conversar, eu mantenho essa imagens por perto, hora que o pessoal começa a viajar muito, eles colocam o povo na terra. E tudo mundo entende o problema que temos nas mãos. As imagens corretas valem por um milhão de palavras.

2009-04-26T03:50:00.002-03:00

É tarde da noite... passei horas incontáveis programando. Tomo um banho e tento dormir, não consigo. Linhas de código passam pela minha cabeça, penso em "if levantar", "sono -= 1", "sono += ler", blog, blog, coisas esquecidas... Levanto, pego o Mac e abro. Fico olhando a tela azul, quando me dou conta, me loguei mas não consigo me lembrar quando digitei a senha. O blog aparece, também não lembro de ter entrado aqui. Começo a digitar a esmo, as palavras vão saindo antes que eu consiga montar uma frase completa na cabeça. E agora, o que estou escrendo? Continuo vendo linhas de código passando na minha frente, o Código chama. Não posso responder ao Código, preciso programar. Não posso, fiz isso por tempo demais. Preciso escrever, já estou, mas não me dei conta. Queria poder escrever rápido como o Akita, programar como Kent Beck, arquiteturar como Fowler, ter a consciência do _Why. Pra quê? Não sei bem, mas imagino que deve ser divertido. Abro o terminal, "ruby -v". __"ruby 1.9.1p0 (2009-01-30 revision 21907) [i386-darwin9.6.0]" - a máquina responde feliz. "irb", eu digo a ela. Um prompt me saúda, o cursor pisca, perguntando o que eu quero. text = <<TEXT Colo o texto que escrevi TEXT words = text.split words[rand(words.size)] O prompt responde: "dormir" Sensato como Ronaldo Ferraz. Deveria, mas ainda náo consigo. Se eu rodar de novo, acho que ele responde "Deixa de frescura e vai pra cama". Direto e contundente como o TaQ. Fico com medo que ele responda isso mesmo e fecho o terminal. Me dou por vencido. Fecho o Mac, uma luzinha branca me lembra que ele ainda vigia. Desisto e fecho os olhos. Amanhã vou rir disso... acho.

case-insensitive e accent-insensitive no PostgreSQL

2009-03-30T19:34:00.003-03:00

Gosto muito do PostgreSQL. Pessoalmente é um dos bancos que menos me causa o efeito "WTF", quando estou trabalhando com ele, com uma notável exceção... não tem nenhum parâmetro nem coisa parecida para poder fazer pesquisas case-insensitive e accent-insensitive. E isso é um grande "WTF" pra qualquer um que possua acentos na língua. Procurando uma solução, encontrei esses posts aqui: http://www.laudatio.com/wordpress/2008/11/05/postgresql-83-to_ascii-utf8/ http://www.mail-archive.com/pgsql-general@postgresql.org/msg112591.html http://www.postgresonline.com/journal/index.php?/archives/9-How-to-create-an-index-based-on-a-function.html Como meu banco é UTF-8, combinei elas em uma única solução:

CREATE OR REPLACE FUNCTION to_ascii(bytea, name)
RETURNS text STRICT AS 'to_ascii_encname' LANGUAGE internal;

CREATE OR REPLACE FUNCTION norm(a_string text)
RETURNS text AS $$
  BEGIN
    RETURN lower(to_ascii(convert_to(a_string, 'latin1'), 'latin1'));
  END
$$ LANGUAGE plpgsql

E como quando fazemos isso sempre precisamos de índice, em tese podemos criar os índices assim:

CREATE INDEX norm_tabela_campo_idx
  ON tabela
  USING btree norm(campo);

Sugestões para programar

2009-03-29T03:29:00.002-03:00

Aqui tem uma lista de sugestões que eu uso quando estou programando. Faço questão de colocar elas para mim mesmo de uma maneira um tanto... "enfática", digamos assim. Descobri que quando fico indignado eu lembro melhor das coisas. Por isso, perdoe minhas "ênfases". Sugestão 1 Nomes significativos: pelo amor de JC e sua gangue, pare um pouco e coloque um nome decente nas coisas que faz (variáveis, métodos e classes). Sempre vale a pena colocar um bom nome, mesmo que isso custe vários minutos pensando. A razão disso? Crie um programa com nomes bem ruins e pouco significativos e depois tente dar manutenção nele, você vai lembrar do que eu disse agora. Sugestão 2 Indireção: use e abuse. Crie métodos a rodo, crie dezenas de classes pequenas, jogue o que puder para uma classe pai, abstraia ao máximo. O efeito disso é criar naturalmente Template Methods e DSLs, sem falar em diminuir a duplicação. Aliás, já repararam como template methods se parecem com micro DSLs? Sugestão 3 Valide o que vai usar para o método que está escrevendo. Se vai usar parâmetros, alguns "ifs" para validar que não está vindo lixo sempre são bemvindos. Se vai usar atributos, teste para ver se estão do jeito que você esperava encontrá-los. Se estiver com muita preguiça, mas muita mesmo, valide ao menos os nulos. Ah... e antes que eu me esqueça... NÃO, isso NÃO vai fazer seu programa ficar lento. Sugestão 4 Estado: se você está programando orientado a objeto. USE A PORRA DO ESTADO! Comece a computação em um método, termine em outro, jogue todas as variáveis possíveis para atributos. Se ficar com atributos de computações diferentes em uma única classe, use a dica 2. Se essa classe for compartilhada por múltiplas threads, não use essa sugestão. Sugestão 5 Pais? Sim, use muito classes pais, evite delegação. Ela dá um trabalho danado (principalmente se sua linguagem do coração não tiver proxies dinâmicos) e o benefício é mais teórico que prático. Ahhmm... mas todo mundo diz que é melhor usar delegação do que herança. Poisé, e eu estou dizendo o contrário. Você está programando orientado a objeto ou não, afinal? Delegação é boa sim, onde fizer sentido, como por exemplo, em wrappers. Sugestão 6 Não use cegamente sugestões e boas práticas. Sempre, sempre, sempre (eu falei SEMPRE, caralho!) conheça os prós e principalmente os contras de toda técnica que você vai usar. Boa prática só é boa se você sabe quando não deve usá-la. Isso vale especialmente para as sugestões que acabei de listar. ;) Que sugestões você colocaria na lista? Ou modificaria?

Flamings e Einstein

2009-03-25T01:58:00.001-03:00

É muito comum ver por aí nos fóruns de tecnologias alguns tópicos que são "flamings". Fiquei imaginando o que causam esses flames e como é difícil distinguir idéias completamente furadas das idéias que realmente tem algo de bom. Acho que consegui chegar em uma pequena fórmula que deve resolver parte do problema, ao menos para mim. O raciocínio veio quando estava lembrando do que fez Albert Einstein. O cara foi tão ponto fora da curva que criou sua teoria da relatividade de cabeça, não por que ele quis assim, mas porque simplesmente não havia (e acho que ainda não há) experimentos possíveis para provar que a idéia é verdadeira ou não. Aliás, no meio acadêmico, isso é bastante comum. Como ele fez isso (e aliás, como os cientistas fazem isso, normalmente)? Ele partiu de um "pressuposto" e começou a raciocinar em cima dele. No caso, o pressuposto é de que a luz possui velocidade constante. Matutando e pensando, ele chegou a conclusões incríveis... desde que a velocidade da luz seja constante. O que tem isso de importante? Bom, se provarem que realmente é uma constante (se já não provaram), é grande a chance de que toda a teoria esteja correta. Se provarem que não é constante, então toda a teoria vai pro brejo. Aí nossa opinião sobre a teoria da relatividade se resume a analisar 2 coisas: 1 - Se concordamos com o pressuposto; 2 - Se achamos que o raciocínio do cara não tem falhas lógicas. Em software temos um problema similar ao que tinha o tio Einstein. Temos grandes dificuldades de provar nossas idéias e teorias sobre software. Acho que daí nascem os flamings e todas essas discussões que ficam parecendo mais discussões religiosas do que discussões sobre uma ciência exata. Como em software não temos quase limitação nenhuma, quase qualquer idéia dá certo com o esforço suficiente aplicado, mesmo as idéias muito idiotas. Essas idéias, idiotas ou não, também são criadas a partir de pressupostos. Não sei se todos, mas todos os softwares, apis, frameworks e posts de blog que consigo lembrar são baseados em alguns pressupostos. O problema é que nunca deixamos claros quais pressupostos são esses. Então nossas idéias são analisadas a partir dos pressupostos que cada pessoa escolhe. Depende do que ele escolhe como pressuposto, sua opinião vai ser favorável ou não a nossa idéia. A "pequena fórmula" para resolver o problema dos flamings, e também o problema para se detectar uma idéia boa de uma idéia idiota é simplesmente deixar bem claro os pressupostos que se tomou para a idéia. Não, não foi dessa vez que descobri a América ou inventei algo novo e inédito, pelo visto. Mas para mim é um coisa que vem dando certo quando tenho que analisar algumas coisas, como Frameworks e posts de blogs. :) Querem ver um pequeno exercício? Você pode concordar ou discordar de tudo isso que eu disse, mas se ela é uma boa idéia ou não é mais fácil analisar se eu colocar os pressupostos aqui. Aí vão eles: - É comum flaming nos fóruns de tecnologia; - O que causa o flaming é a dificuldade de se separar idéias boas das ruins; - É difícil separar as idéias porque é difícil prová-las; - É difícil prová-las porque quase qualquer idéia sobre software funciona se aplicarmos esforço suficiente; - As pessoas tendem a analisar as idéias pelos seus próprios pressupostos; - Podemos separar as idéias se conhecermos claramente os pressupostos em que foram baseadas; Parece uma linha de raciocínio, mas na verdade não é. Cada linha da lista acima pode ser contestada facilmente e não pode ser provada, são pressupostos. Se você concordar com todos eles, provavelmente vai concordar com a minha teoria como um todo. Se deixar de concordar com qualquer uma delas, provavelmente vai achar minha teoria um lixo. Se todos eles puderem ser provados com sucesso, então a teoria é verdadeira. Se qualquer um deles for provado em contrário, então ela é furada. Com tantos pressupostos (são ao menos seis, se não esqueci nada), dá pra ver que essa minha idéia é bem frágil. Bom, agora você conhece a teoria e conhece claramente no que me baseei para montá-la. Espero que fique fácil analisar se ela tem fundamento ou não para você e o porquê disso. E aí? Tem fundamento?

Da série "notas mentais"

2009-02-06T13:08:00.001-02:00

Não aconteceu comigo, mas com um amigo...

Quem efetivamente resolve o problema e faz acontecer não aparece em jornal. Quem aparece é o chefe, que é incapaz de gerar soluções e que mentiu o tempo todo para o cliente.

C'est la vie.

Fadado a ser estúpido

2009-01-30T16:12:00.001-02:00

Tentei escrever um pequeno mecanismo para transações explícitas em Java. Na primeira versão, ou o programador faz "try catch" direitinho (e repetitivamente), ou a coisa não funciona.

Implementei depois usando uma classe anônima. Fica parecido com closure, e resolve esse problema, mas ficou desagradável e com aquele gosto de "gambiarra" na boca.

A solução mais estúpida pareceu melhor...

Tentei também um mecanismo simples de reflexão no banco para poder gravar tabelas simples sem precisar fazer "dança da chuva" toda hora. Consegui, mas ainda ficou um negócio meio repetitivo e com o mesmo gosto de "gambiarra".

A solução mais idiota, criar beans pra tudo, tinha uma aparência melhor.

Moral da história: Ou sou realmente estúpido e minhas soluções são idiotas, ou sou esperto e a linguagem me faz parecer um estúpido. Ou seja, de qualquer maneira, sou estúpido.

Veja, eu adoro Java, é uma linguagem excelente. Mas ela não presta para fazer coisas dinâmicas do mesmo jeito que Ruby não presta pra fazer concorrência.

Generalizando como o diabo...

2009-01-28T19:20:00.001-02:00

Flash 1:
Estava aprendendo "clojure" (http://clojure.org) esses dias e o autor (Rich Hickey) fala sobre os problemas de variáveis mutáveis para multi-threading. Aí advoga sobre linguagens funcionais são melhores para multi-thread.

Flash 2:
Hoje, esbarrei com um código JSP e para tentar fazer uma besteirinha (colocar um valor padrão se um atributo não era fornecido) precisei de 5 linhas de "JSTL". Fiquei indignado e meti um operador ternário dentro da Expression Language.

Flash 3:
Estamos em um sistema que quase não possui regras de negócio. 90% são cadastros com simples validações (tem uma parte de GIS, mas essa é outra história). E temos dezenas de cadastros. Ao invés de criar um objeto "bean burro" para cada entidade e usar o hibernate como manda a cartilha, fizemos um objeto parecido com um Map que resolve pra todo mundo. O resultado é conseguimos fazer um CRUD simples com regras de validação em 4 minutos (mais ou menos), e esse tempo ainda vai cair...

O que esses 3 flashes me ensinam? Generalizações são extremamente perigosas. Se você não tem discernimento suficiente para saber quando quebrar um regra, tome cuidado ao segui-la. Você não sabe por que a está seguindo...

Adição: sempre existem regras que não sabemos quando quebrar.

Corolário: só respeitar a opinião de alguém se ele souber me dar um contra-exemplo.

Princípios de OO segundo Alan Knight (e Dilbert) (parte 2)

2008-06-02T11:37:00.002-03:00

Essa é a segunda parte desse post aqui.

Evite responsabilidades

Objetos devem ser preguiçosos ao extremo. Evite responsabilidades, se tiver que aceitá-las, mantenha-as vagas e delegue o trabalho de verdade para outros. O efeito final é que cada método vai fazer um fragmento muito pequeno de trabalho. Segundo o próprio Alan Kay, em um sistema orientado a objetos bem feito, você não consegue saber onde o trabalho está sendo realmente feito, quando você vê, já foi. Apesar de um fluxo em específico ser mais difícil de seguir (experimenta debugar em Smalltalk q vc vai entender do que eu estou falando), os métodos todos são tão simples que você consegue entendê-los em segundos. A segunda parte da proposição: "mantenha a responsabilidade vaga", significa que você deve desconfiar de especificações do tipo "o objeto deve persistir em banco todas as entradas". Isso porque ele contém detalhes de implementação, na verdade, o que interessa para os outros objetos não é como a informação vai ser guardada, mas como ela vai ser recuperada. Uma especificação melhor seria "o objeto deve saber informar as entradas feitas". Se isso será feito em banco de dados, em arquivo texto, distribuído na rede ou por sinal de fumaça, não interessa, o que nos dá muito mais flexibilidade. No final a idéia é aumentar o reuso. Evitando responsabilidades e delegando o trabalho, na verdade estou procurando reutilizar o que outras classes já fazem. Mantendo as responsabilidades vagas estou escondendo como faço as coisas (encapsulamento).

Princípios de OO segundo Alan Knight (e Dilbert) (parte 1)

2008-05-20T15:36:00.010-03:00

(nossa como faz tempo que não posto... :p) Faz uns anos eu achei um artigo artigo obscuro escrito por Alan Knight por volta de 2000 ou 2001 que é um excelente resumo de como deve ser um bom código orientado a objetos. O mais interessante é que o artigo faz analogia aos princípios "Dilbert", e por incrível que pareça, a analogia encaixa como uma luva. O texto é curto e muito divertido, recomendo a leitura! Como sempre mostro esse artigo pra todo mundo que eu conheço, achei que já era hora de citar ele no blog e fazer um resumo em português pra quem não conhece bem o gringolês. Como posts grandes ninguém lê, vou postando os princípios aos poucos. Nota: AS IDÉIAS AÍ EMBAIXO NÃO SÃO MINHAS, OKAY? EU GOSTO MUITO DELAS, MAS O AUTOR ORIGINAL É O "TIUZÃO TOP FODA" ALAN KNIGHT! Avisados? Ótimo! Senão depois o TaQ briga comigo por estar levando crédito por idéias alheias :).

Princípio 1: Nunca faça nada que alguém possa fazer para você.

Esse é basicamente o princípio do "tell, don't ask". Basicamente, objetos não podem ser caras legais. Nada de "Olha, preciso do total dos custos desde o começo do mês, mas não se incomode, me dê os dados aí que eu mesmo faço o cálculo, não deve ser muito complicado, não é?"

  total = centro_de_custo.itens.inject(0) do|soma, item| 
    if item.data > Date.parse('2008-05-01')
      soma += item.valor 
    else
      soma
    end
  end

Objetos devem ser grandes FDPs. Objeto bom é grosso como seu chefe: "Cara, quero o total dos custos desde o começo do mês! Não quero nem saber e não me interessa como você calcula isso, quero o resultado, e quero JÁ!".

  total = centro_de_custo.total_desde('2008-05-01')

Em Java, vejo muito uma coisa um pouco mais esquisita, normalmente envolve um DAO, injeção de dependência e costumeiramente um Date que não se pode construir diretamente pois o construtor está "deprecated":

  // getCentroDeCustoDAO foi alimentado antes pelo Spring
  // e "new Date" costuma ser gerado via Calendar, pq esse
  // construtor está deprecated faz tempo...
  List itens = getCentroDeCustoDAO().procurarPorDataDesde(new Date(2008, 4, 1));
  BigDecimal resultado = new BigDecimal(0);
  for(Item item : itens) {
    resultado = resultado.add(item.getCusto());
  }

Mesmo que você goste muito desse padrão, seria um pouco melhor do jeito abaixo. Embora já tenha ouvido que isso é regra de negócio e não deveria ser feita no DAO.

  // getCentroDeCustoDAO foi alimentado antes pelo Spring
  // e "new Date" costuma ser gerado via Calendar, pq esse
  // construtor está deprecated faz tempo...
  BigDecimal resultado = getCentroDeCustoDAO().calcularCustoTotalPorDataDesde(new Date(2008, 4, 1));

"Tell, don't ask" <= "Mande, não peça"...

Avanço tecnológico às avessas...

2008-03-17T12:50:00.002-03:00

Não sei se porque ando lendo coisas subversivas mas ando com a nítida impressão que estamos andando em círculos ao invés de fazer avanços na área de software... Alguns fatos me deram essa impressão: 1 - "Redescoberta" de closures -> coisa que antes do hype do Ruby ninguém dava bola, e agora é a discussão do momento. Só que isso existe desde 58 com LISP. Ou, se vc quiser uma roupagem mais moderna, desde 78 com Smalltalk. (Clipper tb tinha, alguém lembra?) 2 - Domain Driven Development -> não entrei muito a fundo, mas me parece basicamente o que o pessoal do movimento O.O. de 1970 e uns quebrados pregava. 3 - TDD -> okay, mesmo o Kent Beck confessava que isso não era novidade. 4 - Uma entrevista com John McCarthy (criador do LISP) na InfoQ -> Tem uma pergunta quase no final da entrevista sobre LISP sendo citado como influência para novas linguagens: "...many modern programming languages like Ruby are claiming big influences from Lisp..." McCarthy confessa que não conhece Ruby, mas pergunta: "Does it use, for example, list structures as data?" O entrevistador responde negativamente, e McCarthy completa: "So if you want to compute with sums and products, you have to parse every time? So, in that respect Ruby still isn't up to where Lisp was in 1960." Interessante... Existem alguns outros pequenos fatos aqui e ali, pequenos demais pra eu estar totalmente consciente deles, mas ando sentindo um "deja vu" desgramado. Será que sei pouco e na verdade há um avanço nessas coisas que não estou percebendo ou será que sei o suficiente e realmente estamos andando em círculos em algumas coisas? Como eu sempre assumo que não sei o suficiente, a questão agora está em saber o que não estou percebendo. Toca estudar mais... :)

Sobrecarga de métodos em Ruby

2008-03-12T18:18:00.007-03:00

Uma das coisas muito legais que o Java possui é sobrecarga de métodos (várias vezes confundido com polimorfismo) que é a capacidade de possuir métodos diferentes com mesmo nome, mas com parâmetros diferentes. Bom, isso não existe em Ruby, mas nada impede que isso seja implementado. Rascunhei isso aqui: class Object

  def self.generate_method_name_for(method_name, *parameter_types)
    # Usamos espaços no nome dos métodos gerados para evitar chamadas acidentais
    "#{method_name}_#{parameter_types.collect{|it| it.to_s}.join(' ')}".to_sym
  end

  def self.def_method(method_name, *parameter_types, &block)

    # Definindo o método genérico da classe,
    define_method method_name.to_sym do |*params|
      send("#{method_name}_#{params.collect{|it| it.class.to_s}.join(' ')}", *params)
    end unless self.method_defined?(method_name.to_sym)

    #Definindo cada método específico
    specific_method = generate_method_name_for(method_name, *parameter_types)

    define_method(specific_method, &block)

  end
end
E para usar: class Test
  def_method :test, String, String do |a, b|
    puts "Duas strings"
  end

  def_method :test, String do |a|
    puts "Uma string"
  end

  def_method :test, Fixnum do |a|
    puts "Um número"
  end
end

x = Test.new

x.test("a", "b")
x.test("a")
x.test(1)
É lógico que isso custa desempenho, mas serve. Acho também que o código poderia ser grandemente melhorado, até pq não sei se isso funcionaria corretamente com herança e polimorfismo, mas não quis perder mais tempo brincando nisso :) Moral da história: adoro classes abertas.

O que é preciso para DSLs?

2008-01-14T18:49:00.000-02:00

(Se vc não sabe o que é DSL, Akita explica... se quiser uma discussão aprumada e ajeitada sobre o assunto, dá uma olhada no que diz o tio Ronaldo) Alguns dizem que Smalltalk, Ruby e Lisp são boas linguagens para criar DSLs. Mas Java, C# e afins não são tão boas? Por quê? Depois de ler um tanto e experimentar mais outro tanto, acredito que para criar DSLs internas (veja o que diz Martin Fowler sobre DSLs internas e externas), uma linguagem precisaria dos seguintes items:

Reflexão(de verdade), ou seja, capacidade de inspecionar e alterar suas próprias definições em tempo de execução - DSL normalmente envolve criar e inspecionar código, e sem reflexão decente não dá pra fazer metaprogramação
Metaprogramação, ou seja, código que gera código - Muito da DSL na verdade é fazer com que pouco código faça muita coisa, às vezes de maneiras pouco convencionais. Para isso sua linguagem precisa conseguir criar código "on the fly" sem grandes maracutaias, porque afinal, você já vai estar fazendo maracutaias, aí a metaprogramação fica maracutaia ao quadrado :p
Closures (ou lambdas) - Permitir passar blocos de código pra cima e pra baixo são essencias para você codificar em um ponto e poder executar em outro, normalmente após preparar o terreno para a execução da closure
Sintaxe flexível - Não é essencial, mas ajuda a vc criar uma DSL simples. Sintaxes rígidas limitam a maneira com a qual você pode se expressar nas DSLs e elas acabam ficando mais complicadas sem necessidade. Um exemplo desse princípio é a tal da "interface fluente". Sem um sintaxe flexível, ela fica meio canhestra.
Classes abertas - Isso é uma extensão da "Reflexão", na verdade é permitir que você possa redefinir tipos básicos como String, Integer e outros. Se você olhar a tal da "interface fluente" vai ver que com classes abertas ficaria bem mais fácil criá-las

Tem gente que acha que uma linguagem de programação que permita essas coisas deveria ser queimada, triturada, empalada e que todos que programam nela são hereges que deveriam queimar no Inferno de Knuth. No final, tenho uma teoria (grandes coisa minhas teorias, mas como o blog é meu, vou postar). Tenho a teoria que, na verdade, Orientação a Objeto é uma maneira de criar DSLs internas, mas sem que pensemos em termos de linguagem. Toda boa API OO me lembra muito DSLs. Acho que nosso trabalho é puramente criar abstrações, quanto melhores, mais somos produtivos e menos dores de cabeça temos. Em um texto, as abstrações são tão maiores quanto mais técnico é o texto, onde uma única palavra (por exemplo: "Façade") abstrai uma idéia um bocado complexa. Do nosso lado, criar classe, métodos e refatorar código é basicamente melhorar as abstrações. Estou certo? Estou errado? Não importa muito, isso é mais retórico do que prático, no final. Mas esse tipo de pensamento muda um pouco minha maneira de encarar o que eu aprendo de novo... Editado: um "PS" aqui... esse artigo estava rascunhado no meu blog faz quase um ano... tou ficando velho e preguiçoso, e talvez um pouco lelé...

Desgaste de informação

2008-01-10T14:49:00.000-02:00

Hoje me deparei com uma situação que todo mundo passa, conhece, mas parece que ninguém toma medidas para conter o problema: quanto mais gente no meio entre a fonte de informação e o utilizador (EU!), pior a informação vai ficando. Cliente pede uma feature -> Relacionamento com cliente repassa para Gerente de projeto -> Gerente de projeto passa para Analista -> Analista passa para desenvolvedor. Nesse caminho, o que o cliente pediu já foi interpretado de maneiras diferente QUATRO vezes (Relacionamento, Gerente, Analista e Desenvolvedor). Em cada interpretação a informação sofreu um certo desgaste, detalhes se perderam e o pior: detalhes que podem ser irrelevantes foram adicionados. Esse é de longe o maior problema da informática, depois da comunicação falha (que é relacionada, mas não é a mesma coisa). Alguém sabe se existe alguma área que estuda o que acontece com a informação?

Closures para quê?

2007-12-20T17:27:00.001-02:00

“Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.”—Alan Perlis, “Epigrams on Programming”

(Esse artigo tem exemplos em Java e Ruby. Estou ignorando as sutis diferenças entre closures e blocos de código no Ruby)

Outro dia, num papo nerd com um colega (“O Francês”), ele me disse que não via ~~nenhuma utilidade para closures~~ com bons olhos a inclusão de Closures no Java. ~~Que até já tinha olhado e brincado um pouco, mas que tudo que closures fazem é perfeitamente possível de fazer sem usá-las.~~(É... ele me fez corrigir o texto :) )

Bom, ficou bem difícil argumentar aquilo no momento. Realmente, tudo que se pode fazer com closures também é possível fazer sem, da mesma maneira que é possível escrever um programa web em C (muita gente ainda faz e adora) ou escrever um aplicativo comercial em Assembly.

Depois dessa conversa comecei a tentar catalogar usos interessantes de closures. Pode ser que isso não convença ninguém de que são úteis, mas ao menos me serviu para organizar minhas próprias idéias. A seguir listo uma série de usos bem interessantes e bastante comuns de closures.

Bom, minha intenção não é explicar o que são closures – para isso o Akita tem um excelente artigo – mas sim mostrar onde o uso de closures é legal.

Callbacks

Talvez um dos melhores usos de closures sejam callbacks), ou seja, uma função que será executada posteriormente. Trocando em miúdos, é um código que queremos que seja executado quando algum evento acontece no sistema, por exemplo quando um botão é pressionado (conhecido como “events”...), quando uma aplicação inicia, quando algo é gravado ou alterado (“triggers” ou “listeners”...?), ou quando algum estado no sistema muda (“hooks”...?).

Cada linguagem tem sua solução para implementar callbacks, como ponteiros para funções (C e afins), a função como “cidadão de primeira classe” (Python, Javascript), classes anônimas (Java), “delegates” (C#) ou … closures, óbvio (que é solução para Smalltalk e Ruby)!

Cada um defende sua linguagem como gosta, mas independente disso, closures são muito práticas. Eu posso definir um callback de um botão da seguinte forma:

(Código em Ruby/GTK2)

 # Cria um botão
 button = Gtk::Button.new("Click me")

 # Quando clicar, imprime "Cliquei no botão"
 button.signal_connect("clicked") { puts "Cliquei no botão" }

A parte do ’{ puts “Cliquei no botão” }’ é um closure. Nesse caso, é o código que vai ser usado quando o botão for ativado (“puts” é para imprimir o texto na console).

Simples assim, sem declarações, sem pré-requisitos, sem detalhes. Simplesmente “toma aqui esse código para executar depois”.

Iteradores (“visitors”)

Estamos sempre processando coleções e iterando sobre elementos. Na maior parte dos casos, um simples loop resolve o problema, mas em outros, somos obrigados a repetir o mesmo loop em uma série de métodos diferentes pois as operações são parecidas, mas não idênticas. Em outros casos a lógica de iteração é um pouco mais complexa e se mistura com a lógica que processa cada elemento.

Closures são fantásticos para resolver esses problemas. Vejamos um exemplo que aconteceu recentemente comigo. Eu precisava substituir o mapeamento do Hibernate em umas 400 classes java. Fiz um pequeno método que encontrava as classes e para cada uma encontrada, eu aplicava a lógica de substituição.

O método para percorrer as classes ficou assim:

 def on_java_classes
   Find.find(@root) do |file_name|
     yield(file_name) if file_name =~ /\/vo\/.*\.java$/
   end
 end

Esse método percorre toda a árvore de diretórios abaixo de @root e se o arquivo encontrado estiver sob um diretório “vo” e terminar com ”.java”, o bloco de código é executado.

E para usar o método para trocar um mapeamento fica assim:

 on_java_classes do |file_name|
   change_hibernate_mapping(file_name)
 end

É lógico que eu poderia usar esse loop e meu método tudo em um bolo só, mas agora eu tenho um método genérico que me permite percorrer essas classes e executar o que eu quiser com elas sem duplicar a lógica que itera sobre as classes. Posso, por exemplo, listar todos os mapeamentos, contar quantos “VOs” tenho, vasculhar se existem mapeamentos fora do padrão e outras coisas do tipo.

A coisa fica tão transparente, que posso usar coisas como “next” (para processar o próximo elemento) e “break” (para parar a iteração) dentro dos closures e eles funcionam como esperado. Por exemplo, se eu quisesse apenas fazer um teste com os 10 primeiros arquivos, poderia colocar um “break” no meio, dessa forma:

   i = 1
   on_java_classes do |file_name|
       break if i > 10 # passou de 10 arquivos, caia fora do método
       change_hibernate_mapping(file_name)
       i += 1
   end

Processamento “durante”

Quase todas as operações que fazemos de IO precisam de algo para “abrir” a operação e garantir que ela seja “fechada” quando terminamos o que precisamos. Isso vale para streams, arquivos, sockets, transações, record sets e sei lá mais quantas coisas.

Isso implica em uma lógica bastante incoveniente que costuma ser repetida à exaustão: abra conexão, execute o que precisar, garanta que foi fechado (normalmente com um bloco para tratamento de exceção).

Conexões com bancos de dados são particularmente um porre, porque costumam abrir e fechar vários objetos.

Com closures, resolvemos isso com facilidade. Aqui um exemplo de como se usar o Ruby-DBI da maneira tradicional. O exemplo foi tirado da própria página do Ruby-DBI, mas com o tratamento de exceções apropriado.

 require 'dbi'

 dbh = nil

 begin
   dbh = DBI.connect('DBI:Mysql:test', 'testuser', 'testpwd')

   sth = nil
   begin
     sth = dbh.prepare('select * from simple01')
     sth.execute

     while row = sth.fetch do
       p row
     end

   # Precisamos tentar fechar o statement, não importa qual o erro
   ensure
     sth.finish if sth
   end

 # Precisamos tentar fechar a conexão também
 ensure
   dbh.disconnect if dbh
 end

Com closures, a coisa fica bem mais simples. Podemos criar coisas para serem executadas ao redor do bloco de código e simplesmente esquecermos da necessidade de ficar abrindo e fechando objetos. (Aviso: o DBI já tem métodos que funcionam assim).

Primeiro, criamos dois métodos:

 # Esse método cuida de abrir a conexão, executar algo
 # e garantir q a conexão seja fechada.
 def connect(uri, user, password)
   dbh = nil
   begin
     dbh = DBI.connect(uri, user, password)
     yield(dbh)
   ensure
     dbh.disconnect if dbh
   end
 end

 # Esse método executa algo para cada registro recuperado
 # em um SQL. Ele cuida de fechar os objetos envolvidos
 # no processo. 
 def for_each_record_in(dbh, sql)
   sth = nil
   begin
     sth = dbh.prepare(sql)
     sth.execute

     while row = sth.fetch do
       yield(row)
     end
   ensure
     sth.finish if sth
   end
 end

E agora, o código para fazer exatamente a mesma coisa que o primeiro exemplo passa a ser:

 connect('DBI:Mysql:test', 'testuser', 'testpwd') do |connection|
   for_each_record_in(connection, 'select * from simple01') do |record|
     p record
   end
 end

Toda vez que precisamos de um código “de preparação” e um código “de finalização” podemos usar closures para poupar trabalho. Além das óbvias vantagens de redução de duplicação, fica bem mais difícil esquecer de fechar algo :)

Só para constar, existe um padrão pra isso, é o “Open During” do Kent Beck. Está no livro dele de “Best Smalltalk Patterns”.

Lógica condicional

Não somente de “ifs” e “switches” vivem os condicionais. Com closures, podemos simular condicionais para condições mais complexas.

Digamos que eu tenha um analisador de texto que me retorne palavrões encontrados em um HTML qualquer. Caso eu encontre qualquer palavrão, quero mostrar uma mensagem de erro.Uma maneira de fazer isso seria assim:

 # O método "find_dirty_words me retorna a coleção de palavrões
 # encontrados no texto.
 dirty_words = html.find_dirty_words
 unless words.empty?
   show_error_message(html, dirty_words, "Bad, bad, no cookies for you.")
 end

Por outro lado, posso criar isso em um método com closures dessa maneira:

 class Html
   def when_dirty_words_found
     dirty_words = html.find_dirty_words
     yield(dirty_words) unless words.empty?
   end
 end

E agora, posso usar assim:

 html.when_dirty_words_found do |dirty_words|
   show_error_message(html, dirty_words, "Bad, bad, no cookies for you.")
 end

Aliás, agora posso executar qualquer lógica com esses palavrões. Posso tentar limpá-los, contar sua frequência (estatística?), colocá-los em uma lista negra e assim por diante.

O melhor exemplo real de execução condicional com closures talvez seja o uso de REST no Rails (veja o método “respond_to” no “Listing.5”).

Domain Specific Language

Arrisco dizer que é impossível implementar uma boa DSL Interna (definição segundo Martin Fowler) sem closures.

Isso porque eles permitem uma grande flexibilidade na sintaxe, permitindo que você use os closures como blocos de código que podem ser armazenados, executados, repetidos, omitidos, reestruturados, postergados ou quaisquer que sejam as transformações necessárias para sua DSL funcionar.

Exemplos ótimos de DSL são o XML Builder e o Rake. Com pouco esforço você conseguem sintaxes perfeitas que se encaixam dentro do Ruby como se fosse parte da linguagem.

Veja por exemplo, como construir um xml com o XML Builder:

 require 'builder'

 xml = Builder::XmlMarkup.new(:target=>STDOUT, :indent=>2)
 xml.usuario(:id => 127) do
 xml.nome("Ronie")
 xml.sobrenome("Uliana")
 xml.idade(31, :type => "integer")
 xml.preferencias do
   ["strogonoff", "lasanha", "bolo de carne"].each do |item|
     xml.comida(item)
   end
 end

Isso gera o seguinte xml:

<usuario id="127">
 <nome>Ronie</nome>
 <sobrenome>Uliana</sobrenome>
 <idade type="integer">31</idade>
 <preferencias>
   <comida>strogonoff</comida>
   <comida>lasanha</comida>
   <comida>bolo de carne</comida>
 </preferencias>
</usuario>

Nesse exemplo, cada aninhamento é um closure, e o builder os rastreia para saber como montar o xml. Muito simples e prático, na verdade.

Generators

Esse eu confesso que nunca me resolveu nenhum grande problema até o momento, mas é uma técnica boa para se ter no cinto de utilidades.

Basicamente, é uma função que retorna outra, a primeira “configura” a segunda. Um exemplo simples que achei foi esse aí abaixo. Ele gera um closure que adiciona sempre o mesmo número ao número passado como parâmetro. Por exemplo, gero uma closure que adiciona sempre 5 a qualquer número que eu passe para ela. No exemplo abaixo criei dois desses, um “adicionador de cincos” e um “adicionador de oitos”.

O exemplo é meio bobo, mas se você pensar um pouco vai achar possibilidades interessantes para isso. Não sei se essas idéias seriam práticas, mas com certeza serão interessantes.

 def create_adder(number)
   lambda {|x| number + x}
 end

 add5 = create_adder(5)
 add8 = create_adder(8)

 puts add5.call(10) # retona 15, ou seja, 10 + 5

 # "add5.call(10)" é a mesma coisa que fazer add5<sup><a href="#fn10">10</a></sup>
 # Pra facilitar, vamos usar essa notação nos exemplos abaixo
 puts add8[ 30 ] # retona 38, ou seja, 30 + 8
 puts add8[ add5[ 1 ] ] # retona 14, ou seja, 1 + 5 + 8
 puts add5[ add5[ add5[ 0 ] ] ] # retorna 15... adivinha porquê :)

Um bocado complicado de entender? Bom, “lambda” é uma função que pega um bloco de código (o que está entre ”{}”) e retonar uma closure de verdade. Na prática, estou retornando uma função que será atribuída a uma variável para ser executada mais tarde. A parte legal é que essa função é “configurada” com o parâmetro “number”.

Esse é realmente embaçado, acho que fazer um equivalente em Java pode ajudar alguns (só espero não complicar o resto do povo)

 public class ClosureExample {

   public static interface Adder {
     public int call ( int x );
   }

   public static Adder createAdder ( final int number ) {
     return new Adder () {
       public int call ( int x ) {
         return x + number;
       }
     };
   }

   public static void main ( String [] args ) {
     Adder add5 = createAdder ( 5 );
     Adder add8 = createAdder ( 8 );

     System.out.println ( add5.call ( 10 ) );
     System.out.println ( add8.call ( 30 ) );
     System.out.println ( add8.call ( add5.call ( 1 ) ) );
     System.out.println ( add5.call ( add5.call ( add5.call ( 0 ) ) ) );
   }
 }

Com uma pequena variação disso da para fazer acumuladores. Ou seja, uma função que preserva a memória cada vez que é executada.

 def create_accum
   memory = 0
   lambda{|x| memory += x}
 end

 accum = create_accum
 puts accum[ 5 ] // retorna 5
 puts accum[ 10 ] // retorna 15
 puts accum[ 130 ] // retorna 145

Conclusão

Closures são muito úteis para várias tarefas comuns da computação. Não é porque sua linguagem favorita não tem e você acha que se vira muito bem nela que Closures deixam de ter sua utilidade. :)

Fechando o artigo do mesma maneira que abri:

“Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.”—Alan Perlis, “Epigrams on Programming”

Have a nice coding! :)

Off-Topic: O Ronie foi abduzido (de novo!!!!)

2007-10-08T15:26:00.000-03:00

Só pra avisar... Vários colegas andam tentando me contactar e nada d'eu responder. Não fiquei mal-educado de repente, não mais que o habitual, pelo menos. Mas estamos numa das fases mais críticas do projeto, bem no esquema "ou vai ou racha". Com isso, estou há algumas semanas sem comer ou dormir muito bem, sem abrir meu e-mail pessoal, sem postar no RubyOnBr, sem responder Skype ou Messenger e coisas do tipo. Sei que é uma tremenda viadagem, mas nesse ponto, quero fazer esse projeto funcionar. Dado esse estado de "podreira-meio-aviadado-não-responde-ao-maldito-e-mail" que eu me encontro, por favor, peço sua compreensão e uma doação pra pagar meu analista, ou então um abraço coletivo. Juro que antes de Dezembro volto a responder os e-mails.

Pra que ORM se não se usa OO?

2007-09-23T11:20:00.000-03:00

Pra que usar um sistema de mapeamento objeto-relacional se você trata seus objetos como dados? Objeto sem comportamento é exatamente igual a uma estrutura de dados. Reza o mito que você deve ter "classes de negócio" que executam regras. Bom... essas classes fazem coisas com suas classes sem comportamento... então... qual a diferença disso para uma função PHP que manipula linhas em tabelas? Bom, UMA das diferenças, certamente, é que usamos um monte de traquitanas a mais para obter os dados. Outra é que ganhamos alguns métodos convenientes para buscar dados relacionados. Mas fora isso, qual o ganho? Sinceramente, mais de uma vez vejo gente defendendo com unhas e dentes frameworks de ORM e usando ele para fazer sistemas que são basicamente, um PHP com mais camadas. E batem no peito pra dizer que é um "Sistema Grande". Veja, não tenho nada contra ORM. É algo absolutamente necessário se você usa um sistema realmente OO... Caso contrário, é só um trambolho a mais para cuidar. Como vejo gente demais fazendo isso, eu devo estar deixando escapar alguma coisa muito importante. Mas alguém me diga o quê.

Esbarrando com gente conhecida...

2007-09-12T23:15:00.001-03:00

Ontem (ou foi anteontem?), entrevistei o Kenobi (posta muito no GUJ) para uma vaga na empresa em que eu trabalho. Fiz a maior confusão com as vagas e acabei falando a vaga errada pra ele :( ê vida besta. É um cara bastante seguro de si, só acho que causou uma má impressão na moça que comecou a conversa com ele. Engraçado como a gente vive esbarrando com gente "virtualmente" conhecida. Acho que o mundo da informática (pelo menos no Brasil) é menor do que eu suspeitava... ou então preciso viajar mais para o resto do país e sair um pouco da Cidade da Garoa :p

Melhorando o detector de "bullshit"

2007-09-12T19:39:00.001-03:00

Sabe quando você está lendo um texto, não chegou nem na metade e pensa: "bullshit". Poisé, faz um tempo tenho um "detector mental de bullshit" pra esse tipo de coisa. Funciona igual aos "code bad smells": você está numa conversa, ou está lendo algo, e algumas palavras fazer o detector tilintar. Aí você lê com mais atenção pra ver se é balela mesmo ou se tem fundamento. Tem algumas palavras que fazem o detector simplesmente gritar :) Muitas delas juntas, então, quase dão dor de cabeça!

Enterprise (top top!)
Arquitetura (ou pior, um texto todo em português, mas usando o termo em inglês)
Flexível
Robusto
Ágil (todo mundo virou ágil depois que isso virou power word)
Escalável
Performance (principalmente se não vem com NENHUMA medição)
"O correto é" ("correto" depende muuuuito do que você está fazendo)
Grande porte (parece que o povo mistura "muitas regras de negócio", "muitos usuários" ou "transações bagaraio" sem muita discriminação)

Entre outras... Recentemente fiz um "upgrade" no detector. Adicionei uma regra: "discussões sobre méritos de tecnologias em que o cara dá argumentos sobre performance". Muito, mas muito raramente mesmo, isso tem algum embasamento maior do que mero "achismo". E, pessoalmente, "rápido o suficiente" já está bom. Por outro lado, tem palavras que entram no "white list" e aliviam a coisa:

Teste
Padrão ou Anti-padrão
Pragmático

É... minha white list tá pequena! :D E aí? Alguém tem outras palavras que fazem o "detector de bullshit" tocar? (Garanto que tem gente que coloca a palavra "Rails" na lista :D)

Da série "Notas Mentais": Pessoas Sérias

2007-09-10T14:23:00.000-03:00

Não consigo levar a sério pessoas que se levam muito a sério... Por quê? Bom, cedo ou tarde, vamos todos virar adubo pra grama, que é a mesma função que um belo monte de merda faz. Aliás, o "belo monte de merda" deve ser um adubo melhor do que nós seremos... :p Aí que está a parte complicada... O cara vem todo importante, botando marra e arrotando peru... aí me vem esse pensamento em mente e não consigo ficar sério. :)

"Pseudo" encapsulamento

2007-08-27T23:58:00.000-03:00

Junto com "herança" e "polimorfismo", "encapsulamento" é o terceiro pilar da programação orientada a objetos. Aliás, tentar fazer da programação um aglomerado de "caixas pretas" é uma coisa que tentamos desde que inventaram o Assembly. A idéia sempre foi ocultar detalhes para que se possa modificar o programa facilmente ou, no mínimo, não esquentar a cabeça com detalhes. Um dos melhores patterns que já vi sobre o assunto faz parte de um catálogo de patterns do Brian Foote chamado "The Selfish Class". Ele não foca exatamente sobre mudança, mas sobre facilidade de uso. Mas no fim da contas, fazer muito através de uma interface mínima é o melhor ponto sobre encapsulamento. O que vemos muito por aí é encapsulamento "pra inglês ver". Só funciona na teoria, porque na prática, é igual tentar se esconder tampando os olhos, no melhor estilo: "se eu não o vejo, ele também não me vê". Ao longo do tempo, comecei a encarar alguns items como bad smell de "encapsulamento pra inglês ver" e gostaria de compartilhar eles: Métodos de acesso : Talvez o bad smell mais comum e o mais polêmico. Métodos de acesso (gets e sets) quebram encapsulamento. Não sou o único a pensar assim (procure no google, você vai achar mais alguns doidos, inclusive com muito mais cacife que eu). Basicamente a idéia é a seguinte: você está expondo seus dados internos, mesmo que seja atráves de um método. Isso não é muito problema, desde que, em 90% do tempo, você trate o objeto como um todo ao invés de ficar cutucando seus dados (do objeto, não os seus) Mas quando você começa a pegar os dados de uma tela web e jogar campo a campo no seu objeto, isso significa que você quebrou o encapsulamento. Uma maneira "caixa preta" de fazer isso seria jogar os dados todos pra dentro do objeto e ele pegar o que precisa OU fazer a atribuição via reflexão. O ponto é o seguinte: se você alterar um campo e tiver que mexer em algum lugar que não seja tela, banco ou regra de negócio, então seu encapsulamento está quebradão. Caso típico é quando você precisa ficar"repassando" os campos. Não concorda? Não tem problema, é um feeling meu (e de alguns outros doidos). Coloca o seu aí, então, ué :) Delegate : Delegates são uma ótima forma de diminuir o número de objetos que você tem que trabalhar. Mas quando você começa a delegar TUDO, ou então os mesmo dados (parâmetros e retorno) são simplesmente passados sem alteração ou qualquer outro comportamento por 2 ou 3 métodos... hmmm... tem algo estranho. Já vi isso sendo usado como uma forma de manter as coisas no lugar quando se está em uma arquitura com muitas camadas. Mas sinceramente, isso é só uma maneira muito esquisita de violar camadas, não de preservá-las. Se você precisa de algo lááá do fundo em uma camada da frente, sem alterações, melhor repensar sua arquitetura nesse ponto. Iteradores externos : (essa vai fazer alguém querer comer meu fígado... sem tempero!!!) Essa viola a máxima do "Tell, don't ask" sem dó nem perdão. A moral da história é a seguinte, ao invés de pedir para as coleções trabalharem para você, somos obrigados a pedir licença, pegar tudo o que elas têm e ficar item a item vendo o que precisa ser feito. A solução para isso seriam iteradores internos, implementados lindamente com closures (viva Smalltalk, 30 anos atrás já fazia isso!). À primeira vista, quem não conhece vai achar que dá na mesma, só quando você olha mais de perto vê que várias operações básicas que fazemos todos os dias podem ser encapsuladas com isso. Tais como "selecionar o primeiro que satisfaz uma condição", "fazer um 'de->para' com os objetos da coleção", "acumular valores segundo uma fórmula qualquer", e por aí vai. "Data Transfer Objects" ou "Value Objects" : Essa viola o "objetos devem ter comportamento". Veja bem, um Objeto (com "O" maíusculo) é justamente a junção de DADOS + FUNCIONALIDADE (comportamento), se você tem dados em um objeto, então a funcionalidade que atua sobre esse objetos está em outro lugar... separando dados e funcionalidades voltamos a programação procedural (ou funcional). E no que isso viola encapsulamento? Viola porque outros objetos precisam conhecer os detalhes do seu DTO para poderem trabalhar com ele. Trocando em miúdos, esse "pseudo-objeto" está com suas estranhas completamente expostas e a mercê de outros objetos malignos que querem comer seu coração (do objeto, não o seu). Okay, como tudo na vida, existem lugares onde DTOs são legais e bemvindos. Mas quando eles começam a aparecer demais, aí dá pra começar a ficar desconfiado. Se a gente realmente caprichar no uso dos DTOs, vamos acabar com um sistema OO com a cara de um ASP dos antigos, mas com mais camadas... No geral, são esses meus bad smells de encapsulamento. E são realmente bad smells, ou seja, pode ser que não seja nada e que o uso esteja correto, mas não custa dar uma verificada. Outra coisa é que encapsulamento é legal, mas não é nenhuma vaca sagrada (é?). Violo ela com muito gosto e uma pitada de sal se for para deixar meu sistema mais simples. Infelizmente, normalmente é o contrário... :)

Linguagens do futuro

2007-08-10T11:01:00.001-03:00

Um colega meu ("O Francês") me apontou alguns links que o pessoal aposta no Erlang como próximo sucessor do java. Isso me deu vontade e exercitar minha "veia futuróloga". Não que eu seja um bom futurólogo, mas é que é divertido ficar fazendo extrapolações. Na minha humilde opinião, acho que existe um buraco a ser preenchido para a "Próxima Grande Linguagem". Explico: Nos anos recentes, ando observando uma crescente valorização das linguagens de script, acho que principalmente por causa do Javascript, Ruby e Python (não descartando PHP) que vêm ganhando atenção. Com isso, vi que certas coisas, como "closures" ganharem bastante importância conforme o pessoal começou a perceber que isso facilita muito a programação. Essas funcionalidades todas, até onde percebo, são justamente as que facilitam a criação de DSLs (Domain Specific Languages). Nota pessoal: um bom sistema Orientado a Objeto é praticamente uma DSL. As boas práticas de programação OO parecem levar inadvertidamente a uma DSL. Se esse pressuposto for correto, a próxima grande linguagem deveria ter funcionalidades boas para gerar DSLs. As melhores que conheço hoje são Lisp e depois Ruby. Para o Lisp virar a "Próxima Grande Linguagem", me parece que faltam duas coisas: uma sintaxe mais digerível para os desenvolvedores que estão acostumados com linguagens de sintaxe "C-like" e uma "killer application" (ou deveria dizer "killer framework") para web. Digo isso porque aplicações web são o que está quente hoje, com tendência a ficar mais quente :) Para o Ruby virar a "Próxima Grande Linguagem", sinto que falta uma boa máquina virtual, talvez com compilação para alguma linguagem intermediária. Aí entra a competência do YARV ou do JRuby (ou IronRuby também). Conclusão: acho que existe um buraco aí que poderia ser preenchido por algo que compilasse em bytecode de Lisp, mas que tivesse uma sintaxe mais similar ao que a grande maioria dos desenvolvedores está acostumado. Eu estava trabalhando em algo na linha, só por farra, mas minhas habilidades em compiladores ainda é meio crua e vai demorar um bom tempo até aparecer algo que valha a pena brincar :) Vamos ver no que dá.

Da série "Notas mentais": Pessoas

2007-07-30T10:12:00.000-03:00

Elas são como livros, só mais inconstantes...

Da série "Notas mentais": Livros

2007-07-30T09:58:00.000-03:00

1 - Nunca acredite piamente em um livro. Exceto pela matemática (e mesmo alguns desses), o resto são apenas opiniões e hipóteses. 2 - Nunca duvide demais de um livro. Mesmo em um livro totalmente errado, algumas idéias podem estar certas. (A idéia que um relógio quebrado ainda está certo duas vezes ao dia) 3 - Consolide sua opinião frequentemente, a maior parte do que é certo hoje se torna errado cedo ou tarde, basta dar tempo o suficiente. Pode me chamar de "descrente", se é que isso tem a ver com "crer" :D

Candidatos a idiomas no Java

2007-06-28T16:04:00.000-03:00

Apesar de focar muito em Ruby, é o Java quem paga o pão nosso de cada dia. E apesar de eu ter algumas encrespadas com a linguagem, ela é muito competente no que faz. Um pouco travada, talvez, mas ninguém é perfeito :) O interessante é que depois de um tempo, vamos pegando alguns "idiomas", ou seja, mini-padrões que vivem se repetindo. Acho que já li esses dois em algum lugar (muito provável), mas como estou usando eles com muita frequência, gostaria de deixá-los registrados:

Idioma: Parâmetros Opcionais Explícitos Problema: Você tem um método quem tem parâmetros opcionais. Frequentemente, a opção não passada é "null" ou tem um valor padrão bem definido. Solução: Crie um método para cada configuração de parâmetros que você tenha e faça os com menos parâmetros chamarem os de mais parâmetros. Apenas o método com mais parâmetros tem a lógica. Reasoning: Sempre usar um único método pode ser um problema se na maior parte das vezes o valor passado é o mesmo. Se você quiser alterar o "padrão", tem que caçar em todo o código. Por outro lado, travar um valor fixo faz você ter que alterar o código se quiser algo ligeiramente diferente. Oferecendo um bom padrão e , ao mesmo tempo, flexibilidade, resolve os dois usos e o custo é baixo. Exemplo:

public Autocomplete ( String className, Object parameter, int maxSize,
 String highlightTemplate ) {
    try {
        this.klass = Class.forName ( className + "Option" );
        this.parameter = parameter;
        this.maxSize = maxSize;
        this.highlightTemplate = highlightTemplate;
        initialize ();
    } catch ( ClassNotFoundException e ) {
        throw new RuntimeException ( "Class not found for \"" + className + "\"", e );
    }
}

public Autocomplete ( String className, Object parameter, int maxSize ) {
    this ( className, parameter, maxSize, "$1" );
}

public Autocomplete ( String className, Object parameter ) {
    this ( className, parameter, 8 );
}

Parece que dá um pouco de trabalho (e até dá), mas é uma maneira muito clara de você passar a idéia de ter parâmetros opcionais, e depois que você acostuma, é completamente trivial alterar os valores padrão. Como experiência própria, só procure evitar "explodir" o número de métodos, procure só fazer os métodos mais usados como padrão e usar a versão "expandida" para flexibilidade total. ---- Idioma: Parâmetros Nomeados Problema: Você tem uma classe que precisa de muitos parâmetros (principalmente opcionais) para ser configurada. Solução: Para cada parâmetro, crie um método "set" que retorna o próprio objeto, assim, você pode encadear os métodos ("method chaining") em um única chamada. Reasoning: Criar construtores com muitos parâmetros torna a classe difícil de usar, e forçar um série de métodos "set" repetindo o mesmo objeto torna o código chato de digitar e às vezes pouco óbvio de ser lido. Exemplo: (Tirado da biblioteca JDOM)

new Element("book").setAttribute ( "id", "1" ).setText("Java Idioms");

O equivalente sem o idioma seria:

Element element = new Element("book")
element.setAttribute ( "id", "1" )
element.setText("Java Idioms");

Bom, é isso. Nenhuma invenção nova, só catalogando idiomas que vivo esbarrando e acho legais :)

Estaticamente trabalhoso

2007-05-03T21:08:00.000-03:00

Tava observando um amigo meu trabalhar em um framework ontem e percebi umas coisas interessantes. O processo foi mais ou menos assim: O framework era em Java e ele precisava pegar uns registros no banco de dados pra montar uma combo. O framework tinha sido criado em cima do Hibernate e já cuidava de toda parte xarope de sessions e afins. Pra pegar os dados ele criou um Criteria e passou pro framework. Como não havia um DAO para aquele objeto, ele precisou criá-lo, declarar a coisa no Spring e montar o método que buscava o DAO de lá (tá acompanhando? Se perdeu? Inda não acabou). Para preservar a tipagem estática e encapsular as chamadas nas camadas corretas, ele ainda teve que fazer mais três ou quatro declarações de métodos onde a única diferença era o tipo da variável. Fiquei observando e percebi que a única coisa que realmente havia mudado era o Criteria, o resto, todo o resto incluindo o DAO, só foi feito para preservar a tipagem estática e "isolar" as camadas (isso mesmo, "isolar" entre aspas. Tenho ressalvas com isso, mas é papo pra outro post). Não acho tipagem estática ruim e não estou pregando contra divisão de software em camadas, mas fiquei me perguntando o quão longe a gente vai e o quanto a gente complica as coisas onde não há necessidade real. Nesse exemplo não havia. Um simples hql "select x from Classe as x" enviado para um DAO genérico resolveria de sobra. Será que a gente não anda inventando mais coisa do que seria necessário só por questões de "assim o desenvolvedor idiota não vai usar errado" e "assim fica mais flexível"? Precisamos de verdade dessa proteção e dessa "flexibilidade"? O tempo passa, vou ficando mais cético. Só queria saber se pra bem ou pra mal.

E o que deu o SunTechDays

2007-04-20T23:02:00.000-03:00

No fim das contas, as palestras estavam todas atrasadas mais de hora e a que eu queria assistir ficou muito tarde. Poisé, fica pro próximo ano... O que valeu mesmo foi ver um carinha dançando pra ganhar uma jaqueta (mó legal a jaqueta). O cara literalmente "se desdobrou", só quem estava lá pra entender. Nunca ri tanto!

Ronie no SunTechDays

2007-04-20T10:20:00.000-03:00

(essa porcaria de computador do evento nao estah com os acentos configurados... jah viu como vai sair o post) Depois de todo esse tempo mexendo com Java, resolvi vir a um SunTechDays pra "tirar a virgindade..." Vim soh hoje de manha (dia 20) e pulei o dia 19. Evento bem organizado, tudo muito bonito (sem brincadeira, eh bonito mesmo!). Fui experimentar a palestra do Bruno Souza... ai... ai..., mesma pagacao de pau de sempre, tive que sair logo, antes que ele conseguisse me convencer de que Java era a primeira maravilha do universo e, se Deus usasse Java, o Big Bang teria sido open-source e que eu conseguiria fazer ele no meu celular... Mas o cara eh o "Javaman", entao tah certo. De resto, soh estou esperando, espero que a palestra sobre Scripts rodando na VM seja boa. Pena nao poder ficar o evento todo...

Grandes decepções

2007-04-18T21:07:00.000-03:00

Eu estava comentando com uns colegas sobre "grandes idéias brochantes", ou seja, idéias que inicialmente pareciam muito boas, mas que depois descobrimos alternativas melhores, ou descobrimos que não eram lá tão boas assim. [AVISO! O conteúdo a seguir é de alta octanagem e pode causar flame wars ao menor contato com trolls e outros cabeçudos de plantão. Lembre-se que essas opiniões são baseadas na minha experiência pessoal. Sua opinião pode ser diversa e sua experiência pode ser outra, por isso, se quiser dizer que estou errado e sou um idiota, seja no mínimo educado, pra não passar por troll. (E se me ofender, vou aí chutar sua bunda!)] Vou colocar meus 2 centavos de "grandes idéias brochantes" que aconteceram comigo: Brochante 1: RUP Em idos de 1998, quando descobri RUP, achei que era "O" processo. Que a coisa era a solução definitiva para os problemas de projetos de software mal feitos. Comecei a estudar com afinco, e pensei "Nossa, quanta coisa! Mas um bom processo deve ter definição pra TUDO, então tá certo." Depois, tive que fazer um projeto que usávamos um pouco de RUP. No início achei que tínhamos problemas porque estávamos usando pouca coisa, aí aumentamos nossa "aderência" ao RUP. Resultado: tempo gasto com documentação, menos desenvolvimento, documentos desincronizados, mais tempo com documentação, menos desenvolvimento... e no final, ainda muitos bugs e nenhuma estimativa confiável. Fiquei meio com um pé atrás, será que eu tinha errado? Primeira experiência com a coisa, acho que não tinha usado certo. Aí conheci XP. Primeiro projeto besta que apareceu, experimentei. Ótimos resultados. Apareceu um projeto grande, experimentamos XP. A cada prática que colocávamos do XP, melhoravam os resultados. Conclusão: brochei do RUP. Brochante 2: SOAP A primeira vez que vi, achei que web services com soap eram a melhor invenção desde o pão fatiado. Ainda mais a integração que ele tinha com a plataforma .NET, super simples e fácil. Um pouco mais tarde, descobri que o negócio era meio complicado, já que, fora do .NET, mexer com SOAP era um pesadelo (era o tempo do Apache-SOAP ainda, nem existia o Axis). Daí, tive que fazer integração com alguns clientes que estavam usando simples "XML Vai, XML Vem" (protocolo "XV2") com posts e gets. Foi simples, fácil e muito rápido. Pronto, brochou geral. Hoje minha mente buzina "muita solução pra pouco problema" toda vez que penso em SOAP. E olha que isso foi antes d'eu conhecer RESTful Web Services. Brochante 3: Aspectos Quando conheci aspectos, achei a coisa mais poderosa do mundo. Simples, não intrusivo e resolvia grandes problemas. Comecei a estudar. Até ajudei um colega a fazer um chat P2P de brincadeira em que a encriptação das mensagens era feita por aspecto. Colocava aspectos, pum, mensagens encriptadas; tirava aspectos, pam, mensagens plain text. Fantástico! Comecei a sonhar com uma camada de persistência não intrusiva, toda feita com aspectos. Aí conheci RUBY e o "alias". Fiz tudo que fazia com aspectos sem esquentar a cabeca com pointcuts, advices e outros blah blah blahs. Resultado: brochei de Aspectos. Hoje, quando Aspectos me vêm à mente, tem uma tag mental escrita: "classes abertas + alias, ponto final". Já tentei não pensar nisso, mas não adianta, encalacrou... Brochante 4: Portlets Quando vi, achei uma boa idéia. Era a componentização para web, finalmente! Com um pouco mais de trabalho, a idéia serviria pra fazer componentes que poderiam ser utilizados em aplicações "não-portal". Comecei a estudar... De cara, achei muito tosco, submeter todo o form e tentar manter o estado de cada Portlet era uma gambiarra sem fim... Mas vá, ossos do ofício, já que a web funciona assim. Comecei a achar que componentes pra web não eram lá uma idéia muito boa (ainda acho isso...). Aí apareceu o Gmail, com intenso uso de AJAX. Olhei pros Portlets, pensei em como fazer eles em AJAX e pensei... "poisé, tou perdendo tempo"... Sei que AJAX tem muitas limitações, conheço elas porque uso muito AJAX. O que só reforça minha idéia de que "aplicação web não pode ser pensada como se fosse desktop". Mas sinceramente, entre eles e Portlets... : Brochante 5: Java Essa foi engraçada, brochei antes de conhecer a linguagem. Em meados de 2000 eu trabalhava com Perl Orientado a Objetos (é... existe sim), e fiquei curioso quanto ao Smalltalk, já que todos os lugares falando sobre orientação a objeto mencionavam Smalltalk de um jeito ou de outro. Resolvi aprender... Fiquei maravilhado com a linguagem: simples, poderosíssima, ambiente integrado onde eu alterava os sistemas "à quente". UAU! Aí apareceu a oportunidade de trabalhar com Java, uma vontade que eu tinha desde os tempos de faculdade, pois todo mundo elogiava. Cheguei cheio de espectativas: "Java é bem mais novo, é orientado a objetos e deve ter todos os conceitos do Smalltalk, mas com tipagem forte!" ... Frau frau frau... Brochação geral... Collections ridículas, sem closures, pouca extensibilidade, ciclo de compilação full e nada de alterar a coisa "à quente". E a tipagem estática mais atrapalhava do que resolvia. Conclusão: Hoje gosto muito do Java e desde lá venho usando ele 8 horas por dia, 5 dias por semana. Mas se me perguntarem se é a melhor linguagem pra programação... beeeeemmmm... tenho saudades de collections com closures... Lições aprendidas... O que foi que aprendi com essas "brochações"? Aprendi que nem toda idéia do "mainstream" é uma boa, e a olhar propaganda com muita desconfiança. Aprendi que é bom olhar o underground da computação em busca de idéias novas, ou pior, de velhas idéias fantásticas que nunca caíram no gosto da maioria. Hoje sei que sou um programador melhor a cada vez que gasto tempo aprendendo algo que me faz pensar diferente... ando aprendendo LISP... espero que dê frutos (já deu, pra ser honesto)

Arquitetura três camadas é um mito sobre desacoplamento...

2007-03-19T16:59:00.000-03:00

Uma coisa que aprendemos desde nosso primeiro "if-else" em programação é que aplicações devem ser feitas em 3 camadas (ou mais), a saber: apresentação, aplicação e persistência. Uma arquitetura muito similar a ela é a popular MVC, que separa as coisas de forma parecida, mas a camada de persistência some dentro do "model" e a camada de aplicação é dividida entre "model" (com regras de negócio) e "controller" (que funciona como "cola" entre View e Model). Hoje em dia, boa parte das arquiteturas pra web é um misto de MVC com 3 camadas, num bororô formado por frameworks de apresentação, controllers temperados com "Dependency Injection" e um mapeador objeto-relacional. Tudo isso somado fornece o melhor nível de desacoplamento possível no sistema. É possível até mesmo trocar de banco de dados Oracle pra SQL-Server trocando apenas umas poucas linhas... Mas será que é desacoplado mesmo? Que tal experimentar o desacoplamento com uma alteração bastante comum como, vejamos... adicionar um campo? Bom, temos que mexer na view pra adicionar o campo, tb temos que mexer na camada de negócio para tratar o campo e validar, aí temos o transporte (V.O.s?) onde temos que adicionar o campo, e finalmente, adicionar no banco (o Hibernate até gera o campo pra vc, só que ele não migra os dados quando acontece a evolução do esquema, é na base da recriação da tabela). Okay, o que temos aqui? Uma simples alteração gerou uma "shotgun surgery" no código, necessitando de alterações em todas as camadas. Agora a questão é, como eu ISOLO isso? E, sendo mais cínico, de que me adianta trocar de banco com uma linha (e muito raramente eu faria isso), se para adicionar um simples campo eu preciso espalhar as alterações pra todo lado? Eu já vi a algum tempo atrás na web alguns artigos com a mesma preocupação, eles tinham até um nome pra isso, mas sinceramente não consigo me lembrar, e por consequência, não acho mais os artigos :( Se alguém achar, me dá um toque.

De volta de lugar nenhum, não fui mesmo.

2007-01-11T17:31:00.000-02:00

Depois de dar um gás no RubyOnBr e ele ocupar todo tempo livre q eu tinha pra escrever besteira, resolvi voltar a blogar. E como jurei solenemente pela tira dos malvados que ia ser um cara legal esse ano, vou dar um tempo com meu outro blog :) Agora é pau na máquina e no código.

Meu último post

2006-04-07T15:40:00.000-03:00

Vou aposentar meu blog. É isso mesmo. ("Grandiscoisa", né?) Depois de ouvir muita piada do Bart e do Marlus sobre como eu só posto reclamações, resolvi assumir que sou um resmungão mesmo. Então estou aposentando esse blog.... ... e criando outro :D Agora sim o blog vai ficar bom: http://josebuscape.blogspot.com Poisé... é isso :)

Web tranqueiras úteis

2006-04-06T09:22:00.000-03:00

Engraçado, tou cada vez mais usando coisas web e menos aplicativos locais. Eles são muito mais simples e com menos recursos que os aplicativos locais, mas o fato de você poder compartilhar as coisas faz toda a diferença. Aqui estão algumas web tranqueiras que eu ando usando: del.icio.us (http://del.icio.us/rmuliana) -> Meu "bookmark social". Já não vivo sem isso. blog (http://mecanicamente.blogspot.com) -> Uso mais pra compartilhar idéias com colegas e frequentemente, comigo mesmo. flickr (http://flickr.com/photos/rmuliana) -> Compartilhar fotos. Uso pouco, mas quando uso, vem muito a calhar. writely (http://writely.com) -> Escrever e compartilhar documentos de texto. Estou "começando a começar" a usar agora. jobby (http://www.gojobby.com/Jobby/Resume/?user=986) -> Site para empregos utilizando a filosofia "Web 2.0". Meu currículo está lá e eu assino o RSS com programadores Java no Brasil. Cada indíviduo com o perfil que eu quero que entra lá, meu RSS já "apita".

Justo quando estou tentando fazer as pazes com Java...

2006-04-03T17:46:00.000-03:00

Essa eu até tinha esquecido até 5 minutos atrás quando precisei de novo: "Como você copia um arquivo em Java?" Resposta: Abra dois streams e copie bytes de um para o outro.... COPIAR BYTES!!!!!! Ahhhh... Fala sério!!! Entrou pra minha lista negra, junto com Calendar e Date: File

Parei de brigar com Java

2006-03-23T10:24:00.000-03:00

Tem um monte de coisas que eu não gosto no Java. Collections meia boca, Date e Calendar cretinos, falta de closures, "estupidamente" tipado e outras coisas mais. Porém, tenho que reconhecer que ele tem partes excelentes, a nova api para concorrência (do Doug Lea), muitas APIs pra tudo que você puder imaginar, uma comunidade grande (Apache inclusa), excelente IDEs (como o Eclipse, IntelliJ, Netbeans). Sem falar que eu trabalha fazem muitos anos com Java, então tenho um domínio da linguagem muito bom. Então, decidi que ao invés de ficar reclamando como sempre, vou implementar as idéias que eu gosto (a maioria roubada de Smalltalk e Ruby) e fazer o melhor possível com o Java, usando o que é bom dele. Não dá pra fazer milagres, mas dá pra melhorar bastante. Minha Wishlist: - Collections: Por enquanto, acho q vou me limitar a usar o Apache commons - Date e Calendar: ("muitas APIs") vou começar a usar Joda-Time. Parece muito boa! - Closures: Isso não tem muito jeito. Já via algumas libs legais pra Closures (tem uma aqui muito boa) Mas Closures em Java continua não sendo fácil de usar. Principalmente porque a sintaxe fica desajeitada e porque as coleções não suportam elas (justamente onde são mais úteis). Vou usar o que tem do Apache e provalemente criar uns helpers para classes anônimas, se eu já não achar isso na net. - Structs: Tipo beans, mas dinâmicos. Tem o Apache commons pra beans, bem útil. Mas vou criar umas pequenas estruturas para mim. Ia ser legal achar um nome tipo "Beans" :D Sei lá... o que é menor que um feijão (ou grão) e mais gostoso? "Berries"? "Café solúvel"? Vou ver se junto tudo, faço um Jar legal e adiciono nos meus projetos. Aquela história: "não adianta reclamar se você não vem com alguma solução"

Onde estão os web designers? (Reclamação!!!)

2006-02-23T13:32:00.000-03:00

Eu costumo dividir os caras que fazem o visual da página em 3 categorias: "Fazedor de HTML" não sabe HTML. Usa só Dreamweaver, ou pior, FrontPage. Não tem noção de cores, uso de espaço em branco, fonte, nem nada. No nível avançado, conhece as tags FONT e TABLE, e sabe fazer borda arredondada. Usa o Photoshop só para fazer as bordas e botões. O layout das páginas desses caras costuma ter um monte de coisas, todas competindo pela sua atenção. E mesmo qdo parece boa, tem um "ar" de amador, mas não dá pra definir bem o porquê. "Designer" fez ou faz faculdade de publicidade e propaganda, marketing ou alguma coisa relacionada. Tem noção de design e ama Mac de paixão, mas continua usando Photoshop no Windows XP da empresa. Volta e meia usa o Dreamweaver. Mas faz o design obrigatoriamente no Photoshop. Conhece um pouco de HTML e um pouco de CSS. Manda bem no Flash. O layout desses aí é muito profissional. Mas costuma ter 4 problemas: - É pesado pra carvalho - Se o usuário não estiver rodando 800x600 com fonte padrão no Internet Explorer (800x600 pro cara é "ser compatível), o layout fica um lixo ou então arrebenta de vez. - Usar ele pra programar é um inferno, porque o HTML é tosco e bagunçado (padrão Dreamweaver e FrontPage, muito obrigado) - Se for atualizar o conteúdo, melhor republicar a página toda. Não tem como "só alterar um pedacinho". "Web-Designer" nunca fez faculdade, ou se fez, fez de alguma área de informática, mas sempre gostou mais de fazer interfaces do que chafurdar no código. Conhece HTML bem, CSS como a palma da mão e um bom tanto de Javascript. Acha falhas no Dreamweaver e excomunga o FrontPage. Rabisca o layout no papel antes de fazer qualquer coisa e quando faz, passa mais tempo mexendo na visão "source code", que na "layout". Os problemas desse cara? É muito difícil de encontrar um cara desse tipo, e quando se acha, não se paga o que ele merece. Até hoje, encontrei muito poucos raríssimos dessa espécie. O layout do cara costuma ser leve e limpo, com comentários e ótimo para programar. Sem falar que ele sabe fazer layout líquido numa boa, e a página não estoura se você usar o Ópera ou se seu padrão de fonte for um pouco diferente. Fora isso, é do tipo do cara que se você explicar uma linguagem de template pra ele (qq uma, Velocity, JSP, XSLT) ele não só sabe fazer o layout usando ela, como descobre novos e melhores jeitos de usar que você nunca pensou. Se você é ou conhece um desses, me avisa. Tou precisando conhecer mais!!!

Gerentes querem linguagem dinâmica e não sabem.

2006-02-16T11:38:00.000-02:00

Ando trabalhando com Java e Ruby pra web recentemente e não dá pra evitar notar certas coisas. Em Ruby, posso alterar o servidor de produção sem parar nada. Em Java, se altero uma classe, toca reiniciar o servidor pra pegar alterações. Meu chefe fica muito P da vida toda vez que preciso subir uma correção e tenho que fazer isso. Ele fica me torrando pra usar JSP ao invés de classes Java pra não ter que reiniciar :| (Acho que ele gostaria que eu usasse uma linguagem de script e não sabe disso...) Em Ruby, se eu restarto o servidor de produção por algum motivo, ninguém perde sessão. No máximo a página fica fora alguns segundos. Tem gente que nem percebe... Em Java, tenho que ter o maior cuidado com isso :| Se restarto com muitos usuários online a aplicação redireciona todo mundo pra tela de login... Não que não dê pra fazer um esquema para persistir, o Tomcat até tem um. Mas não é default, tem que configurar e tudo que tem na sessão tem que ser serializable. Meu chefe, DE NOVO, me torra as paciências pra eu evitar restartar... (Continuo achando que ele quer é uma linguagem de script e não sabe). O que eu acho mais engraçado é que você vai procurar por session persistence e a primeira coisa que você acha é cluster de servidores. Será que ninguém pensou que serializar sessão é muito útil por si só? Vai ver, como sempre, sou simplista demais. Isso sem falar em regras dinâmicas muito loucas que apareceram em um projeto. Tive que usar o BeanShell (muito bom, aliás, bom MEEESMO), senão ia ficar maluco... O chefe adorou! (É... tenho _realmente_ a impressão que ele gostaria de usar uma linguagem de script) Não me entenda mal, eu gosto de Java, é uma boa linguagem. Mas é muito mais complicada do que poderia ser. Questões de design da linguagem, eu acho... Só sinto realmente falta de três coisas no Java: Closures, reflexão de verdade e um pouco menos de "estupidamente" tipado... Cansa ficar falando a mesma coisa o tempo todo pro compilador (Usuario usuario = new Usuario(); por exemplo.). Com generics então, que eu achei que ia facilitar isso, só deixou a coisa mais insana:


Map<String, List<String>> map = new HashMap<String, List<String>>();

Experimente um Map de Map, então :D. Too much fun!

Como traduzir um papo técnico

2006-02-14T14:38:00.000-02:00

Eu imagino que esses papos técnicos são um tormento pra que não conhece. Eu que sei do que ele tá falando já me embananei...

De: Usuário Interessado Para: Programador Nerd Assunto: pLACA de video Você tem alguma info ou dica de placa para me dar? Please -------------------------------------------------------------------------------- De: Programador Nerd Para: Usuário Interessado Assunto: RES: pLACA de video Usuário Interessado, Seguinte placa de vídeo é algo complicado e uma das coisas mais caras num micro, hoje em dia como eu já te disse tem placas para todos os gostos e bolsos. Eu posso te dar uma dica melhor se eu souber quais os tipos de jogos que ele gosta e o quão fissurado por “beleza” dos gráficos ele é, eu mesmo não sou muito exigente só preciso de uma placa que rode o jogo, não preciso de algo que me encha os olhos, então eu aconselho algo da linha ATI 9600, modelo PRO ou XT, essas saem por volta de 350 a 400 reais, não tenho muita certeza. As NVidia Geforce 5700 ou 5900 também são muiiiito boas, procure evitar a 5200, no mainstream tem placas de 800 a 1000 que são da linha ATI X800 ou NVIDIA 6000, mas creio que essas não são o seu alvo... Resumindo sem enrolar muito eu aconselho uma ATI 9600 PRO ou XT, eu, Zé e Jão temos essas ai, eu tenho uma 9600 PRO de 128mb o Jão uma PRO de 256mb e o Zé uma XT de 256mb, que é melhor, eu com a minha sendo piorzinha estou muito bem obrigado, hoje em dia acho que por volta de 400, se quiser bater perna na santa ifigênia sempre tem bons negócios... Desculpa o email enorme, tentei dar uma geral e não uma opinião especifica, de qualquer forma se quiser pede pra ele falar comigo no msn ou email mesmo para eu ver o que ele quer e tal :) []s Programador Nerd --------------------------------------------------------------- De: Usuário Interessado Para: Programador Nerd Assunto: RES: pLACA de video Programador, não consegui entender seu email...veja se a tradução está correta! Então....eu estou com os olhos cheios de lagrimas e de orelhas compridas, porque a beleza dos gráficos me fazem pensar em mulher, porem mulher ao custo de 5200 eu acho caro pacas, não preciso de algo que me encha os olhos,já o preço de ATI 9600,eu fico 3 noites sem sair de cima com mais de 20 garotas , modelo PROputas ou XoXoTas, essas saem por volta de 350 a 400 reais/por vez,acho.... não tenho muita certeza. As NinfetasVadias 5700 ou 5900 também são muiiiito boas porem muito, muito caras, procure evitar as vagabas de 5200, no mainstream da Republica do Libano tem de 800 a 1000 que são da linha AToxI 800 ou NasVaDIAs 6000, mas creio que essas não são o seu alvo... Resumindo sem enrolar muito eu aconselho uma boa bronha com mão adormecida e camisinha Jontex 9600 o Tião, Zé e Jão temos essas ai, vagabas 9600 PRO de 128 de rola,já o Jão uma PRO de 256 e o Zé uma de 256, que é melhor, eu com a minha boa maozinha sendo piorzinha estou muito bem obrigado, hoje em dia acho que por volta de 400, se alguém quiser bater uma na santa ifigênia sempre tem bons negócios...

OffTopic: Filme bom pra caramba

2006-01-30T10:40:00.000-02:00

Cinema nacional finalmente está saindo daquela utopia de "Cinema Arte" que só agrada aos cinéfilos. Principalmente daquele tipo que adora falar dos filmes usando termos como: "crítica da sociedade", "uma visão diferente", "belo" e por aí vai. "Se Eu Fosse Você" cai num tema muito batido (troca de corpos :D ), extremamente comercial, mas é MUITO BOM!!!! O filme é realmente divertido pra quem já levou (ou leva) uma vida a dois. Fazia tempo que eu não ria tanto com um filme. Não tem pornografia, não pretende ser "artístico", é leve, bem-humorado e tem até a característica "lição de moral" no finalzinho. :) Glória Pires nem convence tanto, mas manda bem. Agora o Tony Ramos tá MUITO perfeito e MUUUUUUITO engraçado. Eu não botava tanta fé no cara antes, mas depois desse filme, tenho que rever meus conceitos. Parece que dá até pra ver a Glória Pires dentro do cara. Assistam, eu recomendo.

Auto-crítica é uma droga mesmo

2006-01-27T17:20:00.000-02:00

Já fui pior, estou melhorando, mas ainda não cheguei lá. http://www.hacknot.info/hacknot/action/showEntry?eid=81 Tem um pouco de vários, pode me chamar de Henry Kevin Zachary :p Inda chego a ser Quincy.

Arrumando a casa

2006-01-24T16:30:00.000-02:00

Poisé! Andei dando uma garibada no Blog. Cansei um pouco de ficar colocando minhas viagens aqui. De cara, mudei o modelo do blog (de novo), e agora vou começar a postar mais códigos e menos papo, basicamente, utilidades para Java e Ruby. Talvez eu comece a escrever em inglês, não sei alguém mais vai ler a bagaça, e com certeza vou perder umas piadas. Mas nunca fui bom piadista mesmo, nem em português nem em qualquer língua.

Duck Type em Java

2006-01-12T17:23:00.000-02:00

Como o Java é uma linguagem boa e com excelentes APIs, mas muito tosca em algumas coisas básicas (como manipulação de Strings e Coleções), volta e meio fazemos alguns utilitários estúpidos pra facilitar a vida. Aqui vai um dos meus, um simples wrapper para facilitar a chamada de métodos dinâmicos.

package common;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

/**
 * Executes a method in an object dinamically. It's a wrapper to the java
 * reflection way of execute methods dinamically.
 */
public class DuckType {

  public static  T execute(Object object, String methodName, Object ... parameters) {

    if (object == null) return null;
    if (methodName == null || methodName.equals("")) return null;
    
    Class[] classes = extractClassesFromParameters(parameters);
    
    try {
      
      return (T) executeEasyWay(object, methodName, classes, parameters);

    } catch (NoSuchMethodException e) {
      
      return (T) executeHardWay(object, methodName, classes, parameters);
      
    } catch (SecurityException e) {
      return null;
    } catch (IllegalArgumentException e) {
      return null;
    } catch (IllegalAccessException e) {
      return null;
    } catch (InvocationTargetException e) {
      return null;
    }
  }

  private static Object executeEasyWay(Object object, String methodName, Class[] classes, Object... parameters) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException {
    
    Method method = object.getClass().getMethod(methodName, classes);
    return method.invoke(object, parameters);
  }

  private static Object executeHardWay(Object object, String methodName, Class[] classes, Object... parameters) {
    
    // it didn't find the method in the easy way, trying the hard way
    Method[] methods = object.getClass().getMethods();
    
    for (Method method : methods) {
      Class[] methodTypes = method.getParameterTypes();
      
      // Ignore methods with different names
      if (!methodName.equals(method.getName())) continue;
      
      // Ignore methods with different number of parameters 
      if (methodTypes.length != classes.length) continue;
      
      boolean isMethodExecutable = true;
      for (int i = 0; i < methodTypes.length; i++) {
        Class methodType = (Class) methodTypes[i];
        Class parameterType = classes[i];
        
        if (!methodType.isAssignableFrom(parameterType)) {
          isMethodExecutable = false;
          break;
        }
      }
      
      try {
        
        if (isMethodExecutable) return method.invoke(object, parameters);
        
      } catch (IllegalArgumentException e1) {
        return null;
      } catch (IllegalAccessException e1) {
        return null;
      } catch (InvocationTargetException e1) {
        return null;
      }
    }
    
    return null;
  }

  private static Class[] extractClassesFromParameters(Object[] parameters) {
    
    Class[] classes = new Class[parameters.length];
    
    for (int i = 0; i < parameters.length; i++) {
      Object parameter = parameters[i];
      classes[i] = parameter.getClass();        
    }
    
    return classes;
  }
}

Controle de versão para os dados

2006-01-11T10:13:00.000-02:00

Quanto mais eu penso, mais acredito que preciso experimentar essa idéia o mais rapidamente possível. Outro dia estava mexendo com as "rules" do PostgreSQL (triggers) para fazer log de uma tabela essencial do sistema. Qualquer alteração criava um registro em uma tabela gêmea, com a data da alteração e o usuário. Comecei a pensar o que aconteceria se eu fizesse isso para TODAS as tabelas do sistema. Acho que ia virar uma espécie de controle de versão dos dados, e melhor ainda, acho que consigo criar toda essa estrutura, tabelas gêmeas e triggers, com um simples script. Ainda não pensei direito o efeito disso sobre as tabelas de relacionamento N-M, mas acho q também funciona. Talvez fiquem gigantes, mas não vejo problema nisso. E com certeza, as gêmeas não podem ter "constraints" como "unique" e coisas do tipo, mas também acho isso contornável. Resta o problema de manutenção, triggers sempre são complicadas. Mas como as tabelas gêmeas não fazem parte realmente do sistema e nenhuma delas vai ter triggers, acho que não vou ter problemas de atualizações em cascata que o pessoal tanto abomina nas triggers. Acho que dá pra fazer um Engine no Rails (ActiveRecord) pra isso. Já tem um plugin pra isso: acts_as_versioned Quem sabe? Só estou jogando idéias pra cima.

O que me imcomoda em Linguagens e APIs

2006-01-09T11:47:00.000-02:00

Sabe, Tava organizando os pensamentos aqui e finalmente achei o motivo pelo qual não simpatizo muito de certas Linguagens e APIs. O que me torra o saco é quando os designers delas tem a genial idéia de proibir coisas na linguagem para evitar "más práticas". Só que más práticas dependem do contexto onde são usadas. Eu vejo frequentemente que o resultado disso cai em dois casos: - Programadores imbecis continuam fazendo imbecilidades de outras formas. ("É muito difícil fazer algo a prova de idiotas, eles são muito imaginativos") - Programadores menos imbecis tem que fazer imbecilidades para fazer o código funcionar como querem. Quantas vezes você já "hackeou" o Java porque ele não deixava você fazer o que queria de um jeito simples. A lição que eu tiro disso? Você não pode prever como seus usuário vão usar suas coisas, então é melhor não tentar. "AH! Mas os outros programadores são muito estúpidos, se eu não travar isso, vão fazer cagada" -- Típico pensamento arrogante que nós programadores temos. Devíamos ser mais humildes ou pelo menos não subestimar nossos pares. (Já ouvi um "Se você fizer algo achando que seus usuário são ignorantes, eles terão de ser ignorantes pra usar o que você fez") No fim das contas, se o outro programador fizer cagada com sua API/Linguagem, de quem é o problema? Do designer da API?! Isso só pode ser o cúmulo da arrogância, meio querer ser "oniscente e onipotente". Se o imbecil faz imbecilidades, sinceramente, problema dele, devia ter estudado mais antes de ser programador. Se não fizer, tanto melhor!!! Li em um blog outro dia uma coisa muito legal: "Fazer uma boa linguagem de programação 'segura' é como fazer uma faca afiada que nunca corte o dedo de quem usa". Mas sabe, eu estava no açougue outro dia e vi o açougueiro estripando a carne com fé e vontade. Fiquei pensando como é que ele não picava os dedos juntos, tal o empenho que ele estava em estripar a pobre peça de carne (acho que era uma costela, sei lá). Aí vi o motivo: ele estava usando uma luva de metal na mão que segurava a carne... Que isso tem a ver com programação? Que a faca tem que ser a mais afiada possível para você fazer um bom trabalho. E se não quiser cortar os dedos use a porcaria da luva! Imagino que nossas "luvas" sejam testes de unidade, mas não sei ao certo. Só garanto que se a linguagem é realmente afiada, use alguma proteção ao invés de querer fazer a linguagem "perder o fio".

De volta aos posts

2005-10-25T18:16:00.000-02:00

Caçarola, aconteceu tanta coisa nesse último mês que nem deu tempo de escrever :p Trabalho de mestrado + trabalhos em ruby, fora o trampo normal.... Não dava tempo nem pra respirar. Agora as coisas estão entrando no eixo novamente, então vai dar pra escrever mais. De novidade, descobri o podcast do Rails. Bem fraquinhas as primeiras edições, mas parece melhorou, não ouvi as últimas ainda. Outra novidade é foi o lançamento to Rail Release Candidate 2. Tem umas melhorias muito legais, principalmente que agora fizeram um esquema interessante para plugins. Aliás, cedo ou tarde vou ter que comentar as capacidade do Ruby nesse ponto (plugins). Mais uma é que finalmente estamos implantando XP aqui no trampo. Apesar de já ter implantando em outros grupos e empresas, o pessoal daqui estava muito resistente. Agora houveram mudanças estruturais aqui que deram um pouco mais de maleabilidade. Agora vai!!! (Finalmente, ô dureza)

Quando um software morre? E por quê?

2005-09-23T10:10:00.000-03:00

Esse mestrado está excelente! Estou aprendendo muito, tanto com os professores quanto com os colegas. Verdadeira overdose de conhecimento, basta ficar de orelhas abertas. Ontem a discussão foi sobre o ciclo de vida de um software, e principalmente, quando um software morre. De todas as idéias apresentadas (incluindo a "oficial" do Roger Pressman), a melhor foi a que eu vi de dois colegas (Clayton e Orlando, excelente conceito, pessoal!!!). Segundo essa idéia, um software morre quando manter a aderência do software ao negócio fica muito cara. Aderência aqui significa o quanto das suas funcionalidades atendem às necessidades do negócio. E quando e por que isso acontece? Quando é difícil de responder, mas o porquê dá algumas pistas. Discutindo depois, descobrimos que basicamente existem três fatores: os profissionais de uma tecnologia antigas começam a ficar escassos e caros (vide Cobol); e as tecnologias novas geram necessidades que as tecnologias antigas não conseguem atender a um custo razoável. Por exemplo, internet. E finalmente, um software que vem sendo remendado há anos fica muito frágil, o que aumenta o custo das alterações em si. Parece óbvio e simples quando você diz isso, mas quando você está na lida do dia à dia, ralando e cheio de problemas, isso não fica tão aparente.

Novos pensamentos

2005-09-16T09:20:00.000-03:00

Ontem tive aula de Engenharia de Software no Mestrado. Deu pra ter umas idéias interessantes: - Requisito implementado gera mais requisitos (Algo do tipo, desejo atendido faz com que a pessoa queira outras coisas) - Hoje em dia, todas as empresas grandes e de médio porte já estão informatizadas. Apesar de ainda termos muitos sistemas novos aparecendo, surgiu uma imensa necessidade de _manutenção_ nos que ainda existem. Essa manutenção não é do tipo "corrigir problemas", mas sim do tipo "evoluir o sistema" para atender as novas necessidades da empresa. Sei não, mas acho que isso pode se tornar um mercado. Que tal? Uma empresa que vende como serviço a "manutenção evolutiva" do seu sistema? Acho que tem umas complicações... mas se puderem ser superadas... quem sabe?

Canos ao invés de Camadas

2005-08-26T12:26:00.000-03:00

Isso é o germe de uma idéia ainda. Mas já vou postar pra ver se a discussão evolui a idéia. Eu e o Marlus aqui estávamos discutindo sobre camadas (de software) e como é difícil você controlar isso porque camadas podem ter uma "superfície de contato" muito grandes entre si. Sem falar que frequentemente você não consegue isolar uma camada inteiramente do contato com outras duas. Aí, pensando em algumas coisas que implementamos aqui, encontramos uma outra metáfora que leva a um design ligeiramente diferente: CANOS. Imagina que seu módulo não é uma camada, mas um componente isolado que só se comunica com outros através de uma única classe, nosso "cano". Módulos (pacotes ou componentes) só se conecta a outro através de um único cano. Dessa forma, se a comunicação precisar de modificações, validações ou restrições, você pode trabalhar somente na classe que faz a conexão ao invés de ter toda uma superfície de contato para caçar. É como se todo componente/pacote/módulo tivesse obrigatoriamente um façade. (hmmmm....) Essa idéia levou a outra. Se eu tenho um cano e preciso transportar dados, como eu transporto? Minha sugestão é "enlatar" os dados em uma estrutura que ambos os componentes/módulos/pacotes entendam. Os dados só podem ser obtidos dali. Essa idéia de lata de dados foi aplicada em um framework aqui e deu resultados muito bons. Toda a transformação de dados necessário para comunicar os componentes pôde ser feito na lata ao invés de ficar espalhado. Canos e latas.... será que dá pra evoluir a idéia?

Duck Typing?

2005-08-24T17:28:00.000-03:00

Pra mim, isso é duck typing. Mas obviamente o cara tá pensando em algo muuuuito mais avançado, baseado em reconhecimento de padrões.

...Computer architectures as we know them were first designed around simulated wires. Source code is a simulation of pulses that can be sent sequentially down a wire, as are passed variables or messages. Now, I think that's a notion that can be extended very, very, far. And if you really want to, you can even use it to describe all of nature, but it's not the only idea that could be extended that far. And it does get kind of awkward because this is not the way that natural systems work. For example, if you want to describe the connection between a rock and the ground that the rock is resting on, as if it were information being sent on a wire, it's possible to do that, but it's not the best way. It's not an elegant way of doing it. If you look at nature at large, probably a better way to describe how things connect together is that there's a surface between any two things that displays patterns.

-- Entrevista com Jaron Lanier no site da Sun (ênfase minha) Por enquanto, eu fico com o básico "Duck Typing". Pra mim (opinião bem pessoal) é exatamente isso que o cara falou de ter padrões entre as partes que são reconhecíveis. Talvez dê pra estender a idéia um pouco, mas que sei eu?

Qualidade implícita e Fábrica de Software

2005-08-24T10:35:00.000-03:00

Bom, não é novidade pros meus amigos que tenho minhas restrições quanto ao termo "Fábrica de Software", porque ele implica em algumas coisas que eu não concordo muito. Pra poder ser "Fábrica de Software" tem que ter uma estrutura que eu não vi em nenhuma empresa que se auto-intitula isso. Então, fico com a impressão que eles estão vendendo gato como lebre. Outra reclamação minha, a mais básica, é que "Fábrica" tenta seguir o modelo de produção em massa de montadoras: "Coloque o design na ponta da fábrica, os programadores seguem as instruções e o software fica pronto". Isso é uma maravilha sob o ponto de vista gerencial já que é um processo previsível e vc só precisa de uns poucos analistas muito experientes e um tanto de programadores de baixo custo. Por mais que eu tente, não consigo me convencer que isso funcione (por motivos bastante óbvios). Outro fator, que é simplesmente crítico, é que em toda "Fábrica" seu comprador espera que você tenha um processo muito bem definido de qualidade. Ninguém paga 60K num carro pra ele vir parcialmente completo, entregue depois do prazo e com uns defeitos aqui e ali. Imagine então um produto que chega a custar várias vezes um carro desses. Agora eu pergunto pra quem trabalha e gerencia uma fábrica: "Você tem métricas e métodos para produzir um software com a qualidade implicitamente esperada?". Seja sincero pra você mesmo, sem essa de "estamos nos preparando" e "temos mas o prazo não permite". Não é de se admirar que os clientes fiquem nervosos com nossa área. Dou razão à eles. PS: AH! E se vc acha que ter um CMMi garante essa qualidade, olhe o processo atentamente e pense de novo: onde no processo você detecta, corrige ou mesmo previne (ênfase aqui) os defeitos? Preenchendo relatórios e gerando mais ordens de serviço? E onde está o método de detecção? É do tipo: "Q&A vai lá, senta e testa?", "Isso é um processo a ser definido pelo Q&A". Ceeeeerto.....

O programador padrão

2005-08-12T18:49:00.000-03:00

Acabei de pensar quando finalizava o tópico anterior... Até onde será que vai o conhecimento da maior parte dos programadores? UML? Padrões? Aspecto? Anotações? Testes de Unidade? Geração de código? Parsers de linguagem? Expressões regulares? Não estou pensando em questão de coisas ou programadores mais avançados ou menos avançados, acho que nem dá pra classificar isso. Mas no que 80% dos programadores profissionais conhecem em comum. Seria essa a nossa base mínima de conhecimento hoje? Daria pra fazer alguma aproximação útil com isso? Hmmmm... coisas a se pensar...

Sobre Orientação a Objeto e Domain Specific Languages, sempre abstrações.

2005-08-12T18:41:00.000-03:00

No princípio era o macarrão! Grandes blocos de código em sequência com saltos arbitrários que faziam com que rastrear um programa fosse um exercício de desatar nós para escoteiros. Então os gurus disseram - "Que se criem funções", e a programação estruturada surgiu. Pequenos blocos de códigos espalhados por arquivos, às vezes nem tão pequenos, uns referenciando outros. As funções se tornaram comandos e algumas vezes era difícil saber o que era um comando criado dado pela linguagem de outro criado por usuários. As linguagens se expandiam naturalmente. Tempos de ouro das "Bibliotecas". Então os gurus olharam, acharam bom, e criaram a orientação a objeto. Blocos de código que continham seus próprios dados, com a intenção de serem modelos mais próximos das coisas reais. Ela se expandiu, tomou forma, agora, além de comandos, podíamos ter nossos próprios tipos de dados inteligentes e que sabiam interagir uns com outros. As bibliotecas ganharam nome de API, começou a era de ouro dos Patterns e Frameworks. Agora alguns gurus olham e apontam: Linguagens orientada a linguagens, aspectos, linguagens específicas de domínio... precisamos de mais flexibilidade/velocidade! As linguagens específicas de domínio andam me interessando bastante. Usando um pouco delas comecei a perceber que o que fazemos na verdade não passa de criar abstrações específicas para nossos problemas. Isso fazemos o tempo todo, nenhuma novidade, a diferença é que agora, além de criarmos as abstrações, queremos organizá-las em uma sintaxe que seja mais adequada para representar uma solução. Há um monte de implicações nisso: não-programadores podendo escrevendo definições na área onde são experts, mais solução por linha de código, etc, etc. Mas não vou entrar nisso. O que me interessa é que acho a evolução do software sempre nos guiou a criarmos nossa própria "linguagem" com as abstrações para o negócio para o qual estamos programando. Mas isso era implícito, ou talvez não completamente percebido. Agora, com DSL, linguagens de script e outras coisas tomando foco talvez a ficha caia de vez. Talvez não seja nada disso e eu esteja enganado, ou talvez isso só alcance o programador padrão daqui uns trocentos anos. Quem sabe? Enquanto isso, vou testando minha teoria e batendo a cabeça por conta própria.

Padrão nada importante: "Result named variable"

2005-08-11T19:03:00.000-03:00

Um padrão sobre nomenclatura que eu adoto faz uns anos, e já vi alguns outros birutas usando também (é bom saber que não sou o único retardado da área). Problema: Você tem um método que retorna uma coleção, uma das primeira linhas do método é atribuir uma coleção à variável local que vai ser retornada. Você não encontrou um bom nome para a variável. Solução: Chame a variável de "result". Isso parece besta, mas sabe que torna o método muito legível? Ando usando essa nome de variável pra quase todo método onde eu acumulo coisas e retorno o resultado. Não sei se foi pq acostumei com o padrão, mas sempre bato o olho e já entendo o que acontece. Isso estende pra outra idéia que ando experimentando: variáveis locais nomeadas segundo sua função no método. Se é um contador: counter, x ou i; se é um pedaço da string de nome de cachorro:string_part e não dog_name_part. Ainda estou experimentando pra ver se isso é bom. A gente só sabe se fica bom mesmo depois que tem que mexer no mesmo programa depois de seis meses. Então leva um tempo pra ver se é útil de fato.

Limite de popularidade de uma linguagem

2005-08-04T10:25:00.000-03:00

Agora cedo eu e o Alessandro conversamos rapidamente sobre linguagens como Ruby e Python estarem ficando cada vez mais populares.

Ronie  x-arnie  .NET e Java são mainstream, depois vem PHP,
                Python e lá na rabeira, Ruby 
Ronie  x-arnie  Contudo, com o framework de web deles, o Rails,
                estão ganhando espaço, só não sei até onde. 
x-arnie  Ronie  hum.., complicado dizer 
x-arnie  Ronie  mas não vai ficar muito além do python ou php,
                eu diria que no máximo igual ao php
x-arnie  Ronie  pelo que costumo ver nessas evoluções 
Ronie  x-arnie  Por aí. 
Ronie  x-arnie  Sem suporte de uma grande empresa,
                não atinge a "diretoria" 
x-arnie  Ronie  that´s the point! ;)

Taí, se dá pra fazer uma aposta sobre até onde vai a popularidade de uma linguagem, ou o tamanho da sua comunidade, podemos chutar que não vai além do PHP se não atingir a diretoria. O Ruby e o Rails mudariam isso? Eu gostaria, mas duvido muito.

DSL (Domain Specific Languages)

2005-08-02T10:22:00.000-03:00

Volta e meia eu pego algo sobre DSL para ler. Hoje achei um artigo do tio Fowler que é muito bom. Ele explica DSL de cabo a rabo e dá uns links muito legais. Language Workbench (DSLs) Eu nessa história prefiro as DSLs internas. Estou tendo um dose maciça de exposição a Ruby (e Rails) recentemente e percebi que é muito simples criar estruturas que se parecem muito com comandos de linguagem usando a forma funcional de chamada (sem "self", igual java sem "this") e closures. Exemplos simples são o "transaction { blah blah }" e um que nós criamos (muito específico para nossas aplicação) "show_if_relevant { blah blah }". Ambos com forma funcional, blocos e a sintaxe relaxada do Ruby. É... sinto que os próximos anos serão interessantes para linguagens de programação.

Ganhos de velocidade

2005-07-28T10:59:00.000-03:00

Estava observando aqui no trampo que toda vez que nós melhoramos a arquitetura de alguma coisa ou automatizamos algumas tarefas o ganho de velocidade não é de 20% ou 30%, o ganho está ficando na casa dos 200% a 500%. Às vezes o ganho é tão grande, principalmente quando automatizamos, que não dá nem pra medir. Serviços que demoravam uma semana passaram a demorar um dia. Qdo automatizamos o deploy, ele passou de 4 horas a, no máximo, 1 minuto (24.000% ?). A geração automática de código para a camada de persistência fez com que o tempo para se criar um novo objeto de negócio caísse de 30 minutos por objeto para menos de 20 segundos (incluindo o tempo de eu abrir um shell e digitar, comando e conferir o resultado). Com outra pequena melhoria na camada de persistência, inclusões e remoções de campos no banco só me fazem adicionar os getters e setters nos objetos de negócio equivalente, não preciso mexer em nenhum SELECT/INSERT/UPDATE em lugar nenhum. A lição que eu tiro disso? Melhorias em estrutura não seguem uma regra média de ganho de tempo tipo "sempre se ganha entre 20% e 80%"... ela pode facilmente passar dos 1000% em alguns casos. Então a variância é desde 20% mais rápido até 10 vezes ou mais. Óbvio que eu estou analisando o ganho em uma atividade individual, o ganho de velocidade no projeto é bem menor, mas no caso de camada de persistência, por exemplo, o ganho ainda é muito significativo no total do projeto. Isso torna essas melhorias um pouco difíceis de avaliar, mas muito interessantes quando vc consegue mostrar para os gerentes o ganho em números (coisa que a gente sempre esquece: números!).

Productized

2005-07-26T15:08:00.000-03:00

Achei um termo novo. Até onde pesquisei, parece uma daquelas palavras bem comerciais que o povo que vende software inventa para convencer os gerentes que o que eles precisam já está "praticamente pronto"!!! Mas eu achei algo referente ao termo que vale a pena gastar uns minutos pra pensar: A “productized” application is a two-tiered application. The first tier is a single base application that encapsulates common functionality for your product. The second tier consists of several customized applications that inherit and extend functionality from that base. It is useful for web developers who want to create a base application with some sort of generic functionality (e.g. a shopping cart) and then extend or modify that functionality for specific clients only. -- fonte Talvez fosse interessante transformar esse tipo de customização em um Pattern, se é que já não tem por aí e eu não achei. PS: "Praticamente pronto" é uma frase que sempre me arrepia, pois é um sintoma muito frequente ouvir isso de um Vaporware....

Frases antológicas I

2005-07-26T15:01:00.000-03:00

Primeiras frases da série: Sim, eu sou nerd - "Tá vendo?! Não estudou! Virou webmaster" - "Pedaaaaaaaaaaaaaala, Teste!!!!" Também! Com os amigos que eu tenho :p Era ou não pra ouvir umas dessas?

Influências Rubêscas (não, não é do Rubens... é do Ruby)

2005-07-25T14:42:00.000-03:00

Ruby anda me fazendo mal. Volta e meia estou mexendo com Java e fico pensando: "Se isso fosse em Ruby, dava pra fazer assim e assado, duas linhas ao invés de vinte!". Mais ou menos a mesma sensação que eu tinha sobre Smalltalk, mas, no momento, minha cabeça tá cheia de Ruby. Não que Java seja ruim. É muito bom, na verdade! Contudo, acho que sempre vou sentir falta de Closures nela. Outra coisa, nunca fui muito feliz com a tipagem estática do Java. Mas pensando bem, ando percebendo que linguagem dinâmicamente tipada só é boa se vc trabalhar com Unit Tests. Não que isso me preocupe, mas tá meio longe da realidade de 90% das empresas (se não mais). E para quem acha que isso é um argumento que mata as linguagens de tipo dinâmico: leiam Pragmatic Programmer, especialmente a parte sobre programar por coincidência. Aquilo é uma verdade que pega bem no meio das bolas.

Uma longa noite

2005-07-21T14:24:00.000-03:00

Estranho demais. Hoje eu acordei e foi como se eu estivesse meio "anestesiado" pelos últimos 2 meses. Não sei, algo como um "deixar rolar... rolar...". Hoje eu me senti mais vivo, minha cabeça parece que saiu de nuvem cinza. Não sei, acho q coisas aqui no trabalho me levaram a adotar uma atitude meio passiva sem de fato eu perceber isso. E hoje, por algum motivo, eu sacudi a poeira também sem perceber e me senti bem de novo, como eu não me sentia à alguns meses. Talvez eu tenha sacudido porque ontem foi o fundo do poço anestésico, eu estava completamente sem motivação. Fico pensando se tem gente que vive indefinidamente nessa "anestesia". Fico pensando o que foi que me deu. E prometendo nunca mais repetir isso.

Escalabilidade!!!

2005-07-20T16:14:00.000-03:00

Dá o que pensar isso aí embaixo: "I think I should start posting on all those enterprise server forums with comments like "I'm concerned that this won't scale down very well. Could a team of 3 provide 24/7 support while extending functionality? We only have a couple of thousand users and at the rate the market will accept a bigger team would not be economical. The thing is, we 3 really want to do this rather than ending up as corporate drones wasting our existance in a cubicle."" -- Ged Byrne JoelOnSoftware A idéia de software "escalável" é sempre um apelo muito forte. Mas o que pega é exatamente isso: "às vezes não preciso tanto". E frequentemente o problema é custo. Taí um pensamento que vou preservar sempre que ler novos frameworks. "Tá, pra cima escala... mas... e pra baixo? Vou precisar de 15 pessoas pra criar isso ou dá pra fazer com 3?" Interessante, interessante...

Ruby

2005-07-20T15:50:00.000-03:00

Ultimamente eu e o Dadario andamos muito envolvidos com Ruby. O que posso dizer? Estou muito impressionado com a linguagem em si e com o framework do momento para desenvolver aplicação Web: Rails. Aquilo é simplesmente impressionante. Chega a ser brochante quando você pensa em voltar a desenvolver com Java e coisa e tal. Andei fuçando blogs por aí e não me senti só. A opinião geral de quem começa a mexer com Rails é muito parecida com a minha. Pena que isso não fica no main stream das linguagens. Mas como a gente costuma dizer de vez em quando (ô frasezinha arrogante do baralho): "Milhões de Lemmings não podem estar errados.". Sei lá, ainda me sinto um Lemming.

Date e Time, de novo!

2005-07-12T09:51:00.000-03:00

Já reclamei um milhão de vezes do java.util.Date e do java.util.Calendar. Pelo visto não sou o único que acha que aquilo é tosco (ainda bem!) Acabei achando uma biblioteca que aparentemente é muito boa, não testei ainda, mas pela descrição vale a pena dar uma olhada com calma. Chama-se Joda-Time e possui os conceitos de período e intervalo, sem falar em um bom suporte para GMT e linguagens. Vamos ver se dá pra usar isso no próximo projeto.

2005-07-12T09:42:00.000-03:00

Minha wish list tá andando. Gabinete novo não quero mais, vou me virar com o velho. Placa de vídeo já foi Chuveiro já foi Headset já foi Joystick já foi Falta a mesa, o globo de luz e o fogão. Pena que o chuveiro queimou 4 minutos depois de instalado e funcionando, vai entender.

Não tá pronto se não foi testado.

2005-06-30T15:11:00.000-03:00

Essa é outra daquelas coisas que parecem óbvias, mas a gente sempre deixa de fazer. Imagina a conversa: Gerente: "Tá pronto aquilo?" Desenvolvedor: "Tá, só falta testar" Gerente: "Ah! Tá..." Só falta testar???? Caro companheiro, se não tá testado, não tá pronto! E testar só o CaminhoFeliz não deixa a coisa pronta também. Tem que, no mínimo, testar o CaminhoFeliz e os caminhos com os problemas mais óbvios. Até porque, depois de cada teste, sempre vem algo a ser corrigido ou modificado, e isso é desenvolvimento.

Mantra

2005-06-27T18:26:00.000-03:00

Não sei pq continuo fazendo isso.... Agora! Todo mundo comigo! Repitam!!! "Nunca programe sem unit tests" "Nunca programe sem unit tests" "Nunca programe sem a porcaria dos unit tests" Não aprendo, toda vez que deixo de fazer unit tests me arrependo profundamente. E volta e meia eu deixo de lado. Santa Temeridade, Batman!

"Da próxima vez" -> DPV

2005-06-22T10:06:00.000-03:00

"Da próxima vez" ...manter os documentos de projeto em formato de texto puro. Assim o controle de versão e as ferramentas de diff vão funcionar pra eles também. Adendo: Odeio essa porcaria do Star Team. A parte client é meia boca demais!

Tempo passa, tempo voa.

2005-06-20T14:43:00.000-03:00

Caramba, essas duas última semanas foram tão corridas que eu nem bloguei nada. Desperdício... perdi um monte de idéias. Aliás, essas idéias que vou postar agora não são novas. É mais um reforço pra ver se minha cabeça oca não esquece. Idéia 1 (Velha, velha, mas sempre vale lembrar) "Sempre implemente sua própria classe Date no Java. O Date e o Calendar são MUUUUUUITO toscos." Idéia 2 (Essa eu me lasco sempre que não sigo) "Se existe um padrão, mesmo que seja ruim. SIGA a porcaria do padrão!!!"

A lista das coisas mais úteis quando trabalhando

2005-05-20T12:39:00.000-03:00

Ajudem a escrever a lista: 1 - ANT e seus sabores (NANT??) (e o "make" tb) 2 - Expressões Regulares ("regular expressions are write only ") Não me venham com J2EE, Jota-o-caramba, nem Dot-Net-o-escambau... Tou falando de coisas úteis ;D

[Off-topic] Wish list pessoal

2005-05-19T18:40:00.000-03:00

Preciso anotar isso em algum lugar: - Um globo de luz pro meu banheiro - Uma mesa daquelas que aumenta pra colocar na sala de jantar - Um par de controles tipo vídeo game para colocar no micro - Um headset bem legal e grande - Uma placa de vídeo 3D decente - Um chuveiro mega-ultra-power - Um fogão BOM - Um gabinete de verdade pro meu micro Putz... tem chão. :) Sem falar que ainda tenho que colocar o MythTv direito no meu micro, tá com problema na resolução qdo eu coloco conectado na TV.

Pingos e "Vida Digital"

2005-05-05T10:11:00.000-03:00

Ando brincando com programinhas evolutivos. Não, não... nada de algoritmos genéticos ou programação genética. Coisa bem mais simples, mas muito divertida. O objetivo inicial era fazer um objeto capaz de reconhecer algo "bom" e algo "mau" segundo sua própria perspectiva. Fazer ELE decidir o que é bom e o que é ruim pra ele. Para isso criei uns objetos que sabem comer uns aos outros, chamei eles de "Pingos". Cada pingo tem um valor de energia e um número meio doido (chamado "inteligência") para decidir se deve comer o outro pingo ou não. Qdo um pingo acumula energia demais ele se divide e seu valor de inteligência é randomicamente alterado em até 10%. Se ele fica sem energia (morre), eu tiro ele do sistema. Botei os bichinhos pra rodar, com poucas iterações só sobraram os pingos que decidiam comer os pingos mais fracos e ignoravam os maiores. Agora o objetivo é fazer com que os pingos consigam se coligar permanentemente pra ver se eles chegam a montar alguma estrutura mais complexa. Vamos ver. Bom, o objetivo original foi alcançado. Cada pingo sabe reconhecer o que é "bom" e "mau" sob sua própria perspectiva. Como o sistema é baseado em sobrevivência, o conceito de "bom" e "mau" é necessariamente orientada a isso. Items interessantes a se notar: - Se eu "envelheço" os pingos, tirando um pouco de energia a cada ação, o sistema no geral enfraquece e o número de pingos vai diminuindo. Interessantíssimo pq demonstra que a lei de conservação de energia tb pode funcionar digitalmente. A diferença é que é muito simples retirar e adicionar energia de sistema digital. Uma simples cópia de pingos significa que eu adicionei energia no sistema. - No começo, dividir-se era uma operação opcional dos pingos. O que acontecia era que eles iam comendo, comendo e acabava sobrando apenas UM com toda energia do sistema nele. Esse pingo sempre era um dos pingos da primeira geração. Qdo eu obriguei a se dividirem, a quantidade de pingos no sistema se estabilizou e os pingos passaram a ter uma vida média. Detalhe, qdo eu divido o pingo, um deles continua com a idade de antes. A parte interessante aqui é que colocar um número para "desestabilizar" o pingo (obrigando ele a se dividir se ficar muito grande) fez com o que sistema como um todo estabilizasse. É meio óbvio tb, mas é muito interessante. - Não importa muito os números que eu uso ou a conta que eu faço, os pingos sempre se adaptam pra as melhores escolhas. Mas acho q se eu fizer uma conta de decisão melhor, os pingos conseguem evoluir mais rápido. - No fundo no fundo, o mais interessante está sendo observar que leis "naturais" tb valem digitalmente.

Linguagem "estupidamente" tipada.

2005-05-04T15:42:00.000-03:00

Tem horas que eu fico doido com Java. A linguagem é razoavelmente boa, a quantidade de APIs é formidável. Mas sinceramente, tem horas que a tipagem estática é um porre. Java não é "estaticamente tipada", ela é "estupidamente tipada". Vale aquela máxima maravilhosa: "Tipagem estática é um jeito de tornar o compilador tão burro que vc tem que ficar lembrando pra ele toda hora DO QUE vc está falando." (Parênteses) ArrayList<String> list = new ArrayList<String>(); // Dá pra ser mais redundante, por acaso? (Fecha a porcaria do parênteses) Já disse: eu gostaria de opcionalmente tipada. Usa quem quer, quem não quer, não usa.

Linguagens para criar linguagens

2005-05-04T10:10:00.000-03:00

A idéia de DSL (Domain Specific Languages: JetBrains e The Server Side) é excelente. Porém, me pergunto se programação estruturada e programação orientada a objetos no final de contas não são exatamente um meio de vc criar uma linguagem específica para o seu negócio. Se é assim... modelagem de negócio seria melhor se se transformasse em "modelagem de vocabulário". Hmmmm.... Dá o que pensar. Tb dá o que pensar no próximo paradigma de desenvolvimento: vc programa uma "função" que tem propriedades e aceita determinadas interfaces para operar. Ei! Ei! Padrão COMMAND!!!! Taí: Programação orientada a COMMANDs :)... Só precisava achar uma sintaxe interessante.

Pattern: "Eu vi o disco-voador, acredita em mim!"

2005-04-25T09:22:00.000-03:00

Acontece qdo vc tem um problema, não consegue resolver ele de jeito nenhum em duas horas, desiste e chama um especialista. No momento em que o especialista chega, vc vai mostrar o problema e ele simplesmente não acontece. Tudo funciona normalmente. Nesse ponto o especialista olha pra vc com aquela cara de "E aí? Cadê?" e vc tenta se justificar "Cara, juro tava com problema! Foi vc chegar começou a funcionar". Chamamos esse pattern de "Eu vi um disco-voador" por motivos óbvios :D

Desenvolvimento em "Repasses"

2005-04-22T20:36:00.000-03:00

Taí, alguém conhece desenvolvimento em espiral? Basicamente é uma idéia velhinha de Engenharia de Software: vc faz um "protótipo" numa iteração e a cada nova iteração vai completando ele cada vez mais. Pena que isso é teoria dez e prática zero. Na prática o pessoal nunca planeja em espiral, é sempre o maldito cascata. E se não acredita em mim, olha para o seu cronograma, se ele tem "repasses" da mesma funcionalidade, vc é um sortudo. O outro problema é que ninguém nunca diz o que um protótipo deve ter ou não em cada versão... Sempre fica um "cada projeto é de um jeito" no ar e ninguém faz nada na prática. Depois de cozinhar um tanto a idéia na cabeça e rever minhas experiências ("Minha vida inteira passou pelos meus olhos... foi muito chato!" - Babs, A Fuga das Galinhas) cheguei ao seguinte esboço:

Tiro inicial (ou Primeira Iteração): "Esqueletão"

O esqueletão é mais para criar algumas partes essencias do sistema, frequentemente elas nem estão conectadas entre si.

Deixe de fora:

Tratamento de exceções
Objetos de negócios detalhados. Crie um Objeto de Negócio Genérico, provavelmente encapsulando um Dicionário (Map, Hash, Hashtable, vc entendeu!) e use ele para testar o esqueletão. Alguns campos mais essenciais ao negócio e algumas estruturas básicas já aparecem aqui.
Preocupações com desempenho e consumo de memória.
Interface de usuário.
Se puder, descarte Banco de Dados por enquanto.

Inclua:

Testes de Unidade

Primeiro Repasse (ou Segunda Iteração): "Carne entre os ossos"

Aqui vc começa a ligar as coisas.

Deixe de fora:

Tratamento de exceções. Apenas faça uma distinção entre erros de negócio (coisas que o usuário fez errado) e erro de sistema (aqueles que o pobre usuário não tem culpa, como erro de conexão com banco). Siga essa distinção durante todos os outros passos, mas não tente tratar os erros (exceto os mais recuperáveis). O resto, só mande pra cima.
Preocupações com desempelho e consumo de memória
Interface de usuário

Inclua:

Banco de dados.
Objetos de negócio mais detalhados. Mas não se preocupe muito aqui, sempre antes do final do projeto aparecem mais dados (campos) ou somem outros. A idéia aqui não é ter todos os campos e valores, mas sim ter a ESTRUTURA (ênfase dupla na palavra, vou até repetir: "ESTRUTURA") dos objetos de negócio. Por estrutura eu digo: quem conhece quem, e quem contém quem.
Testes de aceitação. Só uns rascunhos usando banco de dados.
Mais testes de unidade.

Segundo Repasse (ou Terceira Iteração): "Vejo algo se mover"

Nesse o sistema já funciona de cabo a rabo, meio toscão, mas funciona.

Deixe de fora:

Tratamento de exceções
Preocupações com desempenho e consumo de memória.
Testes de aceitação. Cuidado aqui. Vc só está adicionando o visual, o teste de aceitação roda "por baixo" dele, não devem aparecer muitos testes novos aqui. A menos que seus testes de aceitação rodem "por cima" da interface (exercitando ela).

Inclua:

Interface com usuário.
Um mané testando as telas, ou um designer gente boa.
Testes de unidade, principalmente de "validadores", que não são exatamente parte da interface do usuário, mas tem o mal hábito de aparecerem quando vc contrói elas.

Okay, pare aqui. Esses passos de 1 a 3 devem ser feitos POR FUNCIONALIDADE. Como assim? Explico. Vc tem um sistema com Cadastro de Usuário, Cadastro de Filme e Locação de Filmes. Isso são FUNCIONALIDADES. Vc primeiro faz os 3 passos para Locação de Filmes, depois faz os mesmos 3 para Cadastro de Usuário e finalmente os mesmos 3 para Cadastro de Filme e assim vai. Por que isso? Por 2 motivos: Vc vai conseguir mostrar coisas para o seu cliente mais cedo, ele vai ficar feliz Se a funcionalidade estiver errada, vc vai descobrir logo (pq ou cliente vai ver) e não daqui 6 meses. No jargão de "Engenharia de Software" isso significa: "Early Delivery" Diminuição de risco Depois disso vc passa para as próximas etapas, novamente elas são divididas POR FUNCIONALIDADE.

Terceiro Repasse (ou Quarta Iteração): "Minha visão está clareando"

Deixe de fora:

Tratamento de exceções.
Preocupações com desempenho e consumo de memória.
Testes de unidade. Só atualize os que vc precisar. Não devem aparecer muitas funcionalidades novas aqui, se aparecerem, óbvio, inclua testes.
Testes de aceitação. Idem acima.

Inclua:

Banco e Interface. Nesse ponto, os campos que vc precisa já devem estar bem defininidos, incluindo aqueles mais obscuros e usados somente por questões informativas (tradução: relatórios, cartas de cobrança).

Quarto Repasse (ou Quinta Iteração): "Toques finais"

Deixe de fora:

Banco e Interface.
Preocupações com desempenho e consumo de memória.

Inclua:

Tratamento de Exceções. Finalmente! Antes vc só arremessava as exceções, agora vc pega elas, apresenta telinhas bonitinhas, manda email pro suporte se explodir erro que não é coisa de usuário, etc e tal.
Testes de Unidade.
Testes de Aceitação.

Quinto Repasse (ou Sexta Iteração): "Sorriso da Mona Lisa"

Deixe de fora:

Banco e Interface.

Inclua:

PREOCUPAÇÕES COM DESEMPENHO E MEMÓRIA. Primeiro, faça "profiling" para ver ONDE estão os gargalos. Crie testes de unidade e aceitação para demonstrar os gargalos e finalmente corrija-os. Muitas vezes esse repasse nem é necessário.

Bom, é isso. Lógico que isso são mais sugestões do que leis. Nem todo desenvolvimento é igual, mas essas são boas "thumb rules" pra se usar. Mas eu vou refinando essa estrutura com o tempo.

Mais livros pra comprar

2005-04-08T14:53:00.000-03:00

O título agora é:"Pattern Languages of Program Design 4". Tem uma série desses livros... Outro, melhor ainda, parece ser: Pattern-Oriented Software Architecture, Volume 1: A System of Patterns US$ 60,00 Decididamente, preciso voltar a comprar livros, estou ficando desatualizado.

O padrão "Idiota Útil"

2005-03-16T11:25:00.000-03:00

Ontem eu estava em casa mexendo em um projeto pra fazer um Wiki. Aí tive um problema qdo estava tentando renderizar uns links. Fiquei ontem o tempo todo olhando para o código e imaginando soluções, fui dormir pensando no problema, acordei e vim trabalhar caminhando e pensando no problema. Foi então que me veio o estalo e a solução apareceu, de maneira óbvia e elegante. Qdo cheguei no trabalho, todo feliz, expliquei pra um colega o problema em linhas gerais. Qdo terminei a explicação ele me veio exatamente com a mesma solução que eu passei horas e horas pensando... :p Frustrante! Aí fiquei imaginando: 1 - Ou eu sou muito estúpido e o cara é muito inteligente (ele é, de fato, por consequência, devo ser um estúpido :p ) 2 - Ou qdo eu expliquei o problema já induzi a solução que eu tinha pensado (provável) 3 - Ou qdo o problema é visto de fora, fica mais simples. A opção 3 ficou martelando na minha cabeça, pq eu lembro que ontem passei boa parte do tempo só pra decidir em qual parte do código deveria modificar. Acho que qdo expliquei o problema sem entrar em detalhes de código, a solução ficou mais óbvia. Então eu senti, na prática e na pele, porque o padrão "Idiota Útil"* é tão bom pra resolver problemas. Vou fazer mais uns testes, mas acho que vou adotar o "Idiota Útil"* sistematicamente daqui pra frente.

* "Idiota Útil" (batizado pelo grande desenvolvedor e "cara de curtição" Cláudio Teixeira) - pra quem não sabe, é quando vc está com um problema e explica pra alguém, aí o cara pra quem vc está explicando nem sequer abre a boca e vc pára: "Pode deixar, valeu! Já achei a resposta".

Wish List para a linguagem ideal (revisada)

2005-03-09T10:38:00.000-03:00

Wish List atualizada, novos itens em negrito Será que Python atende tudo isso?

Closures.
OPCIONALMENTE tipada. Isso mesmo, nem dinâmicamente tipada nem estaticamente tipada, quero usar tipo qdo eu quiser. E mais, por conta disso tem que aceitar polimorfismo local.
Biblioteca decente para Coleções com suporte a Closures e uniformidade de métodos entre as coleções.
Suporte a slice nas coleções (subcoleções) e em arrays e similares.
Reflexão simples e funcional.
Puramente Orientada a Objeto. Classes tb tem que ser objetos.
Suporte a Expressões Regulares no padrão PERL, de preferência com muito açúcar sintático.
Suporte a slice em Strings, aliás, melhor, Strings com mesma interface que Array.
Biblioteca para Arquivos simples e funcional, PRINCIPALMENTE com facilidades para trabalhar arquivos texto. Nada de open - close, deve trabalhar com closures (padrão "during" do Smalltalk). Serialização opcional em CSV e XML tb ia ser legal.
Biblioteca para Banco de Dados simples e funcional. Também que ser capaz de trabalhar com closures naturalmente. Nada de open - close tosco, usar novamente o padrão "during" do Smalltalk.
Biblioteca para Rede simples e funcional. Suporte a closure, serialização e desserialização automática de qualquer objeto. Sockets do Java são um bom começo.
Suporte descente a Threads. A nova biblioteca do Java 1.5 parece boa, mas, adicionalmente, deveria ter uma estrutura especial de linguagem para indicar instruções que eu posso executar em paralelo daquelas que eu sou obrigado a executar sequencialmente. O trecho em paralelo tem que terminar todo antes de prosseguir para a próxima instrução sequencial. A JVM ou equivalente deveria aceitar um parâmetro de quantas paralelizações no máximo ela aceita e qdo esse limite chegar, executar sequencialmente as instruções que estão marcadas como "executáveis em paralelo". Se quiser ter uma boa idéia do que estou falando, veja as tags "sequential" e "parallel" do ANT.
Suporte MUITO simples e funcional a XML e processamento XSLT.

Wish List - A Linguagem Ideal

2005-03-08T17:06:00.000-03:00

Aqui vai minha lista de características para uma linguagem de programação ideal, por ordem de importância.

Closures.
OPCIONALMENTE tipada. Isso mesmo, nem dinâmicamente tipada nem estaticamente tipada, quero usar tipo qdo eu quiser. E mais, por conta disso tem que aceitar polimorfismo local.
Biblioteca decente para Coleções com suporte a Closures e uniformidade de métodos entre as coleções.
Reflexão simples e funcional.
Puramente Orientada a Objeto. Classes tb tem que ser objetos.
Suporte a Expressões Regulares no padrão PERL, de preferência com muito açúcar sintático.
Biblioteca para Arquivos simples e funcional, PRINCIPALMENTE com facilidades para trabalhar arquivos texto. Nada de open - close, deve trabalhar com closures (padrão "during" do Smalltalk). Serialização opcional em CSV e XML tb ia ser legal.
Biblioteca para Banco de Dados simples e funcional. Também que ser capaz de trabalhar com closures naturalmente. Nada de open - close tosco, usar novamente o padrão "during" do Smalltalk.
Biblioteca para Rede simples e funcional. Suporte a closure, serialização e desserialização automática de qualquer objeto. Sockets do Java são um bom começo.
Suporte descente a Threads. A nova biblioteca do Java 1.5 parece boa, mas, adicionalmente, deveria ter uma estrutura especial de linguagem para indicar instruções que eu posso executar em paralelo daquelas que eu sou obrigado a executar sequencialmente. O trecho em paralelo tem que terminar todo antes de prosseguir para a próxima instrução sequencial. A JVM ou equivalente deveria aceitar um parâmetro de quantas paralelizações no máximo ela aceita e qdo esse limite chegar, executar sequencialmente as instruções que estão marcadas como "executáveis em paralelo". Se quiser ter uma boa idéia do que estou falando, veja as tags "sequential" e "parallel" do ANT.
Suporte MUITO simples e funcional a XML e processamento XSLT.

Obs: Qdo digo SIMPLES, quero dizer SIMPLES DE USAR, não que o suporte seja limitado. SIMPLES DE USAR é conseguir executar 80% das operações mais comum em apenas uma linha. É isso aí, aparentemente as linguagens de script que estão crescendo por aí atendem boa parte da minha lista de desejos. Preciso ver em especial Python e Ruby. O Groovy já atende muitos dos requisitos, mas ainda tem uns bugs. Smalltalk atende a maior parte da lista, mas peca um pouco por falta de bibliotecas.

RUP e outros bichos

2005-03-08T09:54:00.000-03:00

Estava lendo uns artigos e comecei a pensar novamente sobre RUP (ou UP pra quem gosta, mas pra mim sempre vai ser coisa da Rational). Sabe, depois de um tempo, comecei a achar que RUP não estava ajudando muito, mas não sabia exatamento o porquê. Hoje eu tive uma boa idéia do motivo. Acredito que RUP erra o alvo duas vezes: 1 - Ele não trata absolutamente nada sobre código, mas é o código que, de fato, constrói o programa. 2 - Ele não trata nada sobre estimativas e prazos, delegando isso para outros. E prazo é essencial para qualquer projeto de qualquer coisa, não somente software. Caricaturando: "RUP é tudo sobre nada que importa".

Regra 5 - Dados críticos

2005-02-25T14:04:00.000-03:00

"Nunca apague dados críticos sem fazer backup e sem que outra pessoa cheque suas cláusulas de deleção. Nunca faça disso um processo automático." Dados de produção são SEMPRE críticos. ;) E não me venha com essa de "nunca apague dados, só desabilite". Tem horas que é inevitável, se é evitável, ÓBVIO que vc não estaria apagando os dados :p

4 Máximas para se manter em mente

2005-02-23T09:49:00.000-03:00

K.I.S.S. - Significa: "Keep It Simple, Stupid" = Mantenha isso simples, estúpido. Simplicidade é a chave para conseguir entender e modificar o sistema rapidamente.
Duplicação é a raiz de todo o Mal. Duplicação leva a designs ruins e sistemas difíceis de se alterar. Considere a duplicação como um pecado mortal, vc vai pro inferno se duplicar seu código.
Não empilhe tarefas. Normalmente, vc está programando alguma coisa e acha algo que deve ser feito ou corrigido para continuar. Evite fazer isso no momento em que vc encontra a coisa, anote ela em um papel e termine o que está fazendo. Se for inevitável empilhar, anote onde vc estava, pra poder voltar com segurança.
Mantenha a Equipe sincronizada (principalmente seu gerente). Se as pessoas não sabem o que as outras estão fazendo, podem tomar decisões erradas simplesmente por falta de informação. Mantenha seus colegas e principalemente seu gerente (que toma decisões que afetam todo o grupo) a par do que vc está fazendo.