Apartir do dia 04 de setembro eu faço parte de mais uma estatística do Brasil. A lista de desempregados. Isso mesmo!!! Estou saindo da Tata Consultancy Services. Passei quase um ano nesta empresa e aprendi muito com excelentes colegas de trabalho.

O motivo da saída é um intercâmbio de 03 meses no Canadá, mais específico em Vancouver. Espero poder praticar e melhorar meu inglês pois um bom conhecimento do inglês é muito importante na área de TI. Estou indo em busca de mais este conhecimento.

Bem… quem quiser me ajudar.. em dezembro estarei procurando emprego…rs

Linguagem dinâmica, também conhecida como linguagem de scripting, ainda é algo obscuro para a grande maioria dos desenvolvedores. Entender e aplicar seus conceitos é algo que pode causar espanto e muitas dúvidas. Porém, é importante conhecer as vantagens e destantagens deste tipo de linguagem, saber quando é válido ou não a sua utilização no desenvolvimento de sistemas.

Estas linguagens são linguagens de alto nível, a grande maioria com tipagem dinâmica e com um Protocolo de Meta-Objeto (Meta-Object Protocol), ou MOP. Estas duas características proporcionam muitas facilidades e um enorme poder no desenvolvimento. Porém, quando não usadas com cuidado, podem causar grandes problemas.

Tipagem dinâmica é muito criticada pela comunidade de desenvolvedores, principalmente porque “escondem” alguns erros em tempo de desenvolvimento (compilação). Linguagens dinâmicas não são compiladas, portanto tipagem dinâmica faz todo sentido. Porém, existe algumas linguagens dinâmicas que utilizam de tipagem estática, como Groovy, para utilizar de técnicas como overloading de métodos e de construtor.

Meta-Object Protocol sem dúvida é a grande vantagem das linguagens dinâmicas. Em linguagens de programação como java, os objetos armazenam seus métodos e seus atributos. Com MOP, cada objeto tem um meta objeto associado e é no meta objeto que ficam os métodos. O objeto é responsável por armazenar seu estado. A grande vantagem é a possibilidade de alterar o meta objeto em tempo de execução e adicionar novas funcionalidades nos objetos.

Com o surgimento do Ruby e do framework Ruby on Rails, as linguagens dinâmicas vem ganhando força. Muitas empresas que utilizam metodologias agéis, estão aderindo a este tipo de linguagem, principalmente ao Ruby on Rails. Portanto, é visível que as linguagens dinâmicas e principalmente a linguagem Ruby poderá ser o próximo “boom” no desenvolvimento de software.

No último final de semana participei do evento falando em java 2009. Como sempre, o pessoal da Caelum arrebentou. As duas paletras do Jim Webber foram sensacionais.

As dicas que o Sérgio Lopes deu sobre o hibernate também foram excelentes. Concordo com ele que o grande problema do hibernate são os desenvolvedores que não se preocupam em utilizá-lo adequadamente.

Outra grande novidade foi o anúncio do vRaptor 3. Particularmente, eu sou fã deste framework.

Estou ansioso para o lançamento do livro que o pessoal da Caelum está escrevendo.

Infelizmente,  ainda não foi este ano que ganhei o Wii….

Tive o prazer de participar de mais um grande evento. Fico feliz por ver eventos bem organizados e com palestrantes de alto nível no Brasil.

Cada vez mais posso comprovar que a dupla SCRUM e RoR está muito forte e tem tudo para revolucionar o mercado de TI.

Destaco as palestras do Fabiano Milani e do Guilherme Chapiewski. Gostei muito das dicas do Guilherme sobre como se tornar um bom profissional de TI.

Resumindo, foi um bom esquenta para o Falando em Java 2009.

Post bem rápido.
Apenas para contar que agora estou no twitter.

Quem quiser me seguir:
http://twitter.com/celodemelo

Um recurso muito interessante e extremamente útil na linguagem Ruby é o Módulo (module). O módulo possui duas funcionalidades: namespace e mixin.

Namespace

O Módulo pode ser utilizado para prover um namespace para os componentes, mantendo-os mais organizados evitando possíveis problemas de sobrescrita. Veja o exemplo abaixo:

Devido às características dinâmicas da linguagem, o método verify da classe AccessControl foi sobrescrito e o resultado do código será ‘verify 2′. Esta sobrescrita pode ser intencional ou não.

Para deixar o código mais organizado e prevenir que o componente seja sobrescrito por engano, pode-se utilizar o módulo como namespace:

Para referenciar elementos que estão dentro de um módulo, usa-se Modulo::Elemento

Desta forma, a sobrescrita por engano já está evitada. O código abaixo irá imprimir:

verify
verify 2

Mixin

Mixin é um recurso interessante. Um módulo pode ser incluído em uma classe. Quando isso ocorre, a classe passa a ter os métodos declarados no módulo. Veja o exemplo abaixo:

A classe AccessControl não possui o método “testing”. Quando o interpretador do ruby não encontra um método um um objeto, o método method_missing é invocado.

No exemplo, o módulo MethodMissing foi incluído dentro da classe AccessControl. Desta forma, a classe AccessControl passou a ter os métodos definidos no módulo.

O código imprime:
verify 2
The method ‘testing’ doesn’t exist!!!!

—-

O conceito de módulo é sem dúvida um recurso muito interessante e bastante utilizado pelo framework Ruby on Rails.

Quem gosta de Rails agora tem uma revista onde será possível compartilhar conhecimentoe novas idéias. A revista é Canadense e em breve será disponibilizado uma versão em PDF da mesma.

Creio que já passou da hora de uma iniciatia deste porte aqui no Brasil.. O que vocês acham?

Hoje em dia o mercado de trabalho oferece muitas oportunidades e talvez seja por isso que existem tantos profissionais que não se preocupam em aprender novas tecnologias. 

Quais profissionais que você conhece já parou pra estudar outro framework? Quantos conhecem EJB? Spring? JPA? VRaptor? Waffle? JSF? etc

Esta falta de interesse dos profissionais pode ser um motivo para que a maioria das empresas continuem utilizando o famoso Struts 1.x.

Tenho alguns amigos que com 3 anos de experiência chegaram a um cargo de Desenvoledor Sênior. Outros com 05 anos que ainda são plenos. Na minha opinião, o que distingue um profissional de TI é o seu conhecimento e não só seu tempo de experiência. Felizmente, na nossa área, o conhecimento pode ser adquirido sozinho. Você pode aprender  JSF, JPA, EJB, Spring e inúmeras outras tecnologias em casa. Basta força de vontade de muita dedicação.

Portanto, não fique reclamando por falta de promoção. Qual o seu valor no mercado de trabalho? Qual o seu diferencial? O que você está fazendo para merecer um aumento? Seja curioso, estude novas tecnologias. Faça como Leonardo Veríssimo, antecipe-se às novidades.

Enfim, vou resumir este post com uma frase que gosto muito.

“Seu sucesso só depende de você!!!”

Capa Head First Rails

Ruby on Rails é uma tecnologia que eu sempre esteve na minha lista de estudos.

Dediquei um bom tempo estudando ruby e quando me achei preparado, comprei o livro Head First Rails para iniciar no mundo rails. Sou fã da série Head First e sem dúvida aguardei ansioso a chegada do livro.

Talvez pela minha grande expectativa, me decepcionei um pouco com o conteúdo do livro. Em algumas situações ele foi um pouco repetitivo deixando de explicar alguns detalhes sobre o funcionamento do framework.

O capítulo sobre a integração com Google Maps é um pouco confuso. O REST é apresentado em poucas páginas apenas no final do livro. Infelizmente faltou conteúdo no livro.

Porém nem tudo está perdido, o conteúdo sobre AJAX está bem claro e simples de entender. O funcionamento dos controllers, views, validações e ActiveRecord também foi esclarecedor.

Bem, apesar de não ter ficando 100% satisfeito, o livro me abriu as portas pra uma nova forma de desenvolvimento web. Muito mais produtiva e sem perder a qualidade. 

railers << “Marcelo Madeira”

Programar é uma tarefa ardua e programar um código que siga os bons princípios é mais ainda. Na correria do dia a dia, acaba-se esquecendo das boas práticas e o resultado é um código “macarrônico” totalmente sem padrão. Um colega sempre dizia “Programar bem é uma arte!!!”.

Neste post será abordado um princípio muito importante para sistemas orientados a objeto, o desacoplamento do código. Todo o artigo será baseado no estudo de caso de uma pequena API para envio de malas diretas.

Abaixo segue a modelagem do problema:

A classe mala direta é responsável por enviar uma mensagem a um grupo de destinatários. Para isso, ela utiliza do componente “EnviadorEmail”. Segue a implementação da mesma:

O exemplo acima demonstra um exemplo de código altamente acoplado. Isto se caracteriza pela utilização direta de uma classe concreta (new EnviadorEmail()), acarretando em um problema muito grave: Torna-se impossível trocar a forma de envio da mala direta em tempo de execução pois o código está altamente acoplado com o componente EnviadorEmail.

Desacoplando o código:

Desacoplar um código consiste em montar um design que o deixe mais fléxivel a mudanças. Programar um código desacoplado garante uma maior qualidade e facilita futuras mudanças.

Erich Gamma, o criador do Eclipse, JUnit e co-autor do famoso livro “Padrões de Projeto” disse em uma entrevista: “Program to an interface, not an implementation”.

Programar para interface deixa o código mais flexível, permitindo trocar a implementação de um componente em tempo de execução. Refatorando o nosso design para utilizar interfaces:

Refatorando o código da MalaDireta:

Quando um código depende de uma interface, pode-se decidir em tempo de execução qual a implementação será utilizada. Um exemplo pode ser verificado na imagem abaixo:

Porém ainda existe um pequeno acoplamento no método enviar. O método ainda precisa dar o new em uma implementação, o que o torna fortemente acoplado a ela. O ideal é que outro componente tome a decisão de qual implementação criar. A função da MalaDireta é enviar sua mensagem. Não é sua responsabilidade saber de qual forma.

Factory

O design pattern Factory tem como função separar a lógica de criação de objetos em um outro componente (fábrica). No exemplo acima, pode-se ter o EnviadorFactory. Uma forma de implementação do factory pode ser visto abaixo:

Refatorando a classe MalaDireta para utilizar a fábrica:

Utilizando a fábrica foi possível separar a lógica de criação da forma de envio das malas diretas, porém o método agora ficou acoplado com a fábrica. Utilizar fábricas solucionou apenas parte do problema, como desacoplar totalmente o código da MalaDireta???

Inversão de Controle

Martin Fowler escreveu em seu site um artigo muito interessante sobre Inversão de Controle (IoC). O artigo levanta uma interessante discussão: Qual controle da aplicação está sendo invertido???

A inversão de controle consiste em uma mudança na forma como são criadas as dependências dos objetos. No exemplo utilizando fábricas, o método “pede” para a fábrica uma dependência. Na visão da IoC, não é mais o código que pede por uma dependência, ele apenas declara que precisa de determinado componente e ele é disponibilizado.

Seguindo este princípio, Martin Fowler questiona se o nome correto para a Inversão de Controle não seria Injeção de Dependência. Segundo ele, a mudança afeta a forma como são gerenciadas as dependêcnias que agora são injetadas nos objetos, eliminando assim o uso da palavra new no código:

A classe acima declara em seu construtor que precisa de uma implementação de IEnviador. Ou seja, alguém irá “injetar” esta dependência. O método enviar não sabe pra onde está enviando sua mensagem. O código está totalmente desacoplado!!!!

Exemplo de um código que utiliza a MalaDireta:

Com um código totalmente desacoplado, fica fácil criar testes unitários e consequentemente aumenta a qualidade do código.

Infelizmente não são todos os desenvolvedores que possuem esta preocupação. Mas espero que este pequeno artigo tenha gerado uma grande reflexão sobre como construir componentes de verdade.

Sempre que for codificar, lembre-se da frase: “Programe para interfaces e não para implementações!”.