Ruby on Rails

Nome do entrevistado:
Akita, Fábio
E-mail:
fabioakita@gmail.com
Área de atuação:
Programação Ruby on Rails

- Fale um pouco sobre Ruby on Rails.

R. Ruby on Rails é um framework para desenvolvimento de aplicações Web construída sobre a linguagem Ruby. Ruby é uma linguagem com mais de 10 anos de idade, com características de orientação-a-objetos, programação funcional, tipagem dinâmica, estrutura muito elegante. Rails só é possível graças às características da linguagem Ruby.

Há mais de 3 anos Rails tem sido a fonte de inspiração da evolução de diversos outros frameworks web em outras plataformas, e continua sendo uma das vanguardas em inovações nessa área.

- Quais cursos/faculdades são necessários para se tornar um profissional nesta área?

R. Um bom programador Ruby não é diferente de um bom programador Java ou C#. Um bom programador é um artista. Artistas não se limitam a saber usar um único pincel. É o que define bons profissionais de desenvolvimento de software em geral. Claro, sempre existe a plataforma favorita, mas isso não deve ser desculpa para ser míope em relação ao mundo em geral.

Como Rubista eu não advogo que um programador Java, por exemplo, deva deixar Java de lado para usar somente Ruby. Acredito que mesmo que um Javeiro não tenha oportunidade de usar Ruby no seu dia a dia, apenas o fato de aprender um novo paradigma aumenta em muitas vezes sua capacidade de desenvolver Java. Desenvolvimento de software caminha mais e mais para a pluralização do profissional.

“Aquele que conhece apenas o martelo vê todos os problemas como pregos”, não poderia ser mais verdade.

Portanto, para se tornar um profissional em Ruby, antes de mais nada esse profissional tem que ter gosto por seu ofício. Da mesma forma como um pintor não pode ser um batedor de cartão, um programador tem que aprender sobre as mais diversas áreas em tecnologia: administração de sistemas, bancos de dados, algoritmos, design patterns. Ao mesmo tempo – em qualquer plataforma – deve tentar ver a maior quantidade de código open source possível. Ninguém sabe tudo de cabeça e o exemplo de um único livro é muito pobre. Seguindo o exemplo do pintor, é como um pintor que aprendeu a pintar tendo como inspiração um único quadro: com certeza seu trabalho será infinitamente mais pobre do que um pintor que observou todas as grandes pinturas do mundo.

- Quais são as maiores dificuldades encontradas em seu dia-a-dia como programador Ruby on Rails?

R. A maior dificuldade é encontrar bons programadores, mas isso não é um problema só de Rails. Mesmo num mercado maior como Java ou C# eu sempre tive alta dificuldade em encontrar programadores competentes. Quantidade não chega nem perto de ser qualidade. A maior dificuldade, principalmente como evangelizador, é convencer as pessoas a descer do pedestal e realmente aprender a ser um “bom” programador, como defini acima.

- O mercado de trabalho tem acolhido bem os profissionais desta área?

R. Sim e não. Os “bons” programadores tem conseguido se virar de diversas formas: algumas poucas empresas no Brasil estão contratando rubistas, alguns empreendedores de produtos inovadores (startups) estão contratando. Lá fora há muita empresa interessada em offshore outsourcing. Eu mesmo trabalhei para uma consultoria americana nesse regime e alguns amigos meus também.

Agora, “fábricas de software”, com robozinhos que batem cartão, não, não existe. E não acho que nenhum desenvolvedor que se preze deva almejar algo assim.

- Quais são os maiores pontos positivos em trabalhar com esta linguagem de programação?

R. Se você já é um programador em outras linguagens, provavelmente sempre programou do mesmo jeito. Para quem pulou de VB para C#, ou para quem saiu de Pascal para Java, enfim, o paradigma mudou muito pouco e não houve necessariamente ganho considerável de qualidade. Linguagens como Ruby, Python, Erlang, OCaml trazem paradigmas diferentes e maneiras diferentes de resolver o mesmo problema.

É como saltar da Idade Media para a Renascença. Novos conceitos são introduzidos como tipagem dinâmica, compreensão de listas, DSLs, concorrência sem efeitos colaterais. Na realidade não são coisas novas, essas linguagens existem faz tempo, na realidade estamos redescobrindo esse potencial.

Ruby é uma das linguagens mais “agradáveis” para se começar e possui muitas dessas características. Depois de uma curva de aprendizado relativamente baixo (o que não significa que seja fácil de entender num único fim de semana, claro) a linguagem é muito gratificante. Uma vez entendido os paradigmas, soluções muito mais interessantes começam a aparecer.

- Qual é a faixa salarial dos programadores Ruby on Rails?

R. Isso varia bastante. Como não existe um mercado “formal” de Rails, tudo vai depender da qualidade do próprio programador em se negociar. Mas não existe mágica: ele vai ganhar exatamente quanto merece.

- Existem níveis de cargo para programadores Ruby on Rails? Ex. Junior, Master, Senior

R. Eu não uso a palavra “cargos” mas sim, com certeza, existem os iniciantes em Rails e os sêniors. Novamente, isso vai depender da qualidade do programador em saber se vender. A maioria das pessoas acha tudo muito cômodo: não basta enviar um currículo e esperar ser chamado. Independente de Rails, bons salários e bons cargos só são oferecidos a profissionais que fazem a diferença. Como eu disse, os empregos em massa estão no mundo Java, C#. Se o objetivo for somente ter um emprego, apenas faça um curso de Java e envie seu currículo às dezenas de empresas de recrutamento. Com certeza haverá um emprego.

Agora, se quiser realmente ter um trabalho motivador, bem remunerado, onde você faz a diferença, é necessário ter uma boa preparação. Novamente, isso independe da plataforma. Todos os Railers do mundo que tem essas características estão empregados e ganhando muito bem.

É a velha história: para riscos pequenos, remunerações pequenas. Os ganhos maiores são apenas para aquelas que assumem os maiores riscos e dão a cara para bater.

- Rails trabalha no formato MVC, fale um pouco sobre este método de programação?

R. Não é um “método”, é apenas uma convenção que mais se tornou conhecida. MVC, ou Model-View-Controller na realidade não é o que classicamente se conhece como “MVC”. Na realidade o padrão que se convencionou chamar de MVC é o Model-2 primeiramente apresentado pela Sun para o J2EE, uma variância do MVC clássico – que é um padrão de desenvolvimento desktop criado no Smalltalk vários anos antes da Web.

Programadores da Web 1.0, que vieram de ASP, PHP, estão acostumados a pensar em páginas que chamam páginas. Páginas que podem ser incluídas dentro de Páginas, e cada página é independente. Isso gera o que chamamos hoje de “código macarrônico”, ou “quick and dirty”. É um jeito muito rápido de se fazer um site Web, mas é extremamente ruim quando seu site é grande ou quando você precisa dar manutenção depois. Isso sem contar que é bastante complicado otimizar performance, monitorar segurança, etc.

Dividindo o problema em “camadas”, as chances de organizar seu código crescem muito. MVC advoga a separação em duas camadas independentes: Model e View e uma que compõe as outras duas. Uma View não deve interagir diretamente com o Model e vice-versa, apenas o Controller deve poder fazer esse meio de campo.

Porém, nada disso é mágica. É bastante possível (e isso acontece o tempo todo), criar sistemas “MVC” que são macarrônicos. Para amenizar isso surgiram dezenas de “Design Patterns”, que são consideradas boas práticas de programação. Dependency Injection é uma delas.

No caso do Rails, o framework e a linguagem simplificam bastante essa confusão e burocracia. Ela utiliza os conceitos de MVC e internamente tem diversos design patterns já implementados, tornando seu entendimento e utilização muito mais simples.

- Você acredita que o Ruby on Rails possa se tornar uma linguagem tão utilizada quando PHP, ASP, ColdFusion?

R. De jeito nenhum. O sucesso de uma tecnologia não se mede pelo seu “market share”. Principalmente no Brasil, existe ainda muitos programadores ASP por exemplo. Mas a maioria deles dificilmente ganha mais do que um programador Java médio. O mesmo vale para PHP. Existem exceções, claro, mas não é esse o ponto.

Um exemplo prático do mundo é a Apple: com apenas 6% do “market share”, ela fatura tanto ou mais do que HP ou Dell que vendem Windows, que é 90% ou mais do mercado.

Por que vendendo para uma fatia menor ela consegue ganhar tanto? Óbvio: porque ela vende produtos de qualidade Premium por um preço Premium.

É exatamente esse o perfil de desenvolvedores sêniors de Rails e de outros frameworks de vanguarda: nós atendemos um market share bastante pequeno, um nicho. Porém, oferecemos um plus e ganhamos por isso.

O fato do Ruby on Rails ser open source também significa que ela não vai morrer por decreto, como aconteceu com o ASP 2 (e não, ASP.NET não tem absolutamente nada a ver com o ASP antigo, alem de serem feitas pela mesma empresa). A comunidade por trás do Rails é sua verdadeira força e a principal responsável por seu sucesso.

Ruby on Rails será utilizada por empresas que precisam de qualidade, produtividade, não por corporações que não se incomodam com software, onde software é apenas considerado mais um custo necessário. Existe uma grande diferença desenvolver software numa empresa especificamente de software, e de desenvolver numa empresa onde o core business é vender celulares, por exemplo, a prioridade é vender celular, não fazer software. Para esse tipo de empresa, se o código é macarrônico, se os programadores estão satisfeitos, tudo isso é irrelevante, e portanto eles nunca usarão Rails ou qualquer outro dos novos frameworks. Pelo mesmo motivo, os “bons” programadores como expliquei acima, dificilmente duram muito tempo nesse tipo de empresa.

- Dê agora uma DICA PROFISSIONAL aos leitores desta entrevista que trabalham ou pretendem trabalhar com esta linguagem de programação.

R. Novamente, não gosto de falar explicitamente de programadores Ruby. O que eu recomendo vale para programadores em geral. Cada um sabe de si, e a pessoa precisa decidir: ela programa porque gosta de programar, ou programa porque apenas precisa de um emprego, seja lá qual for, e que pague um salário no fim do mês?

Para esses, recomendo se ater às linguagens de “mercado”, onde existem empregos em abundancia, embora a remuneração e as perspectivas de futuro não sejam grande coisa. Para os que realmente gostam do ofício, recomendo continuar no mercado mas se aprimorar não somente em Ruby e Rails mas em todas as novas tendências do mercado. Exemplo? Não é certo ainda, mas os bancos de dados estão saltando para modelos diferentes dos relacionais, procure saber sobre CouchDB ou SimpleDB.

Tecnologias morrem depressa. É ilusão achar que essa plataforma única que você sabe hoje (seja lá qual for), estará no mesmo lugar daqui 5 ou 10 anos. Cobol ainda persiste até hoje, mas o tão visado “market share” praticamente inexiste. Os poucos que sobraram ganham bem, claro, pois são raridade. Mas para os que gostam de baixos riscos, isso não existe mais. Ainda existe muito Clipper e ASP por aí, mas como as empresas por trás delas não existem mais ou não se interessam mais, em breve elas não rodarão mais. Novamente, a zona de conforto desses programadores já não existe mais.
Qualquer profissão exige aprendizado constante, alguns mais do que outros. Vejam medicina e direito: o tempo todo existem novidades. Os bons médicos e bons advogados, são os que mais estão atualizados. Existem os médicos e advogados medíocres, e eles continuam ganhando pouco. Os bons ganham muito mais, mas não existe almoço de graça: para ter o maior prémio, é exigido o maior sacrifício.

Em tecnologia isso não é diferente, a diferença é que o ciclo de vida dessas tecnologias é muito curto. Onde uma técnica medica pode durar décadas, uma tecnologia inovadora pode perder seu brilho em 10 anos ou menos. Os que já investiram ou estão começando a investir em Rails agora são justamente os que terão os maiores retornos.