ANALISTA DE SISTEMAS
Projeto de 3 meses (prorrogável) em país da América do Sul
Fundamental: Inglês fluente
Desejável: Espanhol
Arquitetura SOA
Web Services + WSSE
XPath
XQuery
UML
Orientação a objetos
Modelagem de processos e indicadores (SLA)

Enviar currículos somente EM INGLÊS para:
fernanda.godoy@concretesolutions.com.br

Atenção: Enviar currículos preferencialmente até o dia 07/01/2010, pois as vagas precisam ser preenchidas rapidamente.

http://www.surveymonkey.com/s.aspx?sm=wKc7Ys_2frf39cs7hJ_2bewPYw_3d_3d

Fiquem à vontade para passá-lo adiante, quanto mais respostas forem coletadas melhor. O perfil do respondente não precisa necessariamente ser o de um desenvolvedor. Quaisquer profissionais que possuam experiência e saibam opinar sobre os benefícios de uma Arquitetura Orientada a Serviços para uma corporação serão bem vindos.

Agradeço aos que puderem participar. Como tenho bastante interesse na área, quem quiser discutir mais sobre o assunto é só entrar em contato.

Não vou comentar sobre a essência das idéias de Platão, para este fim eu recomendo demais a leitura do texto na Wikipedia. Mas vou traçar um paralelo para situações corriqueiras atuais que nos mostram que a natureza humana não mudou muito nesses mais de 2300 anos que nos separam de Platão

Desenvolvimento com Produtos x Desenvolvimento Customizado

Ao longo da minha carreira, já estive focado no desenvolvimento com produtos e no desenvolvimento customizado de software. Tive contato com uma variedade razoável de produtos e tecnologias, com diferentes visões para o mesmo problema, e abordagens diversas de construção de software. Hoje em dia fico muito feliz por ter traçado esse caminho, pois nunca ficarei aprisionado na caverna.

O desenvolvimento com produtos às vezes tem um efeito colateral sobre a maneira das pessoas lidarem com problemas de software. Os produtos são concebidos de acordo com a visão de algumas pessoas sobre uma determinada classe de problemas. A concepção envolve a análise e o raciocínio de alguns profissionais sobre o problema, e o ferramental para prover soluções ao mesmo.

Isto quer dizer que ao utilizar um produto você está “ganhando” o tempo de raciocinar sobre o problema, e também na construção da solução. É como diz o mantra: “Não reinventar a roda”. Eu concordo plenamente! Porém, quem lê meus textos ou me conhece sabe que eu tenho mais algumas coisas a dizer

Arquiteturas de Referência, Blueprints, Catálogos de Padrões

Em muitas ocasiões eu vi profissionais experientes que viviam do seu expertise em algum produto. Às vezes o cara já fazia aquilo há anos, e com muita competência. Entretanto, na maioria dos casos em que lidei com profissionais assim, eles tinham a forma de raciocinar “engaiolada” pelos produtos. A “arquitetura de referência“, o “blueprint do produto” ou o “catálogo de padrões” do mesmo. A abordagem do produto é o que geralmente orienta o raciocínio do indivíduo, e ele reluta bastante em fugir dessa zona de conforto.

Acontece, meus amigos, que o amadurecimento das pessoas tem tudo a ver com sair da zona de conforto. Para dar mais significado às minhas ponderações, eu vou destacar 2 domínios que eu conheço bem e tenho boa experiência: Portais corporativos e SOA (eu sei que o termo está meio condenado, mas permitam-me a liberdade de usá-lo de forma ilustrativa)

“O que você QUER” x “O que você PRECISA”

Sobre SOA, o principal objetivo de negócio é facilitar a integração de várias aplicações/serviços heterogêneos. Este objetivo pode ser atendido de várias formas, e há muitos produtos focados em prover o “ferramental necessário”. A questão começa a ficar sinuosa quando se discute “O que você QUER” x “O que você PRECISA“. Se você fica “engaiolado” em um produto, vai tender a achar que PRECISA dos recursos oferecidos pelo mesmo, e que a abordagem dele é necessariamente correta.

Normalmente os problemas técnicos de SOA caem em uma combinação de topologias dos Enterprise Integration Patterns. Um profissional maduro neste ramo precisa ter familiaridade com estas topologias de integração propostas. As idéias se aplicam em praticamente qualquer problema de SOA, e te dão uma visão de arquitetura desvinculada de uma implementação específica. Não se prenda à visão do produto, conheça a natureza do problema.

Polyglot Programming

Neal Ford escreveu sobre esta questão um tempo atrás, e essa idéia também está presente no Pragmatic Programmer. Conhecer diferentes linguagens de programação, outros paradigmas de desenvolvimento e outros produtos é sempre importante.

Além de raciocinar sob diferentes pontos de vista, você consegue absorver muitas idéias legais fazendo isso. Inúmeras vezes eu adquiri novas idéias ao conhecer diferentes produtos. Isso se soma às suas ferramentas de raciocínio e amadurece sua visão sobre o problema.

Um programador poliglota consegue aprender novas linguagens, produtos e formas de pensar com muito mais facilidade. Pensar fora da caixa é importantíssimo. Para evoluir essa habilidade é fundamental experimentar diferentes pontos de vista, e ganhar massa crítica.

Bons produtos ajudam a te dar massa crítica

Eu converso bastante com alguns amigos sobre software em geral, e um tema recorrente é a análise de projetos que deram certo e projetos que fracassaram.

Para ter sucesso em um projeto de software, é fundamental que pelo menos um dos membros do time tenha massa crítica avançada sobre o domínio do problema em questão. Se nenhum dos membros tiver, a melhor coisa a se fazer é avaliar um produto bom para o problema que se quer resolver.

Isso não quer dizer que o produto será a solução final adotada, ele pode servir apenas para te dar massa crítica antes de escolher o caminho.

Tendo massa crítica, utilize as facilidades dos produtos a seu favor

Quando você já conhece o domínio e consegue pensar fora da caixa, dá para ter ótimos ganhos de produtividade usando bons produtos. Por exemplo, eu tenho trabalhado muito com portais corporativos, com variadas implementações. Quando analiso um produto de portal, eu verifico, entre outras coisas:

• Plataformas/tecnologias que ele exige/permite usar
• Disponibilidade de wiki, fórum, blog, calendário, etc
• Personalização de estilos/layouts (o cliente quer um portal com a cara dele, não com cara de produto)
• Facilidade de extensão
• Repositório de conteúdo
• Integração de aplicações

Já conhecendo bem os requisitos na construção de um portal, eu consigo em alguns dias analisar um produto ou implementação customizada de portal e avaliar estes critérios acima. O mundo ideal é trabalhar com um portal que te dê resultados rápidos, mas sem dificultar muito que você o ajuste da forma que o cliente deseja.

Não caia no mito da caverna, explore sua criatividade

Fuja dos dogmas, questione os hypes. Não limite a sua visão aos recursos de um produto. Enxergue o que é a complexidade natural do problema e o que é a complexidade introduzida por humanos ou produtos. Não permita que os produtos engessem a sua criatividade. Esteja sempre no controle, e saia da caverna!

Sobre a migração, foi muito fácil. O Wordpress é uma ótima ferramenta de blogs/sites e é muito fácil adaptar um site existente para o Wordpress. Contando as páginas do site em português e em inglês são cerca de 50 páginas, e foram cerca de 20 horas de trabalho no total. Agora todo o conteúdo do site é facilmente publicável e ficará mais mais fácil dar à Concrete uma presença adequada na web.

Já havia um tempo que eu não estava satisfeito com o site da Concrete, e depois que saí da Globo.com e fui para a sede, ficou mais fácil resolver isso. Já conversamos sobre várias coisas que podem e devem melhorar, e em breve creio que estarei contente com o site.

Duas coisas que não me agradam visualmente são a legibilidade do site e aquele menu em Flash, que é um limitador ao acesso. Vamos ajustar o visual do site para deixá-lo mais agradável para a leitura e retirar a navegação com Flash.

Além da questão visual, o conteúdo técnico está muito defasado. A empresa tem feito muitos projetos interessantes e há vários novos cases de sucesso que precisam ser incluídos no site. Além disso, eu gostaria bastante de colocar algumas demonstrações do que temos feito. A inclusão deste tipo de conteúdo trará uma visão muito mais objetiva do que os clientes podem esperar de retorno ao contratar os serviços da empresa.

Uma última adição importante será uma seção com conteúdo editorial de qualidade. Desde que saí da Globo.com estou atuando como consultor em projetos de pré-venda, e a maioria das coisas que eu poderia publicar fazem mais sentido que a Concrete publique. Assim, em breve eu recomendarei aos que se interessam pelos textos deste humilde autor que acompanhem também o site da Concrete

A Concrete tem profissionais excepcionais e estou certo de que publicaremos conteúdo de alta qualidade na nossa área de atuação. As principais coisas com as quais estou envolvido atualmente são portais corporativos, aplicações colaborativas, BPM e integração de aplicações.

À medida que as coisas forem progredindo no site e no meu trabalho, publicarei mais por aqui e no site da empresa.

Esta JSR é bastante interessante, e já pude ver nela o tratamento de coisas muito úteis. De principal destaque para mim está a abordagem de mapeamento de URIs em recursos e métodos e a questão do mapeamento de classes Java para dados com diversos content-types.

Em relação às URIs, há a definição de regras para mapear URIs em classes e métodos, instanciando as classes necessárias e invocando os métodos adequados. Suponha por exemplo uma requisicao HTTP PUT na URI /usuario/16728/produto/228/configuracao/. Em um protocolo definido por mim, isto representaria uma atualização nas configurações do Produto 228 para o Usuário 16728. Um ser humano consegue entender isso sem tantos problemas, mas uma implementação manual destes mapeamentos e o parsing dos parâmetros podem ser coisas bem trabalhosas. A JSR 311 utiliza várias annotations para conseguir definir o encadeamento de classes e métodos a partir da URI utilizada, e isto faz com que você consiga desenvolver em Java normalmente e ter as suas classes instanciadas e invocadas com URIs tão flexíveis quanto você queira. Muito bom ter isso como recurso, pois implementar na mão é bem trabalhoso.

Outra coisa muito interessante é a maneira de mapear classes Java para diversos content-types. Isso é algo fundamental para uma implementação Restful com bastante flexibilidade E possivelmente alta performance. A idéia por trás disso é que o servidor recebe uma requisição de um cliente e verifica quais são os content-types que o cliente aceita. Com base nestas informações, o servidor escolhe a forma que irá utilizar para transmitir os dados.

Suponha por exemplo que uma aplicação PHP está se comunicando com seu servidor, e ele lhe informa que aceita os content-types text/plain, text/xml e application/json. O servidor pode escolher qual formato utilizar para o envio e possivelmente o envio com formato json facilita bastante a aplicação PHP. Este mesmo servidor pode receber requisições de uma outra aplicação Java, que preferencialmente receberá do seu servidor um stream binário, que terá a melhor performance de todas as opções.

O uso desta abordagem dos mapeamentos em content-types permite que sua aplicação tenha ao mesmo tempo alta interoperabilidade e alta performance. Você conseguirá se comunicar com várias plataformas e aplicações diferentes, e continuará tendo a opção de alta performance, caso seja uma aplicação da mesma plataforma. Você não consegue isso com web services WS-*. Eles não têm tamanha flexibilidade.

O meu próximo passo agora será analisar com detalhes o Jersey, a implementação de referência desta JSR. A especificação em si ainda está um tanto crua, pois ainda é um early draft. Já pude ver vários pontos interessantes, mas a definição ainda está sujeita a muitas modificações. Vou avaliar agora o que o Jersey já oferece e torcer para que ele já tenha componentes fáceis de usar e flexíveis. A proposta dele é excelente, vamos ver se a implementação consegue oferecer estes recursos sem amarrar muito as decisões de projeto.

A nice concept present in the original development is the use of Application Connectors. Through these connectors, other applications get notified of events that happened in the Register application. An example is: when a new subscriber (a paying user) is created, a connector sends the notification to another application in order to create the subscriber’s mailbox in the company’s external mail provider. Another example is: when a user gets provisioned in the blogging service, another connector sends a notification to the blogger application, that does what it needs in order to create the user’s directory and quota on the file server.

Although i like this concept, it currently has some problems. This connector’s invocation is done explicitly by the Register application. The Register application knows that a new subscriber must receive a new mailbox, and it needs to call a given connector to do this. This is my biggest concern with the current implementation. I strongly believe that an application that creates users must not know anything about mailboxes. In the current structure, when a new application ABC must be notified of events in application XYZ, application XYZ must be modified to invoke a new connector. This doesn’t please me at all. Let me explain a solution that pleases me more

To explain my idea, I’ll propose some examples involving Google and its services. As we all know, Google offers several different services, all of which can be accessed using the same Google account. When you register at Google, you receive a mail account. Let’s suppose that Google Register application sends a new entry to an Atom feed every time a new user is created. This way, every user creation is present on the Atom Feed. If an application (for example Google Mail) needs to be notified of the creation of new users, it just needs to subscribe to the Register’s Atom feed.

Let me propose a richer example now. Let’s say Google starts to offer some super cool software development services. If you’re a developer, you can ask them to give you a “development account”. This development account would give you access to a Subversion repository, a Bugzilla project and a MySql database. Each of these would be an independent service offered by them, subject to change at any given time. The activation of “development accounts” could also populate an Atom feed.

This way the Subversion, Bugzilla and MySql services could be subscribers of the feed, doing everything they need when a new development account is activated, in asynchronous manner. The application that activates the development account has no knowledge of any other services. If Google wants to offer new services such as a Maven repository or a Continuous Integration environment, no problem. The new services would just subscribe to the Atom feed and do whatever they need when a new account is activated.

If Google wants to offer a free development account and a non-free account with better features, there could be another Atom feed for the activation of the paying accounts or maybe updates to the same existing feed. The Register application would know only about registrations, and other components could be easily plugged and unplugged from this process, without modifications on the Register application. Ah, and worth mentioning… totally decoupled from any specific platform. I don’t know how to implement any kind of messaging more decoupled than that.

This is much much better than the way our Register application sends notifications currently. And I’ll be pretty happy once we manage to do this, it’ll be so cool!

By the way, these Google’s software development services would be awesome. My friend Bairos kindly provides me Subversion and Trac services, but he doesn’t have Google’s bandwidth Let’s hope Google gets to know about this and starts offering these services. It’d be amazing!