Archive for the ‘guj’ 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.

Construindo Expressividade com Linguagens Elegantes

Friday, July 27th, 2007

Ainda não vi uma definição sobre o que seria uma linguagem elegante, então lá vai a minha:

Uma linguagem elegante é baseada em primitivas simples e extensíveis e, principalmente, sem muitas exceções.

Segundo esta definição Ruby, Smalltalk e LISP são elegantes. Java é um pouco, C# com suas centenas de exceções (sobrecarregar + é diferente de sobrecarregar [], dentre outras várias exceções) não é.

Uma linguagem elegante é simples e compacta. É de se esperar que não tenha sobrecarga de operadores, mas isso não é verdade. O problema das pessoas com sobrecarga de operadores é porque elas vêem isso como uma quebra da rule of least surprise. Essa regra diz (implora, eu diria) para não surpreendermos nossos usuários modificando o mundo que eles já conhecem para que uma ação traga consequências não esperadas. Por exemplo imagine que você vai modificar um programa como o ls para dar mais performance (uau, você é bom!). Faça o que quiser mas não mude os parâmetros de entrada e saída ou você vai quebrar um zilhão de programas e scripts pelo mundo todo. Caso introduza uma feature nova faça o usuário explicitamente solicitar por ela (passando um flag no estilo ls -lira –my-fancy-new-feature) e mantenha o default como o antigo.

E onde entra sobrecarga de operadores nisso? Lá no seu primeiro curso de programação (ou no seu primeiro livro se você opta pelo caminho mais difícil) deve ter aprendido sobre literais, variáveis, condicionais e… operadores. Operadores são caracteres especiais com uma função bem definida na linguagem, por exemplo o operador de divisão, de resto, de adição…

Em Java, quando você chama:

String texto = "abc".toUpperCase();

É fundamentalmente diferente de quando chama:


int numero = 12 + 24;

Porque um método e um operador são coisas diferentes e você aprendeu a pensar desta forma. Se amanhã eu puder sobrescrever o operador + para que escreva algo na tela você vai se surpreender porque não era isso que o manual da linguagem te disse.

Ainda assim, existem muitas ocasiões onde sobrecarga de operador são mais que convenientes, são semânticos. Imagine o exemplo do nosso BigDecimal:


BigDecimal a = new BigDecimal("100");
BigDecimal b = new BigDecimal("300");

Some os dois. Ok, você é um programador Java esperto e sabe que vai ter que fazer algo como:


BigDecimal resultado = a.add(b);

Mas disso até me dizer que é melhor que usar ‘+’ é outra história.

Mas e a simplicidade? Não é legal termos um conjunto pequeno de operadores que faz coisas previsíveis e que servem na maioria das vezes? Sim, é! Mas num mundo onde tudo migra para mais expressividade, com Model-Driven Development e Domain-Specific Languages ter este tipo de limitação não é interessante. As melhores linguagens para construir DSLs são as mais flexíveis e por acaso as mais elegantes, que coincidência, não? E como Ruby, que se enquadra nestes dois aspectos, lida com isso?

Simples. Em Ruby não existem operadores, pelo menos não como você está acostumado em Java, operadores são apenas apelidos para métodos. A vantagem disso é que se muda o modelo mental, a partir do momento que você sabe que um operador e um método são a mesma coisa você tem com operadores o mesmo cuidado que tem com métodos. Ao chamar add() do BigDecimal você tem que saber se o método vai retornar o resultado como um objeto separado, se vai modificar os objetos passados como parâmetros, etc. Como você faz isso? Lendo a documentação até se familiarizar com a classe e seu idioma. Após familiarizado você começa a usar sem pensar.

E quando você espera estar lidando com uma classe que sobrescreve um operador e na verdade recebe como parâmetro uma subclasse dela? Sem problemas! Se o autor seguiu os princípios básicos da Orientação a Objetos, que derivam do Design by Contract e o Princípio de Substituição de Liskov a subclasse tem que obedecer o contrato da classe-pai, e se você obedeceu os mesmos princípios não precisa de nada que não esteja no contrato.

Esse tipo de resistência com funcionalidades é o tipo de coisa que se elimina aprendendo várias linguagens e estudando suas motivações. Existem algumas linguagens como as citadas que merecem ser estudas ainda que você nunca as vá utilizar de fato. Elas abrem a sua cabeça.

Cuidado com Domain-Driven Design

Friday, June 22nd, 2007

Em tecnologia existe um fenômeno interessante. Existe um problema qualquer. Alguém resolve o problema de um modo e as pessoas começam a usar este modo. O detalhe é que as pessoas não param para ler as fundamentações técnicas, a coisa vira um grande grupo de achismo. Aí surge outra solução que é mais eficiente e utilizada por uns poucos que tentam convencer os outros. Quando finalmente as pessoas se convencem elas repetem o ciclo, não estudando a fundo as bases e caindo no conto do vigário.

Este post no GUJ mostra um claro desvio dos padrões estipulados por Domain-Driven Design. Vamos desmistificar a coisa: DDD é uma forma disciplinada de criar um Domain Model, só isso. O foco da técnica é criar um domínio que “fale a língua” do usuário. Isso não quer dizer que você vá “mapear o mundo real” com objetos, esse não é o objetivo nem da técnica nem de Orientação a Objetos em primeiro lugar.

Passeando pela thread, você pode perceber diversas coisas fora do que é definido em DDD. Os conceitos de Domínio e Contexto confusos. Domínio é o que o programa (seja um exercício de faculdade ou um sistema empresarial) modela, o que ele se propõe a resolver. O modelo que você criou deste domínio (o Domain Model) certamente possui intersecções com modelos criados em outros sistemas, serviços, etc. Neste caso o dividimos em Contextos:

Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.

A analogia do círculo é péssima porque ela foca em uma caixa-preta, que não é um Módulo em Domain-Driven Design. Em DDD um módulo é quase que exatamente como um pacote em Java ou namespace em C#. O Contexto é dividido em Módulos, que agrupam entidades com conceitos em comum. A comunicação entre Contextos e entre Módulos é dada através de diversos padrões e técnicas.

Existe uma confusão também com Value Object. Em DDD um Value Object é um conceito de domínio como qualquer Entidade a diferença é que ele não tem identidade própria. Se eu pegar uma nota de dez reais emprestado de você você não exige que eu te devolva a mesma nota, apenas que devolva uma nota de mesmo valor ou equivalente. Este conceito do “mesmo valor” é o coração do Pattern. O tópico coloca o pobre VO como um TO, mero agrupamento de dados.

A parte da transação também é muito complicada. Desde o início deste século que nós estamos separando estas responsabilidades (autenticação, transações, log, etc.) como conceitos ortogonais. Conceitos ortogonais não devem, quando a tecnologia permite, estar implementados junto com regras de negócio, junto com entidades de domínio. Para isso suamos a AOP expressa por ferramentas como Spring Framework ou EJB (seja 2.1 ou 3.0). Eric Evans fala sobre separação entre domínio e tecnologia:

The domain model is a set of concepts. The “domain layer” is the manifestation of that model and all directly related design elements. The design and implementation of business logic constitute the domain layer. In a MODEL-DRIVEN DESIGN, the software constructs of the domain layer mirror the model concepts.

It is not practical to achieve that correspondence when the domain logic is mixed with other concerns of the program. Isolating the domain implementation is a prerequisite for domain-driven design.

Falar que ActiveRecord não funciona é negar a realidade. Frameworks como Ruby on Rails, Castle e Grails se baseiam nele, não é porque não até até então nenhuma proposta Java de framework que o conceito não funciona. O exemplo dado não representa qualquer problema, já que transações são tratadas em um conceito ortogonal separado, como descrito acima. Se AR se aplica bem ou mal no caso X ou Y, com DDD ou o que for é outro assunto, que aliás já tratamos aqui mais de uma vez.

Interessante que toda a thread teria começado porque o autor original achou que os artigos deste blog não são completos o suficiente. Independente de serem (e não são) ou não, o que eu sempre recomendo éleia a bibliografia. Infelizmente tem (muita) gente que prefere simplesmente ter um pseudo-resumo rápido num fórum. Fazendo uma análise dos pontos que levantei aqui e de outros no texto em questão eu percebo que o autor original em si não teve muito sucesso em aprender os conceitos de Domain-Driven Design porque procurou o meio errado. Outro dia uma thread no mesmo fórum sobre o mesmo tema corria parecido, com uma pessoa fazendo críticas em cima de um modelo usando Repositórios. O problema é que o cidadão em questão nem sequer leu sobre a técnica antes de criticar, nem mesmo no resumo disponível gratuitamente apenas pedia um exemplo como se quatro linhas de código fossem passar 500 páginas de conhecimento. O mundo tem pressa e preguiça, mas até onde isso leva?

DAO e Repository

Tuesday, June 5th, 2007

Tópico quente no GUJ. Muita gente está atrás de Domain-Driven Design hoje em dia e não tem a menor noção do que é um repositório.

Re-colando o trecho para a lista de DDD:

On 5/19/07, Phillip Calçado wrote:
> The main thing to keep in mind while working with Repositories is that
> they’re a domain concept, while a DAO or any other Mapper between
> objects and tables aren’t. The domain classes knows that repositories
> are where business objects instances remain. As a business concept it
> can and will be handled, received as a parameter, etc. by those
> business domain classes like services and entities.
>
> A DAO doesn’t fit in a Repositories place directly, this would break
> layered archtiecture of a application, but generally a Repository is
> just something that when invoked will call a DAO.
>
> To avoide the tortures of creating a brinless delegator as a
> Repository you can use the Dependency Inversion principle, by Uncle
> Bob, and make Repository an interface implemented by the DAO class.
> This way your domain classes won’t end up dependent on infrastructures
> classes (like DAOs) while you avoid creating Repository classes that
> acts just like delegators.
>
> I’ve used this approach more than once. In a recent project I’ve used
> this Dao<>Repository strategy and suddenly was requested
> that before checking the database I’d have to first check a enterprise
> search engine (something like google appliances or a dedicated Lucene
> server). I used to have:
>
> Domain Object –<>–> Repository <--<>– DAO
>
> And changed to:
>
> Domain Object –<>–> Repository
>
> Repository <--<>– RepositoryImpl –<>–> DatabaseDao
>
> –<>–>SearchEngineDao
>
> The RepositoryImpl was the class responsible for looking for the
> instance persisted in one of the two deta repositories. The domain
> classes that just relied on the Repository concept, not its
> implementation, weren’t affected.
>
> cheers
>
>
> On 4/25/07, Nick wrote:
> > I’ve just completed my third project using DDD principles and I think
> > I’m ready to move away from the repository pattern (though still
> > giving it some thought). In theory, I think it’s great. However, it
> > just causes so much code explosion, I find it’s just not practical.
> > For example, for the customer aggregate root I have:
> >
> > Domain.ICustomerRepository
>
>
>
> –
> Phillip Calçado
> http://www.fragmental.com.br

O DQO também colaborou.

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.

POX x REST: Interfaces Padronizadas

Monday, April 23rd, 2007

Enquanto o GUJ tem sua massagem noturna eu respondo ao post do Maurício por aqui. O tema é REST x POX, mais especificamente: precisamos usar REST o tempo todo?

Pra você que estava hibernando há uns 12 meses, REST é um estilo arquitetural que se coloca como uma alternativa ao uso de SOAP e padrõesWS -* para criar WebServices. REST é interessante porque este estilo arquitetural é conhecido e utilizado há anos: é o estilo arquitetural que define a Web. Um sistema REST vai usar os métodos HTTP (GET, POST, PUT e DELETE), os content-types, os código de resposta e tudo mais que você ignora solenemente na maioria das aplicações web atuais mas que estão desenvolvidas e especificadas há mais de uma década.

Um possível problema seria de que as pessoas estão dizendo que usam REST quando na verdade apenas usam XML passando por HTTP, o chamadoPOX ( Plain Old XML, um primo do POJO). Este processo é exatamente a mesma coisa que utilizar SOAP com HTTP, exceto pelo fato de que o XML é personalizado (ao invés de 500 envelopes, um dentro do outro) e que não temos umWSDL (o que provavelmente é ruim).

Bom, a pergunta do Maurício é: isso é ruim? A resposta você já sabe: depende, mas depende do quê?

Quando se usa WebServices SOAP ou REST o que se quer é ter uma interface padronizada para um serviço. Há décadas nós temos serviços distribuídos sendoamplamente utilizados, o motivo de existir SOAP e outros é padronizar este ecossistema. Quando você padroniza algo como o protocolo de interface remota de todas as aplicações obviamente você vai pagar um preço em eficiência. Uma aplicação que segue um protocolo genérico como HTTP provavelmente não será tão eficiente em comunicação remota quanto um que segue um protocolo específico e especializado.

A partir do momento que você resolve utilizar uma interface genérica você assina um contrato. Se você me disser que seu sistema éRESTful eu tenho certeza que se eu fizer a requisição de um objeto inexistente seu sistema irá retornar um código de erro 404, e não um código 200 com um XML bonitinho e uma mensagem de erro. 200 pra mimsignifica uma só coisa: “Ok, o objeto existe e seu conteúdo segue no corpo da mensagem”.

Ao fazer POX você quebra esta regra. Pode ser que seu sistema seja simples e que definir um mini-protocolo baseado em POX seja uma ótima solução, mas você acaba de inventar seu próprio padrão, que é exatamente o que o uso de WebServices tenta evitar. Mesmo para sistemas legados com seus próprios padrões (coisinhas em COBOL, por exemplo), nós temos oESB como tecnologia que converte mensagens para um formato intermediário, de modo que não sejam criados seus próprios padrões. A idéia por trás de REST não é abolir padrões mas sim ter uma especificação simples e eficiente, com um mínimo de primitivas e máxima extensibilidade.

Aplicações Web de Alta Performance

Saturday, September 16th, 2006

Rodrigo Kumpera, o louds do GUJ, publicou um artigo na MundoJava deste bimestre falando sobre aplicações web de alta performance. A matéria mostra técncias que são utilizadas em grandes portais mas que podem salvar sua pele em sistemas corporativos muitog randes! Leitura obrigatória.

O Kumpera é conhecido na comunidade Java brasileira como ‘o doente que está desenvolvendo uma JVM como pet project’.

O que é um arquiteto?

Sunday, February 19th, 2006

Inspirado por mais um post no GUJ, resolvi escrever um pouco meus pensamentos sobre esta tão comentada e tão pouco definida função. Quem é o arquiteto de software? O que ele faz?

Vamos olhar o que é Arquitetura de Software segundo o livro Pattern-Oriented Software Architecture, Volume 1: A System of Patterns (Hardcover) (tradução livre minha):

A arquitetura de um software é a descrição dos subsistemas e componentes e suas relações. Subsistemas e componentes são tipicamente especificados em diferentes pontos de vista para mostrar suas propriedades funcionais e não funcionas que sejam relevantes. A arquitetura é um artefato. É resultado de uma tarefa de design de software.

Nos baseando por este conceito, podemos dizer que o arquiteto é quem especifica os subsistemas e componentes de um software e como estes se relacionam.

Olhando por esta ótica, não parece que o arquiteto deva saber sequer programar. A certificação de Arquiteto Java da Sun, por exemplo, não exige esta habilidade. A prova exige conhecimentos de UML, Design Patterns clássicos e JEE, sobre a arqutietura de aplicações distribuídas e as APIs Java EE.

Ainda que acredite que a ementa da Sun seja parte integrante da formação de um bom arquiteto, algum tempo atrás em uma entrevista para o JavaPosse com Burr Sutter, líder do Chapter de Atlanta da IASA , um conceito que acredito que seja o mais importante: Um Arquiteto deveria ser capaz de fazer o sistema todo sozinho.

Não é preciso ser um super-homem para isso, na verdade basta apenas experiência. É claro que podemos ter um arquiteto que nunca participou de projetos como júnior (um em um outro cargo que não costume tomar muitas decisões sobre design de alto nível) ou pleno (ou outro cargo onde você toma muitas decisões o tempo todo mas não tem a palavra final), mas exceto em raros casos de pessoas geniais este “arquiteto nato” não vai conseguir produzir nada muito bom por nunca ter atuado na linha de frente.

Acho que quando a emrpesa possui uma equipe pequena, o arquiteto surge como o gerente da área ou como um líder escolhido por meritocracia. O papel de líder de desenvolvimento separado do de arquiteto é algo preocupante já que as atividades são muito ligadas. O arquiteto deve ser líder e mentor da equipe (não necessariamente gerente), este é seu papel fundamental.

Para resumir esta conversa vou tentar descrever o perfil de um arquiteto que eu contrataria para minha empresa hoje:

Uma pessoa experiente em projetos de diversos tamanhos, preferencialmente em mais de um tipo de negócio e com diversas tecnologias. Programa fluentemente na linguagem a qual o sistema vai ser produzido e em algumas outras, mesmo concorrentes.

Sua mesa ou bookmarks estão cheios de repositórios e catálogos, ele sempre procura referência bibliográfica sobre o que está sendo feito, mesmo que signifique ler um paper de 1975 sobre computadores com bytes de 9 bits. Está sempre sabendo das novidades na sua área de atuação, mesmo que ele nunca tenha nem entrado do site daquela tecnologia nova, ele já ouviu falar e está disposto a ouvir se alguém quiser falar mais sobre ela.

O design que ele produz é simples e extensível ao extremo. Serve como linha-base para o programador mas não sufoca o instinto criativo. Este é criado após mesas redondas com os programadores e demais interessados onde cada idéia é debatida.

Ele sabe que o design mais importante é feito diariamente, então está sempre acompanhando o repositório de código. Uma de suas primeiras atitudes foi convencer a gerência da necessidade de um build contínuo com relatório de métricas de qualidade no código. Também evangeliza ferramentas como PMD e FindBugs e exige que código tenha testes unitários. A qualidade da equipe é fundamental então ele insiste com as pessoas responsáveis que rodas de leitura, workshops e treinamentos sejam realizados.

Para vender todos os seus projetos à gerência, ele aprendeu a falar a linguagem dos gerentes. Um dos papéis mais importantes do seu trabalho é transformar métricas em algo que o seu chefe consiga entender, algo que msotre o real benefício do foco na qualidade do sistema. Mesmo sendo um excelente técnico, ele tem que desenvolver habilidades de comunicação com quem manda na empresa.