Status da Agenda

Pessoal, não desisti da idéia de fazer a agenda em RoR não. A agenda está quase pronta, só estou apanhando um pouco na parte do layout, mas a parte lógica já está 100% funcional. Acredito que devo ter ela toda pronta até o fim da semana e ai coloco em um servidor meu pra vocês acessarem, divulgarei os fontes e também um tutorial passo a passo de como construí-la.
Continuem seguindo o blog que até o fim da semana terei boas novidades.

Abraços e aproveitando, feliz 2007 a todos.

RadRails e Textmate Templates

Sabe aqueles videos do David Heinemeier demonstrando o Rails? Vai dizer que você não morre de inveja quando ele usa aqueles atanhos pra automaticamente completar o código? Bom, a não ser que você tenha um Mac e o Textmate, você sente inveja.
Estava pesquisando no google uma maneira de criar um wizard para .rhtml no RadRails, acho um saco ter que toda hora criar um arquivo vazio, renomear e colocar la dentro sempre o mesmo código (doctype, html, body, head). Eis que sem querer eu encontro este santo post Dr. Nic: Templates Textmate para RadRails e agora minha vida é muito mais feliz podendo usar grande parte dos atalhos no meu RadRails. Valeu Dr. Nic, valeu mais uma vez Akita.
Falando em Akita, quarta chega o livro dele que eu comprei, não vejo a hora :)

PS: Se alguem souber como crio o wizard no eclipse, ficarei muito agradecido se me contar.

Rails Forum e Tutorial October

Estava navegando por ai, lendo sobre Rails e sem querer cai no Rails Forum. A primeira parte que visitei foi Forum News, eis que vejo um post com o nome de Tutorial October. Os caras fizeram uma competição de tutoriais sobre Rails com premios para os melhores. Tem tutoriais muito interessantes e entre eles achei dois que são de uma dúvida que estava me impedindo de terminar a versão 0.1 da minha agenda. Acredito que vou traduzi-los em breve, juntamente com os outros, já que todos são excelentes. Segue abaixo a lista dos tutoriais postados, marcados com * estão os que eu tenho interesse imediato de traduzir e que devem pintar por aqui logo logo.

• XSS and when h just ain’t enough by raensene
• HOWTO: Make a Rails Plugin From Scratch by danger
• Refactoring on Rails: Move to Model by ryanb
• Refactoring on Rails: Multiple Scopes in Controller by ryanb
• *Creating Two Models in One Form by ryanb
• *Editing Multiple Models in One Form by ryanb
• Test Helper: Clean, Custom Assertion Messages by ryanb
• Debugging on Rails: Reading Stack Traces by ryanb
• Introduction to Form Helpers by ryanb
• Programming Best Practices by ryanb
• *Advice to Rails Beginners: Follow Conventions by ryanb
• Handy RJS Tips by ryanb
• Using Autotest with Rails on Windows XP machines by daibatzu
• Image uploads and resizing for Rails models with mini-magick by daibatzu
• HOWTO: Send Instant Messages in Rails by bp
• *Creating Many Models in One Form by ryanb
• *Creating a Variable Number of Models in One Form by ryanb
• Getting Started With RESTful Rails by bp
• Rails Migration For Beginners by vin

Alem destes tutoriais, existe uma parte no forum destinada apenas para posts de tutoriais. Vale a pena conferir clicando aqui.

Ruby on Rails: Entrevista com David Heinemeier Hansson – Parte IV

Ultima parte da tradução da entrevista que o David Heinemeier deu a O’Reilly Network.
Parte I, Parte II, Parte III.

---

ED: Apesar dos bancos de dados relacionais cobrirem 90% dos casos de uso, existem momentos em que diferentes métodos de armazenamento são muito úteis. O que você acha de adicionar meios de armazenamento alternativos como um banco de dados orientado a objetos ou um RDF datastore?

DHH: Rails vai servir muito bem com qualquer modelo que você puder imaginar. Como exempo, Instiki, o wiki que eu criei, foi recentemente portado para Rails mas ainda usa Madeleine (uma implementação de Prevayler em Ruby que funciona mais ou menos como um banco de dados orientado a objetos) como backend.

Assim, é até que fácil esquecer Active Record e usar alguma outra coisa como backend. Eu vi recentemente pessoas utilizando SOAP, SAP, LDAP e um monte de outros backends. Até mesmo arquivos de texto puro. Tudo isso é possível.

O que de fato aconteceu é que o Active Record reduziu o sofrimento de lhe dar com as dificuldades do objeto-relacional a um ponto onde é muito menos interessante procurar por alternativas – especialmente com bancos de dados como SQLite que te dão a impressão de trabalhar com arquivos de texto puro, mas num contexto SQL.

Meu entusiasmo pessoal para com projetos como o Madeleine diminuiu muito conforme o Active Record se tornava cada vez melhor. Não significa que as outras possibilidades não sejam boas, simplesmente tem sido muito mais facil pra mim trabalhar com Active Record do que procurar alternativas.

ED: Um grande número de frameworks web tem sofrido por se tornarem grandes demais e pontencialmente impossíveis de se administrar, Zope por exemplo. Qual a sua estratégia para evitar isso?

DHH: Ficar abaixo da camada de infraestrutura. Não deixar a lógica de negócios fazer parte do framework. Não é a responsabilidade do Rails tratar de administração de conteúdo, listas de controle de acesso, forums, chats ou qualquer outra coisa que você fizer. Tratamos da estrutura geral que faz sentido para todo o tipo de aplicação.

Assim nós jamais nos tornaremos um Zope, ou OpenACS, ou qualquer outro framework que tenha se perdido nas águas da lógica do negócio e tenha sido consumido por ela.

Nós nos preocupamos em facilitar cada vez mais o que a maioria das pessoas fazem na maioria das vezes em qualquer tipo de aplicação. Por exemplo, estamos contruindo um novo subprojeto chamado SwitchTower (o nome do projeto mudou para Capistrano e seu manual pode ser encontrado clicando aqui) para as próximas versões do Rails. Ele resolve o problema de deploy da aplicação para o servidor de produção. Este é um problema com o qual a maioria das pessoas tem que lhe dar, mas ele não complica o processo de desenvolvimento deixando as ferramentas básicas mais complicadas. Ele simplesmente está lá, esperando pacientemente até que você precise dele.

ED: Quais as próximas novidades que veremos no Rails?

DHH: Eu já falei sobre o SwitchTower que será uma das novidades principais, por outro lado, estamos perto do lançamento do Rails 1.0 agora. É a corrida e o polimento final.

Depois disso nós temos muitos planos. Estou especialmente excitado com o Conductor. Mas eu vou manter este projeto em segredo por um pouco mais de tempo.

Parte I, Parte II, Parte III.

Ruby on Rails: Entrevista com David Heinemeier Hansson – Parte III

Continuação da entrevista do David a O’Reilly Network.
Parte I, Parte II, Parte IV.

---

ED: Você em algum ponto pensou que Rails poderia ter sido melhor se tivesse sido escrito em Java ou Python?

DHH: Melhor é um termo muito inadequado e ambíguo para ser aplicado a uma comparação como esta. Se ficarmos em dúvida por um segundo, eu poderia imaginar que Rails em Java teria uma aceitação mais rápida e fácil por parte das corporações. Mas isso não é um critério de sucesso muito importante para mim. Eu criei Rails para me ajudar a fazer o meu trabalho de forma melhor, mais rápida, e não para ser uma ferramenta de adoção em larga escala. Que isso esteja acontecendo é ótimo, mas provavelmente não aconteceria se eu tivesse tentado fazer isso concientemente.

Sobre Python, eu não sei. Olhando de fora, Python e Ruby são muito similares. Mas por dentro, são as pequenas diferenças que fazem com que pareçam mundos muito diferentes. Python com certeza tem vários apelos interessantes, e se não fosse Ruby, eu poderia com certeza me ver nesse campo.

Eu acho que Rails tem as características que tem, exatamente por ter muito do estilo do Ruby. Ele joga pesado com o melhor de Ruby. Os blocos, a facilidade de criação de linguagens de domínio específico, e todo o resto.

ED: Você consideraria recomendar PHP ou Perl para contruir aplicações web agora?

DHH: Claro! Rails não é tudo para todos a qualquer hora. Eu uso PHP vez ou outra quando eu preciso apenas de um esboço de página com conteúdo dinâmico. Nós utilizamos PHP na 37signals em todas as páginas de propaganda que precisam apenas de alguns includes e coisas do tipo.

Apesar disso, Rails está a frente da maior parte dos aplicativos web. Se você estiver me perguntando se eu recomendaria PHP ou Perl ou qualquer outra coisa que seja para contruir aplicações como Basecampo, 43things.com, ODEO, Strongspace, e outros, a resposta certamente é não.

De qualquer forma, as circunstâncias a sua volta podem te levar a faze-lo. Eu acho que estas circunstâncias são na maior parte das vezes superestimadas. Por exemplo, que só porque você não tem nenhum programador Ruby no seu grupo, você não pode usar Rails. Ou porque você utilizou outro ambiente de desenvolvimento no passado, você não pode mudar. Besteira. Bons programadores são bons programadores. E Rails é muito parecido com oque você vem fazendo antes do que você pode imaginar – menos um monte de sofrimento, naturalmente.

Sobre Web Frameworks

ED: Uma das coisas que eu gosto no Rails é a diferenciação entre os ambientes de produção e desenvolvimento. Este tipo de funcionalidade não vem incluída por padrão em ferramentas web para linguagens de script. Você tentou concientemente colocar algumas “funcionalidades enterprise” no Rails?

One of the things I like about Rails is the differentiation between production and development environments. Those kind of features don’t normally come built in with scripting language web tools. Did you consciously set out to provide some “enterprise” features in Rails?

DHH: Eu tentei servir a mim mesmo. Rails é um projeto muito egoista neste ponto. Ele tem ganho muito do foco e apelo porque eu não tentei agradar a pessoas que não compartilham dos meus problemas. A diferenciação entre ambiente de produção e desenvolvimento era um problema muito real pra mim, então eu o solucionei da melhor maneira que eu sabia fazer.

É muito difício resolver os seus próprios problemas com propriedade. Tentar resolver o problema dos outros é muito perto de algo impossível – pelo menos fazê-lo com um nível de satisfação que me deixaria interessado na solução.

Este é o motivo pelo qual mantemos a noção de que “frameworks são extrações” tão presente na comunidade Rails. Frameworks não são designados antes do fato. Eles são extraídos quando você prova a si mesmo que uma idéia funciona. Sempre que nos colocamos a frente de nós mesmos e tentamos pular o processo de extração, voltamos desapontados.

Eu acredito que este seja o motivo para o qual Rails parece bom para tanta gente – porque ele é utilizado por pessoas reais, para trabalhos reais, antes que nós empacotemos para que outros possam reutilizar.

Parte I, Parte II, Parte IV.

Ruby on Rails: Entrevista com David Heinemeier Hansson – Parte II

Continuação da entrevista que o David Heinemeier Hansson deu a O’Reilly Network.
Parte I, Parte III, Parte IV.

---

ED: Qual foi a utilização mais surpreendente ou gratificante de Rails que você viu até agora fora da 37signals?

DHH: Tem sido muito gratificante ver o sucesso do 43things.com. A Robot Co-op foi talvez a primeira grande empresa a apostar em Rails logo após o seu lançamento. Eles tiveram uma grande motivação para seu trabalho: ajudar as pessoas a atingirem suas metas de vida. Como alguem pode não amar isso?

E funciona! Eu fui convidado para dar a palestra na OSCON em parte por Nat Torkington ter visto minha lista de metas e notado que uma delas era “fazer uma palestra sobre Rails para mais de 500 pessoas”. Ele entrou em contato e em agosto eu dei uma palestra para uma plateia de 2000 pessoas na OSCON.

Mas em geral, eu estou extremamente encantado em ver que a adoção do Rails tem acontecido tão rapidamente e que atualmente sabemos que existe toda uma economia girando em torno deste framework. Em nossa lista de pessoas trabalhando profissionalmente com Rails, podemos contar mais de 3000 pessoas de mais de 40 países diferentes. Estou continuamente extasiado por isso.

ED: Qual é a sua funcionalidade favorita do Rails?

DHH: Em geral, todas as coisas que ele não faz. Todas as funcionalidades para as quais dissemos não. Todos os ornamentos que não fizemos. Todo os seus 20% de soluções que resolvem 80% dos problemas.

Mais especificamente, eu realmente gosto da nossa linguagem de domínio específico. A beleza de especificar relacionamentos com belongs_to (pertence_a), has_one (tem_um), has_many (tem_muitos) e has_and_belongs_to_many (tem_e_pertence_a_muitos). A facilidade de uso de validações como validates_presence_of :name (validar_a_presença_de :nome).

Sobre Linguagens de Programação

ED: Quando eu vi Rails pela primeira vez, devo admitir que ser um framework para Ruby me fez pensar duas vezes. É uma linguagem incomum. Como você conheceu Ruby?

DHH: Eu comecei o Rails no verão de 2003. 37signals estava para iniciar o desenvolvimento do Basecamp – o que iria finalmente transformar a empresa de uma firma de consultorias para uma desenvolvedora de produtos. Tinhamos trabalhado com PHP por anos e eu tinha tentado o máximo que podia para conseguir um framework reutilizavel que me proporcionaria uma vida mais fácil. E eu na verdade tinha uma versão bem inicial de Rails rodando em PHP naquele tempo, mas eu não estava feliz.

Então cheguei a um daqueles momentos “ame-o ou deixe-o”. Eu entendi que se isso iria ser o trabalho da minha vida, desenvolver aplicações web, eu precisava usar ferramentas que eu amasse, não ferramentas eu eu simplesmente tolerava. Então eu me abri a alternativas.

Então minhas influências conspiraram. Sou um grande fã tanto do Pragmatic Programmers quanto do Martin Fowler, e eu via Ruby sendo comentado constantemente pelos dois lados. E um amigo meu me passou a idéia básica da linguagem e me desafiou a encontrar razões para continuar com PHP.

Então, por um curto período, eu entrei em “modo desculposo” (tradução é um trabalho ingrato rs) e construiu vários argumentos sólidos para rejeitar a mudança. Nós não vamos encontrar programadores que conheçam Ruby para a 37signals, PHP provavelmente tem uma biblioteca maior e melhor, e assim foi. Mas felizmente isso não durou muito pois eu decidi realmente dar uma chance ao Ruby.

Levou um dia para eu dizer: eu realmente gosto disso. Levou uma semana para eu dizer: nunca mais vou voltar a programar em PHP. E levou um mês até que minha proficiência com Ruby me fizesse andar em circulos pensando nas minhas antigas possibilidades com PHP. Foi simplesmente um encaixe poderoso e inacreditável. Ruby se encaixou ao meu cérebro de forma perfeita. Eu comecei a ter muito mais prazer e a fazer muito mais.

Eu entendo que isso faz PHP parecer ruim, mas não é nada disso. Sou grato ao PHP. Ele me iniciou na programação por sua capacidade impressionante de obter resultados de forma imediata. Me serviu muito bem por um longo período. Eu simplesmente cheguei em um ponto que estava fora do que eu considerava doce naquela linguagem e o Ruby provou ser exatamente o que eu precisava para voltar a esse ponto doce novamente.

---

Parte I, Parte III, Parte IV.