MecanicaMente

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. :)