Rails é o novo ASP

October 7th, 2008 § 40 comments § permalink

Eu achei que o efeito ASP demoraria mais tempo para acontecer, mas que nada, o futuro já está aí.

Amigo meu pegou dois projetos esses dias para manter. Olhou o código e desistiu imediatamente com horror profundo. Eu não vi o código, mas, pelo que ele mencionou, o código do Windows provavelmente é menos complicado do que essas aplicações Rails.

Rails é novo ASP. ASP está morto. Viva o Rails.

Atualização: Eu amo os pundits!

Rails 2.1 destilado

June 6th, 2008 § 5 comments § permalink

O Carlos Brando é responsável por uma das minhas leituras mais constantes sobre o Rails na forma de sua compilação das mudanças de uma versão para outra do mesmo. Agora, ele juntou tudo isso em livro em PDF compilando todos os textos em um formato ultra-conveniente e muito bem acabado. Se você quer saber sobre todas as mudanças que aconteceram, não há lugar melhor.

Parabéns ao Carlos e ao Tapajós pelo excelente trabalho. Vale cada byte. E a propósito, se fosse pago, eu comprava. :-)

Rails escala, um disclaimer

May 26th, 2008 § 6 comments § permalink

Pelo título, você pode pensar que lá vem mais uma discussão longa considerando todos os fatores pelos quais Rails escala ou deixa de escalar. Sem chance nenhuma. Na verdade, minhas considerações são inspiradas pelo fato de que hoje recebi um e-mail bem humorado de um leitor. Depois das devidas permissões e supressões de nome, o conteúdo é o seguinte:

Ronaldo,

Eu leio o seu blog freqüentemente e não pude deixar de notar que você às vezes parece ter uma certa birra com o Rails. E volta e meia você coloca em seu Twitter que o Rails não escala. Mas você não trabalha com [o Rails]? Existe algum motivo para essa birra?

Abraços,

O pessoal do Passenger deu a resposta perfeita: Saying “Rails doesn’t scale” is like saying “my car doesn’t go infinitely fast”.

Como eu não sou tão criativo, vou por uma rota diferente. Apesar dos meus textos um tanto ou quanto provocativos, a resposta é: primeiro, não, eu não tenho uma birra com o Rails; e segundo, não, eu não me importo em absoluto se o Rails escala ou não.

Sendo assim, segue um disclaimer: toda a vez que você me vir usar a frase “Rails não escala”, considere que eu estou tendo uma reação similar à de alguém sentindo calafrios quando outra pessoa passou as unhas lentamente em um quadro negro, fazendo aquele barulho infernal. Eu não me sinto na compulsão de defender o Rails, não vou escrever nenhuma entrada explicando se e porquê escala ou não, não vou evangelizar continuamente e dizer que é inveja dos outros, nem quero saber de qualquer coisa nessa linha. Se alguém precisa escrever um texto quilométrico cheio de justificativas toda a vez que alguém espirra que Rails não escala, bem, isso é um problema entre a pessoa e seu psiquiatra.

Resumindo, é só uma reação alérgica ao debate todo. Nada mais, nada mesmo. Em tempo, Rails escala?

Eu não…

May 8th, 2008 § 22 comments § permalink

  • Eu não escolheria Rails para escrever uma aplicação Web que consistisse, em sua maior parte, em processamento fora da interface com o usuário, ou cujo maior ponto fosse uma API;

  • Eu não escolheria Django para uma aplicação cujo domínio fosse extremamente complexo, com modelos dinâmicos, tabelas construídas on-the-fly, e funcionalidades similares;

  • Eu não escolheria Seaside para uma aplicação que consistisse em recursos individualizados, independentes e cujo referenciamento fosse essencial;

  • Eu não escolheria ASP.NET para um site inerentemente visual, cuja interface externa com o usuário fosse a parte essencial da aplicação;

  • Eu não escolheria Castle Monorail para aplicações de pequeno ou médio porte em que manutenção fosse mais importante do que o desenvolvimento de nova funcionalidade;

  • Eu não escolheria Ruby para aplicações de rede onde o potencial de instabilidade fosse maior do que o normal;

  • Eu não escolheria Python para um ORM ultra-adaptável;

  • Eu não escolheria ASP clássico ou PHP puro para coisa nenhuma.

Conversa com Randal L. Schwartz

April 30th, 2008 § 7 comments § permalink

Durante o FISL, eu tive a oportunidade de assistir a palestra sobre Seaside dada por Randal L. Schwartz, nome famoso nas comunidades livres, principalmente de Perl, e que agora está evangelizando Seaside e Smalltalk.

Perguntei se podíamos conversar um pouco e ele aceitou graciosamente. O resultado está abaixo, em uma tradução livre:

Conte-nos um pouco sobre o seu background, como e quando você começou a programar e o que você está fazendo hoje

Eu aprendi a programar sozinho quando tinha nove anos. Quando cheguei aos quinze, já estava na frente de uma classe, ensinando meus colegas, e escrevendo código sob contrato durante os fins de semana e sendo pago de verdade.

Trabalhei para várias empresas ao longo de oito anos antes de criar a Stonehenge em 1985. A Stonehenge cresceu ao longo dos anos; nós hoje podemos contar 17 das empresas no Fortune 100 como nossos clientes.

Hoje eu gasto a maior parte do meu tempo dando palestras e escrevendo, mas ainda projeto, crio e revejo código também. Também respondo questões gratuitamente durante uma hora por dia nas dezenas de listas, blogs e comunidades Web das quais participo.

Você é extremamente famoso na comunidade Perl, mas agora está advogando Smalltalk e Seaside. O que mudou? Quando você realmente começou a usar Smalltalk?
Eu comecei a usar Smalltalk antes de Perl ser inventada, em 1982. Já escrevi sobre a história no meu blog.
Quais são as vantagens de Smalltalk sobre outras linguagens tradicionais como Perl, Ruby ou Python, por exemplo?

Smalltalk tem uma sintaxe muito simples: eu posso ensinar a sintaxe completa a alguém em cerca de 20 minutos, e, de fato, a incluo em minhas palestras introduzindo as pessoas ao Seaside. As principais implementações Smalltalk (com exceção de GNU Smalltalk) também possuem IDEs maduros permitindo a fácil exploração do código, de modo que aprender as bibliotecas é somente uma questão de olhar a implementação e uso das mesmas

E isso também é um bônus: nós temos duas implementações comerciais (Cincom e GemStone/S) e duas abertas (Squeak e GNU Smalltalk), todas suportando Seaside. Isso permite que gerentes mais preocupados, que podem hesitar ao selecionar uma linguagem estritamente suportada por voluntários, escolherem entre dois provedores comerciais para suporte. Opções são sempre boas!

Você acha que Smalltalk finalmente vai alcançar status mainstream, isto é, ganhar aceitação do mercado em geral?

Bem, Smalltalk tinha status mainstream no meio dos anos 90, logo antes de Java entrar na história, pelo menos do que tange a firmas grandes de Wall Street e outras instituições que desejavam desenvolvimento rápido de GUIs para ficar à frente da competição.

Mas sim, eu acredito que Smalltalk está posicionada para entrar o mercado novamente como um grande player. Para mais detalhes, veja meu artigo sobre O Ano do Smalltalk.

Sua palestra tinha o título, “Seaside: Seu Próximo Framework Web”. O que há de tão interessante sobre o Seaside?

Eu gosto da forma como Seaside consegue abstrair tanto o fluxo de controle (ao longo de um eixo) e a representação (ao longo do outro eixo) com relativa facilidade. Seaside parece colocar as coisas certas relacionadas perto uma das outras. Eu também gosto do “depure uma página com erro dentro da própria página”: quando algum erro aconteceu, eu posso explorar a situação dentro do depurador normalmente, consertar o que está quebrado, limpar a bagunça, e continuar a execução da página como se nada houvesse acontecido.

Da mesm forma, a persistência tradicional em Rails é feita através do Active Record, que requer que objetos passem por um mapeador objeto-relacional para chegar em SQL. Seaside pode fazer a mesma coisa (via GLORP), mas possui soluções melhores pulando inteiramente o mapeamento, e usando coisas como Magma (OODBMS), que é aberto, ou algo como GemStone/S Virtual Machine, que é comercial. Quando você tira a camada ORM, voc&e ganha muita velocidade e um ambiente de programação bem mais confortável.

O que você vê no futuro do Seaside, e como esse futuro se compara ao dos outros frameworks?
A equipe do Seaside está agora no processo de refatorar e re-empacotar o Seaside para tornar a portabilidade ao longo de várias plataformas algo mais facilmente gerenciável e modular. Isso permitirá que cada desenvolvedor use somente as partes que desejar. Eu também estou vendo vários add-ons sendo criados, como o Pier CMS e várias APIs para coisas como Google Graphs e assim por diante.
Você acha que o mercado está pronto para o Seaside?
Sim. O Rails reabriu as discussões sobre o que fazer em um mundo após o Java, voltando para linguagens com late-binding como Perl, Python e Smalltalk. E Seaside é um framework maduro, ainda mais velho do que Rails. Somente não tão conhecido. Eu espero mudar isso.
Você já colocou algo em produção com o Seaside? Se sim, quais foram os desafios?
Eu estou trabalhando em alguns projetos agora, mas nada público. O desafio inicial foi a relativa falta de documentação, o que me forçou a gastar dois dias passando por todos os e-mails na lista de discussão. Fiquei mais informada, mas definitivamente com os olhos cansados. Eu espero devolver esse conhecimento escrevendo em meu blog e ajudando a responder questões no IRC e lista de discussão.
Você agora é parte do Squeak Foundation Board. Quais são seus planos para a Squeak Foundation?
Minha preocupação primária agora são questões de licenciamento, controle das releases e publicidade. Todas essas questões já estão sendo trabalhadas, é claro, mas todos somos voluntários e sempre estamos procurando mais voluntários para ajudar.
A Squeak Foundation tem algum plano para Seaside?
Nada formal, até onde eu sei. Entretanto, como Squeak é a plataforma primária para desenvolvimento do Seaside, eu tenho certeza de que Seaside será um componente principal nesse área.
Quais são os planos mais interessantes dentro do mundo Smalltalk/Seaside atualmente?
Bem, o que me envolve no momento é o GLASS (GemStone/Linux/Apache/Seaside/Squeak), uma solução da GemStone para que pessoas possam conseguir rodar Seaside rapidaemnte. Isso também envolve levar o pessoal da GemStone a criar uma solução comercial de custo zero, mas ainda funcional (mesmo que de forma mais limitada) do GemStone/S. Com essa versão gratuita, uma pessoa poderá construir um negócio, e quando o negócio exceder as capacidades da versão, migrar sem problemas para licenças maiores e ainda razoáveis. É um bela solução para uma VM Smalltalk sólida e comercialmente suportada com persistência e clustering já presentes.
E sobre o próximo ano do FISL? Como você conseguiu três dias inteiros para Smalltalk?
Bem, como eu disse, “tudo começou com algumas doses de caipirinhas…”
Quais são os seus planos para esses três dias? Você tem a intenção de trazer outros Smalltalkers?
Eu estou trabalhando com os organizadores do FISL e vários outros provedores de soluções e grupos dentro da comunidade Smalltalk para produzir uma mini-conferências. Espero ter treinamento inicial e avançado de Smalltalk, e vários tutoriais de Seaside. Expero que a conferência possa atrair um número significativo de desenvolvedores Smalltalk para o FISL pela primeira vez, e expor os demais participantes à linguagem, de modo que todos ganhem.

Muito obrigado, Randal, pela entrevista.

O efeito ASP

January 16th, 2008 § 13 comments § permalink

Muito do meu desenvolvimento diário, para minha infelicidade, ainda é feito em aplicações legadas em ASP e PHP. Desnecessário dizer, não é um trabalho muito agradável mesmo quando a aplicação foi construída com um cuidado maior do que simplesmente gerar arquivos e mais arquivos em uma tentativa de trazer ordem ao caos.

Aplicações ASP são capazes de infligir terror ao mais corajoso desenvolvedor Web. A mistura de lógica e apresentação vem sendo usada há vários anos para exemplificar o que há de pior da área e não sem razão. Atualmente, para falar a verdade, é muito raro que eu aceite um contrato de manutenção ASP se a aplicação não atende certas práticas que eu estabeleci como referência. O trabalho simplesmente não vale a pena, por melhor que seja o pagamento.

Nos últimos anos, é claro, eu tenho tentado me dedicar mais e evangelizar, sempre que possível, novos modelos e frameworks de desenvolvimento. Nem sempre a empresa aceita mudar para algo que ela considera esotérico e fora da realidade do mercado, mas algumas vezes a vontade de reduzir o time-to-market vence o medo e algo de interessante acontece.

Estamos hoje há mais de três anos do início da evolução do desenvolvimento Web que frameworks como Rails e Django começaram e acho que estamos começando a ver os reais efeitos que o desenvolvimento nestes novos paradigmas está tendo. O uso de MVC está se tornando uma constante e mesmo a questão de desenvolvimento guiado por testes está se firmando como algo mais comum em locais onde usualmente se via um processo menos elaborado.

Nos últimos tempos eu tenho recebido alguns propostas para completar ou manter aplicações Rails já existentes e estou surpreso com a baixa qualidade do que estou vendo. De fato, no que tange a falta de cuidado com o código e a mistura de lógica e apresentação, eu só não compararia o nível dessas aplicações ao que usualmente vejo com ASP porque pelo menos a parte de convenção versus configuração segura os abusos mais berrantes.

Eu ainda não tenho dados suficientes para dizer a mesma coisa de Django, mas é possível notar um pouco disso nas aplicações e projetos espalhados pela Web que pouco cuidam em promover técnicas como TDD ou mesmo um reuso mais efetivo de código. E quanto promovem, o que se vê são usos pouco significativos dessas técnicas como a eterna persistência em testar o funcionamento de camadas ORM. Isso é válido também para quase todos outros framework Web, independentemente de linguagem e estruturação.

Parte do motivo desse uso incorreto é explicada pela soma de dois fatores distintos: o fato de que poucos programadores são realmente capazes de entender o que OOP significa e o fato de que Rails, Django e todos esses outros frameworks promovem uma versão mais light, por assim dizer, de OOP que efetivamente isola muitos programadores de um desenho mais efetivo do domínio do problema.

Eu fico pensando no mercado daqui a cinco anos, quando o mesmo estiver inundado de aplicações nesses novos frameworks. Provavelmente, não haverá diferença nenhuma em termos de manutenção para o que vemos hoje. Aplicações realmente bem feitas permanecerão confinadas a um pequeno conjunto dentro da indústria. Um efeito ASP em ação.

A revolução ainda espera e Frederick Brooks continua mais válido do que nunca. Rails e Django podem ser indolores no começo, mas eu tenho pena dos programadores que terão que manter o que está sendo criado hoje.

Rails for Kids: faltam dois dias

December 13th, 2007 § 0 comments § permalink

No próximo sábado acontece o Rails for Kids, organizado pela e-Genial. O evento, que reune dez palestrantes para falar sobre Ruby, Rails e o mercado, acontece ao longo de todo o dia via TreinaTom e terá toda a sua renda doada para uma instituição de caridade do Mato Grosso do Sul.

Se você ainda não se inscreveu, não perca tempo. A inscrição só vai até amanhã e mesmo que você tenha interesse em somente uma das palestras, será um dinheiro bem gasto. Além disso, os participantes que não puderem ver as palestras no dia terão acesso às gravações das mesmas após o evento. Todo mundo ganha com isso. O preço é R$25,00, bem pequeno para um evento assim. Aproveite e ajude quem precisa.

Rio on Rails

December 8th, 2007 § 13 comments § permalink

Cheguei são e salvo ao Rio. Fazia tanto tempo que eu não vinha aqui que tinha esquecido que a aproximação do Galeão é sobre o mar. Para quem não gosta de pousos, a sensação é bem desagradável. Tirando isso, o dia está quente e bonito e o evento começou bem.

No momento, o Demetrius Nunes está fazendo uma introdução ao Rails e Ruby e pelos olhares atentos o pessoal está gostando. Mostrar um pouco da mágica do Rails é uma coisa que sempre funciona para atrair o pessoal para o que realmente importa. Nesse quesito, o Rails não tem rivais entre os demais frameworks e isso, obviamente, explica muito da sua popularidade. Com esse começo, acho que o pessoal vai se entender bem com o resto das palestras.

Minha palestra ainda é a segunda da tarde e eu já estou nervoso. :-)

Atualização: A apresentação do Nunes terminou, recheada de vídeos do Matrix–eu não posso reclamar, é claro–e foi muito boa, deixando o pessoal realmente com água na boca. Em vista do meu texto de ontem, há uma certa ironia com o fanatismo demonstrado pela comunidade Ruby. O que é, de certa forma, esperado, dada a enorme distância dos outros frameworks, mas não algo do qual gosto.

Atualização: A segunda palestra é sobre o Brazilian Rails, um plugin desenvolvido pelo pessoal da Improve IT com o propósito de facilitar o desenvolvimento em Rails para comunidades falantes de português. Iniciativa legal e do tipo que estamos precisando mais. Agora, usarcomodinheiro :valor foi dose. :-)

Atualização: A terceira palestra do dia é o case do O Curioso que tivemos no Minas on Rails também. A palestra é realmente interessante e mostra um uso real do Rails em uma aplicação com um base enorme de dados (400 mil usuários onde só a tabela de scraps adquirida tem 160GB). “O Curioso é um site pirata mesmo”, diz o Eduardo. :-)

Atualização: A quarta palestra é com o pessoal do projeto Lucidus, da Improve IT. Eu já tinha visto a apresentação em Belo Horizonte com o Vinícius e agora estou vendo com toda a equipe. Como tinha dito no meu breve relatório sobre o Minas on Rails, a apresentação é uma visão excelente do uso do Rails com XP e de como uma equipe pode otimizar o processo ao máximo e basicamente vencer basicamente qualquer obstáculo tecnológico ou social no desenvolvimento. A apresentação foi mais rápida, com um bocado de tempo para perguntas que funciona muito bem nesse tipo de apresentação.

Atualização: A quinta palestra é com o Fábio Akita, falando sobre a mágica por trás do Rails. Para o pessoal que já está impressionado, acho que a palestra vai deixá-los ainda mais de queixo caído. O Akita disse que eu sou culpado por uma mudança na palestra dele. Eu juro que não foi intencional. :-) Aliás, boa citação das três leis de Clarke das quais sou fã de longa data. Aliás, boa sacada de combinar um screencast gravado com uma apresentação. Facilita enormemente se você quer exibir código em certo detalhe. O único problema é a velocidade que tem que ser graduada.

Atualização Parentética: Eu acho que sou o único Ronaldo da comunidade Rails mais vísivel (pelo menos no Working With Rails eu sou o único de dois Ronaldos com um perfil definido) mas todo mundo me chama de Ronaldo Ferraz. Deve ter alguma razão para isso. :-)

Atualizacão: Akita está mostrando as mudanças para o Rails 2.0 usando o tradicional exemplo do blog com as facilidades da nova versão que deixam o exemplo bem mais simples em termos gerais (existem detalhes, é claro, que para o desenvolvedor experiente são mais fáceis que para o novo e não mapeiam bem mas o exemplo geral é muito bom). O mais legal é ver o povo que já desenvolve balançando a cabeça em aprovação das novidades.

Atualização: A apresentação foi muito boa mas algumas coisas poderiam ser cortadas pela semi-impossibilidade de mostrar tudo 100% (como as partes do Ajax, iPhone e algumas outras). Ainda assim, foi bom para o pessoal ver como o Rails se move bem rapidamente em termos de desenvolvimento.

Atualização: Hora da minha palestra. A gente volta daqui a pouco. :-)

Atualização: Acho que a palestra foi razoavelmente bem, mas como sempre é complicado passar DSLs para uma audiência mista. Quem já tem uma experiência mais pesada gosta de código e quem não tem tanta experiência fica meio chocado com o peso. :-)

Atualização: A próxima palestra é com o Danilo Sato falando sobre BDD e RSpec. Eu geralmente prefiro o BDD ao TDD puro e é bem interessante expor mais o pessoal ao assunto.

Atualização: Sempre que eu uso, leio ou ouço sobre RSpec, eu não me vejo fazendo outra coisa. Pode ser da forma como minha mente funciona, mas BDD é muito mais intuitivo e mais interessante do que TDD puro.

Atualização: Palestra final começando com algum atraso. O Carlos Eduardo vai falar sobre Flex, via TreinaTom, algo que deve interessar bastante gente. Quero ver é se a conexão de rede agüenta. Durante o dia estava estável mas bem lenta e cheia de bloqueios. Se der, o pessoal com certeza vai se impressionar com o que dá para fazer em termos de RIA.

Atualização: Acabei de chegar em BH. Cansado mas contente com o resultado do evento. A organização foi excelente, o pessoal do Rio é extremamente solícito e o pós-evento foi bastante divertido, relaxando perto da praia e jogando papo fora com o pessoal. Quase perco o último ônibus para BH mas acabou dando tudo certo. Agora só preciso de descansar para levar o filhote no parque mais tarde.

Para terminar, um obrigado especial ao Vinícius e ao resto da turma da Improve IT / Lucidus tanto pelo convite quanto pelo tratamento do Rio. Foi bom também conhecer algumas pessoas que antes só eram avatares em programas: Cris Dias, que é mais pragmático do que eu imaginava; Fernando Campos, do curso da e-Genial; Fábio Akita; e vários outros que minha proverbial falta de memória impede de recordar o nome. Aliás, eu realmente preciso de alguma técnica de associação: lembrar o rosto e não lembrar o nome é dose.

No resumo, foi um evento muito bom e acho que ano que vem já estamos encaminhados para algo bem positivo por toda a comunidade Ruby e Rails. Agora peço licença enquanto vou jogar um pouco de Need For Speed. Até a próxima.

Rails ou Django? Rails e Django!

December 7th, 2007 § 6 comments § permalink

Os dois frameworks irmãos, Django e Rails, receberam recentemente sua dose de atenção da revista Info. O mais interessante é que, nos dois casos, o Python e o Ruby foram considerados os pontos fracos dos seus respectivos frameworks.

Embora eu não tenha lido as matérias na íntegra, eu imagino que os autores das mesmas tenham pensando em ter que aprender uma linguagem nova como o ponto fraco e não nas linguagens em si como algum problema. Novamente, não posso dizer se os autores são programadores mas, se não forem, também é possível entender porque chegaram a uma conclusão assim.

Negativismo à parte, eu acho interessante a atenção que novas linguagens estão recebendo, principalmente as dinâmicas. O fato de que as linguagens são consideradas um problema é mais uma reflexão do mercado do que da realidade de uso das mesmas. Qualquer programador que valha metade do seu cargo sabe que aprender novas linguagens é essencial para sua permanência no mercado, mesmo que ele vá usar uma delas na maioria do tempo.

A proximidade das matérias me leva a crer que a consciência do Rails, Ruby, Django e Python está crescendo como nunca. Quando matérias desse tipo se tornam mainstream, não demora muito para que se filtrem também para o topo da escala decisória.

O que fica, pelo menos como eu considero a questão, é uma lição para programadores Web. Aprender somente Ruby ou somente Django pode ser menos trabalhoso mas aprender os dois provavelmente faz bem não só para sua carreira em termos de crescimento técnico como também em termos de mercado.

Amanhã é o Rio on Rails

December 7th, 2007 § 4 comments § permalink

Amanhã é dia do Rio on Rails e eu estarei lá para mais uma palestra. O assunto é Domain Specific Languages, sobre o qual já falei no Minas on Rails. Dei uma melhora e incrementada no material–no dia do Minas on Rails eu tive que correr um pouco por causa do tempo bem limitado–e acho que dá para explicar bastante o que são DSLs e como elas podem ajudar qualquer programador.

Se você se interessa pelo assunto–sendo Ruby ou não–e mora no Rio, apareça. Nos vemos amanhã.

Where Am I?

You are currently browsing the Rails category at Superfície Reflexiva.