A Concrete está contratando

maio 31, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Olá pessoal, está rolando um processo grande de contratação na Concrete e estou ajudando na divulgação das vagas. Eu trabalho na Concrete há mais de 2 anos e gosto muito da empresa. Eu cheguei na empresa depois de trabalhar por mais de 2 anos numa das maiores (talvez a maior) empresa de consultoria do mundo.

O meu apreço pela Concrete é muito maior do que eu já tive pela empresa anterior. Nesta outra empresa todos nos sentíamos como gado. Sabíamos que cada pessoa era um recurso e pronto. Totalmente descartável, o que explica a alta rotatividade de profissionais que passaram por lá.

Na Concrete desde o começo eu me senti relevante. Os sócios e os associados (nível semelhante a gerentes) me conhecem e a minha opinião é levada em consideração nas decisões da empresa. Em vez de ser o FUNCIONARIO_ID número 105347, eu sou o Bruno Pereira. É uma sensação muito melhor, e isso certamente motiva mais.

Além disso, a Concrete é uma empresa realmente de software. Feita por pessoas que gostam de software e contrata gente que gosta de software. O foco principal da empresa é desenvolvimento mesmo. Com isso, convivemos entre profissionais de alto nível, e isso ajuda muito no amadurecimento e evolução dos profissionais.

Bom, estou ajudando na divulgação de vagas para 3 perfis, com a descrição abaixo. São 2 vagas para cada perfil. Se você se enquadrar neles ou conhecer alguém nesse perfil, por favor me envie um e-mail com seu currículo para: blpsilva@gmail.com.

Analista de Sistemas Java Pleno

Fundamental:
– Java SE 5 e/ou 6, Java EE
– JPA, Hibernate, Struts
– Experiência de uso com algum dos seguintes application servers (se conhecer mais de 1, melhor): BEA WebLogic 9 ou 10, Jboss AS, Apache Tomcat e Geronimo.
– Conhecimento de SQL e modelo de entidade-relacionamento.
– Inglês para leitura e estudo de material técnico. Inglês para conversação é um plus.

Desejável:

– Graduação em Ciência da Computação, Engenharia Eletrônica ou Computação, Informática e Matemática
– Conhecimento e interesse em outras linguagens de programação é bastante apreciado: Ruby, Scala, (Rhino)Javascript, Perl
– Familiaridade com web services e suas especificações WS-*
– Familiaridade com processos de desenvolvimento iterativo

– Familiriadade com comunidades e projetos de Open Source Software
Analista de Sistemas Java Sênior

Fundamental:
– Java SE 5 e/ou 6, Java EE
– JPA, Hibernate, Struts,
– Experiência de uso com algum dos seguintes application servers (se conhecer mais de 1, melhor): BEA WebLogic 9 ou 10, Jboss AS, Apache Tomcat e Geronimo.
– Conhecimento de SQL e modelo de entidade-relacionamento.
– Inglês para leitura e estudo de material técnico. Inglês para conversação é um plus.

Desejável:

– Graduação em Ciência da Computação, Engenharia Eletrônica ou Computação, Informática e Matemática
– Conhecimento e interesse em outras linguagens de programação é bastante apreciado: Ruby, Scala, (Rhino)Javascript, Perl
– Conhecimento de plataforma Linux
– Conhecimento em shell scripting para Unix/Linux é bastante desejável
– Conhecimento em otimização de JVM e Garbage Collector
– Familiaridade com web services e suas especificações WS-*
– Familiaridade com diversos aspectos do ciclo de vida do desenvolvimento de software
– Familiaridade com processos de desenvolvimento iterativo
– Familiriadade com comunidades e projetos de Open Source Software

Consultor/Analista de Infra-Estrutura

– Atuar com suporte à área de produção de TI
– Sólidos conhecimentos de ambientes Linux
– Sólidos conhecimentos em SQL
– Conhecimentos em Oracle e SQL Server para troubleshooting e análise de performance que cause impactos em aplicações
– Desenvolvimento e manutenção de shell scripts
– Sólidos conhecimentos em tópicos de redes TCP/IP, LAN, DNS
– Inglês para leitura e estudo de material técnico. Inglês para conversação é um plus.

Desejável:
– Conhecimentos de Active Directory e protocolo LDAP
– Conhecimentos de WebLogic Server
– Conhecimentos de IIS
– Espanhol para conversação
– Virtualização utilizando suíte VMWare

Anúncios

Curso de web services REST

maio 30, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Ontem na minha apresentação de REST no RioJUG um rapaz (infelizmente não sei o nome dele) me perguntou se eu conheço algum curso ou treinamento sobre REST.

Não conheço nenhum curso disso e não sei se teremos algum em breve. Na verdade, como o Guilherme comentou, existem muito poucos cursos de web services, mesmo os WS-*, que já são bem antigos.

Resolvi escrever esse post para tentar colher opiniões do pessoal quanto a um curso nesse assunto. Vocês se interessariam por um curso de REST? Será que esse curso teria muitos interessados ou a maioria dos desenvolvedores iria preferir a maneira autodidata mesmo? Para os que assistiram a alguma das minhas apresentações de REST, vocês acham que uma expansão do conteúdo com maior detalhamento e exemplos práticos bem explicados daria um bom curso?

A Concrete já ministra alguns treinamentos em produtos da BEA, então certamente haveria espaço para novos cursos de conteúdos interessantes. Eu gosto de fazer apresentações, mas nunca preparei um curso. Estou tentando participar de mais eventos, e também já pensei em atuar um pouco com treinamento técnico, mas ainda não me decidi sobre isso.

Opiniões são bem-vindas 🙂


Fotografia de um EJB 2.1

maio 29, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Fotógrafos muito talentosos conseguiram capturar uma imagem de um EJB 2.1:

EJB Stateful

O anúncio dessa fotografia foi feito no G1 e lá podemos ter maiores detalhes sobre esse EJB. Pela imagem, não restam dúvidas de que ele é bem Stateful.

No G1 o pessoal usou uma nomenclatura para leigos, e então chamaram esse EJB pelo seu nome fictício, de Rinoceronte Javanês.

As pessoas costumam fazer comentários maldosos sobre os EJBs, dizendo que eles são pesadões e com pouca agilidade. Este espécime nos comprova que isso não passa de intriga da oposição.

Infelizmente fui saber que os simpáticos Rinocerontes Javaneses estão em extinção, restando poucos exemplares no mundo. Talvez possamos contribuir com melhores condições de sobrevivência para os bichinhos, e darmos a eles mais alguns gigas de memória, a comidinha preferida deles. Não deixe esta espécie ser extinta, vida longa aos RInocerontes Javaneses!


Java Magazine 57

maio 27, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Já está nas bancas a edição 57 da Java Magazine. Nesta edição saem 2 artigos meus sobre o formato Atom.

O artigo maior apresenta o formato Atom e o seu protocolo de publicação, o AtomPub. Além desta apresentação, tentei indicar alguns pontos importantes que tornam interessante a sua adoção no desenvolvimento de serviços REST.

O artigo pequeno é no formato “Quick Update” da revista. Nele eu analiso a adoção do formato Atom em serviços REST e destaco os principais aspectos a serem considerados para se decidir pelo uso ou não do Atom.

O Atom e o AtomPub são muito interessantes, e mesmo que você não use diretamente o formato, tenho certeza de que ele te trará boas idéias para a implementação de serviços REST. Have fun!


Apresentação sobre REST no RioJUG

maio 19, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Caros amigos, na terça-feira dia 27/05 farei uma apresentação sobre web services REST no RioJUG.

Esta apresentação será semelhante à que fiz recentemente na Globo.com, mas acho que ficará um pouco melhor. Maiores informações sobre a apresentação podem ser vistas na página do grupo. Após a apresentação atualizarei este post colocando os slides.

Quem quiser/puder comparecer será muito bem-vindo 😉


Precisamos de um descritor de serviços REST?

maio 14, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Me perguntaram sobre isso na minha apresentação de REST na Globo.com e isso foi assunto de uma discussão interessante hoje no CEJUG. Como é um assunto que pode interessar a bastante gente e eu me interesso muito por web services, resolvi falar mais sobre isso aqui no blog.

Os web services WS-* possuem o WSDL (Web Services Description Language), um artefato amplamente aceito que descreve de forma padrão os serviços da aplicação. Ao especificar no WSDL quais são os schemas XML dos documentos que serão trocados e a cardinalidade precisa de cada elemento, conseguimos garantir que qualquer cliente que entenda o padrão estabelecido será capaz de interpretar os documentos e comunicar-se corretamente com os serviços. Além disto, a maturidade deste padrão traz a vantagem de que já existem geradores de clientes em várias linguagens a partir de um documento WSDL.

Entretanto, WSDL (bem como muita coisa em WS-*) é complexo. Um ser humano que tenha que analisar um WSDL grande perderá um bom tempo para entender o que está descrito no documento. Já REST não tem uma forma padrão de especificar os contratos dos serviços.

Embora a versão 2.0 da especificação WSDL permita descrever web services REST, os principais projetos open source da área como o Apache Abdera, Google Data API, Jersey e o Mule não utilizam esta forma de publicação. Não tenho conhecimento de nenhum projeto publicamente divulgado que faça uso do WSDL 2.0 para descrever serviços REST, e a adoção desta capacidade é baixíssima (se é que existe).

O projeto Jersey oferece opcionalmente o WADL, que é uma forma de descrever serviços REST. Confesso que ainda não olhei o WADL para ver se seria interessante usá-lo. Pelo que sei, entretanto, a adoção dele também é muito baixa.

Existe também o documento de serviços do AtomPub, que é bem interessante. Ele é um documento simples que lista quais são as coleções disponíveis e a localização das mesmas. O documento informa também quais são os MIME types aceitos em cada coleção.

Eu considero interessante que a aplicação ofereça uma interface simples de consulta dos serviços disponíveis. Não é obrigatório, mas quando a aplicação tem uma certa quantidade de clientes é bem legal ter isso para facilitar.

Em dois projetos que eu trabalhei, eu implementei um Servlet simples que listava todas as URIs disponíveis na aplicação, quais métodos HTTP são aceitos em cada uma das URIs e além disso um exemplo de XML manipulado em cada uma das URIs. Isso foi algo que eu achei bom o suficiente, e não tão custoso. Normalmente a documentação de verdade dos serviços fica em algum lugar como uma Wiki, ou uma página qualquer com a descrição detalhada de como interagir com os serviços.

A questão principal é que quando você segue as boas práticas de desenvolvimento REST, os seus serviços ficam muito mais claros para quem precisa se integrar. Por exemplo, eu trabalhei em um projeto crítico de integração com o Google esse ano. Tive que usar várias funcionalidades da Google Data API. A API deles é REST, e encapsula os dados com o formato Atom. Eles não oferecem nenhuma interface semelhante ao WSDL, eles simplesmente têm uma página com a documentação dos serviços.

Como eles seguiram as boas práticas de implementação REST, eu rapidamente aprendi a utilizar a API deles. Os protocolos de comunicação REST são bem semelhantes, e mais simples de entender do que qualquer coisa com WS-*. Pouco mais de 1 hora depois de olhar a documentação deles, eu já estava conseguindo me integrar com eles, com os primeiros exemplos.

O Guilherme fez uma observação interessante durante a discussão disso na minha apresentação no Tech Talk. Quando você segue as boas práticas e implementa um protocolo conciso e claro, de certa forma podemos dizer que a implementação se “auto-documenta”. É algo que podemos traçar um paralelo ao que acontece ao utilizarmos Domain Driven Design. Aproximando a linguagem do código do domínio de negócio, facilitamos a compreensão da aplicação por pessoas que nunca a tinham visto antes. Uma boa arquitetura de web services declarativos (REST) fica muito mais clara do que uma arquitetura de web services imperativos (WS-*). Isto acontece porque com REST o que fica em destaque são os Recursos (que representam conceitos claros do domínio), em vez de Operações.

É claro que as pessoas ainda terão que ler um pouco da documentação, mas como os conceitos em sua maioria já estarão “no sangue”, as dificuldades iniciais são menores do que com WS-*.

O Felipe Gaúcho comentou no CEJUG sobre a capacidade de gerar clientes automatizados com WSDL. Embora isso seja verdade, no meu ponto de vista isso é meio que um mito. Não conheço ninguém que faça integrações automatizadas sem depender de seres humanos. A motivação disso é clara. Integrações envolvem regras de negócio, e ninguém que eu conheço faz negócios automáticos, sem definir as regras 🙂

Existia o mito de que as aplicações “descobririam” serviços automaticamente com UDDI e se virariam para fazer as integrações, gerando os clientes automaticamente. Embora isso seja tecnicamente possível, na prática isso pra mim é uma viagem que serviria mais para desenvolvimento de inteligência artificial do que para web services propriamente 🙂

Embora esta precisão do WSDL seja um ponto positivo, eu tenho a convicção de que a clareza que temos ao usar REST supera e muito as vantagens de termos geradores de clientes automatizados. Quanto a WS-* x REST de uma maneira mais geral, tem uma frase que eu gosto de utilizar. WS-* é apenas overhead a não ser que você tenha informações relevantes nos seus cabeçalhos SOAP. Se você nunca se preocupou MUITO (veja bem, MUITO) com o que está indo nos seu cabeçalhos SOAP, provavelmente um protocolo REST seria mais interessante.

Tem uma opinião a respeito disso? Estou ansioso para conhecê-la! 🙂


HP compra EDS. Mas isso faz algum sentido?

maio 14, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Hoje foi anunciado que a HP está comprando a EDS. O valor divulgado da compra é de US$ 13.9 bi.

Li algumas notícias dizendo que este movimento da HP tem como objetivo fortalecer a empresa para competir com a IBM. Entretanto, tenho sérias dúvidas se isso terá sucesso. A HP tem muita força na venda de equipamentos, e também presta serviços de manutenção de infra-estrutura. Já a EDS é uma gigante na prestação de serviços de software, tanto na área de manutenção de infra-estrutura como no outsourcing de aplicações, e consultoria de uma maneira geral. Como algumas áreas das empresas claramente se sobrepõem, imagino que muitos empregos serão cortados.

A HP passará a ter uma estrutura gigantesca, mas ainda ficará atrás da IBM em termos de faturamento. Além disso, embora fortaleça a empresa na disputa com a IBM, não fortalece tanto. A IBM tem uma área enorme de produtos de software que a HP continuará não tendo. Será muito difícil para a HP ganhar espaço contra a IBM sem um braço de software forte. Principalmente na área de middleware, onde a IBM está muito forte. E além da IBM, a HP teria que brigar também contra a Oracle neste nicho, depois que ela comprou a BEA.

É bom lembrarmos que a HP não tem lá um bom histórico em compras. A aquisição da Compaq foi bem traumática e não teve custo-beneficio muito bom para a HP. O mercado americano também não reagiu bem a essa compra da EDS. As ações de ambas as empresas caíram razoavelmente, mostrando que a maioria das pessoas do mercado não achou este negócio uma boa idéia para as empresas.

Na minha opinião, a HP após esta compra ainda é uma empresa incompleta para competir com a IBM, Oracle e Sun. Antes dessa compra a HP não era tida como concorrente direta dessas empresas, mas agora ela é. Penso que para a HP ter realmente relevância nessa disputa, ela precisará de um braço forte de middleware, e uma boa pilha de software em geral.

Com o histórico que a empresa tem, duvido que ela se transforme nisso por conta própria. Na minha visão o que faz sentido é a HP comprar mais alguma(s) empresa(s), para conseguir complementar suas ofertas de serviços. Considerando a consolidação atual do mercado, acho que faria sentido que a HP comprasse a Red Hat, levando o JBoss de lambuja. Além disso seria interessante que eles contassem com algum servidor de BD na pilha, já que os concorrentes possuem isso (DB2, Oracle e MySql). Uma ótima opção seria comprar a EnterpriseDB, que oferece uma versão comercial do Postgres, o excepcional BD open source.

De todas as grandes aquisições que rolaram recentemente, esta da HP é a que menos faz sentido, pelo menos atualmente. Dependendo das ações que eles tomarem em seguida, esta compra pode ser uma boa jogada ou um episódio lamentável como a compra da Compaq. Torço para que a HP aumente seus já fortes vínculos com Linux e Open Source e compre a Red Hat para se apresentar firmemente como competidora de peso. E claro, continuo torcendo pelo sucesso do meu estimado Postgres 🙂