Nesse fim de semana saiu minha última coluna na RubyOnBr: Acampamento de Curiosos.

Desta vez proponho um desafio: entender ou mesmo criar seu próprio web framework. Como base falo do Camping, de _WhyTheLuckyStiff.

Mas cuidado: sou contra fazer seu próprio framework e achar que ele é o melhor de todos. Todos fazem mais ou menos a mesma coisa (sem ofensas). A idéia aqui é aprender, porque todo bom programador web tem obrigação de saber como seu framework favorito funciona.

O conceito de todos é o mesmo, as técnicas utilizadas também. Se quiser, é melhor escolher algum já famoso no mercado e participar do projeto como colaborador. Isso é muito mais prático.

E já leram minhas outras colunas na RubnyOnBr? Veja uma lista aqui.

Eu sei que ando meio ausente da comunidade e até mesmo do meu blog (!) Mas realmente o trabalho anda consumindo todo meu tempo (até o livre!). Espero poder voltar às atividades logo. O Ronie também parece estar no mesmo ritmo, ele publicou minha coluna do mês passado um pouco atrasado, mas é totalmente compreensível, dado que eu também estou atrasado com a finalização da revisão da tradução do Getting Real.

Aliás, é exatamente esse o assunto desta coluna. Achei interessante documentar o inside story sobre essa tradução. Dêem uma olhada aqui.

Dia 9 de fevereiro aconteceu o evento RoR eXchange 2007, da Skills Matter, co-organizadora da última RailsConf. Foi um evento de um dia que reuniu alguns bons palestrantes para discutir os últimos desenvolvimentos no mundo RoR.

Neste link vocês podem assistir a todas as palestras. Ainda não vi todas mas gostei muito da apresentação de Chad Fowler. Parte dela tem a ver com minha coluna de Janeiro na RubyOnBr – A Dieta dos Controllers – onde tentei clarear uma dúvida constante: “ok, sei que Rails é MVC, mas onde diabos coloco minha lógica de negócios?”.

Outra parte tem a ver com o que já mostramos sobre o suporte REST no novo Rails 1.2. Mas o ponto alto da palestra é um aviso (muitos não vão gostar, mas vamos lá): Ruby e Rails são anunciados como “linguagem simples”, “framework fácil”, “mais fácil e rápido que Java”, “mais simples de aprender”, etc. Tudo isso dá uma extrema falsa impressão de que qualquer peão (sem ser pejorativo, mas já sendo), que nunca programou na vida, estará desenvolvendo um Yahoo.com amanhã. Novamente, cuidado, essa é a falácia da causa e efeito: porque RoR é fácil, qualquer um aprende fácil.

Vamos consertar isso: ‘Ruby e Rails são tecnologias muito simples para todos que JÁ SÃO bons programadores hoje’. Nos últimos tempos Chad teve a oportunidade de ver muitos códigos de terceiros, muitos deles códigos de novatos. O que ele viu deve horrorizar qualquer um: Rails não protege a aplicação de um mau programador.

Como disse Chad, Java e C# são tecnologias que foram desenvolvidas para programadores idiotas. Calma! Não quer dizer que quem programa em Java é idiota mas sim que ela foi pensada em termos de dar uma série de proteções para evitar erros banais. É isso que faz o compilador: protege seu código contra erros triviais de tipos (mas apenas contra erros triviais), por exemplo, o tipo de erro que um novato cometeria.

Ruby não tem essas proteções. Linguagens como Ruby, Python, Haskell, O’Caml, foram feitas para bons programadores, aqueles que sabem exatamente o que estão fazendo. Rails é uma excelente ferramenta apenas, e somente apenas, àqueles que se deram ao trabalho de estudar como ela funciona internamente.

O exemplo de Chad é muito bom: em uma boa tecnologia de ORM como o Active Record do Rails ou mesmo um Hibernate em Java esconde boa parte do SQL que antes era feito manualmente. Agora imagine que você buscou uma lista de usuários do seu banco (find :all), colocou essa lista para iterar em um loop (.each) e está analisando as permissões de cada usuários para mostrar em uma tela. Você acabou de cair na armadilha conhecida como 1 + N, ou seja, se sua lista de usuários tinha 200 usuários, você vai fazer pelo menos mais 200 queries no banco para buscar as permissões de cada um. Eu discuto isso no meu livro e mostro a diretiva :include dos finders, que é uma das possíveis soluções nesse caso.

Você só sabe onde, quando e como usar uma técnica como :include se souber exatamente o que o ActiveRecord fará no seu banco, como queries SQL se comportam, o que é um left outer join. Se não tiver nenhum desses conhecimentos, trará um impacto que poderia ser mortal à sua aplicação no médio prazo. Outro exemplo é uma homepage “ocupada” (cheia de pequenas queries e informações dinâmicas, uma página não-Web 2.0, digamos) que também terá um impacto enorme caso o programador não tenha noção das diversas técnicas de caching do Rails (outro assunto que também discuto no meu livro).

Em outras palavras: nem Ruby nem Rails protegerá uma aplicação de um programador folgado. Quando um bom programador (que já tem experiência em bancos de dados, em otimização do modelo request-response do HTTP, em configuração de servidores web como Apache, em ORM, em MVC, em Design Patterns, etc) se encontra com Ruby on Rails, temos um excelente casamento. Quando um programador que não investiu o devido tempo a estudar todos esses assuntos se encontra com Ruby on Rails, temos um desastre. E isso não é só com Rails. Coloque um programador que não tem o costume de se auto atualizar como deveria em qualquer plataforma de desenvolvimento e sempre teremos um desastre.

Significa que não há salvação para os novatos? Claro que não, todo programador sênior já foi um júnior. A diferença é que o primeiro investiu cada hora livre de seu tempo em estudo. E eu quero dizer estudo com perspectiva, não um estudo míope de ferramentas, mas sim um estudo amplo de tecnologias. Por que o HTTP é como é? Por que SQL é como é? Por que o que chamamos de MVC atual é como é? Quais as melhores formas de usar todas essas tecnologias em conjunto? Inclusive essa é a linha mestra que guia meu livro: um livro que apenas o leva passo a passo do estágio 1 ao 2, não ensina nada. “Para buscar todas as linhas da tabela, digite find(:all)”. Esse é o tipo de ensinamento que torna possíveis bons programadores em programadores folgados. Ele não diz o principal: “por que”, “quais as alternativas”, “o que acontece por baixo”, “quais minhas opções”.

Por muito tempo associamos programação a dois estilos: quick’n dirty (rápido e sujo) ou slow’n clean (lento e limpo), ou seja, se você programar rápido demais, sem pensar muito, apenas cuspindo código, terá algo sujo, difícil de dar manutenção e cheio de bugs. Para ter um sistema estável, com código razoavelmente simples de dar manutenção futura, é preciso planejar de antemão tudo que fará e ir muito devagar. A nova geração Agile de desenvolvimento postula que é possível sim, ser quick’n clean, ou seja rápido e limpo. Mas algo que está implícito é: para ser rápido e limpo é preciso ser esforçado, auto-didata e estar sempre experimentando técnicas e tecnologias.

Ninguém consegue ser quick’n clean em qualquer plataforma, linguagem ou tecnologia, mesmo tendo Q.I. de Einstein. Experiência não se herda nem se compra: se adquire, com esforço, treinamento contínuo e de qualidade. Para um jogador profissional de basquete, fazer cestas de três pontos é algo quase trivial. Para um principiante é a coisa mais difícil do mundo, a diferença é que o primeiro provavelmente treinou esse lance por várias horas, durantes vários dias, em vários anos a ponto disso se tornar trivial. É um conceito que vale para qualquer coisa, não apenas programação: quanto mais treinamos, mais as coisas difíceis se tornam simples e podemos partir para treinar algo mais difícil.

Lembre-se: David Hansson, Marcel Molina, Sam Stepherson, Miguel De Icasa, Guido van Rossum, Rasmus Lerdorf, Larry Wall, Anders Hejlsberg, Alan Cox e mesmos outros célebres como Bjarne Stroustrup, Dennis Ritchie, Alan Kay, Niklaus Wirth, Donald Knuth e centenas de outros. Acha que está nos genes? Um bom programador nasce geneticamente bem dotado? A diferença entre um programador ruim e estes nomes é a quantidade de esforço investido em estudo, pesquisa e experimentação. Não existe fórmula mágica, curso à jato de 6 meses, voodoo, que substitua o puro e simples suor.

Enfim, Chad repete o que eu disse na minha coluna: lógica de negócios, SQL, operações no banco, devem estar nos models. Os controllers devem ser modelados na filosofia REST (que não é coisa nova) e simular operações CRUD (atenção aos models implícitos na forma de tabelas de relacionamento many-to-many). Leia meu livro, leia os artigos na categoria Rails 1.2 neste blog, assine os feeds de sites como Ruby Inside e outras dezenas de ótimos blogs como do Dr. Nic, Ryan’s Scraps, etc. E principalmente: estude, mas estude muito, constantemente e sempre. Não existe ponto final em tecnologia, ninguém jamais poderá dizer “agora já sei tudo que preciso”, qualquer um que acha isso ainda não passa de um principiante.

Alguns dias atrás, lendo o fórum do RubyOnbr me deparei com uma pergunta recorrente: “Onde devo colocar minhas regras de negócio, nos Models ou nos Controllers?”

Parece algo trivial: “Claro, nos Models”. Mas a justificativa disso não é necessariamente clara, principalmente para iniciantes.

Resolvi discorrer sobre esse assunto na coluna A Dieta dos Controllers que acabou de ser publicada no RubyOnbr.

Acabou de ser publicado minha coluna no RubyOnbr: Rails, Sucesso pela Arrogância?

Pela palavras do Ronie: Lá vai o Akita cutucar a onça :) Nesse artigo desenvolve a idéia de “software de opinião” (Opinionated Software) que guia o desenvolvimento do Rails.

O artigo é um tanto quanto picante e com certeza vai mexer com alguns egos :)

Ele vai bem de encontro com a tendência recente da web de fazer aplicações focadas ao invés de sites que tentam fazer tudo.

Enviei ontem ao Ronie minha coluna de dezembro (link atualizado – 06/12) para a RubyOnbr entitulada Rails: Sucesso pela Arrogância? que dá as bases para este artigo que David postou no Loud Thinking. Quem ainda não ouviu falar ou não sabe o que é “Opinionated Software” deve ler minha coluna primeiro para entender isso. Vamos ao artigo:

Read the Rest

Acabou de ser publicado minha coluna de Novembro Desenvolvimento Sustentável com Rails no site RubyOnbr.

Dessa vez dou uma rápida pincelada em assuntos de processos, metodologias, procedimento e ferramentas.

Meu objetivo é apenas começar uma discussão que vem se arrastando desde Fred Brooks, nos anos 60, a Crise do Software da década de 70, até metodologias Ágeis de hoje.

A conclusão é uma só: não importa a tecnologia, se é PHP, Java ou Rails. Projetos precisam de controle, nem que seja mínimo. Não existe Anarquia em software. Nem mesmo em projetos open source. Aliás, muitos se esquecem que esses projetos tem a figura dos Mantenedores, sejam eles David Hansson, Linus Torvalds, Andrew Morton dentre tantos.

Já devem ter percebido que gosto de discussões sobre futuro. E esta coluna não é diferente, citando o excelente livro “My Job Went to India”, de Chad Fowler. Confiram.

Outra novidade é que agora irei colaborar mais com a comunidade como colunista na Rubyonbr. Outra coluna que escrevi estreou mês passado no novo site Plugmasters, dêem uma olhada. Se tudo der certo estarei escrevendo colunas para esses dois canais de conhecimento. Não deixem de enviar sugestões e críticas. Todos sabem que os canais estão sempre abertos, inclusive via meu e-mail pessoal.

E continuando na expectativa, nos próximos dias o livro “Repensando a Web com Rails” estará disponível nas livrarias. Quem quiser ainda tem chance de comprar com desconto diretamente pela pré-venda no site da Brasport.

Além do mais, estão todos convidados para o evento de lançamento do livro dia 24 de outubro, na FNAC Paulista. Tragam seus amigos e colegas de trabalho, quem sabe ajuda a convencer seus chefes e clientes a apostar conosco na tecnologia Ruby on Rails?

Porém, quem acompanha a blogsfera Ruby foi pego de surpresa por uma discussão inusitada. Joel começou distribuindo FUD ao mundo (Fear, Uncertainty, Doubt – a estratégia de confundir as pessoas usando Medo, Incerteza e Dúvida). David Hansson é famoso por suas opiniões fortes e de não levar desaforo para casa. Ele entrou nessa argumentação no seu blog Loud Thinking.

Read the Rest

• Firefox VS Internet Explorer
• Macs VS PCs
• Windows VS Linux
• C# VS Java

A Microsoft é favorito no papel de vilão. Ela atua em praticamente todos os mercados de informática, por isso sempre será motivo de críticas. “Windows é ruim”, “Office é uma droga”, “Internet Explorer não presta”, “Visual Basic não é linguagem profissional”, etc. Alguns argumentos são válidos, outros são apenas birra de visões estreitas.

Críticas são construtivas quando as pessoas tomam atitudes. Radicais são desnecessários neste mundo. Pessoas que apenas xingam e não agem são irrelevantes: “quem não faz parte da solução, faz parte do problema”.

Read the Rest