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?

Removendo as pedras

May 15th, 2008 § 2 comments § permalink

Hoje terminamos nosso quarto sprint. Foram duas semanas intensas e estamos bem satisfeitos com o resultado: não só a nossa velocidade (a referência de execução que o Scrum usa) aumentou significativamente (e ultrapassou as expectativas), como ainda tivemos tempo de experimentar com uma série de técnicas que tínhamos vontade de usar e estabelecemos vários utilitários para o time que ajudaram e vão ajudar ainda mais nos próximos sprints.

Nesse sprint decidimos usar pair-programming e ver qual a diferença isso fazia em nosso processo de desenvolvimento. Não só registramos um aumento de produtividade enorme como a qualidade do código gerado deu um salto impressionante. Um dos pontos fortes do Scrum são as medições realizadas que levam ao gerenciamento de expectativas proposto por metodologias ágeis.

O mais interessante, porém, foi constatar que a velocidade dos times é relativamente constante em relação aos outros, o que indica que pair-programming é uma técnica bem eficiente de disseminação de conhecimento. Como ainda tínhamos pessoas com um contato relativamente recente com Rails, eu acho que esse foi um dos principais fatores para que a equipe pudesse chegar a um ponto de familiarização rápida com a tecnologia sem onerar o desenvolvimento.

O melhor de tudo foi constatar que nenhum dos nossos temores em relação a tempo ou pressão se concretizou. Isso, pelo menos para mim, representa um dos maiores ganhos do processo: conseguir precisar entregas realísticas e cumprir essas estimativas. Que jogue a primeira pedra quem nunca reclamou de gerentes que passam prazos fora da realidade e que depois sofreu com a queda de qualidade. Combinar prazos satisfatórios a todas as partes e ainda conseguir qualidade é algo que nenhum outro tipo de processo exceto os ágeis é capaz de dar.

Obviamente, isso não implica que eu acho o Scrum perfeito. Há algumas coisas, que eu quero explorar aqui no futuro, que me incomodam. Apesar disso, a experiência tem sido bem interessante. E que venha mais um sprint.

Squeak By Example: Progresso da Tradução

May 13th, 2008 § 3 comments § permalink

O trabalho de tradução do Squeak by Example para português continua indo bem. Considerando o trabalho divido entre tradução e revisão, estamos em 59% do primeiro e 29% do segundo.

Eu acabei de fazer o merge entre todos os clones de tradução e o repositório principal agora está atualizado com todo o trabalho feito até o momento.

Se alguém deseja participar, ainda há espaço para ambas as atividades. Alguns capítulos são bem grandes e podem ser traduzidos simultaneamente e os que já estão traduzidos ou sendo traduzidos precisão de revisão e verificação de estilo e uso de termos.

Só falta agora um wiki ou coisa assim para coordenarmos os detalhes de tradução para que na hora da revisão final seja mais fácil. E toca página para frente. :-)

Multidões

May 10th, 2008 § 8 comments § permalink

Eu me empolguei com computadores na primeira vez em que ouvir falar sobre eles. A possibilidade de comandar uma máquina, fazê-la executar o que eu queria e isso muito mais rápido do que qualquer coisa que eu poderia fazer manualmente era uma coisa saída das páginas de um livro de ficção científica–que, é claro, eu sempre li aos montes.

Minha primeira linguagem foi o Pascal. Eu tive a sorte de pular o Basic e partir direto para um linguagem mais poderosa, mais estruturada. Eu ainda me lembro da sensação de completar um programa particularmente complexo que implementava não só sua própria funcionalidade (um espécie de Paint que era requerido para o trabalho final de programação), como também toda uma família de objetos para interface gráfica com um loop de processamento de mensagens, controle de hardware. Esse era um código que ainda queria ter.

Poucos anos mais tarde eu estava programando na versão mais evoluída do Pascal, o Delphi. Eu já passara então por C, C++, Visual Basic (que me empolgou pela parte visual, é claro, mas cuja linguagem conseguia me irritar nos mínimos detalhes), e já tivera o meu primeiro contato com o mítico Lisp. Foram bons anos com Delphi, dos quais, ironicamente, só saíram três aplicações puramente desktop. Todos os demais anos que eu gastei com o Delphi foram em desenvolvimento Web. Eu perdi a conta de quantos ORM implementei, de quantos frameworks Web, bibliotecas e serviços construí. Foi uma época de aprendizado enorme.

Desde então eu já passei por dezenas de linguagens. Algumas profissionalmente, outras pelo mero prazer de descobrir uma sintaxe nova e ver o que há de interessante. Eu ainda não encontrei uma linguagem que não possui uma característica que a redimisse. Mesmo em linguagens que eu jamais usaria hoje para implementar um projeto a menos que fosse um requisito obrigatório passado pelo cliente, eu encontrei algo de interessante. Pode ser que o resto da linguagem tenha sido descartável, mas alguma coisa sempre era suficiente para justificar a existência da linguagem.

Smalltalk foi a linguagem que mais me fascinou. Foram anos antes que eu publicasse alguma coisa real na mesma, mas eu sempre experimentei com o que havia de interessante. Seaside, no mundo Web, ainda representa para mim o ideal de um framework Web atual.

Linguagens são arte. E arte é algo inteiramente subjetivo no aspecto de gosto e preferências. Mas linguagens também são ferramentas. E para isso, nada melhor do que pragmatismo. Mas a combinação dos dois pode produzir resultados fascinantes.

Eu sustento minhas próprias escolhas, entretanto. Eu não preciso de validação externa para entender o que é interessante e o que deixa de ser interessante. Eu acolho novos pontos de vista, e gosto de entender o que os outros vêem. E eu também tenho preferências. Elas mudarão e eu não me preocupo com isso. Há beleza em qualquer lugar–em última instância, programação também é religião.

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.

O presente do presente

May 6th, 2008 § 4 comments § permalink

Há pouco mais de um mês e meio cheguei em São Paulo para o início de uma aventura. Foi uma mudança em todos os sentidos: de uma cidade grande para uma cidade enorme; de um mercado corporativo, fechado para um mercado genérico, aberto; de uma empresa pequena para uma empresa cujos alvos são muito maiores e mais amplos.

Ainda não concluí o processo de mudança, mas esse está sendo sem dúvida um dos períodos mais empolgantes da minha carreira. Trabalhar no Brasigo tem sido uma experiência fascinante em múltiplos níveis. Fazia tempo que a pergunta “e eu ainda sou pago para fazer isso?” não me ocorria.

Voltar a trabalhar em equipe foi uma das coisas que só percebi como tinha sentido falta até estar no meio da galera. Contribuir para um produto e aprender zilhões de coisas novas–não só profissionalmente, mas pessoalmente–é algo que só um ambiente muito bom pode proporcionar. Poder trabalhar e se divertir, em um local bacana de passar as horas de trabalho é algo que não tem preço. Tem o fato que a equipe não vê a hora em que vou soltar uma palavrão, mas isso é algo em que vai ter que rolar um desapontamento básico. :-)

Mas também, como não fica empolgado: Rails, Wii, Scrum, conversas cabeça no meio do trabalho, BDD, arquitetura de produtos legais, hard-core programming, experimentos malucos, chefe desencanado, e até mesmo a cidade que não para e onde sempre tem alguma coisa interessante para fazer.

Bem, deu para perceber que eu estou gostando da mudança, mesmo com as confusões de arrumar local para morar e trazer a família. E, para não perder a oportunidade, estamos procurando mais gente para a equipe. Gente boa é sempre bem-vinda. :-)

Disciplina é liberdade

May 5th, 2008 § 2 comments § permalink

No que tange a metodologias ágeis, eu concordo com o poeta: disciplina é liberdade. Principalmente quando o ambiente é muito heterogêneo e a entropia começa a tender ao infinitivo. Dito isso, disciplina não é controle e metáforas misturadas são uma porcaria completa.

Uma questão simples

May 5th, 2008 § 8 comments § permalink

Em The Mythical Man-Month, Frederick Brooks afirma que a década após a publicação do livro não traria nenhuma “silver bullet“, isto é, nenhuma mudança de uma ordem de magnitude no processo de desenvolvimento de software através de alguma tecnologia nova. A afirmação já se sustenta há mais de 30 anos.

Pergunta: quando a inexistência de uma silver bullet se tornará um impedimento para a produção de software? Em outras palavras, existe um limite para o desenvolvimento com as tecnologias, ciência e ferramentas que temos hoje?

Qual é a cauda longa de aplicações?

May 2nd, 2008 § 5 comments § permalink

Depois de ler The Long Tail fiquei pensando sobre as aplicações do assunto para o desenvolvimento de software. Não em termos de produtos que podem ser entregues, mas dentro da própria aplicação, em uma curva de distribuição de uso.

Uma coisa é você ter itens que podem ser comercializados, outra coisa é você ter características que podem ser usadas e que possuem um determinado valor para o usuário final. Eu não tenho certeza plena–não cheguei a uma conclusão final sobre o assunto–mas acho que existe também uma cauda longa para características em um software qualquer que podem ser exploradas indiretamente.

Existe muito escrito sobre aplicações de regras 80/20 (ou X/Y para valores quaisquer) em relação à funcionalidade que se deseja criar para um aplicação, mas ainda não encontrei nada sobre customização. E talvez essa seja a cauda longa de aplicações: não o que está e não está, mas o que o usuário pode construir com as peças básicas que lhe forem fornecidas.E isso não é somente flexiblização, mas a habilidade real de montar novas interfaces/fluxos sobre o que existe e criar seus próprios recursos.

Não é algo que toda aplicação precisa, mas é algo que certamente tem um potencial incrível em ferramentas que dependem de uma agregação diversificada.

Bem, preciso pensar mais sobre o assunto. :) E vocês, o que acham?

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.

Where Am I?

You are currently browsing the Programação category at Superfície Reflexiva.