Alguns dias atrás me pediram para responder no Quora a pergunta "Ruby on Rails: Quais são algumas das piores práticas para aplicações Ruby on Rails?". Foi uma resposta que teve muitos votos positivos então resolvi que seria um bom post para meu blog. Segue minha versão extendida.

Existem diversas práticas ruins em desenvolvimento de aplicações em geral e em particular em Ruby on Rails. Eu mesmo já cometi e aprendi sobre várias elas na prática e em particular tive que pegar alguns projetos de resgate onde continuo vendo os mesmos erros acontecendo repetidamente, então vamos tentar resumir as principais que mais me irritam.

Atualização 15/01: Este é outro artigo Why 2012 was the best year ever dizendo a mesma coisa: estamos muito melhor hoje do que em qualquer outro momento do passado. Por que parece que não? Porque muita gente alarmista diz o contrário. E por que eles espalham que o mundo está pior? Óbvio, para que elas possam se sentir "heróis" de fazer "alguma coisa", para elas te fazerem sentir pior por não fazer como elas. Claro, sempre devemos estar melhorando mas não às custas de alarmismo irracional e pânico.

Resolvi começar este ano de 2013 com um artigo que espero que ressoe como uma mensagem positiva para iniciar bem este ano. A mensagem é simples:

O mundo hoje é bom, muito bom, e está ficando cada vez melhor.

Por outro lado fico frustrado toda vez que vejo gente teoricamente "estudada" que prefere acreditar que o mundo está piorando, que estamos pior hoje do que estávamos ontem. Hoje somos "impessoais", não brincamos mais na rua, não temos mais solidariedade, queimamos nossas florestas, todas as corporações são vilãs, o povo sofre mais.

Deixe-me dizer que eu, respeitosamente, discordo de todas essas e todas as outras idéias de que estamos piorando. Um dos motivos simbólicos deste artigo hoje é porque passamos por 2012, uma das últimas profecias conhecidas de "Fim dos Tempos" e passamos por ela como se não fosse nada (aliás, nunca foi nada mesmo).

É claro, qualquer um que lê as notícias sabe que temos metrópoles cada vez mais superlotadas, surtos de violência acontecendo o tempo todo em várias partes do mundo, ainda temos diversas guerras acontecendo no Oriente Médio, intolerância religiosa e terrorismo, desastres naturais que "parecem" resultado do famigerado "Aquecimento Global".

Tudo isso verdade. Nada disso é sintoma algum de que o mundo está piorando.

Pra constar, esse artigo não tem versão alternativa ao TL;DR :-)

Em 2007 eu escrevi dois artigos sobre "consultorias" entitulados Um Desabafo e Um Desabafo II. Dêem uma lida para entender o contexto. Eu gosto de reler meus artigos para ver se eu ainda escreveria a mesma coisa. O primeiro artigo é um conjunto de dicas para que um consultor melhore a si mesmo. No segundo artigo descrevo o maior pecado numa consultoria. Eu escrevi os artigos quando já tinha alguns anos em diferentes empresas, em diferentes indústrias e a mais recente tinha sido anos em consultoria.

This year I had the opportunity to visit 4 fantastic cities across the USA and Europe/Asia. It all started in this first post. There were several goals including getting to know those cities personally as I've never been there before, then meet great people and great companies, and finally try to understand more about this fledgeling new tech startup world.

I wrote about my journey in 6 articles, originally in Brazilian Portuguese. You can use Google Translate that's available in all of them...

_Why is the Howard Roark of the Ruby world

I recently wrote an article named _Why Documentary at Rubyconf 2012, Denver reminding people about this person that called himself "_Why", who decided to vanish in August of 2009, taking all his work with him, essentially committing virtual suicide.

It has attracted lots of trolls and haters at the comments section, more discussion than I anticipated, questioning why we praise someone that was crazy enough to destroy all his work, that is obviously not a good role model, and that compared to other titans of programming has done little and with less quality?

Then, today I heard about this website about Ruby Dramas - that I'm not linking. I don't know the author and I even think this is just for fun, but the reactions from the trolls and haters aren't. Essentially it links a few of what we call "Ruby Dramas", the discussions that trolls and haters call a waste of time, a demonstration of the immaturity and childish behavior of Ruby programmers.

Se existe uma história recorrente em qualquer desenvolvimento de software é o que eu chamo de "Mito do Legado". Se você é programador, já passou por isso: herdou código feito por outra pessoa ou outra equipe, vê que está tudo muito mal feito, e sua recomendação é jogar tudo fora e começar tudo de novo. Você tem certeza que esta é a única alternativa sadia e não fazer isso seria um enorme erro.

Esse comportamento é o que eu também chamo de "Histeria do Amador". E digo isso com total tranquilidade porque eu mesmo já tive momentos desse.

Antes de mais nada, vamos definir o que comumente é chamado de "Legado": basicamente todo código feito até ontem, especialmente se não foi você quem fez, é considerado um "Legado".

Mas o que a maioria dos programadores falha em entender é muito simples: com essa definição, qualquer código sempre se tornará automaticamente um "legado" no minuto seguinte em que ele é concluído: incluindo o seu próprio.

O jardim do vizinho sempre parece mais verde? Pois para programadores, o código do vizinho sempre parece pior. Quantas vezes já não ouvimos?

  • "Como assim levou tudo isso pra fazer esse código? Eu teria feito em menos tempo."
  • "Como assim o código foi feito desse jeito tosco? Eu teria feito melhor."

Building the Legacy System of Tomorrow

Muitas pessoas talvez não tenham entendido minha posição no artigo anterior Mea Culpa: Organizações Democráticas não Funcionam. Recomendo que tentem ler o artigo anterior com calma para entender o conceito correto de Democracia. Mas para complementar devo explicar. O maior problema que todos tem é acreditar que “democracia” é a única e melhor forma de governar ou, mais genericamente, decidir qualquer coisa porque “a maioria”, “o povo”, “as massas” sempre tem razão e o que foi decidido coletivamente deve prevalecer. E este é o maior erro de todos os tempos.

Quem está me acompanhando nos últimos 4 anos nas minhas discussões sobre formas de gerenciamento e de organização de empresas vai se lembrar que eu muitas vezes não só flertei como procurei maneiras de tentar defender um tipo de organização “democrática”. Esse conceito sempre foi incompleto e eu imaginava que mais cedo ou mais tarde a equação iria se fechar. Em vez disso estou retornando ao zero e redefinindo esses conceitos. A primeira coisa que eu preciso corrigir é o uso da palavra “Democracia”. Essa palavra não condiz com o tipo de organização que eu descrevo.

Minha linha de pensamento sempre é baseada em Evolucionismo Darwinista. É a única forma onde Caos consegue tender a uma certa Ordem através de auto-organização. Esse processo envolve diversos mecanismos e é onde já palestrei sobre Redes de Livre Escala, sobre Sistemas Complexos Adaptativos, e como tudo isso leva a processos, metodologias, incluindo o tão discutido Scrum. Essa linha de estudo – que você pode acompanhar nos meus blogs e palestras dos últimos 3 anos – passa superficialmente por temas de biologia, sociologia, psicologia, filosofia, física, matemática. Em última instância me parecia que o caminho mais coerente era em torno do que hoje em dia ficou conhecido como Organizações Democráticas, especialmente por causa de cases famosos como a Semco, de Ricardo Semler e aspectos de democracia na organização que podem ser observadas em empresas como Southwest Airlines, Dreamhost, Groupon, Zappos.

Porém, eu mesmo fui vítima daquilo que sempre critico: um grupo de evidências positivas sobre um modelo, por melhor que pareçam ser, nunca provam o modelo! Concluir baseado apenas em evidências positivas é o mesmo que cargo cult. Portanto, a primeira coisa que devo corrigir é: o tipo de organização que descrevo e defendo não tem a ver com “Democracia”, portanto na minha concepção, o termo “Organizações Democráticas” é um erro.

Existem algumas configurações de Mac que em todo evento que eu vou vejo alguém com problemas. Acho que já é hora de compilar algumas dessas dicas.

Se você faz palestras, essas dicas podem te ajudar bastante.

Meu blog não é muito diferente da maioria. Tem uma página principal com os posts mais recentes, uma barra lateral dando acesso a arquivos, posts mais antigos, últimos comentários e outras coisas.

Hoje resolvi fazer um pequeno ajuste cosmético. Até agora eu colocava uns 10 posts com um texto de introdução de cada. Porém na maior parte dos casos acho que isso não era muito útil pois meus posts costumam ser grandes e só alguns trechos de texto não eram úteis. Além disso só 10 posts na homepage significa que muitos (deste mesmo mês) eram arquivados rápido demais. E pouca gente vai atrás de posts arquivados.

Update 04/26/2010: I just replaced Fuzzy Finder for Command-T as suggested in the comments. Read more about it at the end of this article. One of the most accessed articles in my blog still is The Best Environment for Rails on Windows. It was a long time since then. So I’ve decided to reorganize my vimfiles a little bit. I have been forcing myself to stay away from Textmate and get more used to MacVim. Vim is only really useful if you do invest some time to get used to the key mappings, witho...

Depois de escrever meu artigo na Info, Fábrica de Software é uma Besteira, recebi um retweet com um link muito legal de um texto que eu não conhecia. The Humble Programmer.

Claro, o autor é super conhecido, o grande Edsger W. Dijkstra. Ele é mais conhecido pelo paper seminal A Case against the GO TO Statement. De qualquer forma o The Humble Programmer foi um discurso que ele deu ao receber o prêmio Alan Turing de 1972.

O texto é fantástico e deve ser lido na íntegra, mas resolvi retirar alguns trechos para comentar. O mais interessante é ler com o contexto do fim dos anos 60 em mente e como muito do que ele espera para o futuro é uma coisa que nós, 50 anos depois, ainda continuamos esperando. Não publiquei este texto na Info mesmo por dois motivos: primeiro porque é mais voltado a programadores, segundo porque este é um dos meus textos “tamanho Akita” :-)

Ontem escrevi uma análise em duas partes sobre o iPad, se ainda não leram, acompanhem:

Tentei ser o mais completo possível e mesmo assim ainda esqueci de algumas coisas que pretendo cobrir neste artigo. Se você tem alguma dúvida extra, não deixe de comentar e respondo nos comentários. No final do artigo tento cobrir um pouco a questão polêmica sobre a “loja fechada” também, vejam o que acham.

Leiam a introdução na Parte 1

E finalmente, vamos falar um pouco sobre o aparelho :-)

Como disse antes, o iPad é tudo aquilo que todos já disseram na maioria dos sites de tecnologia que são relevantes: é um aparelho muito bem feito, que passa uma sensação de robustez quando você segura. O sistema operacional é elegante, refinado e trás a experiência ganha com quase 3 anos de iPhone. Na prática, se você já usou um iPhone, definitivamente vai conseguir usar um iPad com zero problemas, afinal o iPad é um iPhone Touch grandão, o que é excelente e inteligente.

24 horas depois que o venerado iPad foi lançado, eu consegui colocar as minhas mãos nele, minha semana não ia prestar caso contrário :-) Comprei a versão com 64GB – eu sempre me arrependo comprando menos armazenamento, desta vez peguei o maior -, fora o dock e a capa protetora da Apple. Não estou escrevendo este artigo no iPad e explico mais abaixo porque.

Pretendo não repetir o que já foi descrito tecnicamente sobre ele. Para mais detalhes, recomendo ler os seguintes artigos:

Todos os reviews são detalhados e precisos. E sim, visualmente falando, é um iPod Touch grande. O acabamento é impecável como sempre. Se você está acostumado com produtos Apple não há nenhuma surpresa, se está acostumado com todo o resto é como andar todo dia de Fusca e de repente comprar uma Mercedes. Resumindo temos o seguinte:

  • 0.68kg de peso, 13mm de espessura, 24×18 cm de área
  • Processador A4 de 1Ghz
  • 256Mb de RAM
  • 16, 32 ou 64GB de armazenamento em drive Flash
  • Saída de som estéreo de qualidade razoável
  • Tela IPS de 9,7" com 1024×768 de resolução
  • Tela Multitouch, Acelerômetro, Sensor de Luz Ambiente
  • Bluetooth 2.1 + EDR
  • WiFi 802.11 b/g/n

Isso dito, vamos ao que interessa.

Estava assistindo o canal FX ontem e por acaso esbarrei numa reprise do excelente show Penn & Teller, Bullshit!. Eles são mágicos famosos que se apresentam em Las Vegas, já apareceram em diversos programas de TV e tem se próprio programa, o Bullshit!, que discute política, disputa o status quo, quebra falácias e folclores populares. Nesse episódio eles terminaram com um truque de mágica, queimando a bandeira americana e falando sobre Liberdade de Expressão. Assistam este trecho antes de continuar:

Esta semana assisti ao excelente filme Up in the Air (recomendo). Eu me identifico muito com a forma de pensar do personagem Ryan Bingham, mas o artigo não é sobre isso. Esse filme conta a história de um profissional do ramo de “recolocação profissional” (eufemismo para “cara que demite”). A idéia do filme não é ser uma lição de moral ou coisa assim, mas tem um trecho que vale a pena compartilhar: Download “Up in the Air” movie snippet Todo mundo sabe que eu evito auto-ajudas, mas de vez em q...

O Manifesto Ágil é calcado em 4 valores. Não sei quantas eu já repeti isso. Mais do que isso ele é calcado em 12 princípios importantes. Muitos os consideram como os 10 mandamentos. Eu sempre sou contra qualquer coisa dogmatizada, por outro lado se você prefere dogmatizar o Manifesto, nunca pegue apenas uma frase dele em isolado. Se for levar um deles ao pé-da-letra, leve todos ao pé-da-letra, senão seria o mesmo que dogmatizar os 10 mandamentos e dizer “Eu obedeço os 10 mandamentos: eu já cometi adultério, mas não tem importância porque nunca matei ninguém, nunca roubei e não foi com a mulher do vizinho que cometi adultério.”

Adoro o vídeo Wear Sunscreen, acho que eu vi pela primeira vez em 2003 ou 2004 e ela ficou para mim como um “aviso”, algo a se lembrar de vez em quando. As partes que mais gosto são:

“Tenha cuidado com quais conselhos você aceita, mas seja paciente com quem lhes dá conselhos. Conselho é uma forma de nostalgia, distribuí-lo é uma forma de pescar o passado do lixo, limpá-lo, pintar sobre as partes feias e reciclá-lo por mais do que vale.”

Outra parte importante:

“Talvez você se case, talvez não, talvez você tenha filhos, talvez não, talvez você se divorcie aos 40, talvez você dance a dança da galinha no seu 75o aniversário de casamento. Não importa o que faça, não se parabenize demais ou se critique demais. Suas chances são de 50%, assim como as de todo mundo.”

Lendo o livro Systems Thinking esbarrei numa história interessante que deu origem ao meu tweet de ontem:

Information < Knowledge < Understanding
Or
What? < How? < Why?

A história é a seguinte: Havia um projeto de controle de natalidade da Fundação Ford na Índia. Eles estavam frustrados tentando ensinar planejamento familiar e controle de natalidade, sem resultados.

“Indianos são irracionais.”

É o que eles achavam pois:

“Eles sabem que o inimigo número um é a população, e aqui estamos nós ensinando sobre controle, dando os contraceptivos e até mesmo um radio como recompensa. Mas veja o que acontece. Eles voltam pra casa, ligam o rádio, e com música fazem um novo bebê.”

Se você ainda não lê a Wired, deveria. Eu leio esporadicamente mas sempre aparecem artigos muito bons. O do mês passado trás uma série sobre fracasso e sua importância para o sucesso. Num dos artigos (leia a íntegra aqui), fala sobre um dos experimentos de Dunbar (quem nunca ouviu falar dos números de Dunbar ?).

Agora, o que Dunbar tem a ver com conceitos de Emergência, Cross Functional Teams, e outros que comumente discutimos em Agilidade? Ele resolveu estudar como cientistas funcionam (!) No meio do artigo vi este trecho que me chamou a atenção: