De volta aos posts

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ê?

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

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

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?

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

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

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.

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"

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

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)

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

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.

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

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

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

"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.

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

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

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"

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.

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

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

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"

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

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"

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)

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

   
1. Closures.
   
2. 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.
   
3. Biblioteca decente para Coleções com suporte a Closures e uniformidade de métodos entre as coleções.
   
4. Suporte a slice nas coleções (subcoleções) e em arrays e similares.
   
5. Reflexão simples e funcional.
   
6. Puramente Orientada a Objeto. Classes tb tem que ser objetos.
   
7. Suporte a Expressões Regulares no padrão PERL, de preferência com muito açúcar sintático.
   
8. Suporte a slice em Strings, aliás, melhor, Strings com mesma interface que Array.
   
9. 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.
   
10. 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.
   
11. 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.
   
12. 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.
   
13. Suporte MUITO simples e funcional a XML e processamento XSLT.

Wish List - A Linguagem Ideal

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

   
1. Closures.
   
2. 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.
   
3. Biblioteca decente para Coleções com suporte a Closures e uniformidade de métodos entre as coleções.
   
4. Reflexão simples e funcional.
   
5. Puramente Orientada a Objeto. Classes tb tem que ser objetos.
   
6. Suporte a Expressões Regulares no padrão PERL, de preferência com muito açúcar sintático.
   
7. 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.
   
8. 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.
   
9. 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.
   
10. 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.
   
11. 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

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

"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

1. 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.
2. 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.
3. 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.
4. 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.

(off topic) Excelente espetáculo - Avenida Dropsie

Fui no sábado com uns amigos assistir uma peça de teatro na Avenida Paulista (SESI). Chama-se "Avenida Dropsie" e é uma adaptação de uns quadrinhos de Will Eisner. Sinceramente, não esperava muito, não. Não sou muito fã de Eisner. Mas o espetáculo me surpreendeu agradavelmente. Ele é ÓTIMO!!! Basicamente, são dezenas de micro estórias (dá impressão de ser uma centena, de tão rápido que são os atores) que se passam em uma avenida de uma grande cidade. Na verdade, são pequenas reflexões sobre a vida urbana muito engraçadas e muito interessantes. A peça foi montada de um jeito, que parece realmente um estória em quadrinhos. Depois de alguns minutos dá a nítida impressão que vc está lendo uma revista e os personagens começaram a se mexer sozinhos. Outra coisa que me impressionou bastante foi a produção da peça, fantástica! Chega a chover dentro do palco, água de verdade, e muita! Vale a pena, mesmo, e olha q foi só um ensaio aberto. A peça estréia oficialmente em 25 de fevereiro.

Troca de mensagens entre servidores - KISS way of life

Se vc tem um servidor de banco de dados que não é o servidor de aplicação; se ambos os servidores de aplicação tem acesso ao servidor de banco de dados, então, simplesmente, grave as mensagens no banco e faça os servidores de aplicação lerem de lá e fim de papo. Sim, às vezes o KISS é meio tosco conceitualmente (Ei! Puristas, não me fuzilem!), mas funciona bem pra caramba.

Faz diferença no mercado de trabalho?

Ontem um amigo meu veio me perguntar se, do ponto de vista do mercado, tem diferença entre os curso universitários de "Engenharia da Computação" e "Análise de Sistemas". Até hoje comigo, e com os amigos que trabalham na área, nunca pediram um curso específico nisso ou naquilo em nenhuma entrevista/vaga. Sempre foi: "Curso superior completo na área de informática", ou coisa similar. Se vc for seguir carreira acadêmica talvez faça diferença, sim. Mas mercado, até onde conheço, não. Eu lembro qdo estava prestando vestibular, ninguém sabia a diferença entre "Análise de Sistemas", "Engenharia da Computação" e "Ciências da Computação". Só vim a descobrir bem depois, durante o curso. Imagino que muitas das pessoas que contratam não estão diretamente envolvidas com a área, e tb não se importam com a diferença, desde que o cara saiba fazer o que eles precisam. Por outro lado, faz uma diferença imensa a experiência que se tem com a linguagem de programação ou as ferramentas para o trabalho. Várias vagas pedem "2 anos nisso", "5 anos naquilo". Se bem que nunca vi ninguém pedir mais de cinco anos em alguma coisa, acho que esse é considerado o nível máximo de tempo para virar mestre em alguma coisa. Ter trabalhado em projetos de sucesso também conta muito. Numa entrevista, sempre fica uma sensação confortável qdo vc relata que trabalhou em um projeto, que ele foi concluído e que o cliente ficou satisfeito com o resultado. (Às vezes fico pensando que vale a pena montar um "portifólio" com os projetos que vc participou, igual ao que os publicitários fazem). Conclusão? Desde q vc faça um curso superior em informática, qual curso não importa muito. Importa sua experiência e os projetos que vc participou.

Bug no compilador do java 1.3.1

Acho que acabei de encontrar um bug no compilador do java 1.3.1. Não testei no 1.4 e acima pra ver se dá o mesmo resultado. Isso aqui não compila: Object x = true ? new Integer(1) : "string"; Mas isso aqui compila: Object x = true ? (Object) new Integer(1) : "string"; ou isso: Object x = true ? new Integer(1) : (Object) "string"; Alguém já ouviu falar de upcasting?

Software in the night exchanging glances...

Wondering in the night... Ontem a noite eu, Klaus (do Prevayler e Computação Soberana) e Rodrigo (do Boo e Bamboo) ficamos discutindo planos futuros. A brincadeira foi boa, rendeu a criação de um projeto Wiki (qual o nome para ele, hmmm..?) e muitas idéias legais. Pequenos detalhes ficaram retidos no meu banco de memória: - Boo é uma linguagem que vale a pena dar uma olhada. Dei uma sapeada na página hoje cedo e realmente vale a pena olhar ela com cuidado. - Computação Soberana é um conceito meio doido (mas isso eu já sabia), mas tem algumas coisas que a gente pode fazer aqui e agora. Acho que faz a coisa interessante, e mais imediata, são dois conceitos que andam processando na minha cabeça há um tempo: um é Rede Social e outro é Referência Semântica (na falta de um nome melhor). Se juntar os dois conceitos + Computação Soberana... hmm... hmmm... *processando* - Tem mais um um livro pra comprar: Object Oriented Software Construction - Acho que descobri o truque do Google (Será que eu era o único que não tinha sacado? Tão óbvio!), vou tentar fazer o mesmo. Do assunto principal mesmo eu não vou adiantar nada mais do que já adiantei, vamos fazer sair algo primeiro antes de ficar fazendo promessas, certo? ;)

A área de T.I. tá ficando maluca ou sou só eu?

Sou só eu que acho estranho? A SUN está querendo propor um uma versão para XML binário... Hmmm... Mas pra eu iria querer isso? E se não é pra um humano ler isso, pq não usamos algum dos vários padrões binários que já existiram e eram muito bons? Acho que os caras estão perdendo o senso de sanidade, ou já perderam, quer ver? Conhece XDoclet, já usou pra configurar EJBs? Aquele negócio que vc coloca no comentário dos Java, passa um extrator e gera arquivos de configuração. Hmmm, vc usa arquivos de configuração pra não fazer configurações hardcoded, certo? Aí o arquivo fica complicado demais e vc volta a colocar a configuração no código... Tem algo errado aqui. É a área de T.I. que está perdendo a sanidade ou sou eu que preciso estudar mais?

Assertion Driven Development

Um tempo atrás, na lista do Test-Driven Development do Yahoo, surgiu um cara que propôs trocar o nome de TDD para ADD (Assertion-Driven Development). Eu até postei um comentário sobre isso. Mas aí a discussão continuou, cada um propôs uma coisa, e ninguém modificou nada. Esses dias atrás senti na pele o problema de colocar a palavra test num método de desenvolvimento. Está tão arraigado na cabeça das pessoas que teste é coisa pra se fazer no final do processo e que é responsabilidade da equipe de controle de qualidade, que eles param de te ouvir assim que vc menciona a palavra test. Acho que é impossível mudar a mente das pessoas num curto espaço de tempo, e é desperdício de fôlego ficar explicando que vc chama de teste uma coisa que não é bem um teste do jeito que o cara conhece. Daí, ao invés de mudar o mundo, acho melhor mudar minha abordagem. Pra mim tá decidido, nunca mais apresento TDD pra alguém como Test-Drive Development, pra mim agora é Assertion-Driven Development e ponto. Além do que, "ADD" é uma sigla muito mais comercial do que TDD.

Truque: Como retornar o número de colunas da última linha.

Quando a gente está fazendo uma tabela e colocando dados da esquerda para a direita, normalmente a última linha fica incompleta.

1	2	3
4	5	6
7	8

Essa tabela, por exemplo, tem só duas colunas preenchidas na última linha. Pergunta! Dado o número de items, quantos items tem na última coluna? Reposta: número de items MOD número de colunas. Nossa tabela acima: 8 MOD 3 = 2. Ou seja, duas colunas na última linha. Legal né? É sim, mas o que acontece se o número de items bater certinho? Tipo, 9 items para 3 colunas? 9 MOD 3 = 0... Hmmm... ZERO não é o número de items da última coluna, o número de items da última coluna é 3. Ok, então, aqui vai um truque para voltar o número exato: (((colunas - 1) + (items MOD colunas)) MOD colunas) + 1 EITA!!! Exemplos pra tentar facilitar um pouco: 7 items, 3 colunas: (((3 - 1) + (7 MOD 3)) MOD 3) + 1 ((2 + 1) MOD 3) + 1 (3 MOD 3) + 1 0 + 1 1 9 items, 3 colunas: (((3 - 1) + (9 MOD 3)) MOD 3) + 1 ((2 + 0) MOD 3) + 1 (2 MOD 3) + 1 2 + 1 3 É isso aí. Pra quem não quer fazer um simples if, ou é um maníaco matemático. Essa é uma solução. Alguém conhece outras?