Fragmental

Mais uma vez, estou contratando para minha equipe. A última vez foi bem produtiva, então vamos seguir com o anúncio de emprego…

A idéia nesta equipe é um grupo pequeno e coeso de profissionais com grande conhecimento em tecnologia e desenvolvimento de sistemas. O trabalho exige um conhecimento acima do feijão-com-arroz que estamos acostumados a ver no mercado, e este tipo de profissional é difícil de ser encontrado.

Por isso estou colocando este post aqui, acho que quem se dá ao trabalho de ler este blog ao invés de um site de notícias ou tutorial sobre a última ferramenta da moda tem o perfil que estamos buscando. Este é possivelmente o maior anúncio de oportunidade de emprego que você já viu.

Temos uma vaga para o Rio de Janeiro. Nesta equipe, os profissionais são responsáveis por levantar requisitos técnicos, determinar arquiteturas e implementar sistemas de alto desempenho, com literalmente milhões de acessos em horários de pico (e milhares nos horários normais). Não existe a divisão entre analista/projetista/programador/arquiteto, esta equipe trabalha de maneira ágil com profissionais capacitados em todas estas áreas. A equipe utiliza metodologias ágeis no desenvolvimento: foco nas pessoas e não em especificações técnicas de trezentas páginas.

Basicamente a pessoa em questão precisa ser altamente proficiente em Java, pois é linguagem mais utilizada pela equipe. Acontece que não é a única, então conhecimento em outras linguagens é muito apreciado. C#, Ruby, PERL, Python, C++ ou Common Lisp são ótimos atrativos extras, mas não requeridos, apenas desejáveis.

Se você lê este blog então imagina que conhecimento Orientação a Objetos é essencial, não? Sim, você está certo. Conhecimento profundo do básico de OO: classes, herança e polimorfismo é o mínimo esperado. Conhecimento em Domain-Driven Design, métricas e Padrões (de Projeto e Arquiteturais) são vantagens.

Ah, com conhecimento em redes TCP/IP (você já teve que lidar com sockets na vida?), programação concorrente (threads, threads, threads…), shell scripts Linux/UNIX e Oracle (alguma coisa de PL/SQL), são ótimos, mas não essenciais.

Como desta vez não estamos contratando juniors, ter experiência em aplicações semelhantes te dará um diferencial interessante. Áreas que possivelmente deram experiência no nosso ramo são provedores de acesso e conteúdo, mega-portais, produção de mídia e redes de telefonia. Na verdade se você não for tão experiente não tem problema, basta ser alguém maduro e esperto o suficiente.

O mais importante é que esta pessoa deve ser compromissada. Não adianta entrar nesta seleção se você está feliz pulando de galho em galho nas consultorias como PJ, continue onde você está. Nosso interesse é trazer pra dentro de casa um bom profissional e fazê-lo crescer ainda mais, levando a empresa junto. Nós não temos clientes externos, nossos clientes estão na baia oao lado ou somos nós mesmos, então não adianta toda a técnica adquirida em enganar as pessoas. Estamos no mesmo barco aqui, amigo, se o sistema falhar você também não tem PL.

Acho que a principal vantagem que alguém com o perfil que procuramos verá é trabalhar com liberdade para criar, numa equipe de alto nível, utilizando metodologias ágeis e tecnologias de ponta (onde mais você iria usar memcached, rest, selenium…?). O horário é bem flexível também, e você não tem que trabalhar vestido de pinguim.

A posição é como CLT de uma das maiores empresas do mundo no seu segmento, com os benefícios (e impostos, não se iluda) esperados nesta posição. É um lugar para fazer carreira ou pelo menos para ficar um boooom tempo e não simplesmente participar de um único projeto.

Claro que como incoveniente máximo você irá trabalhar na minha equipe. Ok, vamos lá, eu não mordo. Não muito.

Se você se sentiu próximo a este perfil (não precisa ser exato, mas não pode ser muito distante) mande um curriculo seu em PDF ou DOC para oportunidade-rj@fragmental.com.br. É extremamente importante que no e-mail você me diga o título (ISBN é legal também) dos 3 últimos livros que leu. Se você parecer com o que estamos procurando vai receber um telefonema meu.

Observação: Este e-mail será desativado assim que a vaga for preenchida. Se você não se enquadra no perfil não perca nem o meu nem o seu tempo: não mande seu curriculo. O que eu vou fazer é apagá-lo, não vou “guardar para futuras oportunidades”, não vou encaminhar para lugar algum. Vou simplesmente apagar, e isso ainda pode atrapalhar em seleções futuras. Alguém que panfleta curriculos a torto e a direito não é o que eu espero pra mim ou meus clientes.

NOTA: Este post está sendo descaradamento “upado”

Este estudo de caso sobre Domain-Driven Design é bem interessante. Mais do que a forma como simplificaram o código e deram sentido a ele, ele mostra um problema que já vi em muitos projetos que se dizem Orientados a Objetos. É muito comum nestes cenários termos classes gordas cheias de tipos primitivos (Strings, int, long, double, etc.), especialmente seguindo o odioso “padrão” BO/VO.

Para um exercício não importa. Provavelmente o seu professor está querendo que você aprenda a processar uma operação matemática utilizando um programa, não construir um sistema de gerência de galinheiro (apesar de eu conhecer histórias sórdidas nesta linha, outro dia eu conto). O domínio é apenas uma ilustração, o que importa é a manipulação de números.

Bem, acontece que aqui fora dos muros da faculdade não é bem assim. Um sistema de informação não serve para mostrar o quanto seus algoritmos são performáticos, que você leu toda a série do Knuth ou como eles podem ser aplicados em trinta mil situações diferentes. Sistemas servem para resolver problemas das pessoas e sua estrutura interna deve mostrar isso.

Um bom design vai mapear os conceitos do negócio de maneira transparente para o software. Uma das grandes vantagens desta prática é quando você entra em uma reunião, um planning game ou algo do tipo e desenvolvedores e cliente falam a mesma língua. Funciona mais ou menos assim:

Quando você tem classes gordas e vazias em significado, quando o cliente fala algo, pede uma mudança, etc. ele fala em termos de negócio. Enquanto ele vai falando seus engenheiros tentam transformar mentalmente aqueles conceitos nas suas representações. Quando o cliente fala ‘Venda’ o programador imediatamente tenta adivinhar quais das 10 classes diferentes que lidam com este conceito (vários BOs, VOs e tudo de ruim que alguém possa criar) é responsável por aquela parte do conceito de venda. Quando ele enfim descobre e pensa em algo que pode solucionar o problema ele precisa fazer o caminho inverso, mapeando sua solução completamente técnica em uma classe que não faz o menos sentido para o cliente para suitspeak.

Agora imagine que o software modela o negócio corretamente. Imagina que ao invés de uma grande classe cheia de tipos primitivos nós temos várias classes que tentam chegar próximas de um mapeamento 1-1 com o negócio. O conceito de venda é representado por uma classe venda que possui todas as características desta (lógica e dados), se relacionando com outras classes que também modelam o negócio. Por exemplo ela possui 1 ou mais instâncias da classe prestação, que possuem os dados das parcelas das compras (data de vencimento, valor, data de pagamento, se está vencida, quantos dias do vencimento, multa a ser aplicada, etc.). Quando o cliente fala o desenvolvedor imediatamente sabe do que ele está falando. Sem mapeamentos adicionais, quando o conceito de venda mudar o desenvolvedor sabe que deve mudar a classe venda.

Essa é a ubiquitous language que Eric Evans tanto dá ênfase, a linguagem onipresente que deve existir entre desenvolvedores e clientes. O uso desta linguagem permite chegar ao ponto onde o cliente está apto a questionar as classes de negóciod e maneira eficiente. Se as classes mapeiam profundamente o modelo dele, não devem existir conceitos diferentes dos que ele conhece nelas. Claro que notações como UML podem dificultar a comunicação mas se a equipe modelar de maneira ágil e apenas o necessário a barreira da notação técnica é facilmente transpassável.

Eu trabalhei em um sistema de gestão de laudos clínicos há muitos anos. Para projetar o sistema eu não tive dúvidas: a interface de entrada eram formulários e a saída era composta por relatórios que eram os tais laudos. Tudo muito simples: havia um objeto ‘laudo’ que continha algumas informações do paciente, as informações do exame, diagnóstico e etc. O sistema seriviria tanto para laudos médicos quanto para qualquer outro tipo de relatório, e era tão simples que eu cogitei fazer em Microsoft Access.

O problema começou quando houveram algumas mudanças sutis no modelo de negócios. Um tipo de relatório passou a requerer tratamento especial. Depois outro. E outro.

Neste instante crio uma rule of thumb em programação: você pode medir o quanto um código é ruim pela quantidade de ifs necessárias para implementar uma mudança. Neste caso basta dizer que minhas teclas ‘i’ e ‘f’ estavam gastas.

Como sempre o problema é do cliente que não sabe especificar direito blablablabla, fui reclamar com ele. Aquilo não podia continuar, como pode mudar tanta coisa ao mesmo tempo, o sistema emite laudos, não é o Microsoft Word. Nesta conversa eu percebi a grande besteira que tinha feito.

Eu não modelei o domínio do cliente, eu modelei um sistema de laudos genérico. Acotnece que para o cliente existiam X tipos de laudos, cada um com informações muito específicas e que seguiam por um fluxo de negócios diferente. A versão original do sistema cobriu todas as necessidades de todos os laudos como se eles fossem um só tipo, um super-laudo. Quando cada um mudou para um lado eu tive que esticar o super-laudo até arrebentar.

O cliente não queria um super-laudo. Ele me falou desde o momento 0 que queria gerenciar os laudos que emite, me disse quais eram e as necessidades de cada um. Um dia, ainda durante a análise, eu peguei um bando de diagramas para tentar validar o que eu tinha entendido. Foi uma experiência extremamente frustrante, o cliente não entendia nada daquilo que ele havia modelado junto comigo. Pensei logo nos professores de facudlade dizendo que o maior problema é sempre que o cliente não sabe o que quer e ignorei.

Quando chegou ao fundo do poço, após a reunião onde eu fui sabiamente descascado, tive que tomar uma atitude. Me tranquei num quarto (eu era freelancer nesta época) e só sai depois que modelei o sistema de acordo com o que as pessoas pensavam. Funcionou, ganhei flexibilidade e melhorei o diálogo, mas esta reescrita saiu do meu bolso, o cliente não pagou para consertar a besteira que eu fiz.

Isso leva a outro ponto que eu sempre repito: o cliente não quer saber se é java, C++, se é OO, se o código fede, métricas nem nada, ele quer que o treco funcione. Ok, mas ele também não vai querer saber se você tem que alterar 30 arquivos porque seu projeto é uma porcaria, ele quer que você altere, e rápido.

O DQO continua com a conversa sobre REST x WS-*.

Na argumetnação do porque-você-não-pode-simplesmente-ignorar-ws-* entram dois pontos centrais:

a) WSDL
b) REST é para HTTP apenas

Quanto a (a), eu também tinha a impressão que uma linguagem de definição de interfaces é fundamental mas mudei de idéia. Essas IDLs geralmente são muito complexas (desde CORBA) e isso está intrínseco ao fato de que devem definir tipos simples, tipos complexos, tipos do usuário, etc. de maneira auto-contida. Uma lignaugem de tipos genérica não tem como ser muito simples.

Quanto a ser editado manualmente, EJBs também foram criados apra serem editados apenas por ferramentas. Assim como eu tenho que editar EJB-Jar.XML todo santo dia eu tenho que editar WSDLs. temos um padrão aqui? Fora que os bindings SOAP para linguagens como PERL são…sofríveis. Na melhor das hipóteses. Enquanto isso qualquer coisa que faça HTTP e trate um formato como XMl está pronto para REST.

O ponto é que se eu tenho um conjunto de primitivas simples como PUT, GET, POST e DELETE eu não rpeciso de muito mais. parsers XML, YAML, JSON existem aos milhares e basta ser bem documentado para saber o que uma estrutura de dados representa.

Quanto ao ’ser HTTP-only’, sim, é uma limitação que pode não permitir o uso de REST out-of-the-box em alguns cenários. Mas SOAP, apesar de não ser dependente de transporte, não possui até onde eu sei especificações formais para o uso de JMS ou qualquer outra coisa que não seja HTTP. O que existe são implementações proprietárias destes transportes, e nada impede a criação de uma bridge JMS-HTTP, até via ESB.

Acho que o único motivo técnico real para o uso de SOAp é a abundância de ferramentas e suporte em diversos produtos. Em termos de integração, REST parece fazer muito mais sentido na maioria dos casos.

Mudar para o Netvibes, seguindo recomendação do Marcelo Martins, mas não deu certo. É tudo muito bonitinho, muito Web 2.0, muito AJAX, mas basicamente são widgets para construir páginas personalizadas, não o que alguém que tem 15.892 feeds consegue utilizar.

O Bloglines pode não ser a melhor coisa do mundo mas ele é bom no que se propõe: leitura de artigos via RSS. Não tem widgets, não tem integração com qualquer-coisa-que-tenha-uma-porta-80-aberta, mas ele consegue me dar um mínimo de conforto ao selecionar o que presta ou não nos feeds.

Se pelo menos o NetVibes removesse da página os feeds já lidos eu poderia pensar no caso, mas quando você tem mais de cem blogs numa categoria (que vira uma página) e eles continuam aparecendo mesmo depois de lidos você tem um problema.

Símbolo brasileiro da primeira bolha da Internet, o IMasters parece tentar retomar sua posição numa internet, ao contrário da anterior, soterrada de informações. Bom, os primeiros passos estão indo bem, pelo menos a publicação do artigo do Maurício Linhares foi sensacional: Ócio como combustível para a inovação.

Começa um debate com base em uma entrevista publicada no InfoQ. Sanjiva Weerawarana defende as especificações que ajudou a criar, a famosa pilha WS-*.

Do outro lado, um oponente que até pouco tempo atrás pouco se ouvia falar sobre e agora temos até uma JSR. Não que você precise disso para utilizar REST, muito pelo contrário. Para usar REST tudo que você precisa é de algo capaz de fazer uma requisição HTTP e tratar o formato dos dados, seja XML, seja JSON, seja YAML ou o que quer que seja.

Tudo isso sem reinventar protocolos, sem ignorar as características do HTTP, sem criar mil e um consórcios para produzir duas mil especificações redundantes entre si. Mais sobre o tema em breve.

Ajude a manter a Wikipédia no ar - mesmo sem colocar a mão no bolso!
O BR-Linux.org lançou uma campanha para ajudar a Wikimedia Foundation a manter a Wikipédia no ar. Se você puder doar diretamente, é sempre a melhor opção. Mas se não puder, veja as regras da promoção do BR-Linux e ajude a divulgar - quanto mais divulgação, maior será a doação do BR-Linux, e você ainda concorre a um pen drive!

O Yahoo! lançou um serviço fantástico chamado Y!Pipes.

Esta ferramenta permite realizar transformações em feeds e relacionados de maneira extremamente simples, g?afica e sem programação. Como um exemplo vejam “todos os posts do fragmental que não possuem a palavra Java no corpo de texto (mal) traduzidos para o inglês“.

A Editora Mundo (que, aliás, precisa de um site) ataca novamente: Mundo .Net. Obviamente que eu tenho meus pontos contra a tecnologia .Net e com a Microsoft em específico mas é simplesmente burrice para qualquer arquiteto de software fechar os olhos para a penetração que a plataforma possui hoje em dia e as boas idéias -principalmente a aplicação de idéias antigas- que estão surgindo neste meio.

Eu sempre evitei comprar revistas (e até outro tipo de literatura, na verdade) sobre plataformas MSFT porque o conteúdo editorial nunca teve qualidade. Tem alguns meses que assino o Microsoft Architecture Journal e é um material de altíssima qualidade. O mesmo eu espero de uma revista que sai da mesma casa que a renomada Mundo Java e que tem como editor-chefe Rafael Steile Hamilton Veríssimo como colunista, ambos dispensam apresentações.

Vídeo fantástico no YouTube sobre novos conceitos da nova rede.