Rails e [Tecnologia/Técnica X]

October 31st, 2006 § 6 comments § permalink

No Seminário Ruby on Rails, durante algumas palestras foram levantados alguns questionamentos sobre o modo Rails de fazer certas coisas e como esse modo pode ser comparado com outras linguagens. Felizmente, as discussões foram bem civilizadas e estão rendendo bons comentários até o momento. Quando das questões, não houve muito tempo para responder algumas delas e como eu fiquei pensando no assunto na viagem de volta, resolvi colocar algumas dessas considerações aqui.

Antes de começar, vale a pena dizer que não é possível comparar plenamente uma tecnologia como o Rails, que tem pouco mais de dois anos de vida com outras que já estão passando pela linha de dez ou doze anos. O ecossistema do Rails, por maior que seja, ainda é muito menor e menos desenvolvido. É claro que ele está crescendo, mas algumas comparações simplesmente não se aplicam.

Uma das coisas que eu vi que é que “convenção ao invés de configuração” é algo que muitos desenvolvedores demoram a colocar na cabeça–principalmente para usuários de linguagens estaticamente tipadas, que dependem de muita configuração. Olhando de fora do Rails, pode parecer às vezes, com foi citado no seminário em alguns momentos, que o Rails é procedural. Nada mais longe da verdade. O que acontece é que essas convenções do Rails colocam tantas peças em lugares automáticas que um desenvolvedor iniciante ou de outra linguagem poderia pensar que o Rails é como uma dessas bibliotecas onde você simplesmente preenche as linhas em branco. Mas, nesse caso, basta um pouco de experiência para entender que a convenção jamais se opõe à flexibilidade.

Dito isso, é possível esclarecer algumas perguntas feitas.

Uma delas foi em relação a regras de negócio, mais especificamente, onde eles se localizam no Rails. A resposta mais simples seria que quaisquer regras de negócio ficam no modelo de dados. A verdade é que isso depende de quais regras estamos falando. Regras relacionadas ao modelo ficam realmente no modelo. Validações, agrupamentos, esses tipos de regras são facilmente expressas por meio dos métodos já presentes do Rails (validações, chamadas interceptadas, entre outras). Mas, caso o desenvolvedor precise, ele pode usar classes fora da hierarquia padrão do Rails para expressar quaisquer regras necessárias, usando qualquer estratégia que deseje.

O fato é que o Rails não possui, propositadamente, qualquer meta-framework para expressar regras de negócio. Cabe ao desenvolvedor escolher a melhor maneira para descrevê-las. Com a flexibilidade do Ruby, a tendência atual é a utilização de linguagens de domínio extremamente especializadas para isso. Em resumo, o Ruby permite um poder de expressão tão grande em termos de linguagem que qualquer -framework especializado seria redundante. Se a linguagem é limitada, e exige que o desenvolvedor “roube” cada vez que precisa de algo mais avançado, o resultado é o surgimento de bibliotecas que violam a linguagem em favor dos desenvolvedores. No Ruby, isso não acontece e o desenvolvedor é livre para criar suas próprias linguagens de domínio. Tanto é assim, que plugins em Rails tendem a ser bem simples e específicos. Aliás, um exemplo dessa flexibilidade e simplicidade pode ser visto em um plugins que ajuda a criar máquinas de estado finito em puro Ruby.

Esse tipo de coisa é comum ao Ruby e acessível a qualquer desenvolvedor, que não fica dependente de bibliotecas pesadas e complexas para resolver problemas comuns.

Uma outra pergunta feita foi em relação ao Rails e AOP. Muito do que eu disse acima se aplica a esse tema também. Particularmente, eu acredito que o Rails nunca precisará de uma solução equivalente ao AOP porque o Ruby é uma linguagem que suporta AOP indiretamente por padrão.

Um exemplo citado foi o uso do Glassbox para fazer depuração e profiling de aplicações Java. Com stack traces do tipo que o Java gera, não é difícil ver a necessidade de uma aplicação que faça as coisas pelo desenvolvedor. A facilidade de expressão e reflexão que o Ruby dão ao desenvolvedor significam menos problemas, menos erros e mais entendimento do que o código faz. O Glassbox usa AOP, com compilação dinâmica, para capturar o estado da aplicação e identificar problemas. Uma aplicação assim provavelmente seria muito mais fácil de se escrever em Ruby por causa da natureza dinâmica da linguagem, sem necessidade de compilação ou interceptação indireta. O Ruby possui mecanismos naturais para isso, usados por qualquer aplicação. Ou seja, AOP acaba sendo uma prática natural e não algo a ser colocado sobre a linguagem.

É claro que pode-se dizer que AOP é mais do que isso. Mas esse argumento é enganoso. AOP existe para suprir uma falha em linguagens fechadas demais para permitir construções nativas que fornecem o equivalente. Isso é resultado do paradox Blub, descrito por Paul Graham. Mesmo o C# prova isso, apesar de sua natureza mais estática.

Uma terceira dúvida foi sobre a extensibilidade interna do Rails, ou seja, a capacidade do mesmo de se adaptar a problemas mais complexos. Isso é comum em bibliotecas onde a convenção é muito forte. De experiência pessoal, eu posso dizer que o Rails não falha nesse quesito. Recentemente, tive que fazer um aplicação onde tabelas genéricas, com grande valor semântico, eram criadas pelos próprios usuários durante a execução do programa. Essas tabelas tinham que se comportar, em termos de mapeamento, de maneira exata às tabelas pré-existentes na aplicação. Além de não ter qualquer problema com a geração das tabelas, também não tive problema algum em gerar todo a estratégia MVC correspondente às mesmas em tempo de execução com completa persistência sem recorrer a nenhuma técnica especial além da declaração de umas poucas definições idiomáticas para me auxiliar.

É fácil imaginar o que aconteceria se eu estivesse usando uma linguagem estática em que as definições tivessem que ser feitas em tempo de compilação. Seria, claro, possível fazer o que eu fiz, mas não com a naturalidade de nem precisar criar funções extras na biblioteca. E esse é um problema simples. Em aplicações que eu estou desenvolvendo agora, eu tenho casos de linguagens que são customizadas pelo usuário, geração dinâmica de condições de execução e coisas similares. Com o Ruby, eu não preciso fazer qualquer esforço.

Essas são algumas das minhas considerações iniciais. Se eu me lembrar de mais alguma coisa, continuo em outra entrada.

Eu não vou falar sobre implantação, que causou algumas dúvidas, porque acho que é só pesquisar sobre o Capistrano para perceber que no Rails não poderia ser mais fácil.

Obviamente, dúvidas são sempre válidas quando uma nova tecnologia promete muito. E acho que o Rails responde muitas coisas de uma maneira bem simples e poderosa. O fato é que, independentemente do que o Rails representa para outras tecnologias, desenvolver com o mesmo é algo que dá a qualquer programador uma agilidade maior na codificação e de quebra, por causa do Ruby, muda o seu modo de pensar. Nada melhor do que isso para algo tão novo.

Seminário Ruby on Rails: O Retorno

October 30th, 2006 § 0 comments § permalink

Sábado aconteceu o Seminário Ruby on Rails, organizado pela Tempo Real. Meu irmão e eu participamos e gostamos bastante. Para o primeiro seminário sobre o assunto no Brasil, tudo correu relativamente bem, com uma participação expressiva de desenvolvedores vindos de todos os cantos do país.

Tivemos cinco palestras, por nomes bem conhecidos da comunidade, com temas variados, cobrindo uma boa gama de assuntos, apesar de alguns probleminhas.

A primeira palestra foi do TaQ, sobre o Ruby em si. O conteúdo foi excelente e só não foi melhor por causa de uma certa pressa no final por conta do tempo. Mesmo assim, quem não tinha familiaridade com a linguagem viu que ela realmente é bem interessante. Eu ouvi vários comentários ao redor quando uma comparação era feita, com desenvolvedores admirando a facilidade e pureza da linguagem.

A segunda palestra foi dada pelo Adriano Dadario, do RubyOnBr, introduzindo o Rails e mostrando como instalá-lo. O único pecado da palestra foi o uso excessivo do PowerPoint quando o código seria mais eficiente.

Depois do almoço tivemos uma outra palestra sobre o Rails com o Bill Coutinho, da Dextra, que me decepcionou um pouco pela repetição de muito material da palestra anterior. Um comentário do próprio Bill no meio da palestra revelou que ele não tinha visto a palestra do Adriano. Na hora de introduzir o código, o tempo foi muito curto e não deu nem para começar, mas o uso Ajax Scaffolding foi um sucesso.

A quarta palestra foi do Ronie Uliana, também do RubyOnBr. Excelente, e bem prática. Uma boa seção de perguntas e respostas também, com a participação um pouco negativa de alguns nomes da comunidade Java. Mas, não se pode falar bem de uma tecnologia sem arrancar uns rosnados de proponentes de outra…

A palestra final foi do Fernando Gomes, apresentando o Rails 1.1 e o RadRails 0.7. Bem divertida, mas muito corrida também por atrasos na programação. Mesmo assim, acho que deu para mostrar que o Rails 1.1 tem muita coisa interessante e que o RadRails é um excelente IDE.

No final das contas, foi um evento muito bom, principalmente pelo pessoal que deu para conhecer pessoalmente, incluindo o pessoal acima e mais o Spiceee, o Kenji, o Koch e outros. Houve um momento em que eu achei que nem conseguiria chegar já que meu irmão e eu viemos de carro e tivemos um problema no meio da estrada, mas tudo correu bem na ida e na volta.

Agora, é só esperar o próximo evento.

Propaganda despuradora: E, a propósito, se você tem interesse em aprender Rails com a mão na massa em um curso super-prático, a Tempo Real está promovendo um no fim do próximo mês, ministrado por mim.

Structure and Interpretation of Computer Programs

October 26th, 2006 § 0 comments § permalink

Eu tinha mencionado o livro Structure and Interpretation of Computer Programs como um excelente livro de teoria e prática da computação disponível inteiramente grátis na Internet. O que eu não sabia é que vídeos das aulas também podem ser baixados.

Eu já assisti o primeiro e estou baixando os outros. As aulas deram origem ao livro e oferecem o conteúdo da primeira edição do mesmo. Mesmo se você já tem experiência na área, vale a pena assistir. E para quem está querendo se aprofundar na teoria (e de quebra aprender Lisp/Scheme), mais motivo ainda.

Second Life

October 25th, 2006 § 1 comment § permalink

Eu andei brincando um tempo com a versão grátis do Second Life, mas por falta de tempo, deixei de lado. Hoje vi a notícia de que a Reuters, uma das mais conceituadas agências de notícias do mundo está abrindo uma filial dentro do Second Life. Na notícia, ainda descobri que várias outras empresas, incluindo Toyota, Sony, Adidas, Sun e IBM estão fazendo a mesma coisa.

Isso é extremamente interessante porque o Second Life é algo bem mais genérico que um World of Warcraft e provavelmente o primeiro verdadeiro ambiente virtual que funciona, mesmo que ainda não seja imersivo (como disse Charles Stross: The definition of a real Virtual Reality environment is one where somebody can hold a coup d’etat in it and make it stick in the real world). Ao contrário dos ambientes de fantasia e/ou ficção científica, o apelo é mais aberto e esse fluxo de empresas é uma mostra disso.

Future shock, indeed.

Plantão Médico

October 22nd, 2006 § 2 comments § permalink

Você sabe, ir para no hospital com dor abdominal que começou quando você estava assistindo um episódio particularmente gástrico de Plantão Médico não é uma maneira interessante de terminar o fim de seman. Oh, well. :-)

Mão na Massa: Rails para sua Diversão e Lucro

October 19th, 2006 § 3 comments § permalink

Na esteira do Seminário Ruby on Rails que acontece agora no dia 28 de outubro, a livraria Tempo Real está oferecendo um curso completo de Ruby on Rails, ministrado por este que lhes fala.

O curso é direcionado tanto àqueles que desejam começar com o Rails como àqueles que já tem alguma experiência inicial e desejam aprofundar um pouco mais no conhecimento do framework. Para isso, vemos desde o desenvolvimento básico da aplicação até tópicos avançados como auditoria, autenticação, escopos, plugins, entre outros–uma visão rápida, mas suficientemente compreensiva para que o participante acelere a sua produtividade do Rails, partindo do zero ou não.

A duração do curso é de 8 horas, e ele acontecerá nos dias 24 e 25 de novembro em São Paulo. O valor e mais informações sobre o mesmo podem ser encontrados na página do curso. Descontos especiais para quem cadastrar mais cedo e crédito para compra de livros para quem participar no dia 24.

IE7 disponível

October 19th, 2006 § 0 comments § permalink

Só para constar, o Internet Explorer, sétima instanciação, já está disponível para download. Bônus: versão nativa do XMLHTTPRequest. Baixar ou não baixar, eis a questão.

Aprendizado de Programação e Complexidade

October 16th, 2006 § 2 comments § permalink

Esses dias eu andei pensando em um artigo que David Brin escreveu para o Salon, intitulado “Why Can’t Johnny Code?” No artigo, Brin, que é um conhecido escritor de ficção científica, reclama da falta de um ambiente de aprendizado de programação em computadores modernos que seja tão simples quanto o BASIC era.

O artigo suscitou algumas reações interessantes, negativas em sua maioria, mas eu não posso me furtar ao sentimento de que Brin estava parcialmente correto–embora talvez não pelo motivo que ele especifica.

É certo–como alguns responderam–que hoje temos um ambiente relativamente ubíquo de programação presente em quase todos os computadores: o navegador, que pode ser usado para o desenvolvimento de aplicações mesmo sem a necessidade de um servidor, algo demonstrado por aplicações como o TiddlyWiki. Apesar disso, a barreira de entrada é comparativamente alta para aplicações que ultrapassam o mais simples do HTML mais JavaScript e passam para o domínio da necessidade de persistência e continuidade.

Existem dois níveis em que a questão pode ser abordada: o aprendizado infanto-juvenil, ou seja, a exposição à programação como qualquer outra matéria curricular aplicada; e o aprendizado como uma ferramenta de trabalho.

O artigo de Brin tratava exclusivamente do primeiro nível acima, pensando na formação uma nova geração de programadores com conhecimento íntimo dos detalhes internos daquilo que usam. Segundo o argumento de Brin, as linguagens atuais são de um nível tão alto que é difícil para o programador iniciante enxergar dentro da abstração. Eu concordo que as linguagens mais populares realmente podem levar a esse problema. Mas existem ferramentas–como o Squeak, por exemplo, que é uma implementação do Smalltalk voltada primariamente para propósitos educacionais–que permitem que o programador que esteja aprendendo veja o que está fazendo nos mínimos detalhes.

A grande diferença–e o grande problema–talvez esteja na expansão das bibliotecas de apoio. Obviamente, bibliotecas são boas. Bibliotecas são o que tornam a programação eficiente. Mas elas também proporcionam uma barreira ao aprendizado. A curva de aprendizado de uma linguagem como o C# é mais íngreme do que o BASIC porque muitas primitivas estão embutidas diretamente na sintaxe dessa última ao contrário de estarem delegadas a bibliotecas como no caso da anterior.

O Smalltalk, mesmo com uma biblioteca de classes gigantesca, não sofre desse problema porque sua sintaxe é tão simples (cinco palavras chave e uma dúzia de regras sintáticas)  que a biblioteca de classes–desenvolvida em peças pequenas que são montadas quase como blocos Lego–parece parte da linguagem. O resultado é que o programador iniciante aprende a montar suas aplicações de peça em peça, em uma espécie de unit tests mentais que favorece o processo de aquisição de conhecimento.

Em última instância, essa diferença talvez tenha impacto mesmo do segundo nível acima, do aprendizado de programação como ferramenta de trabalho direto. Recentemente, exibindo o funcionamento do Seaside para um colega programador, não consegui que ele entendesse o impacto de continuações do fluxo de construção e execução contextual da aplicação. Esse colega entende o Rails perfeitamente–comparado ao ASP.NET–mas não consegue passar disso para o Seaside, mesmo sendo um programador razoavelmente experimentado. Há um salto de conceitos aqui que a formação dele não consegue ultrapassar no momento.

Isso é resultado–eu acredito–do problema que Brin descreve: programadores que pensam somente em abstrações tão específicas que não conseguem descer até um nível anterior e reconstruir dali quando necessário. E sem linguagens que permitam essa passagem, a f0rmação de novos programadores resulta em pessoas que conseguem juntar ASP, HTML e JavaScript para fazer alguma coisa que funcione, mas nada com a elegância de um Django. Eles podem saber usar, mas não fazer.

Também interessante é o fato de que isso gera uma outra barreira: contribuições a projetos de código aberto. Projetos de grande aceitação geralmente começam porque alguém resolveu revolucionar uma área específica–conscientemente ou não. Entretanto, essas revoluções implicam em abstrações quase que perpendiculares ao status quo–algo que gera um problema de complexidade inerente. É incrivelmente fácil usar o Rails ou o Django, mas a vasta maioria dos usuários dessas bibliotecas jamais contribuíra com uma linha de código para a base original–não por preguiça, falta de tempo ou falta de gratidão, mas por pura incapacidade de abstrair para os conceitos que levaram à simplicidade de uso em primeiro lugar.

O impacto da linguagem de programação é algo que não pode ser subestimado. Eu me lembro de ter desenvolvido uma biblioteca MVC para aplicações Web quando usava o Delphi, uma linguagem estaticamente tipada, como minha ferramenta primária. A parte de persistência de dados foi baseada em um artigo de Scott Ambler sobre a estratégia Active Record, usada atualmente tanto pelo Rails quanto pelo Django. O desenvolvimento–que ocorreu por volta em 2002–foi relativamente simples e bem sucedido. Eu usei a biblioteca em alguns projetos até ter que abandonar o Delphi quando mudei de emprego sem maiores problemas.

Hoje, porém, mesmo tendo esse código e podendo usá-lo e aperfeiçoá-lo com base no que aprendi, escolho não fazer isso, preferindo o Rails. Isso é resultado do Ruby, em oposição ao Delphi. As possibilidades de abstrações vazarem são menores no Ruby do que no Delphi e isso tem um grande impacto de meu processo de desenvolvimento. E eu entendo muito melhor o que estou fazendo porque já estive dentro da biblioteca em outra instância.

Assim, eu entendo o que Brin diz em seu artigo como uma maneira um pouco mais verbosa de dizer que, em programação, saber usar não é suficiente. E para ir além de saber usar, é necessário esse interesse de pensar no que move o programa, algo facilitado por uma linguagem que permita  um início mais particionado–algo que linguagens de programação com capacidades de meta-programação permitem como uma segunda natureza e linguagens mais simples possuem por necessidade.

Por isso, no final das contas, eu tenho que concordar parcialmente com David Brin. Os programadores de hoje tem muito mais deficiências do que antigamente por causa dessa mudança de foco. Não é uma questão de talento, mas de percepção. E, felizmente, nada que um bom estudo não possa corrigir.

Dabble DB

October 15th, 2006 § 0 comments § permalink

Eu vi o vídeo do Dabble DB há alguns meses e confesso que o meu queixo chegou ao chão. Fazia muito tempo que eu não via uma aplicação tão bem feita e com tanto potencial–e melhor ainda: desenvolvida em Smalltalk pelos mesmos gênios por trás do Seaside. Se você acha que sabe o que é uma aplicação Web 2.0 é porque ainda não viu o Dabble DB funcionando. E se quiser ver, basta se inscrever para um mês de testes grátis, agora que eles estão no ar.

E não, não estou ganhando nada com a propaganda.

Acima e avante

October 15th, 2006 § 5 comments § permalink

Where am I?

You are currently viewing the archives for October, 2006 at Superfície Reflexiva.