Archive for the ‘web’ Category

JustJava 2007 (Upped)

Monday, October 8th, 2007

Update: Enfim o Paulo publicou.

A palestra com o paulo foi sensacional. Muita gente me perguntou ao final da palestra qual minha relação com a Caelum, se sou instrutor de lá ou coisa do tipo. Bem, não :)

Palestra

Além de ser amigo do pessoal da empresa eu acredito fortemente na proposta de trabalho da Caelum, mas não tenho nenhum vínculo empregatício, comercial ou que quer que seja com eles.

Eu simplesmente acredito que o nível de treinamento que alguém obtém lá é bem superior ao treinamento pasteurizado dado pelos centros de treinamento que eu conheço. A palestra em si foi prova disso, nós falamos sobre tecnologias e técnicas que não são vistas nos ‘cursos de arquitetura’ normais e sobre como as tecnologias que de fato fazem parte do programa destes cursos quase sempre é antiquada e/ou inadequada. É uma empresa que consegue sair do commodity que é treinamento Java hoje em dia e trazer algo de valor, geralmente por um preço muito mais acessível.

Caelum

Os slides devem estar disponíveis no site da Caelum em breve.

Sistemas Simples, como Portais por exemplo

Sunday, October 7th, 2007

Esse debate no GUJ me mostrou umas coisas engraçadas. Eu já tinha idéia de como as pessoas não têm noção das dificuldades em manter um portal no ar, porque eu mesmo não sabia e porque entrevistei algumas dezenas de pessoas neste meu ano no setor, mas não deixa de ser engraçado.

Quando eu trabalhava numa pequena agência web, lá pelos idos de 2000-2002, eu atendi a muitos grande clientes. Petroleiras internacionais, bancos de investimento, bancos convencionais, fundos de pensão… para todos eu participei do desenvolvimento de sistemas web às vezes muito simples, ás vezes muito complexos. Existia um padrão neste segmento de sites institucionais feitos por pequenas agências, não sei se é assim hoje em dia mas era:

  1. Escolha um gerenciador de conteúdo (CMS)
  2. Escolha a tecnologia para construir o resto do site (se o CMS deixar)
  3. ‘Customize’ (yuck!) os templates (também conhecido como: Corrija os bugs do CMS)
  4. Entregue o site

Eu trabalhei com diversos CMS, na época todos os que prestavam eram pagos e caros. Para clientes pequenos usávamos o Publique!, para clientes maiorzinhos o Calandra, para clientes maiores o Vignette, para monstros que precisavam não de um portal mas de GED o Dcomentum e algumas vezes os caras pediam para trabalhar com Microsoft SharePoint. Minha opinião após algumas dezenas de projetos: Nenhum deles prestava (e duvido que prestem hoje).

Quando fui convidado para entrar para o mundo dos portais fiquei um pouco preocupado. Desde meus tempos na agência eu já havia trabalhado com sistemas de billing, telecom, logística, análise de risco e vários outros domínios complexos com sistema mega-complexos que de tão caros são cobrados em Euros e não dólares. Milhões de Euros, na verdade. Mas topei porque quem me fez a indicação é uma pessoa que sei que não me indicaria uma furada.

Veja só minha surpresa quando descobri que para um destes mega-portais de Internet um CMS não é opção. Ok, muitos deles até usam soluções dessas, meu empregador inclusive, mas apenas para uma parte muito pequena e repetitiva do trabalho. Para tudo que não puder ficar em cache o buraco é bem mais embaixo.

Mesmo para conteúdo cacheado, você acha que é simples manter uma página sendo acessada por milhões de pessoas num intervalo de tempo muito curto? Eu vejo quando uma pessoa na minha equipe evoluiu porque ela começa a ler sobre redes, gerenciamento de memória, etc. Outro dia um cara muito bom mas muito focado em Java que trabalha comigo recebeu uma reclamação de que a aplicação estava gerando um load muito alto nos servidores. Ele teve que se virar para entender o que é o load de um servidor e porque o CPU não fica em 100% mesmo quando o load atinge duas casa decimais. Daí a coisa evoluiu para entrar no servidor e ficar tirando thread dumps (que muitos nem sabem o que é) para analisar o sistema, depois olhar o fonte do java.util.HashMap e identificar um problema de loop infinito que acontecia nesta classe somente quando havia uma grande concorrência. É engraçado, o cara entra com aquela mentalidade de ‘analista/desenvolvedor JEE’ e sai como um profissional de verdade. Eu acho que todo mundo devia trabalhar num lugar assim, ou fazer estágio ao menos.

E aí as pessoas dizem que os nove sites citados lá pelo estudo são simplezinhos e por isso usam LAMP. Isso é muito protecionismo, meu Zahl…

Java é uma boa plataforma para vários casos, mas não para todos. O modelo de IPC pobre, o deployment caixa-preta e a falta de uma meta-programação de verdade afetam fortemente a plataforma mas não é nada que não se consiga viver com. O ponto é que as outras plataformas possuem também suas diversas vantagens em vários casos, entre eles sites como os citados. Cada vez mais os portais possuem maior lógica na Camada (Tier) de apresentação. Os sistemas que temos desenvolvido no meu dia-a-dia de portal geralmente são compostos por um site que possui lógica de aplicação e acessa vários serviços.

A lógica de aplicação eu sinceramente mudaria para Rails sem pensar meia vez. O único ponto que me faria ponderar a princípio seria performance, ironicamente Java é hoje uma das mais performáticas plataformas disponíveis, mas mesmo hoje performance é garantida através de outros meios como caches e hardware (nota: existem poucas coisas que deixam um sistema tão lento quanto construí-lo usando um CMS).

A parte de trás da aplicação, onde ficam os serviços, não seria tão simples. Alguns serviços podem ser migrados para plataformas leves sem pensar duas vezes (muitos deles já estão em PERL e PHP, na verdade) mas assim como faz o Flickr eu usaria Java em alguns deles (o flickr é em PHP e usa Java para upload).

O ponto não é usar ou não Java. O ponto não é Ruby on Rails ganhar de Java no caso XYZ. O ponto é usar ferramentas certas nos lugares certos. Devia fazer parte da ética profissional este tipo de coisa…

Ruby “ou” Rails?

Tuesday, October 2nd, 2007

Esse post no GUJ me fez pensar sobre a melhor maneira de absorver algo como o Rails. Rails é uma plataforma de desenvolvimento altamente produtiva e boa parte da produtividade vem do fato de que não é preciso abstrair um domínio na linguagem.

Desenvolvimento de aplicações web é um domínio que inclui diversos conceitos e abstrações. Vejam por exemplo uma sessão web. Se uma pessoa ler sobre o protocolo HTTP em si vai perceber que não existem sessões, o protocolo não mantém estado entre as requisições. Para burlar este problema nós utilizamos cookies ou URIs especiais para informar ao servidor o ID da sessão do cliente. Este é um conceito.

Em Java (ou outra plataforma parecida) vamos abstrair a sessão em uma classe. É desta forma que trabalhamos em Java: criamos classes para representar os conceitos do domínio.

O problema é que até conhecer o suficiente para utilizar de maneira adequada esta abstração na forma de classe você precisa conhecer o que é uma classe e todos os conceitos derivados desta. Basicamente não se consegue criar algo razoável sem saber um mínimo de programação orientada a objetos.

E como Rails resolve isso? Rails abstrai boa parte destes conceitos na linguagem. Ruby é uma linguagem OO e é possível representar a sessão da mesma maneira que se faz em Java mas este não é o meio utilizado em Rails e esta forma de representar as coisas é seu maior diferencial.

Uma sessão em Rails está embutida implicitamente dentro do controlador. Trabalhar com elas é muito simples, para efeito de comapração é como se seu controlador em Java herdasse uma classe que possuísse o objeto que representa a session (que tem a mesma interface que um Map) como atributo protected. Exceto que o acoplamento gerado para acessar a session da classe-mãe em Ruby é muito fraco enquanto em Java seria enorme (na verdade provavelmente a melhor opção em Java seria um método e não um atributo. Em Ruby estes conceitos são bem mais flexíveis) é mais uma questão de filosofia do framework do que de linguagem utilizada em si.

Apesar da polêmica se é ou não uma Domain-Specific Language, Rails é um exemplo claro de Language-Oriented Programming. Neste paradigma de programação (praticado em Lisp desde…sempre!) a linguagem utilizada é modificada e estendida para acomodar os conceitos do domínio. No caso do Rails a linguagem Ruby ganha características que permitem ser estupidamente simples criar uma aplicação web.

E o que isso representa para quem está aprendendo? Eu diria que existem 2 tipos de pessoas que desenvolvem em Rails: desenvolvedores e desenvolvedores de aplicações web. Qual a diferença?

Desenvolvedores aos quais me refiro são desenvolvedores profissionais de software (analistas, programadores, hackers, o que quer que você queira chamar). São pessoas que se dedicam profissionalmente a entender as milhões de coisas que são importantes no desenvolvimento de projetos de software. Utilizar Rails para eles é apenas se beneficiar de uma boa ferramenta que implementa conceitos de MVC, ActiveRecord, LOP, Domain Model, Meta-Programação, convention over configuration, JavaScript, etc.

Para eles eu recomendo primeiro aprender Ruby. Rails sem Ruby é exotérico demais, você não vai entender como é possível que sua classe ganhe métodos conforme precisa deles e outras coisas estranhas (principalmente se você vem de Java ou C#).

O outro estereótipo, o desenvolvedor de aplicações web, geralmente é umc ara com menos conhecimento técnico, menos interesse em construção de software e habilidades em outras áreas. Pode ser o designer que quer fazer seus projetos com relativa independência de programadores, pode ser o cara que tem um estalo e uma brilhante idéia para uma aplicação Web 2.0 que o fará milionário… O ponto é que desenvolver software para este cara é só uma parte do processo, o meio, e não o fim. Este cara não precisa aprender tantos conceitos, ele pode se basear em receitas prontas e correr para um técnico quando precisar de algo mais heavy-metal. Para este cara eu recomendo aprender diretamente Rails, eventualmente ele pode melhorar Ruby e programação em geral com a evolução do seu projeto.

Interessante notar o conceito que funciona com Rails e com desenvolvimento baseado em Domain-Specific Languages (sendo Rails uma ou não): o usuário não vai desenvolver o software sozinho. Ele se baseia em algo construído para ele por um técnico (seja o framework Rails ou uma DSL) mas não consegue sair muito daquele escopo específico e limitado sem acompanhamento profissional. Este é o objetivo dos pesquisadores de DSLs neste momento.

Introduzindo Agilidade num Ambiente

Wednesday, August 15th, 2007

Toda empresa em que eu já tenha trabalhado, atendido como fornecedor ou prestei consultoria até hoje tem o mesmo discurso: esse negócio de [qualquer novidade] é legal mas aqui dentro não funciona. Pode até funcionar nas empresas certinhas, mas aqui nosso negócio é muito específico, nossa tecnologia é muito específica, nossos banheiros são muitos específicos…. Tenho uma notícia para quem pensa assim: não existe empresa certinha. Todo mundo acha que é diferente dos demais.

Ainda bem que no meu trabalho as coisas não são assim. Todo mercado é dinâmico mas o de Internet chega ao ridículo, da noite para o dia todos os paradigmas mudam. Ao mesmo tempo nós somos o braço de Internet de um dos maiores grupos de mídia do mundo e temos que seguir os mesmos critérios de qualidade, agilidade e inovação dos nossos “irmãos” nos canais de TV, Jornais e Rádios.

Quando fui contratado um dos requisitos era exatamente trabalhar o processo de desenvolvimento da empresa. Não somos diferentes de ninguém, temos um processo que foi criado e adaptado por sete anos e está longe de ser perfeito, como em qualquer lugar padrão. Após algum tempo observando como as coisas funcionam começamos a introduzir mudanças.

Somos uma equipe grande (incluindo alguns colegas blogueiros) que tem como trabalho cuidar de diversos sistemas entre sites, ferramentas de edição e produção de conteúdos e utilitários diversos.

Antes da mudança que introduzimos nosso fluxo de trabalho era o mais caótico possível: alguém enviava um e-mail com algo que estava errado ou precisava ser feito. Este e-mail originava uma tarefa num Gantt Chart. Uma das minhas tarefas diárias era correr atrás da equipe com o cronograma na mão perguntando o que estavam fazendo, depois sentar na minha mesa e atualizar o cronograma. Cada desenvolvedor pegava uma tarefa, ocasionalmente dois dividiam uma mais complexa. Ao terminar o desenvolvedor enviava um pacote para a equipe de testes (nenhum teste além do eventual feito pelo desenvolvedor era feito por aqui) que testava e homologava. Eventualmente o pacote voltava e ia para produção.

A primeira providência foi acabar com o cronograma. Nós temos uma licença do Jira, que apesar dos seus problemas funcionais é um dos melhores issue trackers disponíveis. O fluxo mudou: agora o cliente enviava um e-mail, este entrava no Jira e era designado para a pessoa que dava um prazo para a solução.

Dentro os diversos problemas que ainda tínhamos era colocar coisas em produção. Para homologar, agendar para subir em uma janela, acompanhar a janela, etc etc perde-se muito tempo e a cada tarefa concluída o ciclo era repetido. Solução? Só subir software a cada 15 dias. Em vez de mandarmos 5 ou 7 pacotes por todo o processo mandávamos apenas um e desta forma economizamos muito tempo. Eventualmente conseguíamos fazer mais coisas por parar menos com distrações do processo.

O próximo problema era no mundo das prioridades. Antes alguém mandava um e-mail e olhávamos para ele. Se fosse algo muito grave no nosso ponto de vista (ou se o cliente ligasse reclamando) nós colocávamos a alteração no topo da lista, caso contrário ia para quando “tivéssemos tempo” (i.e. nunca). Obviamente o cliente não ficava satisfeito com essa priorização e nós perdíamos muito tempo trabalhando no que era importante para nós sem saber se era importante (ou mesmo útil!) para o cliente ou não.

Solução? Jogo do Planejamento. Temos diversos clientes internos (e alguns milhões de externos) então elegemos o grupo que realmente representa nossos clientes. Em reuniões semanais de uma hora nós passávamos todas as issues abertas (depois da primeira reunião isso foi rápido) e agendamos possíveis subidas para estas. O cliente pode alterar qualquer iteração, menos a que está em execução. Quando o sistema vai para o ar o cliente recebe uma lista com todas as modificações que subiram para testar e mandar o feedback.

Estava melhor mas ainda não era o ideal. Nossos projetos ainda eram planejados em extensos Microsoft Projects que em algumas semanas perdiam sua sincronia com… o mundo real. A visão era de que o esquema de Jira/Jogo do Planejamento/Release de 15 dias funcionava bem para a manutenção mas não para projetos.

Então mudamos algumas coisas. Após quatro membros da equipe participarmos do curso de Scrum da Teamware nós resolvemos colocar em prática alguns conceitos, melhorando o processo utilizado para manutenção de maneira que servisse para nossos projetos.

Colocar em prática? Como assim?!? O projeto já possui cronograma definido, equipe definida, o escopo vêm sendo discutido há meses! Por que não esperar uma boa oportunidade, com tudo calmo? Simples: porque ela não vai acontecer. Qualquer empresa que queira se manter competitiva vai estar sempre bolando algo novo e mantendo suas pessoas ocupadas com isso. Oportunidade não se espera, se cria.

Para minimizarmos o risco da adoção nós introduzimos as coisas aos poucos. O foco não era implantar o processo X ou o processo Y mas sim coisas que nos ajudassem. O Scrum é um bom molde, um bom guideline. Vamos tentar implantar o molde, se virmos algo melhor ou ruim no caminho adaptamos. Vamos seguir, devagar quando necessário, mas movendo para frente.

Primeiro precisamos diminuir a importância do Jira em favor de post-its. Issue trackes são ferramentas bem interessantes, com o passar dos releases fizemos os usuários aprenderem a abrir issues no jira e acompanhar o andamento por ele (muito menos telefonemas de ’status report’!). Um dos problemas da ferramenta era presença. Para termos o Jira numa reunião precisamos de um notebook e nem todos poderiam utilizar a ferramenta ao mesmo tempo. Outro problema era a granularidade das tarefas. Outro era que cada um tinha sua lista de issues para resolver então eu passava horas (eu diria quase que 8) todo santo dia priorizando todas as issues abertas para cada desenvolvedor.

Picture 001

Para os desenvolvedores deixar o Jira um pouco de lado está sendo simples. Eles já não atualizavam o status dele mesmo! Eu tinha que encher o saco diariamente. Para os outros interessados no andamento do projeto não, após termos ensinado a todos a utilizar a ferramenta falar para olharem para uma outra não seria muito bem recebido. Além disso, muitos dos nossos clientes estão em outros prédios da empresa e não conseguem olhar nosso quadro. A solução encontrada foi mantêr as user stories no Jira, mas não as tarefas.

As user stories passaram a ser blogs. Quando alguém enfrenta uma dificuldade e resolve o problema ele “bloga” um comentário, mas não chega nem a atualizar o status. O uso passou a ser muito mais documental e menos de visão de status. Quando alguma story atinge o status de ‘done’ eu atualizo o status no Jira. A documentação não é tão util, já temos um wiki com especificações técnicas (segundo princípio de Agile Modeling, geralmente fotos dos whiteboards e descrições de alto nível apenas) e estou louco para me ver livre da obrigação de sincronizar com o issue tracker todo dia.

Um dos problemas é que não tínhamos espaço disponível. O escritório oferece uma boa disposição de mesas em baias de 4 pessoas, mas não há paredes disponíveis para pregarmos cartazes.

Picture 009
(desconte a poluição visual da minha mesa)

A solução imediata foi pregar o cartaz com os post-its num rack de servidores para desenvolvimento que fica no corredor.

DSC00460

Hoje já pegamos um antigo laboratório para nossas reuniões mais importantes, mas ficamos um bom tempo apenas com o rack e ainda o utilizamos. Salas de reunião ou mesmo o laboratório são fechadas e os cartazes lá dentro não estão 100% do tempo visíveis. Seguimos com o planejamento do sprint atual no rack e os outros cartazes e artefatos no laboratório. Antes que alguém pergunte tudo é registrado em câmeras digitais e como já me reportou uma vez o Vinícius sobre suas experiências as fotos nunca foram usadas além de decorar Flickrs e 8Ps.

Então todos os dias nos reunimos em frente ao rack para nosso Daily Scrum, uma reunião rápida diária. Um dos problemas que as pessoas sempre levantam para fazer este pequeno “compartilhamento de status” é a hora. Fazer muito cedo as pessoas podem não chegar, muito tarde não vai ser produtivo… bem, aqui a coisa é bem pior. Nossa equipe não exige a priori nenhuma restrição de horário, trabalhamos com pessoas que criam software e soluções, não com recepcionistas que precisam atender o telefone. Como consenso decidimos que as 11 da manhã todos estaríamos aqui. Temos ainda problemas, alguns dias falta um ou outro mas no geral vamos bem.

DSC00462

A reunião dura quase que exatos quinze minutos, para evitar que as pessoas se dispersem precisamos conversar algumas vezes e explicar que o foco é nos objetivos, não no desenrolar das tarefas. Outro ponto foi esclarecer que a equipe se reporta a ela mesma, não a mim. Eu viajei bastante nas últimas semanas e eles precisaram tocar sozinhos, o que fizeram com maestria.

O projeto já estava com as entregas definidas e renegociar não era uma opção. Infelizmente não conseguimos fazer reuniões de priorização com o cliente mas o responsável pela definição de negócio senta aqui do lado e nossos Sprint Backlogs, a lista de coisas que implementaremos a cada Sprint, já estavam bem definidas, com pouca margem para reagendamento (que foi devidamente utilizada).

Para fazer o pouco de planejamento que restava nós nos trancamos numa sala e estimamos todas as tarefas. Nas primeiras iterações mesmo explicando que um Story Point é dado por relatividade (primeiro você acha o mais simples depois estima os outros usando da métrica do “o quanto mais difícil é fazer X do que fazer aquele mais fácil?”) o time surgiu com valores quase que aleatórios para as tarefas, basicamente marcaram um número muito alto para todos. Nas iterações seguintes as estimativas foram ficando mais reais e hoje todos fazemos piada dos valores originais. Descobri que incluir uma reavaliação das estimativas na reunião de retrospectiva pós-sprint é útil para termos um melhor critério.

Na reunião de planejamento de Sprint nós deveríamos fazer uma versão inicial das listas do que precisamos fazer (tarefas) para atingir o objetivo (user story) de cada item do Sprint Backlog. Com medo de introduzir muita coisa nova eu optei por fazer apenas a lista da primeira Story. No final isso se mostrou irrelevante.

DSC00455

A empresa possui seu fluxo de processo já estabelecido e precisamos fazer nosso processo ser compatível com o das outras equipes, que inclui um grande teste de homologação no final. Antes das mudanças o desenvolvedor não executava teste algum, a equipe de QA era a responsável. Com o tempo percebemos o quanto isso era trabalhoso e propenso à erros. Uma das soluções que buscamos é ter testadores na nossa equipe mas enquanto isso não acontece nós mudamos a forma de pensar.

Lá no início da jornada o Guilherme e eu introduzimos testes unitários com JUnit no build. Demorou um pouco mas fatalmente as pessoas começaram a fazer (e as palestras do Guilherme fizeram com que pessoas de outras equipes começassem a fazer testes unitários por si só!). Quando o Bruno entrou na equipe, antes do projeto, uma das primeiras tarefas que dei para ele foi configurar o CruiseControl para fazer build e executar testes unitários. Mais problemas: não havia um servidor disponível para instalar. Conversa aqui, conversa ali conseguimos espaço num servidor de testes que roda diversas máquinas virtuais de VMWare, instalamos Ubuntu e o dito cujo (hoje usaria o Buildx), pronto. Após o CruiseControl o Bruno tratou de integrar o Fit ao nosso processo para fazermos testes de integração, e rodando com o CruiseControl.

Como ninguém tinha experiência com o Fit, o Bruno trabalhou em par com quem pegava a tarefa de implementar os testes. Com uma semana as pessoas estavam escrevendo Fixtures razoáveis, mesmo os estagiários.

Outro ponto que precisávamos testar era a interface, quase sempre web. Avaliamos o Selenium e mesmo com limitações ele parecia razoável mas não ideal. O Tiago investiu um dia integrando o Selenium no nosso build e trabalhando com test-cases em XSTL e fez o mesmo esquema que o Bruno para passar conhecimento. Agora nosso desenvolvimento só está “pronto” quando o código foi criado, com JUnit, com testes no Fit e com Selenium. O último QA achou apenas um bug em um módulo que alguém esqueceu de testar com caracteres especiais.

No primeiro Sprint eu não fiz reunião de revisão. Foi um erro cometido pela pressa mas imperdoável. No segundo nós fizemos uma reunião extremamente útil, levantamos pontos bons e ruins e colocamos num quadro (cuidado, termos fortes abaixo. ambiente irreverente é assim mesmo):

Picture 029

A maior parte dos pontos ruins (no “nem F$#%endo”) eram interrupções externas que eu preciso trabalhar. Minha viagem (que era um dos pontos ruins) recente fez com que os desenvolvedores respondessem por compromissos meus (outro ponto: reuniões que duram dias inteiros) , além de deixá-los sem proteção de interrupções externas (outro ponto citado) como telefonemas e até suporte a outras equipes integrando com nossos sistemas. Tirei daí que se precisar me ausentar preciso deixar alguém como Scrum Master, ainda que o time perca um membro ativo. Diluir o papel de Scrum Master causa mais prejuízos do que tirar uma pessoa do time de desenvolvedores.

Os pontos positivos incluíram o trabalho em equipe, os mecanismos de teste que ajudaram no desenvolvimento, o QA não ter encontrados bugs, a janela para produção ter sido tranquila e outras coisas que basicamente derivam da nova maneira de trabalhar.

Dos pontos ruins o que me preocupou mais foram os referentes a plataforma tecnológica da aplicação. Fizemos uma mudanças grande na direção de uma arquitetura SOA e como qualquer empresa não temos tempo de treinar todo mundo rapidamente.

O desenvolvimento desta arquitetura foi feita basicamente antes do projeto iniciar. Eu incubi o Guilherme de levantar possíveis soluções para nossos problemas de integração e esboçamos o projeto dos WebServices com tudo que tínhamos de melhor, incluindo REST. O primeiro uso desta infra-estrutura foi num projetinho bem curto que realizamos no início do ano e ela se mostrou muito boa.

O problema foi que neste projeto apenas o arquiteto (o próprio Guilherme) e eu metíamos a mão neste sistema. Quando começamos o projeto maior os conceitos ali dentro precisavam ser espalhados. Na primeira iteração com algumas cabeçadas conseguimos um desempenho bom mas ainda não o suficiente. Também vimos alguns pontos onde a arquitetura estava diminuindo muito a produtividade das entregas e que a introdução dos conceitos de WebServices REST, Hibernate/JPA, caches distribuídos e outras coisas menores precisa ser feita com mais cuidado. Algumas pessoas aprendem rápido e sozinhas, outras não e isso não tem a ver com habilidade técnica e sim com perfil (coisa, aliás, que defendo aqui desde sempre).

A solução que pensamos foi adicionar como tarefa um workshop arquitetural. Eu não queria cometer o mesmo erro e trancar o projeto na mão de um membro do time apenas (ou alguns), então nos reunimos durante a tarde. Na primeira parte da reunião o Guilherme explicou a arquitetura do início, mesmo para quem teoricamente já sabia foi útil.

Picture 019

Para estruturar a coisa eu pedi ao Guilherme quatro visões: a estrutura lógica (componentes), a estrutura física (servidores, bancos de dados, etc.), a de pacotes (como os módulos são divididos) e a de caso de uso (descrição do que acontece numa user story relativamente complexa do início ao fim).

Depois nós realizamos um exercício que aprendi no curso da TeamWare: cada um recebeu um bloco de post-it e uma caneta. Por cinco minutos escrevemos tudo que atrapalha nossa produtividade rapidamente, se alguém não pensasse em nada escrevia “nada” no papel. Depois discutimos cada ponto destes sorteando um de forma aleatória. Da forma escolhida para sortear surgiu o nome interno da técnica: a Dança do Siri (derivado da maneira “curiosa” de obter os papéis pelo Tiago):

Picture 027

Houveram poucos pontos técnicos, a maioria de infra-estrutura. Neste meio surgiram também coisas de processo como o papel dos estagiários no time. Um dos pontos levantados é de que nosso time não é tão homogêneo (e qual é?) e nem todos conseguem trabalhar em todas as partes do sistema. Uma estratégia que definimos foi de fazer pares quando ocorrerem estes casos e se tudo mais falhar partir para outra tarefa. O importante é quebrarmos os feudos de sistemas.

Todas foram discutidas, os pontos cabíveis foram anotados e mantivemos o histórico:

Picture 028

Na reunião para a entrega do primeiro pacote tínhamos um problema: descobrimos um erro no cronograma inicial (criado antes do projeto iniciar e antes de adotarmos o processo novo) que iria atrasar o projeto em oito dias. Começamos a reunião com uma descrição do processo de desenvolvimento para os clientes (aqueles que não participam no dia a dia do produto), revisão dos fatos ocorridos que desencadearam no atraso, o que faríamos para voltar ao rumo e a demonstração das funcionalidades. Para nossa surpresa a resposta foi excelente. Os clientes elogiaram a transparência do desenvolvimento, elogiaram o fato de verem algo em produção tão rapidamente e terminamos tendo que responder a uma pergunta: mas por que não fizemos assim antes?

Nós não implementamos o Scrum por completo (me viu falar em burndown chart aqui?), ainda falta bastante. Também não conseguimos eliminar problemas de prazo, tivemos que trabalhar algumas horas extras no último Sprint e possivelmente neste também. Algumas pessoas não se adaptaram aos novos processos e deixaram a equipe. Mas o importante aqui é que elevamos a qualidade do nosso trabalho consideravelmente -a ponto do cliente perceber- e as pessoas estão felizes em trabalhar desta forma, tanto as de fora quanto as de dentro. Paramos de correr atrás do prórpio rabo resolvendo problemas aleatórios diários e estamos trazendo resultados.

Engraçado que outro dia alguém falou comigo no corredor “Poxa, tô sabendo que vocês estão indo muito bem no projeto, heim? Perguntei pra Fulana -uma cliente- e ela disse: ‘É, eles estão gerenciando na linha dura desta vez, estilo sargentão’”.

Será?
Picture 023

PUTz grila

Monday, July 2nd, 2007

O Guilherme Chapiewski acaba de postar sobre uma conversa que tivemos hoje que, como sempre, começou na baia, passou por 3045 livros, papers e blogs e acabou num sanduíche de mortadela.

Afinal, qual a diferença entre POST e PUT numa arquitetura REST?

Encapsulando o Futuro Incerto

Tuesday, June 26th, 2007

Após as turbulências voltamos ao normal, ou quase. O número de visitas caiu pela metade neste período, então por favor avisem a seus amigos que o blog mudou: philcalcado.com. As URIs antigas devem funcionar mas esta é a oficial.

Nestes últimos dias acabei migrando para o Gnome. Eu nunca fui muito com a cara do gerenciador, mas acho que sempre foi por birra minha com o Miguel de Icaza. Eu nunca engoli direito a história de se implementar as pseudo-especificações da Microsoft como Software Livre em vez de investir em uma plataforma como Java, Python, Ruby ou Strongtalk, mas enfim, hoje em dia eu até Mono uso…

O Gnome segue um paradigma mais minimalista, quem está acostumado com muitas opções sofre um pouco mas anda fácil depois de um tempo. Eu não diria que é melhor ou pior que o KDE< é questão de costume e gosto apenas. O problema que eu venho experimentando não está no Gnome ou KDE e sim nos softwares que os acompanham. Para a maioria das pessoas que usam um computador as configurações de fábrica são mais que suficientes. para um programador este não é o caso. Nós sempre temos que experimentar,t estar e acabar com um HD torrado ou algo parecido. No caso destes ambientes, "algo parecido" geralmente é uma aplicação travando. O problema acontece mais frequentemente com aplicações pequenas, aquelas que ficam nas respectivas docks. É interessante que na maioria dos casos as aplicações funcionam normalmente, mas basta quebrar uma dependência, tentar algo muito diferente e elas desabam. Aí você procura uma solução na internet e descobre que aquele comportamento se deve ao fato da aplicação fazer várias suposições sobre o ambiente que roda, por exemplo que está no KDE ou Gnome. E falha.

Vivi um caso parecido há poucas horas. Era uma página de Internet simples, o problema consistia apenas em XHTML e JavaScript. Uma determinada <div> continha uma objeto flash dentro de si e em alguns casos especiais ele deveria ser substituído por outro. Aí entra o problema. O objeto original faz parte de um determinado framework de anúncios, o novo faz parte de outro. Ao trocar o conteúdo havia um problema de JavaScript que só se manifestava no pior browser: Internet Explorer 6.0. Este browser possui recursos pífios de depuração e por anos é a dor-de-cabeça do pessoal de implementação client-side. Eventualmente, após muitos alert()s, descobrimos que o problema era que o framework original estava no time dos que fazem diversas suposições sobre o ambiente. Ele supunha que existiria um objeto com determinado nome, que uma determinada função estaria disponível, etc. etc. etc.

Estes são dois exemplos simples que mostram o quanto encapsulamento é importante. Você não precisa de objetos para ter encapsulamento (apesar de que se você tem objetos deveria ter encapsulamento), você pdoe encapsular algo como o que sua aplicação expõe e espera encontrar do lado de fora ou como seu JavaScript reage a mudanças na página - Web 2.0, meus caros, Web 2.0 -, o que importa é que seu código abstraia a implementação do que acontece no exterior (uma <div> é uma <div>, não importa se dentro possui o objeto A ou B), qual a implementação das coisas (KDE e Gnome fazem basicamente a mesma coisa) e, principalmente, colabore com as outras aplicações escondendo delas os detalhes da sua implementação.

A “culpa” da quebra de encapsulamento geralmente não está na classe que usa outra e sim na que não oculta dos seus clientes os seus segredos mais íntimos: como diabos ela é implementada.

Falando novamente

Monday, June 25th, 2007

Post dando um up no Falando em Java, evento da Caelum no próximo sábado.

Formulários

Saturday, June 16th, 2007

A maioria das aplicações web de hoje em dia são apenas um grande conjunto de formulários e relatórios derivados dos dados inseridos. A maioria das empresas (especialmente as de 3 letrinhas) não consegue enxergar o investimento em usabilidade, arquitetura da informação e design como algo rentável neste ambiente, deixando a cargo dos pobres programadores a criação das telas. Se você está neste barco, dê uma olhada pelo menos nos guidelines que Luke Wroblewski postou sobre formulários. Fantástico.

Falemos em Java

Thursday, May 31st, 2007

Fui convidado pelo pessoal da Caelum para participar do Falando em Java 2007. Achei a idéia dos rapazes fenomenal: uma conferência rápida sobre um tópico atual a um preço acessível. Você paga R$200,00 para ir num Sun Tech Days da vida e passear por 2.545 palestras que falam superficialmente sobre um milhão de coisas e não aprendendo muito além de que se você usar Netbeans você vai ser mais feliz, mais gostosão e sua alma não vai para o Inferno, mas se você está cansado disso pode preferir pagar R$40,00 e ter um dia com 5 palestras sobre coisas que você precisa saber pra ontem. A grade inclui indexação e busca de conteúdo, REST, APIs públicas, JavaFX e AJAX, tudo girando em torno do tema Web 2.0.

A Culpa é da Marvada

Tuesday, May 22nd, 2007

O Vitor respondeu meu post, eu tentei colocar um comentário mas ficou muito grande, então vamos tentar retrucar por aqui mesmo :)

Eu entendi que ele quis dizer algo como “em >coloque -um-valor-muito-alto-aqui<% dos casos usar OO é overhead” e, como disse, concordo em parte, mas acho que mais uma vez houve uma certa ênfase errada.

Para começar, acho que mudou bastante de idéia. Em Fevereiro você disse:

Como um bom amante da Orientação a Objetos pura eu odeio os bancos de dados tradicionais e acho os frameworks de O/R um saco (além de ser uma grande gambiarra)! Por isso eu uso Prevayler. :D

Que foi o que começou este debate todo. Bom, vamos lá.

Por exemplo, com o BabaXP eu forcei a implementação de um DAO, mesmo usando o Prevayler. Achei que era possível criar um DAO OO, algo bonito, que abstraísse as diferenças entre Prevayler e um banco relacional qualquer. Me enganei. É impossível fazer algo nesse nível só por causa de uma única diferença entre as duas tecnologias, o acesso direto a memória dos dados.

Bom, Prevayler em si não é OO, como já discutimos no seu blog e em um post passado aqui neste mesmo, mas ainda que fosse não há problema em ter um Mapper (que é conceito por trás de um DAO) entre dois domínios de objetos diferentes. Na verdade, Eric Evans possui ótimos textos sobre Context Mappers no seu livro que fazem exatamente isso.

Quando trabalhei com Hibernate 2 e EJB 2, não consegui imaginar uma forma melhor de se programar do que seguir um fluxo de ida e volta: Locator -> Facade Session Bean -> Transaction -> DAO -> Hibernate Entity. Com VOs circulando entre eles. Aparentemente uma bela estrutura OO, exceto por um problema: os algoritmos continuavam seqüenciais, apenas em objetos diferentes. Os objetos não resolviam os problemas da regra de negócio, mas sim simplificavam o uso da própria tecnologia (EJB). Não haviam objetos inteligentes, apenas os JavaBeans secos, como o Hibernate 2 queria, e VOs secos, com regra de negócio pertinente ao objeto e só.

Ahm? Por que o Hibernate fazia você usar DTOs? Eu usei Hibernate com objetos de negócio nesta versão e não tive nenhum problema, poderia explicar melhor? Mesmo os tão mal-falados EJBs podem ser utilizados com objetos. Não não é tão fácil quanto em JPA/Hibernate 3, mas também não é difícil.

E não, DTOs/VOs/TOs ou como estejamos chamando esta semana não fazem um bom modelo OO, muito pelo contrário.

Uma estrutura semelhante foi criada com o JavaFreeCMS, uma arquitetura Action Based não poderia gerar outro resultado do que uma implementação Action Based, que é um nome mais bonito para implementação seqüencial. Por mais que eu quisesse implementar algo OO, tinha algo que me prendia ao modelo relacional. Cultura? É, foi sim. O JavaFreeCMS foi baseado no phpNuke, no qual é muito fácil adicionar módulos e componentes. Lá basta você adicionar um .php e criar a tabela, pronto. Tentei fazer algo semelhante, mas orientado a objetos. Acabei descobrindo que o esforço para implementar tal flexibilidade era tamanha que eu precisaria de uma equipe para desenvolver um Simples e Idiota CMS OO. Acabei chutando o balde e implementando o mais simples possível.

Foi então que comecei a suspeitar da utilidade da Orientação a Objetos e dos Design Patterns. Como falei antes, até então eu considerava que o problema era eu. Que eu era incapaz de fazer algo bom utilizando o melhor da OO e dos design patterns. Afinal, tanta gente mais experiente falava bem dos patterns e tals, alguma utilidade eles deveriam ter, não é? No entanto, hoje eu vejo que não é bem assim.

Antes de mais anda não existe nenhum vínculo entre OO e Design Patterns, um existe sem o outro. Depois, existem diversos CMS OO por aí para provar que não é bem o paradigma que tem problemas. Em boa parte deles adicionar ou remover módulos é simples, provavelmente o design que se fez para este caso do JavaFreeCMS em específico não foi adequado (aliás o Prevayler prega um paradigma Action-based em suas transações).

Não adianta você querer implementar a sua estrutura de dados com o melhor da orientação a objetos se você vai acabar migrando esses dados para um sistema relacional. Você tem um esforço considerável para identificar várias heranças, composições, agregações, relacionamentos uni e bi-direcionais e após isso mais um esforço para migrar essa estrutura para o ambiente relacional. Para variar, não existe nenhum framework de O/R que consiga mapear atributos específicos de cada abordagem sem perder em performance, em simplicidade ou produtividade. Até hoje eu nunca vi ninguém conseguir implementar um sistema completo OO e somente depois de tudo criado integrar com alguma forma de persistência de maneira transparente. A OO aplicada, com todos os seus recursos e ideologias, neste tipo de aplicação, só serve para complicar as coisas, trazer mais trabalho e problemas para o desenvolvimento.

Você está ignorando simplesmente décadas de técnicas de mapeamento Objeto-Relacional e, mais uma vez colocando problemas no Hibernate e JPA que eles não possuem. Pode explicar por que eles não fazem este mapeamento?

Segundo este conceito podemos chegar à conclusão que linguagens de Assembly foram uma coisa muito ruim, já que elas apenas adicionam uma abstração em cima do modelo “real”, de linguagem de máquina. Será que elas não trazem benefícios?

A mesma coisa pode-se dizer das aplicações request-response, que mudam de nome a cada ano, mas continuam a mesma coisa. Muitos frameworks não nos deixam fazer muita coisa da OO. Você recebe uma lista de parâmetros e devolve uma lista de resultado. Lista == tabela == relacional. Para provar, pense no seguinte, a cada resposta que um sistema como esse dá, ele carrega todos os relacionamentos de cada objeto, ou carrega apenas a parte que interessa ou que a aplicação cliente usaria? Agora outra pergunta, para isso utiliza-se VOs específicos para cada request ou um único VO com sistema de lazy loading? Implementar um VO para cada requisição é dose. Deixar por conta de um lazy loading também muitas vezes falha (ou a conexão fica aberta e bloqueia outros acessos ao banco ou ela se fecha e se o usuário pedir algum objeto, irá ter um belo “session closed”). Alguém já ouviu falar no conceito de “páginas” com Orientação a Objeto? Não né. Por que esse conceito foi criado pelos bancos de dados e implementado graciosamente com a instrução “limit” no SQL.

Acho que você confundiu um pouquinho listas de estruturas de dados com álgebra relacional. Em um programa eu posso ter listas de qualquer coisa, e elas não precisam obedecer aos princípios de álgebra relacional. Por um acaso bancos hierárquicos ou em rede não implementam listas? Por um acaso uma HashTable é relacional? Prevayler trabalha com listas de objetos, ele é relacional então, certo? Sua prova… bem, não condiz com a realidade.

2007. Faz pelo menos 3 anos que VOs são completamente desnecessários em java, se é que algum dia foram. Lazy loading funciona muito bem, obrigado. O problema de sessão aberta é contornável facilmente com algumas técnicas, apesar de sim, ser um problema real, mas nada impede que eu tenha paginação em uma consulta OO via Hibernate, basta eu fazer eager fetching (que pode, inclusive, contar com consultas polimórficas) antes.

Mas… putz…dizer que páginas foram criadas nos bancos de dados é ignorar solenemente os diversos usos de paginação em memória e outras estruturas uhm… não relacionais.

Pense na seguinte frase: Os dados saem de uma base relacional, são transformados em objetos, executam uma regra de negócio simples (Somas, médias, grupos, contatores, etc), são transformados em relacional novamente e exibidos. Esse é o fluxo de muitas aplicações web e desktop. Se é assim, para que diabos alguém adicionaria aquela transformação e destransformação para OO no meio do processo?
Não parece. É, uma coisa desnecessária. Se a regra é simples, se a arquitetura que você utiliza dificulta o processo ou se os objetivos da aplicação são “relacionais”, para que ficar inventando moda? Os Design Patterns também não escapam. Em várias ocasiões eu vi que era possível implementar padrões um pouco mais complexos diretamente na regra de negócio, como o State por exemplo. No entanto, o State é tão complexo e chato de manter que não vale apena trocar por um campo de “situação” e mantê-lo com o próprio objeto.

Sua aplicação é simples? Ótimo! Pode abrir mão do bom uso de OO e ainda assim manter uma estrutura legível e com manutenção razoável? Excelente! Só não tome isso como regra geral. Se você acredita que a complexidade de criar um programa com estruturas de dados de objetos quase nunca é justificável eu realmente não entendo o que te faz não utilizar uma linguagem que permita este design e ainda traga mais vantagens, como ASP clássico, ColdFusion, PERL+CGI ou PHP. Java pra quê?

Quanto á confusão com Patterns vou considerar respondida acima.

Obviamente, nem toda a aplicação web é tão simples assim, mas minha intuição me diz que 98% do mercado brasileiro segue essa estrutura. Apenas 2% das aplicações merecem ter boas implementações de OO e Design Patterns.

Mais ou menos concordo (mais sobre isso abaixo), mas existe um problema intrínseco aí. Como você frequentou a academia mais tempo acredito que saiba melhor que eu que existe algo chamado programação estruturada e suas variantes, dentre elas programação OO e procedural. Agora, dado que a grande bibliografia de Yourdon, Page-Jones e seus amigos mostra que fazer programas em paradigma procedural exige várias técnicas (fan-in, fan-out, coesão, divisão de módulos, controle de flags, acoplamento… lembra?) para manter um programa… hmm… editável… acho que você está saindo da programação estruturada pura e simplesmente, certo? Segundo este princípio crie classes apenas com atributos públicos sendo manipulados por funções estáticas, aliás, por UMA GRANDE função estática :P

Eu concordo em gênero, número e grau que OO pode ser um overhead tremendo quando se tem um domínio simples, e inclusive defendo arduamente o uso de DSLs simplificadas para construção de sistemas, mas simplesmente largar o paradigma OO em favor de algo que não é OO nem Procedural é retroceder para antes de Dijkstra. Só falta um GOTO.

Entre esses 2% estão, em geral, aplicações com baixa quantidade de informação do usuário: compiladores, ferramentas de BI, diagramadores de interface, toolkits gráficos, aplicações como diagramadores vetoriais, gimp, blender, engines de jogos, browsers, IDEs, etc. Aquelas aplicações de sistemas de informação que seguem a estrutura de frameworks, o estilo de linguagens ou APIs, definitivamente não precisam de mais padrões ou mais OO. Você está preso a ela, portanto faça o que ela mandar e você será produtivo, invente moda e já era! Tente trabalhar de uma forma diferente da MVC com o Swing, e você se verá enrascado. Tente transformar as entities do EJB em Business Objects e estarás f.u.d.i.d.o. :)

Sei não. Ou minha realidade é muito diferente ou a sua é meio..exótica. Nos últimos anos trabalhei em sistemas de gestão de previdência privada, billing de telefonia, análise de risco, gestão de malha ferroviária, gestão de passageiros, conteúdo multimídia, gerenciadores de conteúdo (sim! e alguns deles)… e boa parte das pessoas que eu conheço ficam com sistemas parecidos. Todos eles tinham lógica a modelar como objetos

Fiz também muito destes CRUDs simples na vida mas eles definitivamente não são 98% nem do que eu fiz nem do que as pessoas que conheço fizeram. Se alguém só faz CRUDzinhos simples que nem um Domain Model se justifica a primeira sugestão é deixar Java de lado e trabalhar com algo mais produtivo como PHP4. O problema é que sistemas crescem, se integram e mudam, e acho que é este ponto que você ainda não entendeu que um bom design, seja ele OO ou não, faz diferença.

Caindo nos bons designs você irá ver um bom design procedural e perceber que existem práticas que são melhor implementadas num modelo de objetos, como quando você precisa proteger uma estrutura de dados de acesso indevido, ou sua invariante. Foi assim que o design de aplicações evoluiu até hoje.

Concluindo, nos dias de hoje, em grande parte dos sistemas de informação, a estrutura relacional atuando sozinha é perfeita! Ninguém precisa de Objetos para tais atividades, a não ser, é claro, que você utilize um banco de dados Orientado a Objeto, aí a coisa muda de figura. Mas como muita gente tem medo deste recurso… Hoje, está bem claro para mim: Aplicações com mais regra de negócio do que informação, utiliza-se orientação a objetos. Para sistemas de informação, onde há mais dados do que regras, vai do banco. Bancos relacionais, aplicações relacionais, SQLs e etc. Com bancos OO, aplicações OO.

Isso é complicado. Se você coloca o banco de dados no centro do universo é bom colocar as regras de negócio lá também, cheia de Stored Procedures, e ficar apenas com front-ends em linguagens de programação convencionais. Do contrário o que você faz quando duas aplicações tentam compartilhar o mesmo conceito? Se eu tenho um conceito formado por um join entre duas tabelas o conhecimento sobre este formato deve ser espalhado por todas as aplicações que utilizam o conceito, e quando eu mudar a implementação das tabelas tenho que mudar TODOS os sistemas, ou criar malditas views para segurar o legado.

O modelo de SGBD como centro do universo já foi substituído há quase vinte anos, uma boa lida sobre componentes e serviços vai te dar uma luz neste tema.

No entanto, se você puder escolher que tipo de abordagem usará, saiba que o que vale é a sua intuição. Não force as coisas. Não deixe de implementar a sua estrutura OO só porque alguém te disse que deveria ser implementado o Design Pattern Xyz. Utilizando o mesmo exemplo do State, se você quer fazer uma enumeração e ficar controlando no teu objeto, faça, se achar melhor cair no mundaréu de leis do State, vá em frente. Tudo se resume a sua intuição. Se alguém disser que pode ser feito de um jeito melhor, sem atrair complexidade e dificuldade de manutenção, mande o cara refatorar o teu código e pronto! Mas, não se assuste em ver gente complicando as coisas sem a mínima necessidade :)

Sim, cada caso é um caso mas acredito que o que deve guiar a escolha técnica não é a intuição e sim a razão, derivada da experiência e estudo das diversas técnicas e práticas, arquiteturais e de design, que foram desenvolvidas pela comunidade de desenvolvedores, acadêmicos, pensadores e práticos por todas estas décadas.

Eu tenho certeza absoluta que você pode me mostrar um monte de coisas super-simples sobre sua área de engines gráficas que eu vou achar mega-complexas sem estudar o motivo pelos quais as coisas são desta ou daquela forma. Por isso que não adianta, plataforma não vence cultura.

Update:

O Vitor colocou um follow-up no blog dele. Como não traz nenhum novo argumento aos pontos aqui levantados além de fazer um bashing sem nenhum argumento concreto em cima de AOP e OO (poxa, até o BileBlog usa alguns argumentos), e cisas estranhas como “eu disse que era impossível porque não faz nenhum sentido gastar tempo e simplicidade implementando esse tipo de coisa”, questionamentos vazios como “por que HQL não implementa todas as funcionalidades da OO?” (Como se Java os implementasse…), tratar um ERP, coração de qualquer empresa, como “coisa menor”, não saber o que é eager fetching e detaching e ainda assim achar os criticar, e, principalmente, este trecho:

Shoes, pergunte para alguém das antigas se ele leu Yourdon e Page-Jones para poder programar. Não leram. Se você for olhar o fonte de alguém das antigas perceberá que tem uma organização. Não é uma OO, mas é tão organizado quanto, e certamente não baixa a produtividade da equipe. Hoje só para programar uma boa OO precisamos ler várias bibliografias, conhecer Design Patterns, e várias outras coisas que você conhece bem. Porquê? Para desenvolver um sistema onde o cara vai cadastrar e ler dados? No máximo um relatório com algumas aglutinações, somas, consultas, limites e etc?

Que me preocupa muito vindo de um estudante de mestrado (além de ser bravata, já que a maioria dos engenheiros de sistems de verdade em algum momento tiveram seu contato com análise struturada/essencial e projeto estruturado).

Eu realmente adoraria ter um debate sadio mas a falta de argumentos e o excesso de factóides, evidências anedotas, falácias e achismos não deixa. Eu realmente tentei mas fico por aqui.

Eu já vi este ponto de vista várias vezes e na grande maioria delas um pouco mais de leitura e experiência ao manter sisteminhas “simples” “de cadastro” que viraram bombas-relógio, vivem mais tempo do que deviam e têm que ser integrados, entendidos, estendidos ou meramente consertados mudaram a perspectiva. Provavelmente é só questão de tempo.