Durante o ano de 2008 eu gravei um programa semanal com as últimas noticias sobre Ruby on Rails junto com o Fábio Akita. Infelizmente o programa não sobreviveu àquele ano.

Durante muito tempo eu planejei voltar a gravar o Rails Podcast Brasil, mas nenhuma das tentativas deu muito certo. Hoje felizmente não faz mais sentido um programa como aquele, já que noticias sobre Ruby e Rails podem ser facilmente encontradas em sites como o Ruby Inside Brasil e outros.

Mesmo assim eu ainda desejava voltar a gravar. Assim me juntei ao Rafael Rosa Fu em um novo projeto: o Grok Podcast!

A intenção desse novo podcast é apresentar um único assunto por vez e aprofundar o máximo possível dentro desse tópico. Os episódios sempre girarão em torno de programação, empreendedorismo e tecnologia.

O primeiro episódio conta a história da empresa PayPal. Nos baseamos no livro Founders at Work de Jessica Livingston, para contar sobre os primórdios da empresa. Acredito que esse tipo de conhecimento é prático para qualquer programador e principalmente para aqueles que pretendem iniciar o seu próprio negócio.

Espero que gostem e ajudem a divulgar esse novo projeto!

Grok Podcast: http://grokpodcast.com/

Agradecimentos

Eu gostaria de agradecer ao Vinícius Machado da X4-Internet Development Solutions e a galera da Anathumana pela trilha sonora que eles prepararam especialmente para este podcast.

Também tenho de agradecer ao Rafael B. Tauil pelo logo maneiro que ele desenvolveu para o projeto.

Patrocinio

Este primeiro episódio é patrocinado por Webbynode. E foi com a ajuda deles que conseguimos esse site maneiro para o programa.

Se você deseja patrocinar ou ajudar o podcast de qualquer forma entre contato conosco através do formulário de contato desse blog ou do próprio site oficial do podcast.

Priit Haamer liberou recentemente a documentação atualizada do Rails 3 para o aplicativo Dictionary.app do Mac OS X.

Para instalar é fácil, basta baixar o dicionário, decompactá-lo e copiar o arquivo para o diretório ~/Library/Dictionaries.

A common task is uploading some sort of file, whether it’s a picture of a person or a CSV file containing data to process. The most important thing to remember with file uploads is that the form’s encoding MUST be set to “multipart/form-data”. If you’re using form_for just using file_field inside of it does the trick, but if you’re using form_tag :multi_part => true must passed as an HTML option, in the second options hash. If you forget to do this the file will not be uploaded.

Nos dias 6 e 7 de agosto desse ano estive presente na segunda edição do Oxente Rails em Natal no Rio Grande do Norte. E para variar o evento superou as expectativas. Programadores de qualquer linguagem e pessoas interessadas em empreendedorismo não podem perder esse evento, simples assim.

Abaixo estão os slides da minha apresentação e um trecho de código que será facilmente entendido por aqueles que assistiram a minha palestra.

Se você pretende executar o código abaixo é necessário instalar a gem RubyInline antes:

gem install RubyInline

Segue a brincadeira:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

require "rubygems"
require "inline"

class << self
  inline do |builder|
    builder.add_compile_flags '-fasm-blocks'
    builder.c "
      int sum(int num1, int num2) {
        int result;
    
        __asm__{
          mov eax, num1
          mov ebx, num2
          add eax, ebx
          mov result, eax
        }
    
        return result;
      }
    "
  end
end

puts sum(2, 3)

Se você não pôde estar presente, a boa notícia é que esse ano todas as palestras foram gravadas e devem ser disponibilizadas em breve!

No dia 9 de setembro de 1945 a equipe da Dr. Grace Hopper (que mais tarde se tornaria a criadora da linguagem COBOL) e de Howard H. Aiken estava diante de um problema na sala do computador Mark II. Depois de uma análise minuciosa detectaram uma mariposa entre os contatos de um dos relés do computador. Ironicamente Grace documentou o incidente nos registros adicionando o inseto e a frase “First atual case of bug being found”.

Existe um efeito psicologico muito forte quando um erro explode em um software. É dificil para um profissional assumir que cometeu um erro ou deixou de testar adequadamente antes de colocar algo em produção. Quando um bug aparece, a tendencia é sempre procurar pelo culpado ao invés de procurar pelo problema.

Há alguns anos eu trabalhei em uma consultoria que mantinha uma lista na parede com um ranking dos programadores que mais deixavam bugs no código. Toda vez que um usuário ligava reclamando de algo, iniciava-se uma espécie de corrida para ver quem encontrava o culpado primeiro. Assim que o infeliz programador era apontado, ele era obrigado a vestir uma faixa com os dizeres: “Eu quebrei o código” durante todo o dia de trabalho.

Não é possível desenvolver um software isento de falhas. Infelizmente, os computadores ainda estão limitados a fazer aquilo que mandamos ele fazer, e não necessariamente aquilo que queremos que ele faça. E enquanto isso não se tornar uma realidade estaremos sempre em modo de manutenção.

Desenvolver é um ciclo que envolve escrever algo original por alguns minutos e então passar algumas horas solucionando bugs. Escrever um código novo e então reescrever algo que aparentemente ficou ruim. Todos os programadores deveriam ter isso em mente antes de ingressarem nessa profissão.

Um bom programador precisa inicialmente desligar todos esses sistemas instintivos de defesa. Eu sei muito bem o que é estar procurando por um bug no código com o gerente de um lado e o cliente do outro observando cada passo que você dá. Concentre-se, não perca o foco.

Pense em um médico. O paciente chega no consultório com dor de cabeça, nauseas, dor em certas partes do corpo, etc.. Se o médico tentar solucionar cada um dos sintomas de forma isolada ele estará mascarando o real problema do paciente. O objetivo é identificar o que está gerando todos esses sintomas. Ao localizar a raiz do problema e medicar o paciente corretamente, de forma natural todos os sintomas desaparecerão.

Da mesma forma, o maior erro que um programador pode cometer ao tentar resolver uma falha em um sistema é atacar os sintomas. Isso normalmente só confundirá a sua mente.

A maneira mais simples de encontrar um erro no código é explicando o problema para outro programador. A outra pessoa não precisa dizer uma única palavra, o simples fato de explicar passo-a-passo o que o código deveria fazer, normalmente é o suficiente para que você mesmo vislumbre o que pode estar causando a falha.

Pode parecer simples demais, mas ao explicar o problema para outra pessoa você terá de entrar em detalhes que talvez estejam passando despercebidos por você. Isso lhe dará uma nova visão do problema.

Solucionar bugs é parte da rotina de um programador. Algumas técnicas apenas diminuem a quantidade de incidencias no seu código, mas evitá-los totalmente é impossível. O mais importante é ter em mente que um erro no software, mesmo trabalhando em uma grande equipe nunca terá um culpado, ele sempre será um problema seu.

Estou sempre recebendo e-mails de pessoas interessadas em Ruby me questionando se realmente vale a pena gastar o seu tempo estudando essa linguagem de programação ao invés de estudar linguagens mais conhecidas como Java ou C#. Tenho certeza que a mesma dúvida preenche a mente de qualquer um que esteja interessado em apostar em alguma tecnologia emergente.

Por que alguém estaria disposto a gastar o seu precioso tempo estudando algo no qual não tem certeza se terá a oportunidade de ganhar dinheiro com isso depois?

A minha resposta sempre foi: “paixão”. Bons programadores são apaixonados pelo que fazem, isso explica o motivo deles adorarem estar sempre aprendendo coisas novas.

Mas existe um dilema cultural aqui. A maioria de nós vem de famílias que emergiram para a classe média apenas uma ou duas gerações atrás. Fomos ensinados por nossos pais e avós a colocar os interesses financeiros da família em primeiro lugar e deixar a satisfação profissional em segundo plano. Isso explica muito bem porque tantos profissionais continuam em empregos ruins, mesmo insatisfeitos.

Seguindo o pensamento de nossos pais, não é mais inteligente apostar no time que está ganhando? De forma alguma. Correr riscos e estar satisfeito profissionalmente são sem dúvida a receita para o sucesso.

http://github.com/carlosbrando/ruby-on-rails-tmbundle

Getting lost with all available attributes names on an Active Record object is normal, especially on large projects.

A lot of programmers have developed the bad habit of consulting the migrations to identify which attributes are available on an Active Record model. This certainly is not the smartest way to do this.

I had been using a gem called annotate to automatically add comments in my models with the database schema. But that wasn’t automatic enough.

So I decided to create something more practical and I ended up implementing a pseudo-intelissense for Textmate which can display a list with all available attributes for each Active Record model in my project. See how it works:

The idea is pretty simple. The variable name is important here. Since you can’t get the project scope through TextMate (if anyone has an idea how to do it please let me know), then the variable name is what indicates which Active Record model should be used.

For example, if you have a model named User you should use variable names as user, @user, @@user, etc.. Variables such as product and @products will show the Product model attributes. The concept is simple. If you use a different variable name, you must indicate which model should be used.

This is still an experimental feature and a work in progress. See some of the latest features that I’ve been working in recent days:

[nggallery id=1]

You can install running the following commands in the terminal window:

mkdir -p ~/Library/Application\ Support/TextMate/Bundles

cd ~/Library/Application\ Support/TextMate/Bundles

git clone git://github.com/carlosbrando/ruby-on-rails-tmbundle.git "Ruby on Rails.tmbundle"

osascript -e 'tell app "TextMate" to reload bundles'

This bundle is a fork of Dr. Nic’s ruby-on-rails-tmbundle. So if you already have installed this bundle, it’s advisable to remove it before to avoid conflicts.

The project is on GitHub: http://github.com/carlosbrando/ruby-on-rails-tmbundle

Enjoy!

Quem nunca se confundiu com o nome dos atributos em modelos do Active Record? Principalmente em projetos maiores é comum se perder com os nomes das colunas que cada tabela do projeto possui.

Alguns programadores acabam criando o péssimo hábito de consultar os arquivos de migrations para identificar quais atributos estão disponiveis através do banco de dados em uma classe do Active Record. Além de não ser nada pragmático, essa com certeza não é a forma mais inteligente de se fazer isso.

Até então eu costumava usar uma gem chamada annotate para adicionar de forma automática comentários em meus modelos com os nomes dessas colunas. Isso já simplificava bastante.

Resolvi então avançar um pouco mais e implementar um pseudo-intelissense no Textmate que pudesse exibir em uma lista quais atributos estão disponíveis em cada modelo do Active Record em meu projeto. Veja como ficou:

A ideia é bem simples. O nome da variável é importante aqui. Como não é possível recuperar o escopo do projeto através do TextMate (se alguém tiver uma ideia de como fazer isso fale comigo), então o nome da variável informa qual é o modelo do Active Record correspondente.

Por exemplo: Se a variável se chamar user, @user, @@user ou qualquer coisa parecida então o bundle procurará pela classe com o mesmo nome, no caso User. O mesmo vale para um modelo chamado Product, onde você deverá usar variáveis com nomes como product, @product e assim por diante.

Esse recurso ainda é experimental. Ainda há muita coisa a ser feita, como melhorar o sistema de cache e resolver algumas incompatibilidades com gemsets do RVM e diferentes versões do Rails.

Para instalar, faça o download do bundle (clique aqui) e carregue-o clicando duas vezes.

Você também pode instalar diretamente pelo terminal, executando os comandos abaixo:

mkdir -p ~/Library/Application\ Support/TextMate/Bundles

cd ~/Library/Application\ Support/TextMate/Bundles

git clone git://github.com/carlosbrando/ruby-on-rails-tmbundle.git "Ruby on Rails.tmbundle"

osascript -e 'tell app "TextMate" to reload bundles'

Esse bundle é um fork do repositório do Dr. Nic, no qual eu também sou commiter. Se você já tem o bundle do drnic instalado, é melhor remove-lo antes de instalar esse novo para evitar conflitos.

O projeto se encontra no Github: http://github.com/carlosbrando/ruby-on-rails-tmbundle

Boa diversão!

A muitos anos atrás programar em Visual Basic era uma escolha de baixo risco. Para um jovem em inicio de carreira, como eu, parecia a escolha óbvia a fazer. Era fácil encontrar trabalho, porém havia tantos programadores Visual Basic no mercado que a média salarial não era nada especial. Um baixo risco e uma baixa recompensa.

Com o tempo o Visual Basic cedeu espaço ao C# e mais uma vez essa era a escolha natural para muitos programadores. Mais uma escolha de baixo risco e por consequência uma recompensa compatível.

Depois de mais de dez anos trabalhando com tecnologia Microsoft, conheci o Ruby. Eu realmente gostava de programar com essa linguagem, porém poucas empresas estavam investindo em Ruby e era muito difícil conseguir um emprego para trabalhar com ele.

Mas alguma coisa dentro de mim dizia que havia algo especial naquela linguagem somada ao framework Rails. Era um sentimento forte de que aquilo poderia se tornar grande.

Eu investi cedo em Ruby, numa época em que o risco era muito alto. Alto risco, grandes recompensas.