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.
9 Comentários | 
Comentários Gerais | 
Link Permanente
Escrito por Alexandre Garrefa
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.
2 Comentários | IDE | Link Permanente
Escrito por Alexandre Garrefa
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.
Alem destes tutoriais, existe uma parte no forum destinada apenas para posts de tutoriais. Vale a pena conferir clicando aqui.
83 Comentários | Comentários Gerais, Rails | Link Permanente
Escrito por Alexandre Garrefa
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.
Deixar um comentário » | Comentários Gerais, David Heinemeier Hansson, Rails | Link Permanente
Escrito por Alexandre Garrefa
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.
Deixar um comentário » | Comentários Gerais, David Heinemeier Hansson, Rails | Link Permanente
Escrito por Alexandre Garrefa
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.
1 Comentário | Comentários Gerais, David Heinemeier Hansson, Rails | Link Permanente
Escrito por Alexandre Garrefa
Estive lendo o blog do Akita, que é muito bom, e achei muito interessante a ideia de software de opinião (opinionated software), o Akita tem vários posts sobre o assunto, alguns que eu achei e que gostei muito são Rails Sucesso Pela Arrogancia e David Hansson e Opinionated Software. No segundo post foi que encontrei o link para a entrevista do David que eu traduzi abaixo.
Está é a tradução da entrevista que o David Heinemeier Hansson deu ao Edd Dumbill para a O’Reilly Network. Pra quem não sabe, David, é o criador do Rails.
A entrevista original pode ser encontrada neste link.
Parte II, Parte III, Parte IV.
Por Edd Dumbill
30/08/2005
Poucos devem ter perdido o aparecimento da mais recente estrela das plataformas de programação – Ruby on Rails. O criador do Rails, David Heinemeier Hansson, já deixou a multidão estasiada no OSCON deste ano e está escalado para uma palestra na European O’Reilly Open Source Convention, que acontecerá em agosto deste ano, em Amsterdam.
David mora em Copenhagen, Dinamarca, e é sócio da inovadora 37signals, criadora do sistema web para gestão de projetos conhecido como Basecamp. A O’Reilly Network conversou com ele sobre o sucesso e o futuro do Rails.
Sobre o Sucesso do Rails
Edd Dumbill: Rails está se tornando mundialmente popular. Quando o criou em 2004, você tinha ideia de que ele seria tão bem aceito como tem sido?
David Heinemeier Hansson: Sim e não. Não acho que se possa predizer, muito menos planejar o tipo de sucesso que Rails tem atualmente. Mas eu tinha um bom palpite sobre a possibilidade dele ser bem aceito, principalmente por eu me sentir tão bem trabalhando em Rails. E eu achei que se esta ferramenta podia melhorar tanto o meu prazer e a minha produtividade em comparação com a maneira convencional de trabalhar que eu tinha utilizado no passado, porque ele não seria capaz de proporcionar o mesmo para outras pessoas?
Eu acho que consegui representar dois contextos que são pouco comuns na programação. Eu estive trabalhando com PHP por um longo tempo, então eu tinha aquela ânsia por fazer as coisas de maneira rápida, me preocupando em ver o resultado antes de todo o resto. Ao mesmo tempo, eu tive uma educação universitaria e trabalhei com Java em uma loja desenvolvida em J2EE por um tempo. Isso me fez dar valor a pureza e a facilidade de manutenção que bons padrões e práticas podem te dar.
Então eu estava no cruzamento entre duas filosofias muito populares em desenvolvimento de software. Aquela representada pelo PHP era rápida-e-suja, já a do Java era lenta-e-limpa. Combinar essas influências para chegar a última meta – rápido-e-limpo, me deu motivos para andar pelos dois lados.
ED: Qual você acha que é o ponto chave para a popularidade do Rails?
DHH: Não existe uma chave. Isto é, não existe apenas uma grande inovação no Rails para que se possa apontar e dizer: este é o motivo. De alguma forma, isso faz com que Rails seja mais difícil de se explicar pois a ideia não pode ser concreta e ao mesmo tempo seguir apenas uma linha de pensamento.
Mas vamos focar em apenas uma das chaves: Rails é software “de opinião” (opinionated software). Ele se diferencia por ignorar os antigos ideais de desenvolvimento de software. Um destes ideais é a flexibilidade – a noção de que nós devemos tentar integrar o maior número possível de opções, que não devemos julgar formas de desenvolvimento, ignorando uma em favor de outra. Bem, Rails faz isso e é por isso que eu acho que funciona.
Com Rails você troca flexibilidade no nível da infraestrutura para ganhar flexibilidade no nível da aplicação. Se você tem a felicidade de trabalhar no caminho de ouro que eu defini para o Rails, você tem uma recompensa imensa em termos de produtividade que te permite fazer mais, mais rápido e melhor em nível de aplicação.
Ainda assim, não é uma venda fácil. Vejá só as guerras travadas de tempos em tempos sobre padronização de código. Se as pessoas simplesmente pudessem concordar com uma forma de posicionar suas chaves ({ }), eles provavelmente poderiam códigos mais legíveis e uniformes. Para muitas pessoas isso não funciona, pois a troca não lhes parece boa o suficiente. Obter uma base uniforme de codigicação é frequentemente tratada como não mais importante do que “liberdade” individual por muitos programadores.
Em essencia, Rails tenta fazer o mesmo que os padrões de código fizeram, mas a razão para a qual ele está se saindo melhor é que a troca é muito mais doce. Conseguir uma base de codificação uniforme é uma meta abstrata e alguns grupos de programadores. Ver a sua aplicação funcionando em uma fração do tempo que você levaria antes é uma meta muito concreta e individialmente recompensadora.
Uma característica dos softwares de opinião é a noção de “convenção sobre configuração”. Se você seguir convenções básicas, como classes são singulares e tabelas são plural (a classe pessoa se refere a tabela pessoas), você é recompensado por não ter que configurar esta ligação. A classe automaticamente sabe que tabela usar para persistência. Nós temos uma tonelada de exemplos como este, onde a utilização todos acaba por fazer uma enorme diferença no uso diário.
2 Comentários | Comentários Gerais, David Heinemeier Hansson, Rails | Link Permanente
Escrito por Alexandre Garrefa
Essa é uma pergunta que eu me fiz pelo menos umas 300x durante o ano de 2006. MVC é a sigla para Model-View-Controller, uma metodologia de design que divide o software em 3 partes.
Lindo, eu li isso em milhares de lugares diferentes, mas a pergunta persiste, What The Fuck Is That? Que negocio é esse de estado da aplicação? Ok, a parte das telas eu entendi, mas poxa, que raios é a lógica de negócio de uma aplicação? E como eu junto isso tudo?
Ontem todas estas minhas perguntas foram respondidas :)
Estou aprendendo ainda, então se você já tem experiência com isso e estiver lendo alguma besteira, por favor me avise, assim como fez o Danilo Magrini e eu já corrigi os erros que ele apontou. Valeu Danilo.
A figura abaixo foi retirada do livro Agile Web Development With Rails e ilustra bem o modelo MVC.
Facil não? Só não entendo por que demorei tanto para aprender isso. Enfim, acho que o único texto que encontrei que explica isso direitinho foi o Agile.
O mais curioso de tudo é que eu sempre achei que MVC era uma ideia nova. Nova nada, MVC foi idealizado em 1979!!! E eu achando que MVC era pra web apenas. Trygve Reenskaug foi o cara que pensou no MVC, engraçado que o pessoal do desenvolvimento web só se voltou pro MVC muito tempo depois de quebrar a cabeça e fazer o sistema todo num bolo só (monolítico). O site oficial dele pode ser acessador por aqui.
14 Comentários | MVC, Software Design | Link Permanente
Escrito por Alexandre Garrefa
Alguns pontos do dia de hoje.
Deixar um comentário » | Comentários Gerais | Link Permanente
Escrito por Alexandre Garrefa
Após testar algumas coisas me decidi por utilizar o eclipse como IDE. É impressionante como o eclipse cresce, a gente encontra plugins pra tudo nele. Bom, junto com ele estou utilizando o plugin RadRails. Não fui atrás de saber o motivo, já que tenho pressa de iniciar logo a codificação, mas a instalação do RadRails pela interface de instalação de plugins do eclipse não deu muito certo pra mim, acabei fazendo o download e instalando manualmente, ai ele criou o radrails.exe que eu uso pra abrir o eclipse com o plugin ativado, pela instalação automatica ele até me deixava criar o novo projeto, mas depois que eu iniciava servidor ele não encontrava nenhum dos métodos que eu tinha criado. Enfim, com a instalação manual tudo funcionou belezinha e até resolveu um outro problema meu, eu estava usando o plugin Ruby Development Tools (RDT) e iniciava o servidor e fazia geração de models, controllers e etc via console, agora faço tudo pelo eclipse :)
Após a instalação do RadRails é necessário configurar os caminhos dos scripts que este plugin utiliza. Para isso é só ir em Window->Preferences, selecionar Rails->Configuration e setar os caminhos do rails, rake e mongrel. Detalhe, é necessário ter instalado o ruby antes, nesse link é possível fazer o download. Eu estou rodando o ruby no Windows, e eu instalei o ruby em C:\ruby, sendo assim, os caminhos que eu setei para o rails, rake e mongrel foram: C:\ruby\bin\rails, C:\ruby\bin\rake e C:\ruby\bin\mongrel_rails. Mais um detalhe, após instalar o ruby no windows, eu tive que ir ao command, entrar no diretório C:\ruby\bin e fazer: gem install rake mongrel. Com isso ele instalou tudo que preciso para continuar o desenvolvimento.
Feitas estas configurações, ainda na tela de preferências, ir em Ruby->Installed Interpreters e configurar o interpretador. É só clicar em add, definir um nome (ruby) e dar o caminho, no meu caso C:\ruby\bin\ruby.exe. No meu aqui eu criei dois interpretadores, um eu coloquei como nome ruby e caminho C:\ruby\bin\rubyw.exe (que ficou como interpretador padrão), e o outro eu criei como ruby console e o caminho C:\ruby\bin\ruby.exe. A diferença é a seguinte, quando você interpreta um programa com rubyw.exe, ele não abre um console, já com o ruby.exe o console é aberto. Assim quando eu crio um programa em ruby pra desktop em linha de comando, eu interpreto com ruby.exe, nos outros casos eu uso o rubyw.exe.
Finalizando, falta ir em Ruby->RI/rdoc e configurar o caminho para os mesmos. Aqui ficou C:\ruby\bin\rdoc e C:\ruby\bin\ri.
2 Comentários | IDE | Link Permanente
Escrito por Alexandre Garrefa
