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:
Segue a brincadeira:
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”.
Foto do que possÃvelmente seria o primeiro bug encontrado em um computador
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.
Foto de Marc Castejón
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.
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:
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!
Foto de Marcin Wichary
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.
Foto de D'Arcy Norman
Até pouco tempo atrás o Textmate era uma unanimidade para programadores Rails. Recentemente porém tenho visto alguns programadores migrando para outros editores de texto, como o Vim e o Emacs.
Embora eu já tivesse uma certa experiência com esses últimos, eu nunca havia tentando desenvolver código de verdade com eles. Depois de fazer uma experiência trabalhando com cada um deles por uma semana, vejo que ambos são excelentes editores de textos e obviamente boas alternativas para o desenvolvimento de software em diversas linguagens.
Porém, quais critérios devem ser usados ao comparar essas ferramentas e decidir qual delas é a melhor? Quais são as caracterÃsticas mais importantes em um editor de textos que poderiam determinar a minha escolha?
Acredito que o mais importante nesse caso é ser proficiente. Chega a ser irritante ver alguém pressionar dezenas de vezes a seta para a esquerda afim de colocar o cursor no começo de uma linha ou recorrer ao mouse para chegar ao topo do documento no Textmate, sendo que existem atalhos para se fazer isso com apenas uma combinação de teclas.
Escolher um editor de textos para programar não deve ser algo trivial. A curva de aprendizado é bastante Ãngreme até que você não precise mais pensar em quais combinações de teclas devem ser usadas para realizar uma operação. Tudo deve acontecer por reflexo.
É importante que a ferramenta seja flexÃvel, permitindo que o programador possa configura-la de acordo com as suas preferencias. Como o processo de aprendizado é lento, é importante que você possa continuar usando o editor de textos mesmo ao trocar de uma linguagem para outra. Bons editores são capazes de aprender a trabalhar com qualquer nova linguagem de programação que apareça.
Alguns recursos como syntax highlighting e auto-indentation são indispensáveis para o desenvolvimento de software.
A conclusão é que todos esses editores de textos mencionados no inicio do artigo passam com louvor na avaliação dos requisitos mÃnimos. Mas isso ainda não responde a pergunta: Qual é o melhor editor de textos para se trabalhar com Rails?
Eu não sou um usuário comum do Textmate. Além de me sentir totalmente à vontade com essa ferramenta eu estou constantemente implementando meus próprios Bundles e refinando os recursos que mais uso para o meu estilo de trabalho.
Como particularmente sou mais produtivo no Textmate, então especialmente para mim essa é a melhor ferramenta para programar em qualquer linguagem.
A idéia aqui não é defender o meu editor preferido. De fato, não importa se você escolheu o Textmate, o Emacs ou o Vim. Desde que o seu editor seja uma extensão das suas mãos.
Eu costumo trabalhar muito com o terminal, assim é natural usar o comando mate . para carregar um projeto Rails no meu Textmate.
Em projetos grandes é normal utilizar o sistema de buscas da ferramenta para localizar um arquivo ou encontrar alguma declaração, por exemplo. Embora existam plugin como o excelente AckMate que melhorem perceptivelmente a performance dessas buscas, elas ainda costumam ser lentas. Um dos vilões nessa história são os arquivos temporários e logs que são inclusos no processo de busca, e normalmente esses arquivos costumam ser bem grandes. Além de deixarem a busca mais lenta, eles também acabam poluindo o resultado já que na maioria das vezes não estamos procurando por algo nos logs.
Arquivos de log incluÃdos nas buscas
Inicialmente eu costumava remover os diretórios tmp e log depois de carregar o projeto no Textmate. Porém realizar essa operação todas as vezes não era nada prático.
A solução mais simples e definitiva é alterar as configurações do Textmate para que ele ignore esses diretórios. Para isso abra as preferencias do editor de textos (⌘,) e na opção Advanced vá até a aba Folder References.
Folder References
Os dois campos acima são expressões regulares que determinam quais arquivos e diretórios devem ser carregados em um projeto. Isso é útil para impedir que o diretório do CVS apareça no Textmate, por exemplo.
Para adicionar os diretórios log e tmp nessa lista negra precisamos alterar o campo Folder Pattern. Adicione |tmp|log exatamente antes do |CVS. Pronto, de agora em diante toda vez que um projeto for carregado à partir de um diretório, essas pastas também serão ignoradas.
Além disso você também pode adicionar outros diretórios ou arquivos, como por exemplo a pasta vendor se você não pretende alterar ou visualizar o código de plugins e gems.
MS-DOS
Acredite, nem sempre houve interfaces gráficas. Meu primeiro contato com um computador foi feito através de uma tela preta com letras verdes. Não me lembro exatamente, mas provavelmente era alguma versão do MS-DOS ou do PC-DOS.
Qualquer criança com acesso a um computador nessa época, rapidamente aprendia a manipular arquivos e diretórios através de comandos básicos que o sistema operacional oferecia. Era necessário aprender esses comandos se quisesse se divertir com um novo jogo, por exemplo. Além disso, muitos jogos mais sofisticados exigiam que o usuário entendesse, mesmo que superficialmente, como o sistema operacional manipulava a memória. Termos como memória estendida, superior, convencional e expandida eram comuns na roda de amigos.
Pode parecer nostalgia, mas mesmo depois de mais de uma década, todo esse conhecimento básico continua me sendo prático até os dias de hoje. Afinal, a maior parte do meu trabalho é resolvido através daquela mesma janela do terminal.
É claro que muitos programadores conseguem realizar todo o seu trabalho através de uma um ambiente integrado de desenvolvimento (IDE). Mas será que realmente podemos fazer tudo igualmente bem apontando o ponteiro do mouse e clicando?
Eu sempre acreditei que não. Interfaces gráficas são ótimas e realmente convenientes para muitas situações, mas o seu poder também é a sua limitação. Quando nos tornamos dependentes de uma interface gráfica (GUI) para realizar nosso trabalho, estamos presos à imaginação dos desenvolvedores que a criaram.
No terminal, nossa liberdade é quase infinita. Não vamos encontrar nada muito sofisticado lá, a maioria dos comandos e utilitários realizam apenas uma única tarefa. Mas realizam essa tarefa muito bem. Não existem distinções entre documentos, diretórios, discos rÃgido, drives de CD e DVD, teclados, impressoras e monitores por lá. Todos são simplesmente arquivos e são manipulados como tais, o que facilita muito as coisas.
Mas a maior vantagem do terminal é que podemos facilmente combinar sequencias desses comandos em scripts, o que nos dá a liberdade de automatizar praticamente qualquer tarefa que podermos imaginar, algo essencialmente importante para um programador pragmático que se preze.
Tire o máximo de proveito da sua IDE, mas não ignore o terminal. Aprender a usar bem o shell deve ser uma prioridade para qualquer programador iniciante.
gabriela em 
biker solitario em 