Este texto é uma tradução do artigo escrito por Matt Linderman para o blog Signal vs. Noise, originalmente em inglês. Outro dia, fui vender alguns livros na livraria The Strand. Eles têm um balcão separado na parte de trás para a venda de livros. Eu os trouxe em uma sacola e dois funcionários começaram a fazer [...]
Eu já falei do método try() antes. Na época era apenas uma dica dada por Chris Wanstrath (que ainda nem era famoso pelo GitHub) para simplificar o bom e velho trecho de código: @person ? @person.name : nil Que com este método ficaria assim: @person.try(:name) # Um outro exemplo, com parâmetros Person.try(:find, 1) Ele funciona como o Object#send, mas ao invés [...]
Meu amigo Márcio Gasparotto me deu de presente um logotipo para o projeto Remarkable! Veja abaixo: Agora só falta o site do projeto!
Não é segredo para ninguém que membros da comunidade brasileira de Ruby on Rails estão traduzindo os famosos Rails Guides para o nosso idioma. Liderados por Cássio Marques, o grupo é formado por Daniel Lopes, Carlos Antonio da Silva, Adolfo Sousa, Cairo Noleto e Warlley Rezende. Os Rails Guides apareceram recentemente como uma importante ferramenta de [...]
Guarde este dia: 23 de dezembro de 2008 – o Fim da Guerra Rails x Merb! Neste dia o Core Team do Rails e do Merb decidiram parar de brigar e resolveram trabalhar juntos para construir o melhor framework possível. Recebemos de braços abertos toda a comunidade Merb e esperamos que eles também estejam tão empolgados [...]
Um pouco de historia Os que me seguem no Twitter devem estar sabendo que nos últimos dias esteve trabalhando num projeto em Java porém utilizando RSpec para testar ele. Se você ainda testa código feito em Java utilizando Java, te recomendo sair dessa vida, gasta um dia ou o tempo que for necessário para poder criar [...]
Se você mora na Terra, deve saber que o Rails Edge adotou o Rack. Mas, o que é esse tal de Rack? O que é o Rack? O Rack é uma interface entre servidores web e aplicações Ruby, baseada no padrão WSGI do Python. Ele possui diferentes handlers para os mais diversos webservers, como: Passenger, Mongrel, Thin, Ebb, Webrick, entre outros. Ele é [...]
Vou me repetir sobre o que eu já disse em outro artigo, porque muita gente ainda não entendeu: Ruby on Rails não é a salvação que muitos pensam. Isso é bem óbvio, mas o próprio DHH resolveu dizer isso. Assistam a apresentação que ele deu na RailsConf Europe, em Berlim, este ano:
David Heinemeier Hansson’s keynote at RailsConf Europe 2008.
Essa apresentação se chama Legacy Software. Muita gente entra de cabeça em Ruby on Rails acreditando que ele é o Salvador da Pátria. Basta usar Rails que as aplicações serão magicamente perfeitas. Nada feito em Rails se torna “legado”. Legado é Java, PHP, etc.
Conheci Steve McConnell há muitos anos, primeiro com os livros After the Gold Rush e Software Project Survival Guide. Muitos o conhecem mais pelo Code Complete. Ano passado ele escreveu um excelente artigo sobre o assunto Dívida Técnica. Discutindo esse assunto recentemente, resolvi retornar a esse texto e traduzí-lo. Novamente, depois de anos de experiência eu ainda me surpreendo que este é mais um conceito que pouca gente discute e incorre no mesmo erro o tempo todo.
Antes de mais nada, o conceito de “Dívida Técnica”, é uma metáfora para indicar que toda vez que você toma um atalho técnico (o bom e velho “não importa que saia sujo, o importante é lançar o produto rápido!”). Isso não sai de graça. Toda vez que fazemos isso, é como fazer um empréstimo num banco, ou seja, é como assumir uma dívida. E como toda dívida, essa também corre juros e um dia será devidamente cobrada!
Extremistas costumam dizer “paguem tudo à vista, pois cartões de crédito são do mal.” Isso também não é verdade. Empréstimos podem ser bons e importantes. Que comerciante nunca teve um aperto de fluxo de caixa, onde um pequeno empréstimo não lhe deu um fôlego? O problema, como sempre, é o exagero, como o comprador compulsivo que inclusive paga um cartão de crédito com outro cartão de crédito! Muitas empresas agem exatamente assim com software: assumem centenas de dívidas e depois de alguns anos se assustam com o montante acumulado de dívidas a pagar.
E você: assumiu dívidas técnicas recentemente? Está preparado para começar a quitá-las? Segue a tradução do artigo original do Steve:
Depois de vários anos percebo que um grande número de programadores simplesmente não entende o Método Científico. Atualmente discutimos bastante sobre agilidade, sobre como fazer testes, TDD é importante. Em “testes” existe algo que deveria ser óbvio mas parece que não é. Existe um passo que considero muito importante que é a experimentação.
Da mesma forma como muitos usam “falta de tempo” como desculpa para não fazer testes, a mesma desculpa é usada para não testar hipóteses via experimentação (a maioria sequer entende que deveria estar experimentando hipóteses). O que estou falando aqui é sobre criar provas de conceito, “pedaços” do que você quer desenvolver que potencialmente será jogado fora. O “jogar fora” é a parte que deixa os programadores (e os gerentes) arrepiados. “Mas isso é perda de tempo, trabalho jogado fora! Inaceitável!”. Esse pensamento faz as pessoas pensarem que toda linha de código escrito necessariamente precisa estar na aplicação.
Novamente, é o errôneo pensamento que precisamos acertar tudo da primeira vez, a cultura de que tentativa-e-erro é errado. Pois bem, estou aqui dizendo que errado é pensar que sempre vamos acertar da primeira vez. Na maioria dos casos vamos errar todas as primeiras vezes.
activerecord_i18n_defaults é um plugin para Rails 2.2 que permite criar arquivos de localizações assim: pt-BR: activerecord: attributes: _all: login: "Identificação" name: "Nome" admin: [...]
Update: Como eu disse que ia acontecer, saiu o primeiro contra-ataque contra a EY, direto do pessoal da . Isso foi motivado por um blog post recente do Tom Mornini, CEO da EY.
Faz algumas semanas que temos Rails 2.2. Como já dissemos inúmeras vezes antes, a melhor parte é a Internacionalização. Mas há mais a ser dito.
Uma coisa que nunca teve muita atenção foi a parte de thread-safe. Talvez tenha sido só coincidência, mas é fato que o Merb provavelmente incomodou o Rails Core Team um pouco alguns anos atrás quando ele colocou como meta ser thread-safe. Nunca fez muita diferença porque o Ruby MRI, também como já falamos inúmeras vezes, apenas usa green-threads. Ou seja, não fazia sentido investir muito tempo num recurso que daria pouco retorno.
A esperança do Ezra e da EngineYard era criar um framework thread-safe em Ruby e ao mesmo tempo uma nova implementação de Ruby que também fosse thread-safe. Daí o motivo de adquirir o projeto Rubinius. Foi nessa época em que o Ezra falava de mod_rubinius. Porém, infelizmente o Evan ainda não conseguiu evoluir muito e recentemente, devido à crise econômica, a EY foi obrigada a dissolver a equipe do Rubinius. O sonho do “turtles all the way” ficou para depois.
Por outro lado, um desenvolvimento que o Rails Core ignorou foi o JRuby. No começo esse projeto ainda era lento, mas o Charles, Tom, Ola, Nick, e muitos mais da comunidade Java/Ruby foram extremamente rápidos. Do 1.0 ao 1.1.5 foram poucos meses e a performance sempre aumentou muito. Com a diferença de poder contar com a JVM, que lhe dá um garbage collection geracional, suporte a threads nativa, Strings UTF-16 e muito mais de graça.
Nesse cenário, sim, um framework thread-safe faz bastante diferença! E o Merb seria o framework mais completo e thread-safe. Por isso fez sentido o Rails Core também correr atrás disso, motivado pelo Merb estar se aproximando de lançar sua versão 1.0.
Mais do que isso, o lançamento do Merb 1.0 fez o DHH entrar em modo de evangelização. Foi quando ele começou sua série de posts de Mitos Rails. Até então ele praticamente não blogava e nem twitava, agora ele twita todos os dias. A EY também sempre atacou o Passenger. Mais explicitamente, em suas palestras recentes o Ezra diz que o Passenger só é bom para pequenos projetos. E o CTO da EY, o Tom Mornini disse muito mais contra o Passenger. Por isso, a 37signals e o próprio DHH passaram a apoiar bem explicitamente o Phusion Passenger como a melhor maneira de deployment.
Isso porque a EY, até agora, sempre vendou serviços de Rails mas evangelizou que a única maneira de escalar muito seria com nginx + mongrel + merb. O DHH está disposto a vender que a melhor opção é apache + passenger + rails. O desenvolvimento do Rails 2.3 já está evoluindo bem rápido. Em pouco tempo eles adicionaram o plugin Rg que dá templates: uma resposta aos Merb Stacks. E também começou um movimento em torno de melhorar a plugin Engines: outra resposta ao Merb Slices. Outra coisa que o Rails 2.3 está perseguindo – e o Merb também – é lazy loading. Na hora que li isso imaginei que fosse quebrar pois o Ruby não sendo thread-safe por natureza, a metaprogramação também não é. Nesse caso o auto loading de classes on demand facilmente poderia quebrar em 2 threads o que foi confirmado nessa discussão. Isso ainda vai evoluir, mas não sei o quanto isso é realmente eficiente.
No mundo Unix isso não faz muita diferença. O Windows (e isso não é um fanboyismo, apenas um fato) que tem o ineficiente CreateProcess mas não tem o equivalente a Fork e muito menos a copy-on-write. Com essas capacidades básicas um processo Unix pode criar uma cópia de si (fork) mesmo consumindo quase nada de recursos se a memória alocada interna for sempre constante (copy-on-write): que é o que o Ruby Enterprise Edition faz para economizar RAM. Aliás, ambos REE e Passenger tiveram novas versões lançadas recentemente, ambas apoiadas pela 37signals.
O Merb tem um suporte nativo a controlar clusters de processos Mongrel, de forma parecida como o Passenger faz com Rails, mas com a diferença que ele não é um módulo de Apache e ainda precisa configurar proxy reverso de HTTP manualmente. Além disso o Merb ainda não tem suporte a filas e monitores de CPU e Ram como o Passenger já tem.
Neste exato momento o clima está quente. Muitas coisas estão acontecendo nos bastidores que infelizmente poucos vão ficar sabendo. Mas o Rails deve dar uma boa acelerada neste momento por causa disso e algumas notícias interessantes vão começar a aparecer muito em breve.
Quando estive em São Francisco, uma coisa que conversei com o Matt foi como é difícil conseguir bom material na língua nativa. Ele é francês então também entende isso. Quando uma tecnologia nova sai, alguém escreve um livro em inglês. Só depois que esse livro já fez algum sucesso é que alguma editora nacional resolve comprar os direitos para traduzir. Depois de um longo tempo de tradução e revisão, finalmente sai no mercado … já obsoleto pois a tecnologia anda muito mais rápido do que esse processo moroso.
Pensando nisso, o Matt resolveu criar o projeto Merb-Book. Ele buscou colaboradores e os primeiros convocados foram eu e o Makoto Kuwata, que é rubista do Japão. Outros países se seguiram e ele ainda está procurando mais gente.
Aproveitando: não percam o novo curso de Merb que o grande Satish Talim anunciou hoje para o RubyLearning.org
Como eu disse alguns dias atrás, o Ruby on Rails foi escolhido pelo voto popular (via revista Info Exame e pelo site deles) como a melhor plataforma de desenvolvimento do ano. As outras opções foram Adobe Air e Django. Foi uma disputa cabeça-a-cabeça porque o Rails ganhou do Air por apenas 1% :-) Foi 41% vs 40%!!
Ruby on Rails cresceu bastante em 2008, ao ponto em que finalmente muitas empresas já estão usando e outras estão pensando seriamente em usar. Muitos programadores já estão aprendendo e agora é hora de não perder tempo! Vejam a premiação da Locaweb e do Rails abaixo:
Prêmio Info 2008 – Locaweb from Fabio Akita on Vimeo.
Além disso, cruzei com o pessoal do Mozilla Brasil por lá também já que o Firefox ganhou pelo segundo ano seguido. Então aqui vai um vídeo com eles também :-)
Prêmio Info 2008 – Firefox from Fabio Akita on Vimeo.
Curiosidade: sabiam que no mundo o Firefox tem 20% de market share de browsers, mas no Brasil já alcançamos 30% !?
Parabéns ao Ruby on Rails, ao Firefox e às comunidades Open Source!