Ganhos de velocidade

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

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

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)

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

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!!!

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

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!

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.

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.