Durante o almoço eu estava conversando com um colega e citei que, se tivesse uma empresa, gostaria de contratar um programador/desenvolvedor/engenheiro que fosse preguiçoso. Por meio minuto ele deve ter imaginado que eu estava louco, ou que queria abrir transformar minha empresa imaginária numa repartição pública.

Vou tentar ser breve na explicação.

O primeiro ponto é que uma pessoa preguiçosa, dentro desse contexto, é completamente diferente de uma pessoa acomodada, encostada ou vagabunda. Uma pessoa preguiçosa, novamente nesse contexto, é aquela que se incomoda de fazer várias vezes ao dia a mesma tarefa, e encontra meios de automatizar isso.

Um caso real: eu trabalhei numa projeto em que era necessário compilar os fontes, passar os binários resultantes (executáveis, DLLs ou JARs) por um software proprietário para que esses fossem convertidos num formato que a plataforma proprietária entenda, e então utilizar um outro software para jogar esse binário convertido para dentro do dispositivo.

O segundo passo, a conversão dos binários, era freqüentemente esquecido, fazendo com que um binário desatualizado fosse instalado no dispositivo, desperdiçando tempo e estressando os envolvidos.

Um colega, preguiçoso, criou um passo novo que foi adicionado ao Maven para que essa geração fosse automatizada, reduzindo todo processo à compilação e instalação. Não fosse o software de instalação tão fechado, a coisa toda seria realizada num único processo.

O mesmo acontece com a utilização de testes automatizados. Poderíamos muito bem executar passo a passo todos os itens de uma planilha gigantesca cada vez que eu gerasse uma nova versão do sistema. Ao invés disso, escrevemos alguns testes automatizados (705 da última vez vi) que levam trinta segundos para executar toda vez que você altera o código. A cada nova funcionalidade, uma nova série de testes é escrita, fazendo com que a coisa seja menos trabalhosa para todos os envolvidos.

Automatizar tarefas repetitivas aumenta a produtividade, reduz drasticamente a possibilidade de que erros idiotas aconteçam e ainda te dá tempo para investir no que realmente interessa.

E você, está sendo preguiçoso ou acomodado?

Pessoal, hoje estamos lançando a pesquisa de intenção do nosso próximo produto: Sitefique.me, uma ferramenta online para criação de sites focado na simplicidade.

Sobre o produto

A idéia surgiu há vários anos mas somente agora nos sentimos experientes o suficiente para tirá-la do papel mantendo sua principal característica: ser simples. Se você acompanha nosso blog já deve ter notado que nossa busca por simplicidade é uma constante (e não é uma coisa fácil de se encontrar nos ambientes corporativos).

Foi seguindo essa filosofia, de ser simples, que decidimos criar o Sitefique.me, voltado para pequenas empresas, que têm a necessidade de um site próprio, divulgar seus produtos e serviços ou até mesmo vendê-los pela internet, mas que ainda não encontraram a ferramenta na medida ou que coubesse no orçamento da empresa.

O Sitefique.me permite criar um site do zero em poucos minutos, escolhendo um layout que pode ser personalizado, e criar páginas a partir de modelos prontos como vitrine de serviços, álbum de fotos, localização com mapa e formulário para contato. Tudo muito simples e direto ao ponto.

Precisamos da sua ajuda

A versão final do produto ainda não está disponível. Estamos finalizando os detalhes, cuidando de alguns assuntos legais, e passando aquele pente fino no código, mas pretendemos lançá-lo nas próximas semanas. Por enquanto, gostaríamos que respondessem nossa pesquisa de intenção, para nos ajudar a decidir sobre alguns pontos do produto, como valores e planos. Quem responder nossa pesquisa e tiver interessado no produto, será convidado para testá-lo antes do lançamento oficial e ainda ganhará o primeiro mês de mensalidade grátis, sem compromisso.

Infelizmente não possuímos capital para investir na divulgação. Tudo que fizemos até agora foi com nosso próprio dinheiro (servidores, etc) e nosso “tempo livre”. Por isso, pedimos sua ajuda para divulgá-lo:

• Se você apóia iniciativas de empreendedorismo como esta, indique o produto para seus contatos ou empresas que podem necessitar desta solução. Você também pode retuitar para seus seguidores.

• Se você é um desenvolvedor, como nós, nos ajude divulgando o produto para sua rede de contatos, como mais um “case” de Ruby on Rails. Você também pode retuitar para seus seguidores.

• Se você tem um tio ou um cunhado que pega no seu pé nos encontros de família: “Ei sobrinho, quando você vai fazer um site para minha lojinha”, nos ajude indicando o Sitefique.me. De qualquer forma, você também pode retuitar para seus seguidores.

• Ou se você simplesmente já sofreu com a famosa Síndrome do Sobrinho, com certeza nos ajudará a retuitar para seus seguidores.

Muito obrigado.

Retuite para seus seguidores. Assine o blog do produto. Conheça a empresa. Entre em contato.

Documentação é aquilo que você reclama para fazer e reclama quando não encontra.

Por Plínio “Chico Xavier” via Twitter.

Isto me fez refletir (bem rápido) sobre as possíveis causas da não-documentação:

• É muito chato ! Editar wiki, doc … é incrível como toda documentação geralmente é feita em algo não produtivo.

• Espaço e Tempo (ou seja, prazo!). Sempre é deixado por último e nunca sobra tempo pra ser feito.

• Não é levado a sério. Levanta a mão que já viu a secretária documentando “tela” de sistema … :D

• Normalmente o “investidor” do software não vê valor nisto, ou melhor, espera alguém pedir e repassa a tarefa com prioridade “faz rapidinho”.

Ok. Após reflexão feita, hora de atacar o problema.

Usando “guides” para criar um Guide !

Este é um resultado da experiência abaixo:

Com a gem guides, em segundos você tem um scaffold, pronto para ser preenchido.

<span style="font-family: Georgia, 'Bitstream Charter', serif; color: #444444;"><span style="line-height: 22px;">$ gem install guides</span></span>




<span style="font-family: Georgia, 'Bitstream Charter', serif; color: #444444;"><span style="line-height: 22px;"> </span></span><span style="color: #444444; font-family: Georgia, 'Bitstream Charter', serif; line-height: 22px;">$ guides #mostra os comandos disponíveis</span>




<span style="font-family: Georgia, 'Bitstream Charter', serif; color: #444444;"><span style="line-height: 22px;">$ guides new sample</span></span>




<span style="font-family: Georgia, 'Bitstream Charter', serif; color: #444444;"><span style="line-height: 22px;">$ cd sample</span></span>




<span style="font-family: Georgia, 'Bitstream Charter', serif; color: #444444;"><span style="line-height: 22px;">$ guides build && guides preview</span></span>

Pronto. Em http://localhost:9292 você terá acesso ao novo guia gerado.

Preenchendo o seu Guia

Em guides.yml (exemplo aqui), está o básico do seu Guia. Nele está o índice de “capítulos”, com resumo e nome do arquivo que o link deve seguir. Os arquivos textile  gerados/criados ficarão na pasta source, o resultado do “guides build” ficará na pasta output.

As páginas são em textile, o que facilita bastante. Mas o grande diferencial, está em alguns helpers disponibilizados pela gem, que torna muito simples criar áreas de destaque como INFO, WARNING … etc e adicionar comandos e códigos.

Para ter idéia de uma página em textile, segue o link source/getting_started.textile (raw).

Repensando a documentação

Com certeza, usando a gem guides, vocẽ consegue um boost na hora de documentar. Já evitando aquela chatice de editar wiki, .doc, controlando versão … etc. Usando textile, seu editor preferido e git, não tem mais desculpas.

Desenvolvendo Frameworks e APIs

Já faz um tempo que eu topo com a vibe Documentation Driven Development. Como tudo na vida, é questão de bom senso. Documentar uma API, nada mais é do que definir a interface dela, e dependendo do caso, isto ajuda bastante antes de começar o desenvolvimento.

Você é um Usuário !

Uma documentação com um monte de imagem e seta, descrevendo o óbvio não serve para nada (além de passar raiva). Uma documentação sucinta, com o básico, por exemplo Instalação, Modo de Usar, Configurações Disponíveis é bem melhor que muito dossiê por aí ! Tente ao máximo se colocar no lugar do usuário ao escrever alguma documentação ou ajuda.

Não deixe de contribuir com o post. Mande sugestões, comentários, reclamações etc.

Aproveitando a grande repercussão do post do Plínio sobre atitude empreendedora e um gancho do meu último post sobre simplicidade e prática constante, volto ao assunto depois que o Roger me lembrou deste gist do Vínicius Teles, que foi escrito por Klaus Wuestefeld, autor do manifesto da Computação Soberana e criador do Prevayler, apresentando dicas de conduta na carreira e como aproveitar as oportunidades.

Apesar de ter gerado muita discussão sobre se vale a pena ou não fazer faculdade, a idéia aqui é apenas gerar reflexão e reforçar o que vimos falando nos últimos posts. Divirtam-se!

Torne-se excelente

Seja realmente bom em alguma coisa. Não fique só choramingando ou querendo progredir às custas dos outros. Não pense que, porque você sentou 4 anos numa faculdade ouvindo um professor falar sobre software, você sabe alguma coisa. Jogador de futebol não aprende a jogar bola tendo aula. Ele pratica. Instrumentistas geniais não aprendem a tocar tendo aula. Eles praticam. Pratique. Chegue em casa depois do trabalho e da aula e pratique. No final de semana, pratique.

Crie seu próprio vírus, seu próprio jogo, seu próprio SO, seu próprio gerenciador de janelas, seu próprio webserver, sua própria VM, qualquer coisa. Várias coisas.

Não precisa ser só programação. Pode ser networking, vendas, etc. Só precisa ser bom mesmo. Tenha paixão pela coisa.

As melhores práticas do mercado são polinizadas primeiro nos projetos de software livre. Aprenda com eles.

Discípulo, Viajante, Mestre: Primeiro seja um discípulo, tenha mestres locais, aprenda alguma coisa com alguém realmente bom, qualquer estilo. Depois viaje, encontre outros mestres e aprenda o estilo deles. Por fim, tenha o seu estilo, tenha discípulos, seja um mestre.

Vou fazer o curso da Mary Poppendieck em SP semana que vem e quando tiver o curso de Scrumban do Alisson e do Rodrigo quero fazer também.

“Torne-se excelente” também pode ser chamado de Melhoria Continua ou Learning.

Não seja deslumbrado

Desenvolvimento de software é a mesma coisa há 60 anos: modelo imperativo. Há 30 anos: orientação a objetos. Bancos de dados relacionais: 30 anos. (Web, por exemplo, não é uma tecnologia ou um paradigma. É meramente um conjunto de restrições sobre como desenvolver e distribuir seu software).

Não corra atrás da última buzzword do mercado. Busque a essência, os fundamentos.

Busque na Wikipédia e Grokke: determinismo, complexidade de algoritmos O(), problema de parada de Turing. Pronto, pode largar a faculdade. Falando sério.

Trabalhe com software livre. Não dê ouvidos a grandes empresas, grandes instituições ou grandes nomes só porque são grandes.

Você acha que vai aprender mais, ter mais networking e mais chance de alocação no mercado trabalhando em par comigo no Sneer por um ano, 8h por semana, ou passando 4 anos na faculdade, 20h por semana, pagando sei lá quanto por mês?

Você acha que vai aprender mais trabalhando em par com o Bamboo 6 meses na linguagem Boo e na engine do Unity ou fazendo um ano de pós em “a buzzword da moda”?

“Não seja deslumbrado” também é conhecido como Coolness.

Mantenha-se Móvel

Com a demanda que temos hoje no mercado, se você é desenvolvedor de software e não consegue negociar um contrato com uma empresa onde você é pago por hora e pode trabalhar quantas horas quiser com um mínimo de meio período, você precisa rever a sua vida.

É melhor ter dois empregos de meio período que um de período integral, porque você pode largar um deles a qualquer momento.

Você nunca vai conseguir nada melhor se não tiver tempo, se não tiver disponibilidade pra pegar algo melhor quando aparecer.

Você sustenta seus pais e 7 irmãos? Não. Então pare de ser ganancioso e medroso no curto prazo, para de pagar facu, mestrado, pós, MBA, sei-lá-o-quê e vai aprender e empreender.

Trabalhe remoto. Não é o mais fácil, mas é perfeitamente possível.

Não fique reclamando que está trabalhando demais. Aumente seu preço e trabalhe menos.

Emparceire-se Promiscuamente

Participe de dojos, de congressos, de projetos de software livre. Tenha amigos, colegas, conhecidos. Seja conhecido. Não faça ruído em seis projetos e doze fóruns. Ajude de verdade em um ou dois projetos de cada vez. Ao longo do tempo, você terá ajudado em varios projetos, trabalhado em várias empresas.

Mentalidade de Abundância

Ajude seus amigos sem cobrar (a “camaradagem” do Vinícius). Dê palestras gratuitas. Cursos gratuitos. Participe de projetos de software livre.

Pare as vezes uma tarde pra receber um amigo seu e explicar seu projeto. Vá visitar seus amigos nos projetos deles. Viaje com algum amigo seu pra visitar um cliente dele, só pra conversar e fazer companhia.

Você tem um espaço onde dá cursos? É uma Aspercom, Caelum da vida? Chama os brothers para dar curso. Porra, bola um modelo em que as pessoas podem se inscrever para cursos variados, pagando um sinal, e mantém tipo uma agenda pré-combinada: “Será numa terça e quinta à noite, avisadas com duas semanas de antecedência”. Se rolar, beleza, se depois de meses não der quórum, devolve o sinal. Pode ser curso de Prevayler, de Kanban, de Scrum, de Lean, de Comp Soberana, de Restfulie, de Cucumber, de Rails, de Teste Automatizado Mega-Avançado, qualquer coisa.

Chame amigos seus pra dar curso em dupla com você. Divida clientes. Divida projetos, mesmo que não precise de ajuda.

Dizia o pai de um brother meu de infância: “Tudo que custa dinheiro é barato”.

Busque modelos de custo zero

Trabalhe em coisas que tem custo administrativo / burocrático / manutenção zero. Por menos ganho que tragam, depois de prontas, estarão tendo uma relação custo/benefício infinitamente vantajosa.

Ganhe notoriedade

Faça coisas massa. Participe de projetos de software livre. Dê palestras gratuitas. Promova eventos (dojos, debates, grupos de usuários, etc).

By Dairton Bassi: Não tenha medo!

Meta a cara. Arrisque empreender. Arrisque inovar. O que você tem a perder? No máximo um emprego, mas isso pode ser revertido facilmente em um mercado aquecido como o atual. O pior que pode acontecer é não dar certo. Mesmo assim você terá aprendido muito mais do que batendo cartão.

Saia da zona de conforto. Se o seu trabalho estiver fácil e sob controle, isso significa que ele não está mais agregando para a sua evolução técnica e pessoal.

Não desperdice a chance de trocar de função se a nova oportunidade for mais desafiadora. Isso fará você crescer tecnicamente e o preparará para desafios maiores ainda. Conhecer pessoas novas é tão importante quanto manter-se em contato com código.

Não se detenha por insegurança ou pela sensação de despreparo. Como você acha que vai ganhar experiência em alguma coisa se sempre adiá-la?

Antes de qualquer outra coisa, escrevo esse post em forma de autocrítica e como um tapa na cara em mim mesmo. Espero que a carapuça sirva em você também.

Cena 1: dois programadores estão tomando refrigerante enquanto reclamam do site que um terceiro programador fez, deu certo e e acabou virando a principal fonte de renda do empreendedor.

Cena 2: um grupo de funcionários critica um colega que está ganhando mensalmente o equivalente ao salário com aplicações para iPhone e iPad com frase do tipo ‘isso aí até eu faço’, ou ‘é pura falta do que fazer’.

Cena 3: um programador, desses acostumados a usar paletó, gravata e passar o dia em cima de diagramas de stick figures, setinhas e balões, profere sem o menor pudor: ‘Estudar uma tecnologia nova em casa? Eu só aprendo algo novo se for pago pra isso.’

Cena 4: um colega, inocente e empolgado, convida outro para participar de um Coding Dojo, e recebe como resposta: ‘programar depois do expediente? eu prefiro levar uma topada no dedão’

E a clássica cena 5: funcionários reunidos almoçando/tomando café/fumando/num happy hour e falando mal do coordenador/líder técnico/chefe/diretor/gerente/empresa em geral.

Pense um pouco e você vai perceber que, com certeza, já presenciou ou já fez parte de algumas dessas cenas.

Reclamar, ficar insatisfeito, criticar ou debochar é algo natural, faz parte da natureza das pessoas e, acho eu, até mesmo de certas espécies de animais. O problema aparece quando a crítica vira choradeira e nunca passa disso.

Eu trabalhei numa empresa pequena, com cinco funcionários, onde havia contato direto com o dono e com os clientes. A quantidade de coisas que aprendi ali, tanto profissionalmente quanto pessoalmente é algo que me ajuda até hoje. Porém, talvez pelo fato de eu ter ficado por ali mais tempo do que seria produtivo para ambas as partes, eu perdia tempo demais reclamando, me estressando e agindo de forma infantil e improdutiva. Chegou ao ponto de uma namorada dizer ‘que cada funcionário está na empresa que merece, e cada empresa tem o funcionário que merece’.

Até hoje penso nessa frase e apesar de toda a violência com a qual ela foi empregada, não deixo de notar a realidade por trás das palavras.

Um ex-funcionário do Google escreveu um artigo (se alguém ainda tiver o link, por favor me envie) em que conta que seus colegas reclamavam da qualidade do granulado usado nos doces que eram dados pela empresa no horário de trabalho simplesmente por não terem do que reclamar.

Já presenciei colegas reclamando da qualidade da churrascaria que a empresa escolheu para a confraternização de fim de ano, onde comeram e beberam de graça sem pagar um centavo que fosse. E, honestamente, era um local que eu não teria condições de levar minha família sem deixar uma parcela considerável dos meus rendimentos.

As pessoas, incluindo eu e você, deveriam parar de choramingar, de reclamar e de perder tempo com conversinhas inúteis e começar a meter a mão na massa, produzir coisas de que se orgulhem e que sejam úteis para outras pessoas.

Não estou me limitando ao discurso Go Horse de ‘não está feliz, peça as contas’. Estou dizendo para que você pense em como se tornar adulto, até mesmo em como se tornar economicamente autossuficiente (pela Nova Gramática).

Atualmente, o custo de se iniciar um projeto ou de se colocar uma idéia em prática usando a Internet é próximo de zero. Qualquer pessoa com iniciativa e, principalmente, acabativa, consegue colher bons frutos com praticamente nenhum investimento além do próprio tempo.

Fazendo uma conta de padaria: se você investir uma hora e meia por dia estudando e/ou implementando uma idéia, por mais absurda que ela pareça para os outros, em um mês você vai ter investido 45 horas, o que é tempo mais do que suficiente para aprender os fundamentos de uma nova linguagem ou apresentar um protótipo da idéia.

Hoje em dia você tem Rails, Sinatra, Django, web2py, uma lista imensa de ferramentas que permitem a criação rápida de aplicações, sem a perda de tempo de editar arquivos XML, descritores ou ficar desenhando bonecos de palitinho.

Pare de reclamar. Se organize. Tenha metas claras e reais. Pare de apontar o dedo e comece a trabalhar. Leve o problema a quem for devido ao invés de simplesmente adotar uma postura passivo-agressiva. Busque motivação onde ela não existe, ou vá respirar novos ares. Tente uma forma diferente de fazer as mesmas coisas, compartilhe conhecimento, ouça mais e aprenda mais.

Enfim, deixe de ser uma menininha chorona e comece a agir.

E, a propósito, parabéns ao Vinicius Teles e equipe pelo trabalho iniciado, concluído e bem feito.

No final do ano passado, ao ver um twitty do José Valim, fiquei tentando a comprar o livro, mas depois do post Crafting Rails Applications: Why I wrote this book, tive certeza que não perderia este presente de Natal.

Apesar de poucas páginas, o livro tem muito conteúdo. Logo no começo, em “Who should read this book ?” é avisado, não é para iniciantes. Os capítulos são separados em tópicos interessantes, abordando diferentes maneiras de extender o Rails 3.

Aliás, extender é a palavra chave do livro. Dos projetos que compõe o Rails, somente o Active Resource não foi citado. O livro com certeza pula o básico, ou seja, não espere por explicações em como usar as funcionalidades do Rails.

–

Detalhes que tornam o livro interessante.

• Enginex – é uma Ruby gem que cria um Rails 3 Engine com Rakefile, Gemfile e pronto para rodar testes em cima de uma aplicação “vendorizada”. Ou seja, no livro temos projetos reais, que são executados e tem testes !

• TDD – todo código apresentado, é feito seguindo o Test-driven Development, mostra-se o teste falhando e vai implementando aos poucos, até tudo ficar verde.

• Como melhorar o seu código – conhecendo Responders e o Renderer Stack do Rails 3, você com certeza irá ampliar o seu leque de possibilidades de como melhorar o fonte das suas aplicações. Tem bastante exemplos de Rails Generators também.

• Desmistificando Rails – o Valim realmente conseguiu de forma majestosa explicar as entranhas do Rails 3. A cada capítulo e detalhe explicado, pude ver o verdadeiro trampo que fizeram no projeto, em comparação com o 2.x, o Rails mudou muito (internamente!).

Finalizando…

Se você é um desenvolvedor que se preocupa em conhecer a fundo o framework que trabalha, compre agora! Confesso que depois da leitura, estou muito mais a vontade para navegar no fontes do Rails, inclusive passei a acompanhar os tickets no Lighthouse. :D Rails 3 definitivamente está mais flexível, e o José Valim conseguiu expor tudo isso com código e uma leitura agradável.

Este é um assunto polêmico e que gera muita discussão nos escritórios de TI. Mesmo assim, tendo trabalhado em várias empresas, grandes e pequenas, presenciando vários projetos fracassarem por decisões arquiteturais (as gerenciais não contam nesse contexto), e os mesmos erros sendo cometidos repetidas vezes, sinto-me na obrigação de passar esta experiência e meu ponto de vista.

Escalabilidade, por definição

De acordo com a Wikipedia, escalabilidade é uma característica desejável em todo o sistema que indica sua habilidade de manipular uma porção crescente de trabalho de forma uniforme, ou estar preparado para crescer. Em outras palavras, um sistema deve estar preparado para suportar uma demanda crescente.

Pode ser classificada como:

• Carga de escalabilidade: um sistema distribuído deve ser fácil para ser expandido e usar sua gama de recursos para acomodar tanto exigências do mesmo sendo elas pouca ou excessiva.

• Geograficamente escalável: um sistema é geograficamente escalável quando ele mantém sua utilidade e usabilidade, não obstante como são usados os seus recursos.

• Escalabilidade administrativa: não importa a variação de informação que diferentes organizações necessitam compartilhar em um único sistema distribuído, ele deve permanecer fácil de ser usado e gerenciado.

• Escalabilidade funcional: capacidade de melhorar o sistema, adicionando novas funcionalidades com mínimo esforço.

Pode ser aplicada como:

• Escalabilidade Vertical (scale up): significa adicionar recursos em um único nó do sistema (mais memória ou um disco rígido mais rápido).

• Escalabilidade Horizontal (scale out): significa adicionar mais nós ao sistema, tais como adicionar um novo computador com uma aplicação para clusterizar o software. Você pode encontrar escalabilidade horizontal nos sabores Sistemas Distribuídos, Serviços de Componentes, SOA, System of Systems, etc.

Do ponto de vista do custo de desenvolvimento, manutenção e suporte, eu defino escalabilidade como: caro (complexo) vs. barato (simples). Porém, o que é caro nem sempre é bom… e vice versa.

Analogias com o mundo real

Nós gostamos de fazer analogias com coisas reais, são ótimas para expressar idéias e facilitar a comunicação.

Call centers, ou centrais de atendimento. Se você mora no Brasil provavelmente já perdeu algumas horas de sua vida pendurado no telefone tentando resolver um problema com sua assinatura de celular, internet, TV, energia elétrica, etc. Mas por que isso acontece? Provavelmente, essas centrais de atendimento começaram com poucos funcionários, porém foram “projetadas” para crescer conforme a demanda. Basta contratar mais funcionários, dar treinamento e pronto: mais “nós” atendendo as requisições. Entretanto, o processo passa a ser mais complexo e mais burocrático, pois é muita informação para disseminar entre os funcionários. Resultado: alto custo para empresa e pouco resultado para os clientes. A espera ainda existe e quando finalmente somos atendidos, a sensação é de estar falando com um robô, que dificilmente entenderá seu problema e dará uma solução padrão ou insatisfatória para o mesmo.

O processo é adequado para escalar a demanda horizontalmente, o que o torna complexo e não garante a qualidade. Vale lembrar que o software apenas automatiza ou apóia a realização dos processos reais. Se o processo é complexo, o software será tão complexo quanto (e em alguns casos até mais complexo).

Um exemplo diferente: o Fusca. É um dos carros mais simples que existem, não precisa nem de refrigeração a água. Costuma-se dizer que pode ser consertado com um alicate e um rolo de arame. Seu custo de fabricação seria mínimo se comparado com o custo de um carro popular moderno. Ok, não oferece a mesma segurança, velocidade e conforto de um carro moderno, mas ambos conseguem transportar 5 passageiros ao destino desejado.

Mas o que um Fusca têm a ver com escalabilidade? Bem, imagine um congestionamento na véspera de um feriado, por exemplo. Tanto o Fusca quanto o carro moderno ficarão parados na mesma fila de farofeiros. Toda tecnologia, complexidade e custo da fabricação do carro moderno não o livra de um congestionamento. Não há projeto que consiga prever ou contornar esse problema.

Voltando para nossa realidade, em certos casos o custo não paga o benefício. Mesmo um sistema bem planejado, distribuído, separado em camadas e serviços independentes, pode não suportar a demanda, seja de carga ou de funcionalidade. O mesmo aconteceria com um sistema mais simples arquiteturalmente, com certeza. Porém, o custo e velocidade de desenvolvimento e manutenção seria bem menor.

O que fazer então?

Sistemas precisam evoluir de acordo com a necessidade. Projetar um sistema prevendo todos os possíveis “casos de uso” bem como suas hipotéticas cargas (ou acessos) é uma forte característica do waterfall. Sistemas mais simples arquiteturalmente evoluem mais facilmente, em outras palavras, escalam mais facilmente:

• Keep it simple, stupid! Soluções simples geralmente custam menos e trazem retorno mais rápido. Qualquer funcionalidade ou recurso que não agregue valor deve ser descartada. Simples assim!

• Simplifique requisitos. Clientes sem software costumam viajar nos requisitos. Converse, escute e entenda exatamente seus PROBLEMAS, então negocie e sugira uma SOLUÇÃO simples e rápida. E a entregue logo!

• Busque soluções prontas. As necessidades dos clientes, em muitos casos, são parecidas. Provavelmente existe alguma solução pronta que você pode entregar para seu cliente ao invés de desenvolver um novo [software que todos conhecem] do zero.

• Otimize sua infra-estrutura. Procure a melhor forma de deploy da aplicação. Qual hardware é mais adequado, qual sistema operacional e arquitetura. Faça tunning do webserver (workers, pool, memória), módulos e load balance. Utilize uma versão otimizada do interpretador, como o Ruby Enterprise Edition, JRuby ou Rubinius.

• Monitore sua aplicação. Uma vez que esteja em produção, monitore-a em busca de gargalos e possíveis pontos de otimização. Existem várias ferramentas para ajudá-lo nessa tarefa, como o Hoptoad, NewRelic, ou até mesmo o Rubinius Profiler.

• Otimize sua aplicação. O log é seu melhor amigo no desenvolvimento. Não ignore queries demoradas ou que geram N+1, otimize-as! Faça profiling, analise e otimize o código. Utilize caching para serviços externos e para páginas. Caching pode ser a melhor alternativa para turbinar sua aplicação, mas use-o com sabedoria. Bancos de dados não devem ser um problema, por isso saiba escolher a melhor distribuição para seu caso. Mesmo que NoSQL esteja na moda, não quer dizer que é a melhor solução para sua aplicação (a menos que seja necessário para o negócio).

• Simplifique o desenvolvimento. Fameworks ajudam bastante, mas use-os com sabedoria para não inflar o stack da aplicação. Em certas situações, vale mais a pena desenvolver algo simples do zero do que utilizar algo pronto, pesado e que precise ser adaptado para sua necessidade. Escreva menos: quanto menor seu código, mais rápido será sua execução. Camadas são perigosas: evite rodeios e escreva código que realmente interessa. E lembre-se: sempre existe uma ferramenta certa para cada problema.

SIMPLIFIQUE!

Tenha sempre a palavra SIMPLES gravada na sua mente. Se uma coisa exigir muito esforço para ser feita, talvez nem valha a pena. Volte para o início, pense novamente e busque uma ALTERNATIVA mais rápida/fácil/barata. Quanto melhor for sua técnica, melhor serão suas escolhas. Pratique constantemente.

Se você está pensando em fazer o deploy da sua aplicação Rails em um server Nginx com Phusion Passenger, você está no caminho certo! Não apenas pela segurança e performance do Nginx, mas também pela facilidade de instalação e configuração quando comparado à outros web servers populares.

A instalação do Nginx bem como configuração do módulo do Passenger são relativamente simples. A documentação de ambos é bem completa. Você provavelmente não terá muita dificuldade. Eu recomendo seguir o passo-a-passo da instalação do Passenger:

  passenger-install-nginx-module

Uma vez que tudo esteja instalado, é hora de configurar o Nginx editando o arquivo nginx.conf (provavelmente localizado em /usr/local/nginx/conf/nginx.conf)

Usando sub URI

O deploy como sub URI torna sua aplicação acessível com o endereço http://dominio.com/app1, sendo app1 o nome da sua aplicação. Supondo que diretório público do Nginx esteja em /var/www e sua aplicação Rails em /var/rails/app1, configure-o assim:

http {
    ...
    server {
        listen 80;
        server_name dominio.com www.dominio.com;
        root /var/www;
        passenger_enabled on;
        passenger_base_uri /app1;
    }
    ...
}

Ainda é preciso criar um link simbólico para que o contexto da aplicação Rails seja visível pelo document root em /var/www:

ln -s /var/rails/app1/public /var/www/app1

Reiniciando o Nginx, sua aplicação já estará rodando. Para adicionar outras aplicações, basta adicionar:

        passenger_base_uri /app1;
        passenger_base_uri /app2;
        passenger_base_uri /app3;

E em seguida criar os links simbólicos como descrito acima. Nota importante: em alguns casos, será necessário informar a URL relativa correta nas configurações do Rails:

   config.action_controller.relative_url_root = "/app1"

Usando subdomain

O deploy como subdomain torna sua aplicação acessível com o endereço http://app1.dominio.com. Basta configurar o Nginx como segue:

http {
    ...
    server {
        listen 80;
        server_name app1.dominio.com;
        root /var/rails/app1/public;
        passenger_enabled on;
    }
    ...
}

Note que o root aponta diretamente para o diretório “public” da aplicação Rails. Para fazer o deploy de outras aplicações como subdomínio, basta configurar outro “server”, alterando root e o server_name:

http {
    ...
    server {
        listen 80;
        server_name app1.dominio.com;
        root /var/rails/app1/public;
        passenger_enabled on;
    }
    ...
    server {
        listen 80;
        server_name app2.dominio.com;
        root /var/rails/app2/public;
        passenger_enabled on;
    }
    ...
}

Uma vez que o DNS do host esteja corretamente configurado, suas aplicações estarão acessíveis em http://app1.dominio.com, http://app2.dominio.com, etc.

Dúvidas ou sugestões, utilizem os comentários. Sucesso!

Enviar emails de uma aplicação Rails é muito simples. A parte complicada fica com a configuração do ambiente e do servidor de email. Se você não souber ou não tiver muita paciência para fazer isso (por exemplo instalar e configurar sendmail, mutt, etc), pode facilmente usar sua conta do Gmail para enviar as mensagens da sua aplicação.

Basta incluir as seguintes configurações no bloco config dos respectivos ambientes da aplicação (por exemplo, config/environments/production.rb):

  config.action_mailer.delivery_method = :smtp
  config.action_mailer.smtp_settings = {
    :enable_starttls_auto => true,
    :authentication => :plain,
    :address => smtp.gmail.com,
    :port => 587,
    :user_name => "seuemail@gmail.com",
    :password => "suasenha"
  }

O toque mágico é a chave :enable_startls_auto => true para habilitar TLS. Sucesso!

Quantas vezes você precisou buscar alguma informação externa para sua aplicação, como um número de telefone ou uma foto em algum site? A idéia é simples: criar um crawler script para fazer parse de algum conteúdo HTML. E basta apenas Ruby e Nokogiri.

Exemplo

Digamos que eu queira obter a última versão de uma dada gem consultando diretamente no site http://rubygems.org para me ajudar quando precisar instalar novas gems no meu ambiente. Vamos ao código:

#!/usr/bin/env ruby

require "rubygems"
require "open-uri"
require "nokogiri"

gem = ARGV[0]
site = open("http://rubygems.org/gems/#{gem}")
document = Nokogiri::HTML(site)
version = document.css(".title h3").text

puts "#{gem} version #{version}"

Vou salvar esse script no arquivo gem-version.sh, torna-lo executável com chmod +x gem-version.sh em seguida executar no terminal:

$ ./gem-version rails
  rails version 3.0.3

Pronto, agora você também pode brincar à vontade com Nokogiri no seu shell!