You are currently browsing the archives for the engenharia category


Você deveria considerar Erlang para seu próximo grande projeto

Ao ler o título deste post, talvez você esteja se perguntando: por que eu deveria considerar Erlang para meu próximo grande projeto? Bem, meu objetivo com este post é te apresentar alguns importantes motivos para fazer isto.

Erlang nasceu no laboratório de ciência da computação da Ericsson na década de 1980, influenciada por linguagens como ML, Ada, Module, Prolog e Smalltalk, quando um time de três cientistas – entre eles, o grande Joe Armstrong receberam a missão de descobrir qual seria a melhor linguagem de programação para escrever a próxima geração de sistemas de telecom. Após dois anos de investigação e prototipação, estes cientistas descobriram que nenhuma linguagem era completa o bastante para tal objetivo e, conclusivamente, decidiram criar uma nova linguagem. Nasceu então Erlang, the Ericsson Language.

De lá pra cá, Erlang tem sido evoluida e usada para escrever grandes sistemas críticos, porque é exatamente nesse cenário que Erlang faz mais sentido. Se seu projeto é construir um sistema crítico, altamente tolerante a falhas, com disponibilidade 24×7 e veloz como o papa-léguas, sim, Erlang é para você. Mas se não é bem esta sua necessidade, se você quer apenas construir um pequeno sistema, com baixa concorrência, poucos usuários, pouca necessidade de performance e possibilidade de passar horas down em manutenção, não, você não precisa de Erlang. Que tal Basic?

Diferente de algumas linguagens que nascem para encontrar um nicho, Erlang nasceu com um problema a ser resolvido, com requisitos a serem atendidos. Tolerância a falhas, concorrência realmente pesada, computação distribuída, atualização da aplicação sem derrubá-la, sistemas de tempo real, este é o nicho de Erlang; foi para isto que Erlang nasceu.

Quem usa Erlang atualmente?

Além da Ericsson, é lógico, há algumas outras grandes empresas e projetos usando Erlang, como por exemplo:

Facebook, no backend de seu sistema de chat, lidando com 100 milhõs de usuários ativos;
Delicious, que tem mais de 5 milhões de usuários e mais de 150 milhões de bookmarks;
Amazon SimpleDB, o serviço de dados do seu poderoso EC2;
Motorola, CouchDB, RabbitMQ, Ejabbed, etc.

Ok, mas Erlang é propriedade da Ericsson?

Não, felizmente, não. Em 1998 a Ericsson tornou Erlang open source sob a licença EPL.

Quer mais uma boa notícia? Você não precisa de um servidor de aplicações para rodar sua aplicação Erlang, nem mesmo uma pesada IDE para escrevê-las. Tudo o que você precisa é de uma distribuição de Erlang para sua plataforma, seja Mac OS X, Linux, Windows, Solaris, ou qualquer outro sistema Unix-like, que traz consigo máquina virtual, compilador e vasta bibliotéca de módulos muito úteis – além do banco de dados Mnesia; e um editor de textos de sua preferência TextMate, por exemplo, tem um ótimo bundle para Erlang.

Algumas características de Erlang

1- Expressividade e beleza

Há quem diga que não, mas Erlang é uma linguagem muito bonita — ao menos pra mim. Dado as já citadas influências de Erlang, ela é uma linguagem bem expressiva e declarativa, que encoraja a escrita de código simples e objetivo, o que certamente torna seu código fácil de ler, de escrever e de organizar [em módulos reutilizáveis]. O snippet abaixo é um exemplo de implementação do famoso fatorial:

-module(sample1).
-export([fac/1]).

fac(0) -> 1;
fac(N) -> N * fac(N-1).

2- Forte uso de recursividade

Isto certamente é uma herança da veia funcional de Erlang que torna o código muito menos imperativo e mais declarativo. Mas além da beleza declarativa óbvia, é importante saber que Erlang foi projetada para lidar com iterações recursivas gigantescas sem qualquer degradação – e sem estourar o “heap” de memória.

3- Livre de efeito colateral

Uma das grandes capacidades dadas por Erlang é a construção de sistemas altamente concorrentes rodando em processadores com multiplos núcleos. Isto não combina nada com efeito colateral, por isso, em Erlang, uma vez que um dado valor tenha sido atribuído a uma variável, esta não poderá mais ser modificada – ou seja, estão mais para o que conhecemos por constantes do que para o que conhecemos por variaveis.

Se você já escreveu código concorrênte sabe o quanto tê-lo livre de efeitos colaterais te faz livre de dores de cabeça. Poucas coisas são tão deprimentes quanto debugar código concorrênte repleto de efeitos colaterais.

4- Pattern matching

Pattern matching em Erlang é usado para associar valores a variáveis, controlar fluxo de execução de programs, extrair valores de estruturas de dados compostas e lidar com argumentos de funções. Mais um ponto para código declarativo e expressividade. Vejamos o código abaixo:

-module(sample2).
-export([convert_length/1]).

convert_length(Length) ->
    case Length of
        {centimeter, X} ->
            {inch, X / 2.54};
        {inch, Y} ->
            {centimeter, Y * 2.54}
    end.

Fala por si, não?

5- Concorrência baseada em passagem de mensagens (a.k.a. Actors)

Acho que concorrência baseada em passagem de mensagem entre atores é uma das features mais populares de Erlang. Vejamos o porque com o famoso exemplo do Ping-Pong:

-module(sample3).

-export([start/0, ping/2, pong/0]).

ping(0, Pong_PID) ->
    Pong_PID ! finished,
    io:format("Ping finished~n", []);

ping(N, Pong_PID) ->
    Pong_PID ! {ping, self()},
    receive
        pong ->
            io:format("Ping received pong~n", [])
    end,
    ping(N - 1, Pong_PID).

pong() ->
    receive
        finished ->
            io:format("Pong finished~n", []);
        {ping, Ping_PID} ->
            io:format("Pong received ping~n", []),
            Ping_PID ! pong,
            pong()
    end.

start() ->
    Pong_PID = spawn(sample3, pong, []),
    spawn(sample3, ping, [3, Pong_PID]).

Neste pequeno snippet podemos observar algumas características de Erlang já citadas neste post, tal como pattern matching na captura das mensagens e recursividade no controle das iterações.

Agora, falando do aspecto concorrente em sim, algumas coisas são particularmente interessantes aqui:

a. Em Erlang, a concorrência acontece entre processos leves, diferente de linguagens como C++ e Java, que baseiam sua concorrência em threads nativas de sistema operacional [caríssimas];
b. Em Erlang, há um tipo de dado chamado PID, o qual é o identificador do processo paralelo (mais conhecido como Actor) e para o qual as mensagens podem ser enviadas.

Releia o código acima com estas informações em mente e veja como concorrência em Erlang é algo completamente descomplicado e natural. Depois, pense no mesmo código implementado em C#, Java ou C++.

Gostei de Erlang, há algum livro para eu começar a estudar?

Sim, há dois livros excepcionais. Um, do próprio criador da linguagem, Joe Armstrong:

E outro de Francesco Cesarini e Simon Thompson:

Além disso, há o próprio material on line que é muito bom e barato. :)

Conclusão

Erlang possui muitas outras características e informações bem interessantes, mas que me falta espaço neste post para citar e apresentar, senão ele ficará absurdamente gigantesco para o meu gosto. Mas acredito que pelo que já apresentei até aqui, você já tenha motivos suficientes para pensar em Erlang com carinho e conciderá-la para seu próximo grande projeto.

Em breve devo escrever algo sobre OTP, já que neste post apresentei características mais inerentes à linguagem em si e nem tanto sobre a plataforma.

Até mais!

Tem gente que acredita em cada coisa

Não é de hoje que esbarramos aqui e ali com artigos em blogs e revistas trazendo revelações – que mais parecem vindas do além – sobre verdades e mentiras no desenvolvimento de software.

Esse capitulo está presente desde sempre. Quem é que não conhece pelo menos uma ou duas, aham?

Há alguns anos:

“Java é lento!”

Há alguns meses:

“Ruby é lento e Rails não escala!”

Isso só pra citar duas das pérolas da velocidade (em nosso tempo).

Hoje mesmo li um post que reune e desbanca algumas dessas revelações – do além -, que algum “guru” do desenvolvimento de software proferiu e acabou caindo na graça do povo. Risada na certa. Vale a pena ler, mesmo que você já conheça todas. :)

E você, quais são as verdades e mentiras do desenvolvimento de software que você acha mais engraçadas, descaradas e descabíveis?

Hierarquias são inteligentes nas “pontas”

Este é o titulo de um post fantástico do Carlos Vilella, que o Rodrigo Yoshima traduziu, e que eu não poderia deixar de citar aqui no meu blog.

Leitura obrigatória!

Comunidade Ágil a todo vapor no Brasil

É muito animador ver o quanto a comunidade ágil tem crescido e se fortalecido no Brasil. A pouco recebemos a notícia do grande evento que acontecerá em outubro, o Falando em Agile 2008, promovido pela Caelum. Treinamentos e workshops acontecem todos os meses Brasil à fora – basta você acompanhar, por exemplo, o blog do Alexandre Magno e do Rodrigo Yoshima, pra saber quando acontecerá o próximo. E agora, mais recentemente ontem, o Manoel Pimentel, editor chefe da revista eletrônica Visão Ágil, postou no GUJ a notícia do lançamento do Blog Visão Ágil.

Iniciativas como esta mostram o quão notório já é o crescimento das agordagens ágeis de desenvolvimento de software no Brasil.

Pratico desenvolvimento ágil em meu trabalho diário há algum tempo, e sei o quando é bom trabalhar assim – sob todos os aspectos. Mas sei também que não é fácil vender essa abordagem; muito menos fazê-la acontecer como deve ser. Contudo, com a comunidade mostrando a cara, e mais ainda, mostrando seus próprios resultados e experiências reais, certamente mais e mais empresas darão a si mesmas a chance de ver o quanto ser ágil é bom!

Imagine o dia que todas as empresas adotarem abordagens ágeis.
Não é difícil, não.
Nada de gantt chart ou gerente alienado,
Nada de comando/controle, só a liberdade de programar, testar e implantar.
Imagine todos os programadores, clientes e empresas vivendo em paz.
Somente a paz!

Você pode me achar um sonhador,
Mas não sou o único.
Espero que você se junte a nós,
E o Mundo do Desenvolvimento de Software será um só.

Conhece esta canção? Nada mau para o momento… rsrsrs

Você precisa de Matriz de Rastreabilidade?

Acabei de ler um post bem legal do Phillip Calçado que você também deveria ler, caso já tenha sido questionado sobre Matriz de Rastreabilidade. Caso “ainda” não tenha sido questionado quanto a isso, não tem problema, leia mesmo assim, porque a sua hora vai chegar! rsrsrs

Nova turma do Agile Requirements Workshop

Em maio participei da primeira turma do Agile Requirements Workshop, e não me arrependi, foi um dinheiro bem gasto investido.

Agora, Alexandre Magno e Adail Retamal estão de volta, promovendo uma nova turma deste bem-sucedido workshop.

Se eu fosse você, não perderia!

JRuby ou Groovy?

Não, não quero começar nenhum flame war em torno de JRuby e Groovy.

O que ocorre é que ontem um cara que tem um blog legal, o Diego, fez um comentário num de meus posts que me fez pensar a respeito… Até agora…

Na hora, sinceramente, não tive nada de muito substancial para responder, porque ainda não havia pensado a respeito. Mas tenho que confessar que isso ficou martelando a minha cabeça o tempo todo… Existe alguma vantagem de se usar Groovy invés de JRuby?

Bem, lendo e pensando a respeito, cheguei a algumas simples conclusões:

Se você tem familiaridade com Java e quer permanecer 100% no ambiente Java, sem a perspectiva de migrar, Groovy é a melhor opção pra você.

Porque a sintaxe de Groovy é muito parecida com a de Java; Groovy traz consigo uma porção de vantagens de uma linguagem OO moderna e dinâmica, como meta-programação, duck type, e closures; e você ainda pode programar usando objetos Java e Groovy numa mesma classe, de forma totalmente transparente (já que .groovy ao ser compilado se transforma em um .class qualquer).

Só que, mais uma vez: Não há qualquer possibilidade de se rodar código Groovy fora de ambiente Java, porque Groovy foi especificamente criada para ser uma “alternativa” à linguagem Java.

Se você quer que seu código seja portável para outras plataformas de runtime, tal como .Net, por exemplo, JRuby é o melhor pra você.

Acho que este é um dos fatores primordiais na escolha de JRuby invés de Groovy. Porque o fato da sintaxe de Groovy ser próxima à de Java, sinceramente, pra mim não quer dizer nada – aprender uma nova sintaxe não é coisa de outro mundo; e é até legal. Agora, portabilidade, isto sim faz a diferença – quando necessário, claro.

Você pode escrever, por exemplo, uma aplicação Ruby on Rails comum e coloca-la para rodar em um web container Java, sem muito esforço. Aliás, se você estiver usando o NetBeans, ele faz isso pra você em um ou dois cliques. E se num dado momento decidir rodar, sei lá, num Mongrel, tudo bem, você pode fazer isso sem problema algum. Isto é fantástico!

Se você quiser se manter 100% compatível com a MRI, isto é totalmente possível, porque JRuby é uma implementação completa de Ruby para a plataforma Java. E se você quiser aproveitar algum código escrito em Java, você também pode fazer isto – mas neste caso, claro, sacrificando a portabilidade.

Outro fator primordial que vejo é “comunidade”.

A comunidade JRuby tem crescido a cada dia – claro que por conta do próprio Ruby/Rails. E a indústria de software tem investido nisto, aja vista o ótimo suporte do NetBeans a Ruby/Rails; e a própria contratação de membros chaves do JRuby pela Sun há algum tempo.

E a comunidade Groovy? Bem, acho que Grails tem ajudado a levanta-la. Mas o seu barulho ainda não é dos maiores não. (Espero que isto mude.)

E o fim deste pensamento, qual é?

Use JRuby. Use Groovy. Use o que melhor atender aos seus próprios requisitos e aos de seu cliente. Porque não há apenas uma linguagem de programação, nem uma única solução pra tudo!

Atualmente estou propenso a usar tanto JRuby [on Rails] quanto Groovy [on Rails]. O que vai me fazer decidir entre um e outro serão os requisitos do momento – e a expectativa futura.

Então, seja JRuby ou Groovy, o que importa é desenvolver o software certo, no tempo certo, com a qualidade certa.

(Valeu Diego, por me fazer pensar um pouco sobre isto.)

Até a próxima!

Agile Requirements Workshop!

Sábado passado participei do Agile Requirements Workshop com o Alexandre Magno e o Adail Retamal.

O nível do workshop foi realmente excelente. Muito conteúdo, muita prática, muita discussão, literalmente, muita formação para qualquer profissional ágil. User stories, Features, Mapas Mentais, Engenharia de Requisitos, e outros assuntos foram tratados com muita propriedade pelos dois. =)

Um momento que achei impressionante foi quando o Alexandre, ensinando o valor da comunicação, disparou: “Não combinei nada com o Adail, mas, Adail, fica tranquilo, eu assumo o prejuizo, tá? Quem quiser ir embora ‘só com a apostila’, eu devolvo 90% do valor pago pelo workshop. Você pega a apostila, vai embora, e eu te devolvo 90% agora mesmo. Quem quer?” O que vocês acham que aconteceu? Ninguém nem piscou! Porque o conteúdo que esses caras tem para passar é muito, muito, além do que qualquer apostila. Comunicação é tudo – e, acredite, esses caras sabem bem o que significa isso.

Enfim, ótimo evento, quem não foi perdeu. Mas, como o Alexandre mesmo anunciou, mais edições estão por vir!

Não fique de fora!

Projeto Da Vinci Machine

A Sun caminha a passos cada vez mais largos em direção à consolidação da Plataforma Java como tecnologia de base para multiplas linguagens de programação, tal como a plataforma .Net da Microsoft. Assunto que abordei em um de meus posts recentemente.

Mais um grande esforço neste sentido é o projeto Da Vinci Machine, que visa facilitar a implementação de outras linguagens para a JVM.

New York Times/IDG: Sun’s Da Vinci Machine Broadens JVM Coverage.

Refatorar é preciso!

Definitivamente, refatorar é preciso!

Ninguém consegue escrever o melhor código do mundo na primeira vez que o escreve. Aliás, arrisco dizer que isto não é verdade apenas com software, mas com uma infinidade de coisas que fazemos ao longo da vida.

Desde que me entendo por gente garoto, sempre tive o hábito de refatorar. Nos meus trabalhos escolares, composições musicais, estudos bíblicos. Dia desses mesmo tive que escrever uma carta para ser lida publicamente [a detendos e familiares] em um presídio de São Paulo. Que responsabilidade! Escrevi e refatorei várias vezes numa mesma madrugada até a tal carta ficar muito boa.

No meu trabalho não é diferente. Escrevo e re-escrevo códigos sempre. Não por terem sido mal escritos por mim ou por algum colega, mas porque acredito que eles sempre podem ser aprimorados.

Refatoração como disciplina da Engenharia de software:

Martin Fowler, em seu site oficial sobre refatoração, diz que refatorar é alterar a estrutura interna de um código sem alterar o seu comportamento externo. É fazer pequenas modificações de cada vez, que somadas, resultem em modificações significativas, sem contudo, afetar o funcionamento do código.

De forma bem prática, no meu dia a dia, costumo enumerar as tarefas da refatoração em: Revisar, remolelar e refinar. Três ‘R‘s indispensáveis na vida de todo bom programador, porque:

1. Todo código precisa ser revisado;
2. Todo código é forte candidato a ser remodelado, pelo menos uma vez;
3. Todo código deve ser refinado sempre.

Quando aplicada corretamente, a refatoração trás excelentes ganhos, tais como:

1. Códigos mais legíveis;
2. Códigos mais performáticos;
3. Códigos mais extensíveis;
4. E sobretudo, código mais simples!

Este e o sentimento da refatoração. Ganhos hoje; e mais ainda, amanhã. 

Agora, sabe qual é a triste realidade? Poucos gestores de projetos entendem e encorajam esta prática. Uma pena, porque o projetos só tem a ganhar. Quantas vezes você já não entrou em um projeto e perdeu horas e horas pra entender o código macarrão que alguém que nem está mais na empresa fez? Quantas vezes mais isso ainda não vai acontecer neste mesmo projeto? Ah, se estas horas tivessem sido empregas em refatoração…

Mas, sabe de uma outra coisa? A culpa não é só dos gestores de projetos. Desenvolvedores de software também precisam aprender a vender suas idéias, soluções, e mostrar resultados reais da aplicação de determinadas técnicas. Afinal de contas, cientistas renomados como Martin Fowler costumam ter razão naquilo que dizem.

Bom, ainda bem que aqui na equipe de arquitetura da CVC Turismo não é assim. Aqui refatorar é visto com muito bons olhos. Bons olhos sobre quem faz a refatoração, dado o seu pró-ativismo; e bons olhos sobre o próprio patrimônio de software da empresa que é valorizado a cada dia.

Se seu gestor não quer nem ouvir falar em refatoração, eu tenho uma sugestão pra você: Faça algumas refatorações por conta própria, sem que estas afetem o andamento do seu projeto, é claro, e depois apresente a ele um relatório de ganhos, conforme citados anteriormente.

Não se esqueça: Frutos falam mais que palavras.

Depois poste aqui o resultado…