É importante não generalizar a linguagem Ruby como se fosse algo que resolverá todos os seus problemas. Ela tem propósito geral, mas será adequada em determinados contexto e outros não, como todas as outras linguagens. O propósito desse post do Kate Cunningham que eu traduzi é mostrar que as características do Ruby são muito harmônicas com as características necessárias em um ambiente efetivo de aprendizado. Isso não quer dizer que o aluno deva estacionar no Ruby. Ele terá o caminho facilitado para o mundo da programação com Ruby, mas isso será só o primeiro passo. Ele deverá sim, aprender outras linguagens, pois é a única forma de se aprimorar como profissional de uma área tão dinâmica. O texto original você encontra aqui. Fique agora com a tradução:

A linguagem Ruby tem recebido muita atenção na última década, especialmente com o advento do Ruby on Rails em 2005. Enquanto a blogosfera está utilizando Ruby a muito tempo, vamos nos perguntar como, exatamente, a linguagem Ruby é propícia para um ambiente educacional.

Copyright (C) 2008 Ruby Association LLC

Claro, podemos ir para a relevância da linguagem Ruby, pois se você está recebendo treinamento em um ambiente educacional para se tornar um programador de computador, e você não sabe o Ruby, então você está ficando cada vez mais fora do circuito. No entanto, linguagens de programação vêm e vão, e educação não é sobre as tendências, é sobre as idéias que sustentam o valor no decorrer dos anos.

Vamos então olhar para a filosofia de linguagem Ruby e ver como é propício à aprendizagem. Por um lado, Ruby é flexível. Ele não tem a rigidez de Java ou PHP. Em um ambiente que maximiza o aprendizado, a flexibilidade é fundamental. E Ruby é tão flexível quanto possível. Yukihiro Matsumoto, o  criador da linguagem Ruby, notou o que ele estava pensando quando ele começou a trabalhar com linguagem de programação: “É engraçado, quando eu usei PHP para desenvolver ou as coisas que eu fiz em Java, eu estava sempre à procura de algo mais.”

Outra grande coisa sobre Ruby é seu reforço da capacidade para a criatividade. Como muitos programadores Ruby notaram, Ruby é mais alinhado com o pensamento humano. Desta forma, é muito fácil de usar. E precisamente porque é mais fácil de usar, é mais versátil quando se trata de ser criativo.

A apresentação de slides sobre a linguagem Ruby explica como Ruby auxilia a criatividade. Afirma que os seres humanos perdem produtividade quando são forçados por “tarefas repetitivas, tarefas desnecessariamente complexas  e resolvendo problemas que não estão dentro do domínio de aplicação.” Desde que Ruby efetivamente se livra dessas tarefas repetitivas e de tarefas voltadas para máquinas, há mais espaço aberto para ser criativo. Com os alunos, especialmente, a produção criativa é a chave para a aprendizagem de forma eficaz.

Um aspecto do processo de aprendizagem que é absolutamente crítico para a eficácia educacional é diversão. Nós geralmente não pensamos sobre a diversão quando nós pensamos sobre a educação. Mas reflita sobre seus próprios anos escolares no passado. Se você pensar bem, você percebe que os assuntos que você aprendeu mais e reteve o conteúdo eram aqueles em que você estava se divertindo. Este divertimento, claro, resulta em parte da criatividade. Quando você está sendo produtivo, você está se divertindo.

Ao contrário de outras linguagens de programação, você pode fazer muita coisa com Ruby, mesmo se você está apenas nos estágios iniciais de aprendizagem. Para os estudantes, o processo de aprendizagem é frustrante e é um pouco prejudicado quando pequenos erros aparecem no caminho de chegar aos conceitos maiores. Linguagens de programação como C++ podem dificultar o aprendizado dos conceitos maiores porque pequenos erros no código sempre aparecem durante o processo. Já usando o  Ruby o aluno não passa por essas pequenas dificuldades quando está iniciando o aprendizado.

Naturalmente, estes são apenas indicações básicas de que Ruby é a melhor ferramenta de aprendizagem para os interessados em programação de computadores, especialmente os iniciantes. No entanto, assim como na educação como um todo, em que mudanças conceituais básicas no processo de aprendizagem levam os alunos para as melhores práticas na aprendizagem,  Ruby oferece a possibilidade de uma aprendizagem fácil, divertida, criativa, por força da simples virtude de que a linguagem foi feita para pragmaticamente funcionar dessa forma. Em análise final, Ruby foi feito para estudantes, jovens e idosos, iniciantes e mais avançados.

Por Kate Cunningham

O ponto chave é que não dá mais para ficar somente na frente do computador (nerd 1.0). Agora o Nerd tem que ser sociável, tem que equilibrar seu gosto por tecnologia com seus relacionamentos interpessoais, seja com amigos, trabalho ou o que for (Nerd 2.0).

A tecnologia é importante sim, mas ela deve estar sempre em função das pessoas e nunca o contrário.

Durante o OxenteRails 2010, uma das booth babes me falou que se surpreendeu com os participantes, pois eles não se isolavam. Sempre tinha alguém para tirar alguma dúvida com elas, para pedir para colocar os postits no quadro de feedback, para chamar para jogar video game junto com eles, para tirar fotos, ou seja, estavam sempre interagindo. Ela complementou que a idéia distorcida que ela tinha do nerd anti-social mudou completamente.

Outro depoimento foi da representante do SEBRAE que chegou no evento e imaginou: Como é que eu vou fazer para explicar os recursos que posso oferecer num local que só tem nerd? Mas o tempo foi passando e logo
ela detectou que ali tinha consultores, professores, desenvolvedores, ou seja, Nerds sociáveis e produtivos.

A própria estrutura do evento foi organizada para facilitar interações entre indivíduos. O Ignite OxenteRais que começou na quinta-feira é um ótimo exemplo disso. O Ignite é um mini evento informal em que as pessoas palestravam durante 5 minutos, trocavam idéias e faziam amizades. Nos dias 6 e 7 de agosto, no final da programação oficial, os participantes se reuniam em algum barzinho da cidade, esse outro mini evento se chama #horaextra.

Alguns dos nerds 2.0 que estavam no Oxente Rails tinham inclusive vocações artísticas. Nesse quesito eu cito o Cukier que recebeu o prêmio da mais bela voz, com o Forró do Elomar e também a Banda Plataformatec fazendo uma performance com vocal e guitarra em um jogo do playstation.

Cito agora o Henrique Bastos: Esse ambiente de confraternização permite ir além do que ampliar a rede de contatos. Permite a criação de uma rede de confiança, que é muito mais significativo para a comunidade e para cada participante.

Um conjunto de idéias bem significativas que representa essa nova visão você pode encontrar no Manifesto Pequenas Ações (Small Acts), com o slogan: Pequenas ações fazem grandes revoluções.  Qualquer um pode se cadastrar e se associar a esse manifesto.

Não podia deixar de colocar aqui outro ponto: A participação feminina no evento. Apesar da grande maioria serem homens, tivemos Cecilia Fernandes palestrando sobre metodologias ágeis,  Tahis Camilo que mostrou o dia-a-dia do seu trabalho na Hashrocket e por fim, a Gleide, que palestrou sobre Ti Verde na desconferência. Portanto o Nerd 2.0 não pode mais dizer que tecnologia é coisa de homem. As mulheres, apesar de estarem em pequeno número, mandaram bem!

E então? Tá esperando o que?

Se você anda passando tempo demais no computador e se esquece da importância da socialização (Nerd 1.0)  fica aqui o alerta: Faça um Git Clone desse novo formato de ver o mundo da tecnologia e atualize a sua visão Nerd para a versão 2.0.

Bônus: Se você ainda tem um pouco de dificuldade de fazer o upgrade para a versão Nerd 2.0, não entre em pânico. Essa mudança pode ser feita de forma gradual. Portanto, se essa idéia fez com que você se preocupasse, tente descontrair um pouco. Para isso, acesse Fuças – a revista de fofocas nerd criada pela comunidade do Piauí. Outro site que vai te ajudar a se descontrair e ganhar confiança para o upgrade é o site de tirinhas nerd: nerdson.

Bônus 2: Não deixem de acessar também o post criado por Alexandre Gomes:  Manifesto 2.0

Quem tiver algum depoimento a respeito desse tema pode deixar seu comentário aqui.

Um abraço e até o próximo Papo de Nerd!

Esse mini-livro é uma jornada linha a linha, teste por teste, utilizando a técnica do Desenvolvimento Orientado a Comportamento (Behavior Driven Development) em um projeto muito interessante: Simulação dos dados do jogo War!

Eu escrevi esse pequeno livro para aprender BDD e RSpec, por isso eu tinha que falar sobre algo simples e de preferência que fosse divertido. Então eu pensei: Por que não jogar dados! Porque não jogar dados do jogo War!
Então aqui está: Aprenda BDD jogando dados!

A aplicação que nós criaremos juntos usa duas classes: Dice e WarDice. No primeiro capítulo eu construo o arquivo RSpec da classe Dice e a classe Dice simultaneamente e passo a passo até todos os testes tornarem-se verdes.

No segundo capítulo eu continuo o desenvolvimento com a classe WarDice, aquela que fará a simulação de cada dado do jogo war!

Finalmente, no terceiro capítulo eu uso as classes criadas em uma divertida aplicação feita em shoes. A filosofia desse livro é aprender fazendo coisas divertidas. Em uma palavra: Experimentação.

Então eu espero que você aproveite esse livro simples mas também muito instrutivo. Os testes usados nesse livro não são uma solução definitiva. Eles são somente possibilidades no meio de outras. Como eu disse, eu o escrevi para aprender RSpec. Você pode enviar sugestões, clonar o projeto, modificá-lo e codificá-lo de outra forma. Quem sabe não faremos juntos a versão 2.0 desse livro .

Fique agora com o livro:

O código fonte completo da aplicação você pode baixar em:
http://github.com/valeriofarias/shoes-war-dice

O texto completo do livro e o código fonte do gerador de livros você pode baixar em:
http://github.com/valeriofarias/learn-bdd-playing-dice-book

se preferir pode também baixar a versão em inglês do livro:
http://valeriofarias.com/learn-bdd-playing-dice-ebook/

I wrote this tiny book to learn BDD and RSpec for myself. I would want to start with a little example. And if was possible with a funny example too. Then I thought: Why not playing dice! Why not playing war dice! Then there you are: Learning BDD playing dice!

The app that we’ll create together uses two classes: Dice and WarDice.

The first chapter I start to construct the RSpec file of Dice class and the Dice class simultaneously and step by step until all of the tests become green.

The second chapter I go on with the WarDice class, that is a simulation of each dice of war game!

Finally, the third chapter I use the classes in a funny shoes application.

The philosophy of this book is to learn making funny things. In one word: Experimentation. Then I hope you enjoy this simple but also instructive book.

The tests used in this book aren’t a silver bullet. They are only a way between some others. How I told, I made to learn RSpec. You can send suggests, clone the project, modify it and codify in other ways. Who knows we’ll playing together in the 2.0 version of this book .

Now just read the book and have fun!

The complete source code of application you can download in
http://github.com/valeriofarias/shoes-war-dice/tree

The complete ebook text and source code you can download in:
http://github.com/valeriofarias/learn-bdd-playing-dice-book

Quem vem linguagens como C, Java, Delphi, C# e usa a linguagem Ruby pela primeira vez, tende a programar em Ruby do mesmo jeito que programava na linguagem que já era fluente. Lendo o post abaixo você perceberá que linguagens que tem características  funcionais, como o Ruby, possibilitam formas próprias de organizar o código (Jeito Ruby) , mais especificamente nesse texto, escrito por Jon Dahl, você verá as formas mais eficientes de fazer iterações (loops) em Ruby. A versão original você encontra aqui. Fique agora com a tradução:

Se você é um programador, você provavelmente já trabalhou com um ou mais livros que te ensinava a sintaxe de uma nova linguagem. Eu tive essa experiência com uma meia dúzia de linguagens, como C, Javascript e Perl.
Estes livros tipicamente introduzem loops no meio da discussão de sintaxe, depois de tipos de dados e controle de fluxo, mas antes de I/O e de recursos avançados.

Loops são quase sempre apresentadas de acordo com esta fórmula:

Texto introdutório: “E se você quiser fazer uma operação mais de uma vez”?
Introduz o loop while, mostrando a diferença entre do while e while do.
Apresenta o laço for, o primo louco do while.

(Bonus) Introduz o laço foreach se a linguagem é suficientemente de alto nível. E é isso – você sabe como fazer um loop através de código e é hora de seguir em frente.

Não tão rápido. Se você for sortudo o bastante para usar uma linguagem que possui traços de programação funcional, você não deve usar um laço dessa maneira.

O ponto
De agora em diante, eu vou usar Ruby para exemplos, mas este artigo não é sobre Ruby. É sobre a transição de loops primitivos para iterar usando coleções, e sobre a transição de funções genéricas (como each) para funções mais específicas (como map).

De loops para métodos que percorrem a própria lista
Durante os últimos meses, estive trabalhando no Tumblon, uma aplicação Rails de porte médio. Eu trabalhei em 15-20 aplicações Ruby nos últimos três anos, provavelmente, totalizando 50.000 linhas de código Ruby.

Eu só usei um laço primitivo uma vez.

Esse laço primitivo era um loop{} loop, sempre percorrer uma lista tarefas à procura do que executar. Em outras palavras, um laço sem nenhuma condição de saída além de ^C, ou uma falha do servidor.

Eu só usei um loop simples em um caso porque o conceito each geralmente é uma opção melhor. Essa implementação Ruby será familiar para quem já viu código Ruby antes:

["horse", "pig", "cow"].each  do |animal|
puts "Old MacDonald has a #{animal}"
end

(Sim, eu tenho uma criança pequena.)

Isto é muito mais enxuto do que as alternativas usando for e while. Ele representa melhor o que estamos fazendo: não estamos iterando com uma condição de saída, estamos interagindo entre os elementos de uma matriz. Mas e se você quiser fazer algo um número fixo de vezes? Você pode interpretar isso como percorrer a seguinte lista: [1,2,3,4,5,6,7,8,9,10].each{}. Mas claro que Ruby dispõe de uma versão mais simples para isso: 10.times{}.

Portanto, se seu loop rodar através de uma lista de algum tipo, each é a melhor abstração para esse tipo de problema. E, na minha experiência de construção de aplicações Ruby, a maioria dos loops percorrem listas. Parsing XML? Iterando por uma lista. Somando números? Iterando por uma lista. Leitura em um arquivo texto? Lendo o STDIN? Trabalhando com linhas em um banco de dados? Iterando por uma lista. Isso é o que o loop each faz bem.

Além do arr.each
Mas each não é a palavra final. É um passo acima das primitivas for ou while quando trabalha com o conjunto de valores, mas muitos loops each devem ser substituídos por outros métodos de array, como map, inject e select.

Quando each é útil? Simples: quando você quiser criar efeitos externos ao array, como salvar no banco de dados, imprimir um resultado na tela, ou enviar uma chamada de serviço web. Nestes casos, você não está preocupado com o valor de retorno; você deseja alterar o estado na tela, o disco, o banco de dados, ou outra coisa. Dê uma olhada neste código.

User.find(:all).each do |user|
Notification.deliver_email_newsletter(user)
end

Você não necessita que o código acima retorne valor, você só precisa que o e-mail seja entregue.

Mas não use each se você quer extrair algum valor novo de um array. Em vez disso, dê uma olhada em outros três métodos poderosos: map, inject e select.

Para entender vamos analisar o código abaixo que itera por um array e cria um novo array com elementos que correspondem a determinada condição, usando each.

active_users = []
users.each do |user|
active_users << user if user.active?
end
active_users

A primeira e última linhas são feias. Por que você tem que inicializar e retornar active_users? Resposta: porque este é um abuso (má utilização) do método each. Nesse caso é muito melhor você usar select (ou seu equivalente, find_all):

users.select do |user|
user.active?
end

Usando select o código fica menor, mais fácil de entender e menos propenso a erros. E mais importante, ele claramente encapsula um uso comum de each (e looping em geral).

Duas outras funções-chave: map e inject (ou reduce) – complementam select e seguem um padrão semelhante. E não é de surpreender que eles formam a base do paradigma mapreduce para processamento distribuído. Eu escrevi mais sobre map e reduce em outro artigo, e aqui é um atalho para saber quando usar essas funções:

Resumo
Use each para mudar o estado. Caso contrário use métodos funcionais de matriz que retorna um valor. Dessa forma seu código ficará mais limpo e menos propenso a falhas.

Aprendendo a refatorar

1. Inicializar um valor vazio, ou matriz, ou o que quiser (new_arr = [])
2. arr.each, alterando o valor inicializado
3. Devolver o valor (return new_arr)

Sempre que você detectar esse padrão, você sabe que existe um laço each que precisa ser substituído.

Esse papo de nerd virtual foi sobre linguagens de programação. Mais particularmente Python e Ruby. A conversa foi com meu amigo Macelo. Fique agora com o texto:

Macelo diz:
O que você Acha do Python?
É o concorrente do Ruby.

Valério diz:
Não necessariamente o concorrente.
Tem filosofia um pouco diferente do Ruby, mas também é uma linguagem dinâmica,
quase que totalmente orientada a objetos, características parecidas com o Ruby.

Macelo diz:
Certo, mas não deixa de ser o concorrente.

Valério diz:
A filosofia do Python é dar UMA solução elegante para cada problema. É ser simples e direto.

A filosofia do ruby e dar produtividade e diversão para o programador. Dar prioridade ao programador ao invés do computador (linguagem humana).
Os dois tem suas vantagens e desvantagens.

Macelo diz:
Como tudo na vida.
Mas, do jeito que você diz, faz parecer que o Ruby é bem mais vantajoso.

Valério diz:
Não necessariamente.
O Python tem o django como framework para aplicativos web, que é muito bem difundido.
É o equivalente ao Rails, mas foi feito com princípios e necessidades próprias.
Cada ferramenta vai ser melhor utilizada em determinados momentos e contextos.

Essa questão de ser concorrente ou não, está muito ligado ao fato de vermos alguns fatos  da vida de forma binária: ou 0 ou 1, ou certo ou errado, ou ganha ou perde. O ponto que quero chegar é que existem outras formas de você olhar para o mundo ao redor e seus recursos. Para você ganhar, não necessariamente o outro tem que perder. Os dois podem ganhar! No caso de linguagens de programação, se eu olhar para elas como mera competição (qual a melhor!) Estarei deixando de lado um universo de possibilidades. Quanto mais pontos de vista e linguagem de programação um programador experimentar e dominar melhor!  Eu escolhi o Ruby nesse momento porque a comunidade é explosiva e de mente aberta, muitos dos programadores Ruby, conversam sobre ou dominam outras linguagens, além é claro do código elegante.

Macelo diz:
haaaaaa.
Assim faz parecer melhor as duas partes.

Valério diz:
Em última instância a minha escolha por estudar Ruby é pessoal. Sempre que a gente for para a parte técnica, acaba caindo nessa situação do “depende do caso”.

Macelo diz:
Uhum.
Notei isso.
Um amigo meu programa em Python, e usa o bloco de notas ..

Valério diz:
Você pode usar Python, mas não use o bloco de notas.
Baixe algum aplicativo mais adequado para programação:

• notepad ++ é uma ótima opção para Windows
• no Linux eu uso o gedit
• no mac você pode usar o TextMate

Se quiser seguir em frente com o Python acesse o blog de Elcio. Ele tem uma empresa e a base dela é Python.

Marcelo diz:
Beleza, falou!

Valério diz:
Falou!

• Twitter -> John Nunemaker ( essa é a mais completa )
• Twittery – uma classe bem simplista que faz upload de fotos pela TwitPic’s API. Esse projeto é administrado por Chris Ledet

Eu tomei como base para aprendizado, a classe do projeto Twittery, pois queria uma solução rápida e simples. Apesar dela não ter a segurança do protocolo de autenticação oAuth que já consta no projeto de John Nuremaker.

A idéia foi a seguinte: colocar o código Ruby para ser pré-carregado no arquivo .irbrc toda vez que o irb for acionado via shell.

Depois de vários teste o código final você pode ver abaixo:

# twitting by irb
require 'net/http'

class Object
  def twitter_config(username, password)
    @username = username
    @password = password
  end

# the message must be between 1 and 160 characters
  def twitter(status = nil, format = 'json')
     if status.empty? or status.length > 160
        puts "twitter 'message with spaces'             (IRB)"
        puts "Obs. (The message must been less than 160 characters and cannot be empty)"
     else
        api_url = 'http://twitter.com/statuses/update.' + format
        url = URI.parse(api_url)
        req = Net::HTTP::Post.new(url.path)
        req.basic_auth(@username, @password)
        req.set_form_data({ 'status'=> status }, ';')
        res = Net::HTTP.new(url.host, url.port).start {|http| http.request(req) }
        puts res
     end
 end
alias :twit :twitter
end

twitter_config('username', 'password')

Os dados de usário e senha já são pré-carregados na inicialização do irb. A vantagem é que esses dados ficam ocultos no arquivo .irbrc, dando um pouquinho de privacidade, caso tenha alguém do lado.

Para “twittar” é só usar o seguinte comando, a qualquer momento, dentro do irb:

irb> twitter "mensagem via irb"

ou ainda

irb> twit "outra mensagem via irb"

Obs.: Esse exemplo usa a forma de autenticação mais simples, via HTTP. O twitter está em processo de mudança da autenticação para usar oAuth. A tendência é que a autenticação básica via HTTP deixe de ser usada, mas isso ainda vai demorar um pouco. Enquanto isso não acontece, vou continuar “twittando” por esse script via irb.

Fico por aqui.

Até a próxima.

• acionar o Vi ou o TextMate a partir do irb, permitindo que você escreva ou cole um código rapidamente, salve, feche o editor e já possa testar no irb, sem precisar criar arquivo e salvar em diretório.
• visualizar um histórico de comandos digitando “h”
• abrir o histórico no TextMate ou Vi usando hvi ou hmate
• assista ao screencast do Akita para ver o funcionamento

Até aí tudo bem, mas o grande problema é que eu uso ubuntu com gedit para escrever códigos ruby. E o utility-belt não possui métodos específicos para acionar o gedit. O help do utility belt dá a opção edit_interactively(:gedit), mas é claro que eu não poderia me contentar com esse método, eu queria que funcionasse da mesma forma que funciona para o Vi ou TextMate.

Pesquisando um pouco, achei um artigo que mostra como  abrir o editor nano do linux através do irb, extendendo o utility-belt. A partir dele eu fiz algumas modificações no arquivo .irbrc que vocês verão na sequência do Post.

A primeira etapa é instalar o utility-belt:

git clone git://github.com/akitaonrails/utility-belt.git
cd utility-belt
gem build utility_belt.gemspec
sudo gem install utility_belt-1.0.12.gem

Agora é só editar o arquivo .irbrc no home do seu sistema e acrescentar as seguintes linhas:

require 'rubygems'
require 'utility_belt'

module InteractiveEditing
   def gedit
      edit_interactively(:gedit)
   end
end

class Object
   def history_to_gedit
      handling_jruby_bug do
         file = Tempfile.new("gedit_tempfile")
         get_lines(0..(Readline::HISTORY.size - 1)).each do |line|
            file << "#{line}\n"
         end
         file.close
         system("gedit #{file.path}")
      end
   end
   alias :hgedit :history_to_gedit
end

UtilityBelt.equip(:all)

Depois disso é só salvar e partir para a execução!

Agora você pode usar o comando gedit direto do irb e também abrir o histórico no gedit usando hgedit ou history_to_gedit. Se quiser entender um pouco mais sobre os códigos leia os arquivos: interactive_editor.rb e command_history.rb na pasta: utility-belt/lib/utility_belt$

Para quem não utiliza o gedit, nem o Vi, nem o TextMate,  é só modificar esse código para o seu editor favorito!

Fico por aqui.

Obs.:O primeiro teste que eu fiz não funcionou, pois estava faltando uma dependência no meu sistema. Era o xsel que é responsável para fazer cópias de texto do shell para clipboard. Resolvi esse problema usando: sudo apt-get install xsel
Para saber mais sobre o xsel acesse aqui.

Obs: Esse post é além de inspirador, muito esclarecedor, faz com que coloquemos novamente nossos pés onde eles precisam estar, que é no chão. Mas mostra também que podemos conseguir diversas coisas legais tomando as decisões certas e fazendo a única ação benéfica e sustentável do mundo da programação que é de ler, escrever e compartilhar código. Se algum trecho da tradução poderia ficar melhor podem mandar sugestões de mudança, o texto original você encontra aqui, fiquem agora com o texto traduzido:

Oi a todos, sou Chris Wanstrath, e vou te ensinar como se tornar um desenvolvedor Rails famoso. Um Ruby rock star. Um programador ninja. Não é difícil, apenas foque-se como um raio laser e tenha um pouco de paciência.

Devo dizer de antemão de que você não precisa se preocupar com qualquer habilidade de programação ou dez mil horas de prática. Isso não importa – é fácil de falsificar.

Então! A primeira coisa que você precisa é um blog. Mas não de qualquer blog. Você precisa de um blog com personalidade. Não importa se a personalidade do blog seja compatível com a sua própria personalidade.

A parte mais importante de qualquer blog é o nome. Claramente. Não pode ser “blog de João”. Ou talvez possa -, é que poderia ser retrô neste momento. Mas você entende o que quero dizer. Não escolha um nome que não te deixe feliz, pois se você fizer a escolha certa, você nunca vai ouvir o final da mesma. (o nome pode ser bom, mas se não te deixa feliz você acaba deixando de lado). É como escolher um nome de uma banda. Ou dando um nome para uma criança. Certifique-se de que é algo que as pessoas irão lembrar.

E tente não se tornar demasiado Railsy. Isso é limitante – faça o seu próprio. É o seu blog, apesar de tudo.

Eu não deveria ter de dizer esse próximo passo, eu odeio dizer isso, mas tenho que dizer: nunca use um template de blog default. Isso é um tiro no próprio pé.

Veja por quê: você eventualmente publicará conteúdos de qualidade no seu blog. Não de imediato, não se adiante. Mas você vai escrever alguns posts realmente bons. Eles serão linkados no Hacker News e Reddit, eles serão “tweetados” e guardados no delicious, e, se tiver sorte, você receberá uma menção em um ou dois podcast.

A primeira vez que alguém visitar o seu blog, se o conteúdo é bom o suficiente, ele aprecia isso. Talvez ele adicione aos favoritos dele. Em seguida, ele passará ao próximo item no leitor de feed.

A segunda vez que a mesma pessoa visitar o seu blog, se o design é único e a personalidade brilha através do conteúdo, ele vai lembrar. “Ei. Eu estava aqui antes. Foi bom!”

Agora não sei exatamente quantos posts de qualidade você vai precisar porque vai depender de cada indivíduo. Alguns se conectam imediatamente. Eles não têm vergonha. Outros são mais lentos – eles fazem você trabalhar por isso. Três, quatro, talvez cinco posts maravilhosos antes deles se conectarem. Mas eles vão conectar.

A idéia aqui é associação – se o seu blog usa um template sem identidade, ninguém vai lembrar que eles estiveram lá antes. Que leram um bom post nele. Você está lutando uma batalha difícil.

Gaste tempo com o design. Talvez contratar alguém, faça alguns favores para um amigo designer, não sei, você vai descobri.

E quando você fizer isso, você terá um nome matador e um design elegante. Bom começo.

Agora para as personalizações. A barra lateral, o cabeçalho. Essas coisas essenciais.

Se você vai colocar uma lista de blogs que você gosta na barra lateral, e eu não colocaria, você tem que ter muito cuidado. Se os blogs são muito populares, as pessoas vão pensar que você é um “Maria vai com as outras”. Se eles são muito desconhecidos, eles podem pensar que você está com má companhias. É melhor estar seguro e ignorar completamente a coisa toda.

Na verdade eu só mantenho a barra lateral escassa, muito escassa. Sem tag clouds ou comentários recentes ou posts recentes. Talvez apenas o arquivo, que cria uma lista mensal. Listar os projetos de interesse pode ser bom.

Ah, e seu endereço de email. As pessoas vão querer enviar email para você.

Mas como eu disse, escasso. Não se distraia do seu conteúdo.

E nunca use anúncios Google – você vai eventualmente querer aderir a uma rede de anúncios patrocinados. Os anúncios do Google apenas desvalorizam o bem (blog).

O cabeçalho é importante porque é a primeira coisa que as pessoas veem. Uma foto sua é provavelmente melhor. Algo especial. Mas se você não pode encaixá-la no cabeçalho, a barra lateral funciona igualmente bem. Lembre-se: as pessoas têm de reconhecer você, saber que você é o João de “blog de João”.

Quanto ao conteúdo, você precisa decidir sobre o seu perfil. Você deve fazer uma lista de dez ou mais famosos desenvolvedores Rails, talvez em uma planilha, e escolha um adjetivo que descreva cada perfil deles. Vá até a lista escolha a combinação que funciona para você. Lúdico e espontâneo? Profissional e inspirador? Ofensivo e verborrágico? Escolha duas características que você acha que pode ter sucesso. Escreva elas. Este é agora é o perfil de seu blog.

A etapa final, antes de blogar, são as regras. Você precisa estabelecer diretrizes para o seu blog, as regras sobre o conteúdo. Se Hashrocket começa a falar de Scala, você pode aderir a controvérsia? Você pode postar sobre o grande e novo cliente Twitter que você baixou? E sobre suas experiências com o Android SDK? Você está centrado no código, a comunidade, suas observações, ou truques esotéricos?

(Eu ficaria longe de truques esotéricos como competência central mas ocasionalmente entregue-se ao desejo a fim de manter a sua credibilidade. Mas isso é só comigo.)

A coisa importante sobre as regras é que ajudam a estabelecer a coerência. Você não quer postar sobre uma elegante biblioteca uma vez e nunca mais mencioná-la novamente. Isso confunde as pessoas. Eles desejam algo estruturado.

Dê isso a eles.

Ok, com tudo o que disse, podemos começar a blogar. Mas não estamos realmente blogando ainda. Estamos apenas praticando. Todo dia você precisa escrever um post. Não importa sobre o que. Ninguém vai lê-los. Mas você precisa práticar a escrita e aperfeiçoar seu tom. Dê ao seu blog uma personalidade.

O que postar? Qualquer coisa. Em vez de apenas fazer um Gist seu belo pedaço de código, post sobre isso no seu blog. Adicione uma pequena história de fundo.Mas não fale continuamente sobre ela. A menos, claro, que seja o seu tom, seu perfil.

A grande coisa sobre como iniciar um novo blog é que você pode voltar atrás e olhar para antigos Gists,  plugins antigos que você escreveu, tarefas rake malucas, e fingir que eles são totalmente novas. Escreva. Faça um post. Trata-se de algo novo para qualquer outra pessoa.

Outro truque bom é olhar o que outros blogueiros estão fazendo, bibliotecas populares ou técnicas que foram pioneiras e melhorar as mesmas. Dessa forma eles fazem a maior parte do trabalho, mas porque você fez um pouco melhor, você pode conseguir alguma atenção deles.

Fale sobre testes. Lamente a falta de alguma coisa. Talvez até mesmo inicie algum problema com o código de outro blogueiro. Ele não funciona para você, por isso é uma porcaria.

Após algumas semanas podemos começar a fazer algo sério. Mas, entretanto, o que você vai fazer sobre a sua conta no Twitter?

Você tem uma, certo? Bem, você não vai querer “tweetar” negligentemente postagens do seu blog – Isso é um enorme fora. E você não quer “tweetar” que você apenas começou um blog, porque não há nada lá e é uma oportunidade perdida.

Em vez disso você poderia mudar o design do seu Twitter (o pano de fundo, cores dos links, tudo isso) para corresponder ao seu blog. Faça-os cumprimentar um ao outro. Enfeite-o para o sucesso. E seja legal.

Dessa forma você não está apenas sendo um desenvolvedor Rails aleatório, você é o autor de “blog de João”. Você é que é João. Certifique-se que o seu avatar tem o seu rosto, também.

Na verdade, por que não usa seu Photoshop e faz um daqueles backgrounds sociais para a sua conta Twitter? Você sabe o que estou falando – com todos os links que você pode apenas ler e certamente pode não clicar. Esses fundos permite que as pessoas conheçam sua idéia de negócios e como encontrá-lo de forma conveniente.

Suas mensagens do Twetter provavelmente seguirão o tom do blog, mas, e esta é a parte divertida, aqui você pode quebrar as regras. Permita que as pessoas saibam algo sobre você. Como num reality show.

De qualquer forma, vamos adiante. Você está de pé, você está “twettando”, você está “blogando”, você está se sentindo bem. Hora de atacar.

Sua primeira postagem que você realmente acha que é bom, ponha-o lá fora. “twette” sobre ele, publique-o em sites de notícias sociais, lute para conseguir uma relação no Rubyflow. faça isso de manhã cedo em um dia da semana, horário padrão da costa leste (USA e Canadá), porque as pessoas adoram se refrescar com Reddit no trabalho.

Mas não esperem muito. Não há tal coisa como sucesso em uma noite. Temos ainda muito trabalho a fazer. Uma forma de obter visitantes e leitores é liberar códigos simples, úteis de forma resumida e diretamente em um post do blog. Mostre às pessoas o problema, mostre a solução, diga como instalá-lo e forneça um meio para fazer o download.

Outra forma é discurso retórico. Mas você tem que fazer isso muito.

No que diz respeito à identificação e liberação de código útil e simples, não se gasta muito tempo pensando nisso. siga seu dia, sua rotina normal, mas mantenha um olho para as coisas que te deixa aflito. Coisas que deixam seus colegas aflitos.

Um idiota mecheu no seu código de produção? Repetição e erro tendem a ser práticas seguras? Bug na autenticação do plugin que você está usando?

Mantenha os olhos abertos e, quando você identificar um ponto de aflição, algo que provoca atrito no seu fluxo de trabalho, anote. Armazene em algum lugar.

Mais tarde naquela noite você pode se servir com um copo de vinho, talvez um copo de uísque, sentar-se no sofá e escrever uma solução. Mantenha a solução simples e certifique-se de que você pode completar a biblioteca ou o plugin em uma noite. Em seguida, escreva uma post no blog e publique.

Limpar e repetir.

Se algo te causa dor, provavelmente causa dor em outra pessoa também. Somos todos desenvolvedores Rails  com tarefas muito similares. Bem, a maioria de nós.

Eventualmente, você vai tirar a sorte grande: algo simples que poucas pessoas querem usar. Mantenha-o, aceite patches, e siga em frente.

A medida que você ganhar mais confiança, você pode começar a procurar problemas e soluções mais ambiciosas. Você conseguirá um reconhecimento melhor.

Agora você está pronto para o circuito de conferências. RubyConfs locais, encontros em sua cidade, e no Santo Graal, RailsConf (No Brasil: Rails Summit Latin America). Abrace um projeto sério e fale sobre ele. Publique o progresso da atualizações. Mas não se esqueça de manter o seu tom e seguir as regras. Vá para os coffe brakes e conheça pessoas. Permita que eles saibam que você é o João de blog do João. Nunca tire seu crachá.

Continue postando com consistência. A maioria das pessoas não sabem a diferença entre prolífico e profundo. ambas as palavras compartilham muitas letras. Eles apenas querem algo interessante para ler, e muito disso.

Acompanhe o que todos estão dizendo sobre as seus posts no Twitter, delicious, e FriendFeed. Você não tem que responder, mas eu buscaria freqüentemente seus posts em todos estes serviços. Verifique algumas vezes em um dia.

Se você contribuir para Rails em si, que é enorme. Outros desenvolvedores famosos de Rails vão começar a notá-lo. Mesmo com comentários em blogs – especialmente os dez na sua lista. Você manteve essa planilha, certo?

Uns poucos meses disso e você estará assinando autógrafos, beijando bebês, indo a boates caras – vivendo uma boa vida.

Todo mundo vai saber o seu nome. Editoras estarão te enviando livros, pedindo-lhe para escrever no blog sobre eles. Você será convidado para falar em conferências. Será reconhecido na rua. Recrutadores vão ocupar toda sua caixa de entrada. Coisas que você disser serão significativas. Seu blog será patrocinado. Talvez você até escreva seu próprio livro.

E, claro, você vai ter de sair com os famosos. Agora você é um deles, depois de tudo.

Parabéns.

O problema é que ser programador Rails famoso não é o mesmo que ser um bom programador Rails. Qualquer pessoa pode se tornar um programador Rails famoso. Faça todas as coisas que eu disse. Boom, garanto que funciona.

Pessoalmente, eu olho para os bons programadores. Eles não se preocupam com a sua contagem de subscrição do RSS, eles blogam como complemento. Pessoas que não estão preocupadas com quantos seguidores no Twitter  possuem e trabalham nos seus projetos todas as semanas, porque adoram fazer isso. Que contribuíram para o Rails por anos por paixão e não são excessivamente preocupados com a divulgação de suas vidas.

Pessoas que se preocupam com código, primeiro e acima de tudo.

Há sempre conversas sobre colocar apelidos em IRC ou Twitter nos crachás das conferências, assim você pode identificar as pessoas que você conheceu on-line, mas nunca pessoalmente. Porque é que simplesmente não ignoramos isso e colocamos em seu lugar o projeto favorito que você tenha contribuído?

“Você contribuiu para Rack? Isso é ótimo, eu amo Rack. Talvez possamos ser amigos.”

“Você trabalhou na Webrat? Pode por favor explicá-lo a mim?”

Pense sobre isso – você conhece as pessoas envolvidas no seu favorito RubyGem? Seu plugin mais usado?

Eles são provavelmente as pessoas que você vai querer estar junto delas.

Código, estou compreendendo, é o fio comum que une os desenvolvedores. Não é pelo blog ou mensagens de erro propositais (trolling) ou pela procrastinação, e sim porque nós amamos o código.

Trata-se de leitura, escrita, e compartilhamento de código.

E quanto mais eu blogo, envio mensagens falsas (troll), e procrastino, penso que o código me trouxe a fortuna maior. O maior retorno sobre o investimento com o menor risco.

Depois que saí da faculdade, eu trabalhava com PHP em uma loja fazendo aplicações de logísticas de entrega. Éramos os intermediários entre transportadores independentes e as grandes empresas como a Kmart. Os transportadores deveriam se registrar no nosso site, dizer que iam estar em Delaware no dia 3 de maio, e que eles estão a caminho de Denver, em seguida, eles obtém informações sobre transferências ao longo do percurso escolhido. Eles poderão, em seguida pedir um preço maior no trasporte ou aceitar o valor estipulado, tudo através de nós.

Foi uma aplicação bastante complexa e duas coisas que estavam faltando: controle de versão e constantes. Não havia controle de versão, de modo que você tem coisas como main2.php e compute_radius_of_from_shipment7.php espalhados ao redor. Junto com as versões de 0 a 6 desse mesmo arquivo, no mesmo diretório. Verdadeiramente doloroso.

Não havia constantes e nenhuma configuração, de modo que o código-fonte estava preenchido com números mágicos. Se quiser fazer um ajuste em qualquer um dos nossos algoritmos, você tinha que encontrar o código que fez o processamento e alterar alguns números de forma manual. Esperávamos esperançosamente que os números estivessem corretos.

Naturalmente, a primeira coisa que fiz foi institucionalizar o Subversion. Rei dos sistemas de controle de versão.

A segunda coisa que fiz foi extrair os números mágicos e colocá-los em arquivos de configuração. Na época, nós faziamos códigos em PHP que acessavam arquivos de configuração .ini. A maior parte do que se precisava era suportado, e eu estava encantado porque o PHP vem com uma biblioteca que acessa e entende arquivos .ini.

Este sistema funcionou bem, mas quando eu comecei mexer com Rails Eu fiquei encantado com o YAML. Tão limpo, tão poderoso. Havia o Syck, uma extensão em C escrita por _why, mas era apenas isso: uma extensão C. Eu não sabia muito sobre carregamento de código C em PHP, e ainda menos sobre como fazer isso em nossos servidores de produção.

Então eu comecei a escrever um parser YAML em PHP, no meu próprio tempo. Como uma homenagem a Syck, eu a chamei de Spyc – SPYC – uma Simples Php Yaml Classe. Foi meu primeiro parser, era stateful (mantinha o estado no decorrer da utilização). Não dei suporte a tudo do YAML, mas ele suportava as principais funcionalidades – dumping e o load. As partes boas.

Me debrucei nele e em pouco tempo estávamos utilizando YAML com grande sucesso na minha empresa. Naturalmente, eu fiz o upload do código para o SourceForge. Rei dos hosts de código-fonte. Meu amigo designer fez uma página e no primeiro mês Spyc foi um enorme sucesso. Eu juro que tinha, pelo menos, 70 downloads. SETENTA!

Isso foi um grande negócio.

Avançou rápido cerca de nove meses: o meu teletrabalho de telecomunicações virou um trabalho de verdade, e eu concordei em ir para Nova Jersey. Eu embalei meu carro, disse adeus, conduzi onze horas para Hackensack, trabalhei um dia no escritório, percebi que todos os meus colegas de trabalho eram completos puxa-sacos, entrei no meu carro e dirigi onze horas de volta para Ohio.

E é isso, eu era um desempregado que abandonou a faculdade sem terminar os estudos.

Não foi tão ruim – Passei muito tempo na piscina naquele verão. E eu passei muito tempo aprendendo Ruby e Rails.

Eu até comecei freelancer novamente. Afinal, eu estava totalmente qualificado. Eu tinha 8 anos de experiência de programação – Fiz algumas QBasic, quando eu tinha 12 anos. Eu estava certo que aquilo contava.

Mas verão acabou e eu precisava descobrir o que eu ia fazer com minha vida.

Como tinha sorte, no meio desse tempo, o web site de vídeo game GameSpot estavam contratando. E eu precisava de um emprego.

Eu não tinha idéia de onde era São Francisco ou o que os caras do GameSpot estavam procurando, mas eu fiz a requisição. Criei um novo currículo e fiquei a noite toda trabalhando no tema da carta. Até o momento em que eu tinha terminado, era uma página longa e bastante convincente.

Nela eu prometi me mudar para a Califórnia no dia seguinte, levando nada além de meu violão e Xbox comigo. Minha família ia me perder, mas eu estava pronto para sair, e eu estava faminto para mostrar ao mundo o que eu podia fazer. Pronto para aprender com os mestres.

A entrevista por telefone correu bem, eles gostavam que eu estava por dentro do mundo Macs e Ruby, e eu obviamente consegui o trabalho. A primeira vez que pus os pés na Califórnia foi quando eu voei para para procurar um apartamento com meu pai.

Minha experiência profissional não foi o que fez com que eu conseguisse o trabalho. Eu tenho certeza que a minha carta tinha algo a ver com isso, mas a minha curta carreira na logística de transporte foi menos que glamourosa. Eu só tinha uma coisa para mostrar a GameSpot – Spyc. Meu código foi livremente disponibilizado, tinha sido usado em produção, e funcionou. Eles podem fazer o download e brincar com ela, ou checá-la online. Independentemente de pensarem que era bom ou não, eles poderiam dizer que era limpo e bem organizado. Bom, talvez não, mas eu tinha um site e 70 downloads.

Consegui o emprego no GameSpot, na minha opinião o primeiro grande passo no caminho que me trouxe aqui, foi graças ao código. Código que eu escrevi principalmente para me divertir, para coçar minha própria coceira.

Então isso foi muito legal, e eu achei singular, até que aconteceu de novo. Enquanto eu estava trabalhando na GameSpot, fui fazendo mais e mais Ruby em paralelo. Eu tinha um projeto Rais open souce chamado Ozimodo, péssimo servidor de FTP denominado ftpd.rb (que eu usei como forma de aprender sobre threading), e um DSL parser de linha de comando chamado Choice. Para Choice, eu tinha um suite de testes completa (eu escrevi essa suite para aprender TDD) e uma homepage criada por RDoc no Rubyforge.

Quando CNET, mãe da empresa GameSpot, adquiriu Chowhound, eles decidiram reescrever o site em Rails. A partir do zero. Clássico. Eles trouxeram dois programadores Rails da Wayfaring.com e foram à procura de outro. Então me encontraram.

Mais tarde eu descobri o meu site RDoc, RubyGem, e a suite de testes provou aos caras da Wayfaring que eu era um “verdadeiro” programador Ruby. Eles queriam alguém animado com essas coisas, e eu certamente era.

Aquele foi um grande momento, porque paguei a minha viagem para a RailsConf 2006.

Conversas sobre código.

Se você não tem quaisquer projeto nesse momento, você deve gastar algum tempo aqui começando algo novo. Algo faça sentido para você, mas que ainda não tenha ao seu redor. Uma ideia que tem estado flutuando.

Ou basta encontrar alguém que esteja haqueando e perguntar no que eles estão trabalhando. Talvez seja interessante o suficiente para pular dentro.

Se você deseja criar o seu próprio negócio, o código é a maneira perfeita para encontrar cofundadores e funcionários. Eu sempre me sinto mal por tipos de empresas que postam em fóruns perguntando sobre a melhor forma de encontrar um cofundador ou CTO. Não por causa do tipo de négocios deles – que todos temos de viver com as nossas decisões -, mas porque eu não acho que isso seja um problema.

Conheci todas as outras pessoas do GitHub através de código: PJ através Chowhound, Tom através do seu trabalho open source, Scott por causa de sua quase irritante variedade de bibliotecas Git baseadas Ruby, e Tekkub pelo seu domínio da seção Lua do site.

Na CNET, encontramos pessoas realmente talentosas, tanto através de fonte aberta e projetos locais.

E todos que você conheceu aqui que você não conhecia antes da conferência, tecnicamente, é conhecido através de código.

GitHub não tornou-se popular em virtude do Git. Ele pode ter ajudado, mas não foi o principal catalisador.

GitHub se popularizou porque ele lida com código. Compartilhando, encontrando, e contribuindo com código.

Rubyforge e Sourceforge não são focados no código. Eles nunca foram.

Na verdade, ainda ontem Sourceforge passou por um redesign na sua homepage. Eles tem pesquisa no Twitter e projetos populares ali, frente e centro. Elegante. Então eu cliquei um pouco.

O primeiro projeto que cliquei, Ares Galaxy, é o número sete na lista top dez. O visualizador CVS disse que não possui quaisquer arquivos. Então eu acho que você pode simplesmente baixar um tarball. O que é bom.

O segundo projeto que eu cliquei era o número cinco da lista, 7-Zip. Ele não tem sequer um link para um visualizador de código fonte.

Sem código.

Eu percebi que fazia muito tempo que não criava um projeto no Sourceforge, então eu decidi fazer isso. Lembro-me que é doloroso, mas este é um novo redesign.

A primeira página é constituída por cinco radio buttons, um campo Nome do Projeto, um campo Nome Unix, um textarea para descrição pública, e um textarea para Notas adicionais. A área de notas é carinhosamente fornecida para que você possa justificar ao pessoal do SourceForge porque deve ser permitida a criação de um projeto. E, claro, você não pode continuar sem dar a eles uma razão que contenha pelo menos 200 caracteres.

Penso que é uma loucura – a maioria dos dias tenho problemas com 140 caracteres.

Além disso, há um aviso na parte superior que diz que você precisa armazenar software open source.

Depois de preenchidos todos os campos e que você clicou em ‘Next’ você é convidado a escolher uma licença open source. Há oito licenças listadas, juntamente com uma opção “outros” e, em seguida, um link para documentação sobre open source e escolher uma licença. Eu escolhi MIT.

Na página três você pode atribuir a seu projeto pelo menos cinco categorias. As opções de categorias são coisas como, “Linguagem de programação Ruby”, “User Interface DirectX”, ou “Desenvolvimento Status Beta”.

Eu escolhi quatro muito facilmente, mas teve problemas com a quinta, finalizava com, “Tema Religião e Filosofia New Age”.

Muito apropriado, se você pensar nisso.

Na última página você é convidado a ler sobre o que significa open source, sobre os termos de serviço do site, em seguida submete o projeto para aprovação.

Após o envio aparece uma tela de agradecimento e um pedido para você esperar de um a três dias úteis.

Eu, obviamente, tenho interesse em desaprovar um site competidor, mas este formulário de inscrição é uma das razões para termos começado o GitHub. Uma vez que você tenha uma conta, criar um repositório GitHub é, penso eu, simples:

Pedimos nome do projeto, uma breve descrição, e a URL do projeto. abaixo desses três campos tem dois radio buttons: esse projeto é público ou privado? A única coisa necessária é o nome do projeto. Você pode mudar qualquer um dos campos mais tarde. Não há nenhum processo de aprovação e você pode imediatamente começar a compartilhar código.

Entre decidir compartilhar o seu código e realmente compartilhar o seu código, SourceForge fornece um formulário de inscrição de quatro páginas e um a três dias de espera.

Mas sua documentação em software open source afirma: “A essência do modelo de desenvolvimento Open Source é a criação rápida de soluções dentro de um processo aberto, ambiente colaborativo”.

Correto.

Aqui está a minha sugestão para SourceForge:

Devem cortar o processo de inscrição para uma única página, remover os 200 caracteres do pedido “por favor hospedem o meu projeto”, serem mais favoráveis com relação a categorização, sugerir uma licença de fonte aberta para você, então permitir que altere qualquer destas coisas depois que seu projeto seja criado.

Eles também devem tornar a criação de projeto instantânea e passa-lo através de um filtro de spam ou ter funcionários remunerados para fazerem vistorias manualmente e aprovarem cada projeto em vez olhar para a lista dos projetos recentemente criados e assinalarem os que parecem suspeitos.

Parece-me que todos os passos necessários e formulários são apenas cerimônia, retardando você e fazendo você perder tempo com algo diferente do que você realmente deseja realizar. Eles agregam valor? Certamente que não.

E se há uma coisa que eu aprendi com Rails, é deixar o inferno fora do caminho e permitir que as pessoas concentrem-se na tarefa em questão.

Reduzir atrito.

Primeira lei de Newton do movimento, faz duas afirmações: um objeto em repouso tende a permanecer em repouso e um objeto em movimento tende a permanecer em movimento. É muitas vezes referida como a lei da inércia.

E inércia, para quem não se lembra ou não teve aula de física, é a tendência do objeto resistir a mudanças no seu estado de movimento.

Se você chutar uma bola, ela vai diminuindo a velocidade até parar. Mas ela não quer parar. O Atrito criado pelo movimento ao longo do solo e do ar reage contra a bola, conspirando para pará-la a todo o custo.

Quanto mais você remover atrito, o avanço da bola vai continuar e vai demorar muito mais tempo para parar.

Esta ideia de atrito, é muito parecida com o inverso da produtividade. Ser produtivo significa obter coisas feitas de forma eficiente e eficaz. Atrito impede de você fazer essas coisas, atrasa você, conspira contra você, é uma perda de energia.

E muitas vezes, o atrito custa seu dinheiro.

Poucos meses antes da segunda RailsConf Deixei Chowhound e a CNET para iniciar uma empresa de consultoria com Hyett PJ. Sabíamos como codificar, pensávamos que sabiamos como blogar, mas não sabíamos nada sobre como iniciar um negócio.

Então, fizemos algumas pesquisas. Aparentemente, existem empresas que você pode pagar para criar um negócio para você. Muito oficialmente. Eles até mesmo enviam-lhe uma pasta para documentos de couro com o nome da sua empresa bordado sobre nela.

E existem pessoas que você pode pagar para fazer a sua contabilidade. Nós vamos chamá-los “contadores”.

Estes são dois dos mais importantes investimentos que você pode fazer quando se inicia um novo negócio: profissionais que lidam com a papelada e que manipulam os números.

E não só porque eles sabem o que estão fazendo.

Você ia querer pagar 100 dólares por hora para um contador inexperiente? Porque se seu preço de consultoria é 100 dólares por hora e você faz sua própria contabilidade é exatamente o que está acontecendo.

Mesma coisa para a criação de um negócio. Todo o tempo que você gasta pesquisando, preenchendo papelada, formulários, dirigindo para Sacramento para encontrar um tabelião – é acrescentado e torna-se caro se você fizer tudo sozinho.

A menos, claro, que seu tempo seja sem importância. Mas você está aqui, portanto, isso não é verdade.

Como seu tempo não é inútil, isso significa repetição, trabalho entediante e duro, e todos os custos excessivos de configuração custam seu dinheiro. Bem, e custam seu tempo. O tempo é muito importante, também.

Acho que uma parte essencial de ser um bom programador é a capacidade de identificar estes pontos negativos e removê-los, para agilizar o processo.

Rack, por exemplo, é ótimo porque ele torna a interface com os servidores web tão fácil.

Git branching(ramificação) e merging(mesclar) são sempre apontados como a razão da escolha.

Nós todos amamos Rails porque faz a maior parte das coisas tediosas irem embora.

E testar é famoso porque, bem, bugs e designs ruins são horríveis.

Portanto, vamos seguir esses exemplos. Vamos criar mais projetos que cocem uma coceira ou aliviem alguma dor. Vamos parar a obsessão sobre qual framework de teste usar e começar a obsessão por constuir sites que resolvam problemas. Vamos parar de discutir sobre linguagens e continuar aprimorando a nossa favorita. Vamos parar de criar longos tutoriais para obter assinantes RSS e começar a contribuir para a documentação oficial.

Vamos nos concentrar mais no código e menos nas conversas. Mais nas informações sobre a comunidade e menos sobre nós mesmos.

Na verdade, acho que já estamos no caminho certo. O Ruby Heroes Awards é uma grande idéia e são dadas para as as pessoas certas. Sites como o Rubyflow e até mesmo o Twitter torna mais fácil do que nunca encontrar projetos novos e interessantes. Calendar About Nothing torna simples encontrar programadores apaixonados e dar uma olhada no que estão trabalhando, enquanto RailsCasts e DocRails são alguns dos melhores esforços de documentação em qualquer comunidade.

Então, sim. Queremos mais disso.

Afinal, nós queremos realmente ser estrelas de rock como Kid Rock ou Axl Rose? Pessoas que são famosamente irresponsáveis – que têm reputações degradante para os seus fans e notoriedade para o seu planeta que é do tamanho do próprio ego?

Acho que eu prefiro trabalhar com e ser um bom desenvolvedor.

Obrigado.

O problema é que o Capitão Morrimento precisou sair de férias do seu batalhão, mas mesmo assim quer garantir que a equipe continue na linha e quer acompanhar os aspirantes para não ter problema com eles no futuro.

Para piorar a situação descobri que o Capitão Morrimento é muito extressado e não quer perder tempo com interface complexa. Ele tem conhecimento dos softwares básicos de escritório (somente o editor de texto). Então ele quer algo que se aproxime o máximo possível de copiar dos registros dos aspirantes que ele tem no seu PC e colocar em um campo que faça a verificação e diagnóstico do Aspira.

Sabendo da necessidade de criar algo simples, resolvi usar os conceitos de DSL (Linguagens Especificas de Domínio) do Ruby e fiz a seguinte classe para que ele pudesse entrar com dados no formato que ele usa no dia-a-dia dele:

def aspirante(nome, &bloco)
		Aspirante.new(nome, &bloco)
end

class Aspirante

	def initialize(nome, &bloco)
		@nome = nome
		@dados = {
			:descricoes => [],
			:numero => nil
		}

		instance_eval(&bloco)

	end

	def descricao(dados)
		@dados[:descricoes] << dados
	end

	def numero(numero)
		@dados[:numero] = numero
	end

	def resultado()

		if @dados[:descricoes].include? "corrupto" then 5.times{ puts "PEDE PRA SAIR!"}

		elsif @dados[:numero] == 2 then 5.times{ puts "PEDE PRA SAIR! SEU 02! Tu e CORRUPTO!"}

		elsif @dados[:descricoes].include? "PM" then 2.times{ puts "NAO VAI SUBIR NINGUEM!"}

		elsif @dados[:descricoes].include? "dorminhoco" then 2.times{ puts "TRAGAM A GRANADA!..."}

		else puts "O senhor e um FANFARRAO seu #{@dados[:numero]}.\n Sera interrogado diretamente pelo CAPITAO."

		end
	end

end

Agora é só salvar esse código num arquivo e carregar (load class_aspirante.rb). Então O Capitão pode usar da seguinte forma:

a1 = aspirante “José dos Azóis” do
numero = 04
descricao = “Disciplinado”
descricao = “Competente”
descricao = “etc”
end

a partir daí é só usar a1.resultado e obtém a resposta que queria.

Bom esse exemplo está em aberto, gostaria de dicas para melhorá-lo, porque, como falei antes, o capitão morrimento é muito esquentado e eu não quero ser chamado de Fanfarrão

Quem puder contribuir com novas dicas de implementação para que a linguagem DSL Caveira fique mais intuitiva e eficiente fique à vontade para comentar.

Até logo.