%w(Akita On Rails) * 2.0Sua referência de Ruby on Rails

Desde meu relato sobre a RailsConf eu já havia dito que Josh Peek tinha um branch do Rails no Github, num trabalho para o Google Summer of Code, tendo Michael Koziarski como mentor.

Finalmente, David Hansson anunciou que Josh Peek passa a fazer parte do Core Team, e uma das coisas que isso implica é finalmente fazer o merge do branch de thread-safe do Josh para dentro do trunk oficial!

Agora, Charles Nutter – sempre à frente dessas polêmicas iniciais – resolveu escrever uma lista de perguntas e respostas (Q/A) sobre que efeitos thread-safety causa no Rails, e especialmente sobre o mundo JRuby. Naturalmente existem muitas opiniões do próprio Charles aqui, mas a maior parte deve ser factualmente correta.

Segue a tradução do artigo dele:

Achei esse artigo interessante, o título original é Why you shouldn’t code in Spanish. E como o autor mesmo fala, a parte engraçada é que ele publicou esse artigo no site chamado CodeSpanish. Eu coloquei “Português” no título porque senão ninguém iria ler :-) Mas vou traduzir o artigo original. Seja português, seja espanhol, a noção é a mesma, então lá vai:

Estava lendo um artigo do GC e por acaso esbarrei com um link de um site que não entro faz algum tempo: Rules of Optimization. Para colocar em contexto, C2.com significa “Cunningham & Cunningham”.

Estamos falando de ninguém menos que Ward Cunningham. Dentre outras coisas ele inventou o conceito de Wiki. Além disso atualmente é CTO da AboutUs.org que, segundo o Alexa Ranking é o 7^o site mais famoso feito em Ruby on Rails. Ele foi recentemente entrevistado pelo Randall Schwartz e Leo Laporte para o podcast FLOSS Weekly e recomendo muito que ouçam.

Mas estou divagando, este artigo que vou traduzir, em particular não é autoria dele :-) Enfim, aqui vai a tradução do artigo em questão:

Faz tempo que não faço traduções, mas este artigo foi bastante nostálgico para mim, então fiz questão de divulgá-lo. É pelo Jon Dahl do blog RailSpikes. Leiam minhas notas no final. Aqui vai:

Go) é um antigo jogo de estratégia com regras simples e um profundo grau de complexidade.

Desenvolvimento de software é a arte de gerenciar complexidade usando um número limitado de regras, estruturas e padrões.

Programadores deveriam jogar Go.

Este ano, na GoRuCo, um evento de Ruby que acontece em Nova Iorque, eu assisti uma palestra do grande Ryan Davis da Seattle Ruby Brigade e atualmente trabalhando para a Engine Yard. Eu me encontrei com ele em Portland mas infelizmente não tivemos tempo de gravar uma entrevista.

Aliás, eu não fui na GoRuCo, mas felizmente a Confreaks esteve lá e gravou todas as palestras, por isso recomendo muito assistir a todas elas. Mas nesse caso específico eu achei a palestra do Ryan muito interessante então falei diretamente com ele sobre fazer uma versão em português para nossa comunidade, e ele rapidamente achou muito legal, me enviou o arquivo original de Keynote.

Eu traduzi o Keynote e gravei uma palestra-screencast. Espero que todos gostem. O assunto é sobre se importar com código, machucar código, e como se tornar um programador melhor.

Machucando Código por Diversão e Lucro – Ryan Davis from akitaonrails on Vimeo.

E quem quiser os slides em PDF, também deixei disponível via SlideShare

| View | Upload your own

E o grande Marcos Tapajós já colocou também para download a versão em Alta Qualidade no site dele ! Valeu!

O grande Lucas se ofereceu prontamente para me ajudar na tradução desta primeira parte ontem mesmo (brigadão Lucas!). Vamos lá:

Rails 2.1 está prontinho para sair do forno e agora vem a atualização para “O Primeiro Tutorial Completo de Rails 2.1”.

Eu vou começar exatamente de onde paramos no último tutorial, então se você ainda não seguiu esse tutorial eu sugiro que o faça agora ou baixe o código-fonte disponível no Github. Eu adicionei uma tag ‘for_2.0’ para marcar o último tutorial e uma tag nova ‘for_2.1’ para as atualizações que vou mostrar para vocês nesse novo tutorial. Você pode seguir os tutoriais antigos para ter tudo rodando ou pode pular e baixar direto o exemplo da minha página do Github.

Eu vou considerar que você tem o projeto do blog em um diretório ‘blog’ no seu ambiente, e não importa se você baixou o arquivo zip ou clonou a minha árvore no github.

Essa é a Parte 1. Você pode seguir a Parte 2 (ainda em inglês) aqui

Novamente, o Twitter ficou um bom tempo fora do ar, deixando milhares de pessoas bastante irritadas, e com razão.

Novamente, o TechCrunch e outros pundits começaram a rolar suas máquinas de FUD: “a culpa é do Rails: Rails não escala.” nhé, nhé, nhé.

Antes de mais nada, os problemas do Twitter tem duas naturezas: ou acabou o dinheiro e, nesse caso, não há o que fazer; ou eles tem realmente problemas arquiteturais sérios que não tem a ver com Rails. Para começar eles já usam um mix de linguagens e tecnologias, PHP, Erlang, etc. Rails é apenas uma delas.

Muitos acham que Twitter = website, e website = Rails, portanto Twitter = Rails. Isso está errado. Twitter é uma plataforma de mensageria. Para os javeiros, estamos falando de coisas como JMS, e não HTTP. Exemplo, um dos componentes dessa plataforma são servidores Jabber, para broadcast para clientes de instant messaging.

Outro FUD grave: “Twitter é a maior aplicação Rails, que bela propaganda para o Rails …” Está também errado. Segundo esta compilação, baseada no Alexa, o topo da lista é o seguinte:

1. Scribd (serviço de upload)
2. Yellow Pages (as Páginas Amarelas!)
3. Hulu (serviço de mídia da NBC)
4. Penny Arcade (não tenho nem idéia do que seja :-)
5. AboutUs (serviço de network de Wiki)
6. Twitter (aqui está ele: 6o. lugar!!)

Fora eles, pouco abaixo estão outros sites que muita gente usa ou já viu e nem sabe que é feito em Rails, como o SlideShare, Guitar Hero, Gravatar, Feed Digest. Portanto, não, o Twitter não é o mais usado, porém os pundits adoram, pois é uma boa desculpa para colocar as palavras “Rails” e “não escala” na mesma frase sem parecer muito cara de pau.

Os problemas do Twitter são particulares do Twitter e de toda aplicação mal estruturada (seja tecnicamente e financeiramente). A lista que linkei acima tem apenas os Top 100. Na Working with Rails há uma lista muito maior, dentre elas 395 americanos e 30 brasileiros.

O objetivo da TechCrunch: imprensa marrom. O objetivo dos pundits: aliviar a dor de cotovelo. Resumindo: invejinha barata (ou “de barata”).

O blog Dare Obasanjo tem uma análise (especulativa) interessante que deve ajudar os iniciantes a entender os perigos de um conceito que parece tão simples quanto “followers” (seguidores).

Segue a tradução:

Eu e o Carlos Brando estávamos conversando e chegamos à conclusão que passou da hora de traduzirmos o Why’s (Poignant) Guide to Ruby.

O Poignant Guide é um livro obrigatório para todo Rubista. O Programming Ruby é bom, o The Ruby Way é excelente, mas nada demonstra o espírito Rubista do que o Poignant Guide (e agora todo mundo vai entender o que é Chunky Bacon :-)

A primeira geração de Rubistas (incluindo o Why) começou com o livro do Dave Thomas, mas a segunda geração (como o Geoffrey) já começou com o Poignant Guide :-)

Ola Bini é um colaboradores mais ativos do JRuby. É um programador jovem (tem seus 24 anos ou algo assim) mas conhece muito bem os detalhes da arte da programação. Apreciador de Lisp e inteligência artificial, é exatamente o tipo de artista que sabe apreciar a Boa Programação. Em luz dos recentes transtornos sobre a controvérsia Twitter, ele escreveu este divertido artigo que traduzo mais abaixo.

Diferente dos pseudo-gurus que continuamente apenas gostam de falar mal dos outros e jogar indiretas. Lembrem-se de uma coisa: um bom profissional não precisa falar mal dos outros como forma de parecer que está correto. Um bom profissional convence que o que ele acredita é bom por méritos próprios.

Outro bom exemplo? Avi Bryant. Ele teria todos os motivos do mundo para ser apenas mais um xiita, falar mal de Ruby, falar mal de Python, falar mal de Perl. Mas ele também é um artista. Ele acredita na tecnologia que desenvolve. Prova disso foi o que eu noticiei semana passada: em vez de cruzar os braços, foi ajudar a implementar Ruby sobre uma virtual machine Smalltalk. Não só isso, mas quando eu o entrevistei, ele disse abertamente que o carro-chefe do framework Seaside, o produto DabbleDB, também utiliza códigos em Ruby e Python. Bons programadores escolhem boas ferramentas para trabalhar. Xiitas precisam que os outros percam para que eles ganhem.

No longo prazo, adivinhem o que funciona? Bom, vamos à tradução:

Depois do anúncio de ontem da Apple com o Roadmap de Software do iPhone, muitos pundits ainda tem negativismo em vista. Mas são as pessoas que nunca se darão por satisfeito. Quando o iPhone foi lançado vieram as críticas: faltam recursos, não tem GPS, não tem flash, a câmera precisa de mais megapixels.

Tudo isso se provou irrelevante e apesar das negativas, o iPhone teve um crescimento meteórico ao longo de meros 8 meses, abocanhando o mercado a largas dentadas e deixando os concorrentes desorientados. Todo mundo está correndo atrás do próprio rabo.

A última grande crítica eram os aplicativos. Pois bem, ontem a Apple respondeu e em praticamente tudo superou até mesmo as expectativas dos mais positivos, entregando muito mais do que o esperado. Acham que os pundits ficaram satisfeitos? Claro que não.

Todos já se conformaram que Palm, Symbian, Windows Mobile não serão páreos para o iPhone, a última grande “esperança” é o Google Android. Mas eles falham em entender que o Android não será concorrente ao iPhone também.

Em mais um de seus artigos esclarecedores, Daniel Eran Dilger explica porque neste momento do mercado o iPhone não tem nenhum concorrente à sua altura. O principal é o seguinte: a Microsoft é uma empresa de Software; o Google é uma empresa de serviços. A Apple é a única que tem a cadeia inteira no seu controle: hardware, software, design, distribuição, varejo, rede online.

A segunda grande coisa é o seguinte: não é interesse do Google concorrer com a Apple e sim com a Microsoft. Os objetivos da Apple e do Google estão mais ou menos coerentes entre si, o que os torna mais aliados do que rivais. A Apple não tem portfolio que cruza com o Google e vice-versa. Quem está tentando sobrepujá-la (mas está fracassando categoricamente) na área de procura online, redes sociais e serviços online é a Microsoft.

E finalmente, por que adotar Linux em celulares não tem nada a ver com liberdade e tudo a ver com custos baixos (US$ 0.00). Acompanhem a tradução do artigo do Daniel:

Jason Fried, da 37signals, acabou de escrever um post que sumariza o que todos nós que estamos acompanhando o fenômeno iPhone estamos sentindo. Sigam com a tradução:

A menos que você já tenha estudado Estatística e Probabilidade ou seja um fã de matemática, é provável que seja um verdadeiro ingênuo em termos matemáticos, para não dizer outra palavra.

Principalmente se, mesmo com pouca frequência, tente explicar eventos puramente aleatórios como “coincidências misteriosas” que “precisam” ter alguma explicação mística ou sobrenatural.

Mesmo entre nós, programadores, muitos ignoraram a disciplina durante o que é ensinado normalmente no primeiro ano de Ciências da Computação. Um dos resultados práticos desse tipo de ignorância: Birthday Attacks que é um tipo de ataque criptográfico nomeado assim porque explora a matemática por trás do Birthday Paradox – que é explicado no artigo que traduzo abaixo.

Diretamente do blog. Aqui vai a tradução para todos acompanharem:

Capistrano é um utilitário para gerenciar servidores remotos e automatizar tarefas remotas. É popularmente usado para deployment de aplicações Rails (mas pode fazer muito mais!). A versão 2.2.0 está disponível agora:

1
2

gem install capistrano

A versão 2.2.0 tem as seguintes mudanças:

Estou na minha temporada de traduções :-) Felizmente a blogosfera produz muitos artigos interessantes. Desta vez foi Steven Devijver que fez um artigo explicando sobre as diferenças entre os termos tipagem dinâmica e linguagem dinâmica.

Vamos à tradução:

Fazia muito tempo que eu não via um bom artigo sobre Estruturas de Dados. Na verdade, acho que desde o tempo da faculdade eu não lia um texto tão legal. Este achado veio do blog matasano chargen e resolvi traduzir para que todos possam apreciar a idéia. Mas avisando: um mínimo de ciências da computação é necessário para entender este texto.

O tema é Binary Radix Trie. Segue a tradução: