Levy Carneiro

Being a Web Developer myself, I keep finding myself thinking of new ideas of web 2.0 sites to build. And now being a Railer, it seems it gives much more power to actually build a killer web app

This guy, Seth Godin, is a well-known Marketing professional and speaker. He really captures the essence in what the costumer wants in a product or service.

The things you learn when you have a blog, or at least when you try to build a great blog on a certain subject, are probably the same things you’ll use when creating a web 2.0 application. That leads to this very interesting article I found on Seth’s blog, which I re-post here.

That makes a lot of sense. After you read that book you love, where can you go to get more of that insight? The author’s blog. Like, once when I read “Freakonomics” I went straight to the author’s blog. I knew I could go there to keep update on the stuff he mentions in the actual book.

37signals is leading a tribe through their blog. In Brazi Fabio Akita and Carlos Brando for instance, are leading a tribe of passionate Rails developers.

What tribe are you willing to lead?

Without further ado, here’s the article.

The number one secret of the great blogs

by Seth Godin

Every one of them leads a tribe.

Boingboing readers recognize each other at conferences. We use the same shorthand, we recognize the same memes. Huffingtonpost editors don’t try to reach everyone. Instead, they are hosting a digital cocktail party for invited guests that have something in common. Garr Reynolds doesn’t try to teach everyone about Powerpoint… instead, he leads a tribe of people committed to changing the way the world communicates in meetings.

Go down the list. Hugh leads a tribe. Josh  leads a tribe. So does Mitch. And Guy, who just wrote a book for his tribe too. It’s not hard to find other examples for my thesis.

In each case, the function of the blog is to be a standard bearer, the north star that tribe members can point to as a place to meet or for ideas to circle around. The blog isn’t about the writer, it’s about the readers.

The key takeaway is this: once you realize that your job is to find and connect and lead a tribe, to give them something to talk about and a place to go, it’s a lot easier to write a blog that works.

Esse título poderia ser: “por que não dá para fazer um blog em 15 minutos”. Tudo bem, David Hanson consegue, afinal ele é o cara

Estou falando do famoso vídeo de uma criação de um blog em 15 minutos, feito pelo próprio criador do framework Ruby on Rails, David H. Hanson. Se você não viu ainda, veja agora! É interessante ver o quanto um vídeo pode fazer para propagar um produto ou idéia, e para empolgar as pessoas. Muitas pessoas que começam a mexer com Rails dizem “eu vi aquele vídeo de 15 minutos, e fiquei impressionado” (myself included!). Desde a criação deste vídeo em 2005, o Rails já evoluiu muito e hoje o próprio DHH diz que já é possível fazer a mesma coisa em 3 minutos. Para um vídeo mais atualizado veja o screencast do Akita, sobre criação de um blog em Rails 2.x (disponível em inglês e português).

Voltando ao assunto, criar um blog em 15 minutos é fácil. Agora para quem quer aprender Rails no processo de criação de um blog, a história é outra. Você precisa de um blog funcional com: autenticação de administrador, um layout mínimo, controle de versão, algum esquema de deployment automatizado, etc.

Pretendo descrever aqui não um processo de um blog, mas sim o processo que fiz para criar o meu blog. Vamos lá:

Layout: aqui é onde muitos programadores (principalmente eu!) empacam. Criar um layout do zero não é fácil, especialmente se você tem bom gosto e especialmente se já viu muitos sites bons por aí. O layout deste blog ficou bem diferente do que eu havia imaginado, mas até que quebra o galho. Levei 2 semanas para criar uma imagem no Photoshop deste layout. Muito tempo, né? Um designer faz isso em 1 hora, se já tiver uma boa direção sobre o que ele precisa criar. Outra coisa que consumiu um certo tempo foi procurar ícones na web. Você geralmente precisa de ícones para realçar o seu layout, e achar um icon set que te agrade, também pode demorar. No meio desse processo, encontrei um blog de um designer chamado Joel Watson que fala muito sobre o processo de criação de um layout de sites, e o que te faz ser um designer melhor. Está em inglês. Vale a pena ler.

Criar o CSS: essa parte é mais tranquila. Em 1 ou 2 horas você cria o CSS básico, e depois vai aperfeiçoando. Se você precisa aprender CSS nos padrões Web, alguns sites que recomendo são: o blog Tableless, o campus online de vídeos da Visie, o blog Pinceladas da Web e o Revolução Etc.

Hospedagem Rails: deployment de Rails não é simplesmente fazer upload dos arquivos e pronto, site funcionando (a menos que você use Mod_Rails e já tenha o Apache configurado). Com Rails você pode fazer o deployment de uma aplicação usando várias combinações de software: Apache + FastCGI, Mongrel, Mod_Rails (Phusion Passenger), Nginx, Thin, Lighttpd. A maioria dos provedores de hospedagem nem sabe como fazer funcionar um site em Rails. Alguns oferecem o Apache + FastCGI, que não funciona muito bem, e só aguenta um uso bem moderado da aplicação. Ao ver algumas opções no mercado, acabei escolhendo o Rails Playground (plano Developer, a US$ 5 / mês, com opções maiores de plano, para quando o site crescer), mas existem outros como Linode, SliceHost, e outros bem mais caros como Engine Yard, Joyent, e por aí vai. Na Rails Playground uso atualmente Apache + FastCGI (eu sei, totalmente básico sendo que temos Passenger, Mongrel, e outros), mas com a opção de mudar para Mongrel quando precisar. E é até interessante começar algo com a versão simples, e ir sentindo a necessidade de escalar a aplicação. E nesse processo todo, você aprende muito sobre deployment de Rails. Você primeiro escala o teu código, fazendo o melhor com o que você tem, e só aí parte pra mudanças no servidor. O investimento de ter uma conta de hospedagem em um provedor que entende de Rails vale muito a pena, altamente recomendado para quem quer aprender Rails.

Controle de versão (Git, é claro!): o Akita fala muito disso no Rails Brasil Podcast. E não é pra menos. É impossível você criar uma aplicação sem ter um controle de versão das alterações. E aqui entra o Git, um software opensource de controle de versão criado pelo Linus Torvalds, sim ele mesmo, o criador do Linux. Em 1 semana esse cara criou um controlador de versão, descontente com as opções existentes no momento (em 2006).

Repositório do código (GitHub, é claro!): depois de criar um código inicial da tua aplicação, ou pelo menos o arquivo README que seja, você precisa colocar isto em um repositório de onde você possa acessar remotamente e trabalhar no código sempre que quiser. Funciona assim: você cria uma conta no GitHub, e envia a tua aplicação para o site. Depois sempre que você quiser trabalhar em cima da aplicação, você “baixa” o código para tua máquina local, trabalha nas alterações, faz teus commits, e depois envia as atualizações para o repositório. Você pode usar o plano free, onde teus projetos são considerados open-source, e assim todos podem abrir e ver teu código. Ou você pode usar um plano pago, a partir de U$ 7/mês, e criar projetos privados, que só você pode ver.

Deployment da aplicação: Capistrano é uma solução em Ruby, que funciona na tua própria máquina. Funciona como um script que faz em sequência, todas as tarefas que você faria para colocar um site em produção:

• entra por SSH no servidor de produção;
• gera um tar.gz do conteúdo atual do site;
• envia o conteúdo novo do site;
• corrige permissões em arquivos;
• roda Migrations, no servidor de banco de dados;
• restarta o servidor Web;

É altamente recomendado, e depois de configurado você só precisa rodar “cap deploy” para subir uma nova versão para produção.

Em breve, teremos a próxima parte da série de posts sobre como foi criar este blog, usando Ruby on Rails. Stay tuned!