Faz mais de um mês desde que voltei de viagem e só agora consegui algum tempo para começar a escrever sobre essa jornada. Quero iniciar com minha primeira atividade logo que cheguei em São Francisco, participar da conferência Techcrunch Disrupt.

Segunda-feira, 8 de setembro, iniciou bem cedo. Pelo que dizem, o Disrupt é um dos eventos mais importantes do mundo das Startups, onde iriam expor cerca de 300 novas Startups de muitas partes do mundo.

O evento foi no The Concourse, cerca de 1km a pé da Market St. descendo pela 8th. O local parece um armazém gigante, com interior convertido para uma área de eventos. Internamente ele foi dividido numa área semi-fechada no fundo, com centenas de cadeiras dispostas como num teatro com um palco à frente, filmada e projetada em cerca de três telões para que o pessoal sentado ao fundo pudesse enxergar tudo. A cenografia foi muito bem preparada, como um evento desse calibre exige, com iluminação verde que é a cor do Techcrunch.

O resto do espaço entre o hall de entrada e o teatro foi dividido em duas enormes áreas abertas. A principal, que dá acesso ao teatro foi chamado de Startup Alley, uma grande exposição de Startups, a maioria dos Estados Unidos. O resto do espaço foi organizado entre alguns países. Usando uma fração da área principal do Startup Alley, estavam os pavilhões de Israel e Coreia do Sul. Esse grande espaço pode ser considerado a área nobre pois é onde a maioria das pessoas transitava entre o hall de entrada e o teatro.

Na área menos movimentada ficava o maior pavilhão internacional, o brasileiro, com cerca de 30 Startups brasileiras expondo. No mesmo espaço mais ao fundo ficaram o resto dos países como Argentina, Chile, México e até uma solitária, embora animada, Startup do Japão. Os momentos mais movimentados nessa região era somente durante almoço e intervalos para lanche, porque as mesas de comida eram montadas no meio de todos os pavilhões.

De qualquer forma, o lugar em si era gigante. Não sei a contagem exata, mas tranqüilamente cabiam pelo menos 3 mil pessoas ao mesmo tempo. Não era um evento pequeno. Para mais detalhes, vocês podem ler a cobertura da própria Techcrunch, o resto será minha impressão pessoal.

Basta começar dizendo que de todas as intenções de visita que eu tinha meses antes de decidir ir, não havia pensado nenhuma vez no Disrupt. Portanto minhas expectativas não eram grande coisa. Imagino que para as Startups expondo a missão foi cumprida pois o que eles buscavam era uma chance de expor seu produto a possíveis investidores. Não importava tanto o volume de pessoas assistindo, mas a qualidade dos seus cartões de visita. Como meu objetivo não era expor, fui com um olho mais de exploração.

Eu sou bem chato com definições, quando leio a palavra "Disrupt", assumo a definição do dicionário: "que drasticamente altera ou destrói uma estrutura de alguma coisa." Com isso em mente, já devem imaginar qual será minha opinião do evento.

Do ponto de vista de quem estava em busca de idéias disruptivas ou inovadoras digo que fiquei bem decepcionado. Gastei os três dias percorrendo cada uma das Startups que estavam expondo já que todos os dias eles rotacionavam as startups do Alley, e quase nada chamou minha atenção. Vejam por vocês mesmos na lista de startups disponível no site do evento. Certamente haverá muitas interessantes de se ver, mas "disruptivas"?

Além das startups que rotacionavam todos os dias no Alley, havia uma área permanente nos 3 dias onde uma seleto grupo escolhido antecipadamente pelo Techcrunch estava expondo. Era o "Startup Battlefield". Não estava muito por dentro de como se deu essa seleção, mas eles tinham espaço privilegiado e apresentações para juízes que iriam julgar quem era o melhor até o fim do evento.

Na minha opinião o mais inovador foi o LitMotors, um veiculo de dois pneus equipado com giroscópios e um sistema que, em teoria, impede esse veículo de tombar, mesmo estando em duas rodas e mesmo se um carro bater em sua lateral na rua. Difícil dizer sua viabilidade enquanto negócio, mas seus fundadores parece que vieram do mercado automobilístico, o que me indica alguma credibilidade e conhecimento de causa. E a implementação técnica do protótipo parece já ter sido bem sucedida. Seria um veiculo urbano para curtas distancias que eu consideraria adquirir.

Podemos tentar dividir o que vi em categorias. E se tinha uma que estava excessiva eram as misturas de redes sociais com classificados. Vi mais de um produto de empregos e recomendações. Vi mais de um site de relacionamento (sim, pois é!). Vi mais de um site de e-Learning. Acho que já deu para entender que foi bem repetitivo.

Uma grande categoria eram os clones de produtos que já existiam. Tenho certeza que vi vários que poderiam ser descritos como "dropbox corporativo", Google Docs, e-commerces em geral. Haviam alguns divertidos até, por exemplo, um e-commerce de óculos onde você usa um aplicativo de iPad que mapeia seu rosto num modelo rudimentar 3D para conseguir encaixar modelos virtuais dos óculos à venda. Então você pode girar sua cabeça para ver como os óculos ficam no seu rosto, como num espelho virtual. Mais uma variação de realidade aumentada.

O que mais eu vi foram derivações simples de coisas que já existem. Lembram como falei de amálgamas de redes sociais e classificados? Pois bem, uma das Startups que inclusive ganhou um prêmio no evento foi o Your Mechanic. Imaginem um jeito online de encontrar mecânicos e poder dar notas, além de procurar por reputação ...

Nada contra derivações, muitas são até mesmo úteis e, se você tiver os contatos corretos fundados no mundo real, pode até oferecer uma barreira de entrada para evitar outros clones. Por exemplo, um que parecia simples mas que precisa de um trabalho não tecnológico pesado foi um aplicativo que organiza cupons de desconto no seu smartphone, chamado Gyft. Nada demais do ponto de vista de programação, afinal não há nada de mais em uma mera carteira virtual com cupons digitalizados, que funciona assim como muitas outras que já existem (como o próprio Passbook do iOS 6). O importante aqui não tem a ver com programação, mas com as parcerias com as diversas cadeias varejistas para integrar com os sistemas de cupons. Bem articulado, de fato existe potencial pra conseguir um alto faturamento. Nada de inovador ou disruptivo, mas um modelo de negócio que espertamente uniu pontas de um mercado que já existe.

Mesmo não sendo um evento especificamente de tecnologia, havia algumas Startups focados em tecnologia, mas que tinham pouco destaque pelo público por justamente não ser um evento voltado para programadores ou engenheiros. Um grande amigo meu, Andrew, e seus amigos lançaram uma tecnologia para smartphones e tablets que permite desenvolver aplicativos em HTML 5 e CSS 3 utilizando os aspectos de aceleração por hardware para conseguir renderizar interfaces complexas mais rápidas e fluidas. Ainda quero ver até onde essa técnica pode ser explorada. Coloque o nome famo.us no seu radar.

Também conversei com outra startup chamada FoundationDB que lançou mais um ("yet another ...") banco de dados NoSql cuja proposta era oferecer armazenamento de dados não estruturados, com qualidades de facilidade de replicação, tolerância a falha e, uma das características mais importantes: ser Acid como em bancos de dados relacionais tradicionais. Porém, se não se tornar open source, não apostaria minhas fichas.

Uma startup chamada DaVinci estava oferecendo uma ferramenta para ajudar desenvolvedores a desenvolver aplicativos iPhone de forma mais simples (talvez interessante para aplicativos simples), que não deixam de ser concorrentes a um PhoneGap ou Titanium. Outras como a FatFractal estavam oferecendo Platform as a Service concorrentes com Heroku ou CloudFoundry. Outra chamada BrightContext era um serviço de Websockets as a Service, mais ou menos como meu favorito, Pusher, mas com funcionalidades extras, como pré-processamento de mensagens.

Tecnologias interessantes, mas como disse antes, derivações de produtos que já existem. É fácil distinguir quando se consegue descrever em poucas palavras usando outros já existentes como referência. Por exemplo, "parecido com eHarmony", "Riak com Acid", "Pusher com ETL", "concorrente de PhoneGap", etc.

O terceiro e último dia do evento deu espaço para menos Startups no Alley e com temas voltados a hardware. Vi algumas coisas interessantes, como por exemplo mais uma tentativa de tornar acessível uma impressora 3D (isso é uma tendência que estou curioso para ver para onde vai), um skate motorizado (não diferente de muitas que já existem), uma pistola para conectar iPhone e virar um tipo de paint ball virtual (Zillion virando iPhone), uma câmera polaroid conectada a um iPhone (inútil) e coisas desse tipo. Novamente, divertido de se ver, mas pouca coisa que prática.

Isso resume em poucas palavras os tipos de Startups que vi. Nada muito diferente disso. É uma sensação que de vez em quando me fazia pensar se era eu quem estava sendo muito exigente. Afinal eu sei que não estávamos num evento de "invenções". Alguns poucos tinham modelos de negocio viáveis, embora a maioria me parecesse bem descartável. Vou manter alguns deles em mente e verificar daqui um ou dois anos para ver quais sobreviveram e quais efetivamente conseguiram se tornar negócios de grande sucesso. Se tivesse que apostar, apostaria em menos de 5% do que vi, se muito.

Uma coisa que eu tinha em mente é que aqui do Brasil nós só conhecemos as Startups que já deram certo e por isso estão na mídia. Eu queria ver as Startups que ainda estão começando, que não se provaram e portanto não apareceram o suficiente para chamar nossa atenção. Mas depois do que vi, acredito que não vamos ver a grande maioria deles novamente.

Como se isso não bastasse, a maioria das palestras e painéis que aconteceram o dia todo, nos três dias, no teatro não foram bons. Não posso dizer que todos foram assim, mas a julgar pelo que assisti, não estou errando por muito. E isso foi uma pena, especialmente porque os nomes na programação eram estelares, incluindo personalidades peso-pesados como Reid Hoffman, Marissa Meyer, Bill Campbell, Ben Horowitz, Biz Stone.

Fiquei desanimado logo no inicio, ao assistir o Keynote do Jack Dorsey, um dos fundadores do Twitter e agora no Square. Sua qualidade como empreendedor é comprovada, mas sua palestra foi excessivamente motivacional, coisa que esperaria ver num evento para estudantes, não em algo do calibre de um Disrupt. E para corroborar sobre essa minha primeira má impressão, assistir o painel do Michael Arrington entrevistando Marc Benioff, fundador da super potência que é o SalesForce.com, foi particularmente irritante. Muito assunto supérfluo, como o Marc falando de bungee jump.

Eu não imaginava que seria diferente, mas também assisti a despreparada (embora linda de se ver pessoalmente, claro) Jessica Alba falando da sua Startup The Honest Company que - surpresa - vende produtos para bebês. Toda resposta era altamente genérica, como se ela não tivesse decorado o texto direito. Nem estou tentando dizer que ela não trabalha de fato nesse negocio, apenas que suas respostas dão mais sustentação à hipótese de que não, e de que é apenas uma celebridade associada a uma marca para alavancar as vendas, por exemplo. Brian Lee, pelo menos, cobria com respostas melhores toda vez.

De longe, a única coisa que conseguiu uma reação impressionada minha foi o painel do Michael Arrington entrevistando Marc Zuckerberg. Foi o painel que mais lotou, e quando o Arrington jogou como primeira pergunta um soco de direita do tipo "o que acha da desvalorização das ações do Facebook" ficou claro que esse painel seria diferente. E quando Mark respondeu tranqüilamente, sem gaguejar, com confiança, ficou mais claro ainda para mim o pensamento "as ações vão subir agora". Não digo que o conteúdo em si foi algo impressionante, mas sim a forma como o Mark foi consistente, decisivo e assetivo nas suas respostas. E como imaginávamos, poucos minutos depois da entrevista ouvíamos as notícias de que de fato as ações do Facebook cresceram quase 9%. Foi o ponto alto de todo o evento.

E para mim pessoalmente, o ponto baixo foi ver uma Startup como Your Mechanicganhar como melhor Startup do show e a LitMotors ficar como runner up. Mas também, "what the hell do I know?"

Continuando sobre minha viagem, vamos falar um pouco das empresas que visitei. Meu estilo de viajar não é do tipo que faz planos minuciosos. Na realidade, só quando cheguei lá comecei a pensar no que fazer. Parte fundamental foi ter acesso à internet e começar a cutucar as pessoas no Facebook e Twitter :-)

Um dos primeiros a responder foi Alex MacCaw. Já conversamos algumas vezes pela internet no passado e o curioso para mim, na época, foi que em 2007 eu ainda era um programador Ruby pouco experiente, trabalhando num pequeno projeto open source. Por coincidência Alex estava fazendo algo similar e por isso começamos a falar. Hoje em dia ele ainda tem seus 21 anos ou perto disso, imaginem em 2007! Ele é muito bom e agora se mudou da Inglaterra para os Estados Unidos para trabalhar na startup Stripe. Imagine o que seria um "Paypal feito direito", utilizando uma infra-estrutura toda com Ruby para transações financeiras.

Minha intenção era ficar em São Francisco as primeiras duas semanas e depois mudar para mais baixo no Vale do Silício, provavelmente em Palo Alto. Porém tive uma situação familiar que exigiu meu retorno antecipado.

Isso significava que eu precisava otimizar ao máximo os meus dias. Eu estava muito interessado em conhecer mais dos negócios, as pessoas, os locais de trabalhos e comportamentos dos São Franciscanos, talvez aprender algumas perspectivas diferentes ou desmistificar o que apenas ouvimos dos outros e assumimos como verdades. Lembra do que sempre falamos sobre o "jardim do vizinho sempre parecer mais verde?"

Meu primeiro compromisso na quinta, dia 13 de setembro, foi um almoço nos escritórios do Twitter, com o Martin Aumont e o grande Fábio Kung - que hoje trabalha no Heroku. Os escritórios do Twitter ficam num predio de estilo mais tradicional na Market St. aproximadamente na altura da 11th St. Uma boa caminhada para quem estava na 5th mas novamente nada muito longe que não dava para ir andando mesmo.

Diferente do que alguns podem imaginar, o Twitter não é mais uma "Startup". Pode até ser considerado no sentido de modelo de negócio que ainda precisa se provar em termos de monetização melhor ou coisa assim. Mas para todos os efeitos ela já é uma grande corporação. Com cerca de mil funcionários, uma empresa desse tamanho sempre converge para um modelo tradicional, hierárquico e departamental onde a maioria não se conhece mais.

O refeitório é muito bom, espaçoso para conseguir atender tantos funcionários, muitas opções de pratos para todos os gostos, e como fica na cobertura tem uma excelente vista da cidade. O ambiente de trabalho em si é bonito e organizado mas com uma cara mais corporativa, mantendo um certo silêncio. Existem áreas de jogos e café que são bem equipados ainda, mas no geral não há como confundir que estamos numa empresa "normal", que precisa manter uma infra-estrutura hoje bem complexa pra atender seus milhões de usuários e suas demandas. Para ter uma idéia do que quero dizer, procurei por alguma parede que tivesse um logotipo grande do pássaro símbolo do Twitter para poder usar de pano de fundo numa foto, mas não encontrei nenhuma. Na pratica, muitos dos lideres e veteranos originais já saíram. Os que ainda estão, possivelmente estão esperando dar o prazo necessário para exercer suas stock options e depois sair, talvez para montar novas Startups. E o ciclo continua, cada vez mais rápido.

Aproveitando que o Kung nos acompanhou nessa visita ao Twitter, resolvi acompanhá-lo para visitar o Heroku que não ficava muito longe dali, descendo até outra paralela à Market St., se não me engano, entre a Howard e Harrisson. Diferente do Twitter, o Heroku ainda mantém seu perfil mais do que consideramos como "Startup", com menos pessoas, cerca de 100 ou 150 (se aproximando do famigerado número de Dunbar). O ambiente é menor, decorado de uma forma mais convidativa do que um escritório corporativo. O lugar não é apertado, mas você sente algo mais acolhedor. Não concluí se é a decoração, a disposição dos ambientes, mas me senti muito confortável.

Não há nada de extravagante, diria que é um ambiente muito funcional, num pequeno prédio de 2 andares onde as pessoas trabalham, 1 subsolo onde fica o estacionamento de bicicletas e a mesa de Ping Pong, e uma cobertura aberta onde dá até pra fazer um pequeno churrasco.

Uma característica dos prédios na região abaixo da Market St (literalmente conhecido como "SoMa" ou "South of Market"). é que são todos industriais. Pelo que ouvi dizer, a região era industrializada mas não sei por qual razão muitas dessas empresas deixaram de existir. Agora muitas Startups começaram a povoar o local e usar prédios industriais. Por isso existe um ar meio "industrial" na decoração de toda Startup dessa região. Olhe para o teto e vai sempre ver emaranhados de canos passando sobre suas cabeças.

Conheci um dos fundadores do Heroku, James Lindenbaum, quando ele ainda não era tão conhecido em 2008. 4 anos depois hoje ele faz parte do conglomerado que é a SalesForce.com de Marc Benioff que, como contei em primeira mão durante minha viagem ao Japão, contratou o criador do Ruby, Yukihiro Matsumoto e outros rubistas japoneses para trabalhar sob seus cuidados.

Mesmo fazendo parte desse conglomerado, pelo menos até agora parece que o Heroku teve a oportunidade de trabalhar de maneira quase independente do resto da SalesForce.com que, por sua vez, emprestou seus músculos. Não sei com certeza, mas imagino que a influencia do Benioff foi importante quando o Facebook passou a recomendar o Heroku toda vez que você cria uma nova aplicação. Somente algumas áreas administrativas passaram a responder à nave mãe, mas a cultura de engenharia ainda deve continuar por mais algum tempo.

Não querendo perder tempo, depois dessa visita encontrei o Alex online novamente e perguntei se poderia conhecer a Startup onde ele trabalha, o Stripe. Agora a caminhada foi da altura da 11th até a 2nd St. A Stripe é um pequeno andar de um prédio nessa rua, minúsculo se comparado ao Twitter ou Heroku. Mesmo assim estamos falando em algo em torno de 300m2. Novamente, bem decorado, nada extravagante, alguns sofás, uma cozinha onde eles podem fazer as refeições juntos (já que são poucos funcionários, talvez na faixa de 30).

Não cheguei a conhecer os fundadores mas parece que eles já tinham sucessos anteriores e não entraram por acidente no negócio de meios de pagamento. O Stripe ainda nem de longe administra um volume de transações tão alto como um Paypal. Porém o tamanho do Paypal tem criado problemas para ele mesmo. E sua resposta tem sido uma série de políticas e regras que estão desagradando muita gente e os levando a procurar alternativas mais flexíveis, como a Stripe. Além disso, também diferente do Paypal, ele oferece painéis de controle mais usáveis e APIs mais bem feitas e limpas para desenvolvedores. Alguns dias depois que os visitei, eles abriram no Canadá. Espero que não demorem a considerar o Brasil como opção.

Aproveitando, o Alex me colocou em contato com outro amigo dele da região, Harry Shoff, que é Engenheiro de Design no AirBnb, e foi assim que já consegui a primeira visita do dia seguinte.

Retornei à região onde estava no começo da semana, próximo ao The Concourse, Zynga, Adobe, que é a região conhecida como Potrero. Soube que é onde será a nova sede do Heroku. Eles devem se mudar nos próximos meses para comportar seu crescimento.

Algumas ruas mais abaixo encontrei um grande prédio de fachada negra onde compartilham espaço a Jawbone (famosa por fones com cancelamento de ruído e caixas de som portáteis) e a agora famosa AirBnb.

Não me parece que o nome é muito conhecido no Brasil mas eles já estão em dezenas de países do mundo. Eles facilitam encontrar casas no mundo que você possa alugar pra passar alguns dias, em vez de ficar num hotel. E se você é proprietário de casas ou apartamentos para alugar por curtos períodos, pode listar nesse site.

Assim como o Heroku eles estão planejando se mudar desse prédio por causa do crescimento. Mesmo assim estamos falando de um espaço grande, onde trabalham cerca de 200 pessoas. Ainda existe um ar de "Startup", mas que demonstra uma transição pelo crescimento. Esta é uma empresa que também está passando da fase Startup e se estruturando para se tornar uma corporação.

Em termos de decoração o que mais chama a atenção é que eles tem muitos aquários no meio do espaço aberto que são salas cê reunião. O diferente é que cada sala de reunião é decorado de forma completamente diferente umas das outras.

Como o negócio do AirBnb é facilitar encontrar os lugares diferentes e até exóticos, de tempos em tempos eles escolhem alguns dos mais famosos, enviando uma equipe para fotografar e detalhar um cômodo desse local. Então eles replicam esse cômodo numa sala de reunião, fazendo uma cópia o mais fiel possível, comprando os mesmos moveis, até contratando pintores locais para replicar os quadros.

O lugar leva decoração tão a sério que até os banheiros tem estilo. O banheiro masculino do segundo andar é escuro, parece um banheiro de balada, e tem uma cabeça e veado na parede.

O item mais interessante para mim, que não conhecia a história do AirBnb - AirBed & Breakfast, foram as caixas de cereal em exposição, réplicas grandes das originais que tinham cereais de verdade, com as caricaturas do McCain e do Obama nas eleições de 2008. Diz a lenda que os fundadores acabaram ficando sem dinheiro antes de conseguir terminar o AirBnb. Uma solução que encontraram foi vender cereais, reempacotacos em caixas dos candidatos, como edições especiais. E acabou dando certo, eles conseguiram acumular USD 20 mil, que foi o suficiente para terminar o produto. E o resto é história.

Depois disso, aproveitei que estava próximo do Heroku e passei o resto da tarde por lá já que tinha algumas ligações pra fazer. Uma coisa legal das empresas dessa região é ter essa noção de não se incomodar um estranho pelo escritório de vez em quando, a maioria é bem receptiva a conhecidos.

Na segunda-feira iniciei o dia bem cedo para dar tempo de tomar café da manha na Pivotal Labs, não muito longe do meu hotel na Harrisson perto da 3rd St. Curioso que ela é vizinha a uma faculdade e ambos os prédios tem o mesmo número, por isso alguém pode acabar errando a entrada como eu.

O escritório da Pivotal é um grande andar que deve ter perto dos seus 400 ou 500m2, suficiente para cerca de 200 pessoas. Novamente, não estamos falando de uma Startup, apesar da decoração ainda ter alguns elementos mais informais. Não se enganem, a Pivotal é uma empresa consolidada de 15 anos de idade. E diferente de todas as outras que visitei, não é uma empresa de um único produto e sim de serviços, uma consultoria.

Além desse escritório em São Francisco ela tem outras pelo pais, totalizando um efetivo de pelo menos 400 funcionários. De curiosidade, um antigo CTO que saiu da Pivotal, Ian McFarland, foi ser CTO de outra consultoria, a New Garage em Tóquio, no Japão.

Ela é famosa por implementar Agile de uma maneira mais rígida do que a maioria das empresas ágeis atua. Não é exagero dizer que o café da manhã serve de incentivo para que as pessoas cheguem no horário. Pude participar como ouvinte da reunião matinal das 9h (em ponto) com todos no escritório. E às 9:05h cada equipe estava fazendo seu equivalente a Daily Scrum matinal.

Logo a seguir fui visitar a Engine Yard. Em 2010 tive a oportunidade de conhecer o antigo escritório que ficava mais pra baixo na região da 4th St, na época em que o Ezra, Yehuda, Carl, estavam todos lá. Sendo sincero, devo dizer que de todos os escritórios que visitei foi o que menos gostei, principalmente porque as pessoas que eram a alma de desenvolvimento não estavam mais lá como o próprio Ezra, a equipe JRuby, a equipe Rubinius, Charles, Evan, Yehuda, Carl.

O espaço em si não é pequeno, é um andar de um prédio, o mesmo onde fica a revista Wired, por coincidência. Mesmo assim deve ser no máximo o dobro do espaço de uma Stripe. Não sei se foi coincidência do dia que fui, mas o escritório me pareceu bem vazio, e além de tudo a decoração deixou na minha memória um cenário "cinza". E ao que parece nesse mesmo dia foi oficializada a saída do antigo CTO, Tom Mornini. A visita valeu mais para eu poder sair, tomar um café e bater papo com o bom e velho Dr. Nic.

Novamente coincidência, Hiro Asari, ex-Engine Yard e agora na Redhat, na equipe do OpenShift tinha chego na cidade e fomos almoçar juntos. Aproveitei para almoçarmos juntos e conheci um amigo dele que trabalha numa pequena consultoria de Rails que foi a criadora do RefineryCMS. Conhecem esse CMS? Recomendo dar uma olhada se ainda não viram.

Minha próxima parada seria no Github, não muito longe, então o Hiro me acompanhou nessa. Essa visita marquei com a Kami Lott, que é meio o papel conhecido como "Team Vibe", um papel que vi em outros lugares como no Heroku, uma pessoa ou uma equipe responsável por cuidar para que o escritório sempre esteja equipado, que todos sempre tenham tudo que necessitam, que organizam as festas e tem a missão de tentar sempre manter a moral de todos elevada.

O primeiro fato curioso foi que quando eu e o Hiro chegamos, tocamos a campainha não apareceu ninguém, o lugar estava deserto. Esperamos um pouco e nada, então decidimos esperar no Starbucks atravessando a rua. Depois de algum tempo, vemos um grupo entrando no prédio ao mesmo tempo. Boa parte da equipe fica remota, em outras cidades, mas quem vai no escritório ainda mantém um bom relacionamento.

O escritório em si, novamente num prédio industrial, um grande espaço que deve ter seus 500m2 e hoje deve ter mais de 100 pessoas no total (no máximo tinha uns 30 ou 40 no dia que fui visitar). Infelizmente nesse dia não encontrei nenhum dos fundadores, nem o Chris, ou PJ, ou Tom estavam por lá, então a Kami é quem se encarrega de fazer um tour pelo escritório.

O espaço é informal mas ao mesmo tempo organizado, com apetrechos de decoração como as diversas pinturas de Octocats, console de suporte estilo espacial. Eles tem até uma área de merchandizing com um estoque grande de camisetas, adesivos, canecas e outros brindes que eles enviam pra quem compra.

Saindo do Github segui mais ao sul de Mission Bay para pegar o Caltrain, o trem intermunicipal que você pode usar para cruzar todas as cidades que compõe o Vale do Silício. Entrei em contato com o Martin Englund que convidei para a Rubyconf Brasil 2012 para falar de seu trabalho no projeto CloudFoundry.

Se você não conhece o CloudFoundry, imagine se fosse possível ter todas as tecnologias do Heroku em open source para que você pudesse ser capaz de criar sua própria infraestrutura de platform as a service. Esse projeto foi iniciado por figuras importantes como o Ezra, que foi co-fundador da Engine Yard e encontrou na VMware um lugar para executar o que ele não havia conseguido na empresa que ajudou a funda.

Agora coloque em perspectiva. Até agora estávamos falando de startups ou pequenas empresas ainda em crescimento em Mission Bay, San Francisco. A VMwareé uma empresa consolidada mais tradicional do Vale do Silício que, como tal, fica mais ou sul, em Palo Alto. E estamos falando de outra escala de corporação, com mais de 10 mil funcionários. Seu complexo de prédios é grande.

O Martin foi um excelente guia, me mostrou os escritórios, contou um pouco do projeto e posso dizer que fiquei bem impressionado. Lembram como falei que o Heroku inteiro tem pouco mais de 100 pessoas? Dentro as 10 mil da VMWare, o projeto CloudFoundry sozinho tem aproximadamente 100 pessoas.

As empresas de Palo Alto parece que tem esse mesmo estilo mais "austero", mais "tradicional". Os departamentos são bem organizados, a infraestrutura é sólida, e todos os engenheiros ocupam os famosos "cubículos". Não se enganem, estamos falando de um ambiente muito confortável, eu diria que o ideal para quem quer ser realmente produtivo.

Não é difícil ficar mal acostumado num campus desse tamanho, com tudo que ela oferece. Restaurantes, ginásio de esportes, áreas de lazer com chafariz e praça ao ar livre. O estilo das empresas de Palo Alto sempre tem um certo estilo da universidade de Stanford, e não por acaso.

Existe uma simbiose entre Stanford e Palo Alto. Exemplo disso é o professor Jim Clark, lendário fundador da Silicon Graphics e da Netscape. Parece que não é incomum professores serem Angels de startups que seus alunos iniciam. Basta lembrar onde foi que o Google começou. Outra coisa que não me informei direito é que parece que Stanford é dona de uma parte das terras de Palo Alto e ela não vende para ninguém, então as grandes empresas da região "alugam" de Stanford. O futuro da universidade é intimamente ligada ao sucesso das empresas de tecnologia da região. Uma simbiose muito benéfica para ambos os lados.

Outra peculiaridade é que diferente de São Francisco onde dá para ir a qualquer lugar a pé ou de bicicleta, é praticamente impossível simplesmente caminhar em Palo Alto. Tudo é muito longe, e algumas ruas sequer tem calçadas. Felizmente o Martin foi muito gentil de me dar um tour pela cidade e depois de passear pela VMWare ele me levou ao campus do Google, do Facebook e da Oracle. Infelizmente eu tinha somente poucas horas disponíveis então só fizemos uma passagem muito rápida por cada lugar.

Vizinha à VMWare, literalmente atravessando a rua está a famosa Xerox Parc, berço de inovações como a interface gráfica e o mouse.

O Google é gigantesco, uma verdadeira cidade, com ruas, quarteirões, todo mundo transitando de bicicleta entre os diversos prédios. Dizem que ela foi construída inspirada no estilo do campus da universidade de Stanford. E tem suas diversas excentricidades como um carro-biciclera para cinco pessoas fazerem uma rápida reunião olhando umas para as outras ao mesmo tempo que pedalam entre prédios. Ou algo mais simples como as bicletas coloridas com as cores do Google, ou o esqueleto em tamanho natural do Tiranossauro Rex decorando um dos jardins.

Quando fomos ao Facebook já estava de noite e não deu para ver muita coisa. Chegando próximo à região encontramos de cara uma placa com a famosa mão de "Like", porém não tem muito mais do que isso do lado de fora do prédio principal. Ele é bem menor que o Google, claro, e tem uma cara bem mais séria do lado de fora. Sequer encontrei um logotipo visível. Pelo que o Martin me contou aquele era o antigo prédio da Sun Microsystems antes de ser dissolvida pela Oracle.

E falando em Oracle, também passamos próximo ao seu complexo. Ele é grande em outra proporção, vertical. São diversos prédios organizados como um condomínio com um enormel lago cercando sua parte frontal antes do estacionamento. Diferente da gradiosidade do Google que expressa uma universidade, tudo na Oracle expressa o auge de uma corporação muito séria. Sinceramente não me vejo trabalhando por ali me sentindo confortável.

Assim terminei minha rápida excursão por Palo Alto e cidades próximas, graças ao Martin.

No dia seguinte, de volta a São Francisco, entrei em contato com Xavier Shay, que muitos devem se lembrar como o criador do mini-blog Enki. Por acaso cruzei com ele no ano passado, no metrô de Tokio, depois da RubyKaigi. Ele é australiano e recentemente se mudou para São Francisco para trabalhar na Square de Jack Dorsey, minha próxima visita.

Esta foi a única startup que não tirei fotos. O motivo é que eles são extremamente cuidadosos com visitantes. Foi a única empresa que visitei até hoje onde tive que assinar um Non-disclosure Agreement (NDA) logo na recepção. Além disso ninguém é permitido dentro do escritório sem estar acompanhado por um responsável. O Xavier me mostrou o lugar. Novamente, é uma "startup" que está na transição de se tornar uma corporação. O ambiente é como os outros, estilo aberto, sem muitas salas fechadas além das de reunião e algumas áreas onde eu explicitamente fui proibido de chegar perto. Nesse dia, para terem uma idéia, a Square tinha acabado de ser avaliada em USD 3.25 Bilhões.

Depois dessa visita, meu próximo destino foi o Yammer. Na festa do Gogaruco patrocinada pelo Yammer conheci rapidamente a programadora e palestrante Heather Rivers. Então trocamos tweets e marquei de visita-los. Eles ficam num prédio bem longe mais ao Sul de Mission Bay, no mesmo lugar onde ficam outros nomes conhecidos como Techcrunch, OpenDNS. O Yammer, para quem não conhece, pode ser descrita como uma rede social corporativa. Eu mesmo nunca sei mas parece que uma parte importante é o chat corporativo já que mencionaram sobre o Chatter da SalesForce ser um concorrente.

Quando cheguei por acaso a Heather não pôde me receber - bugs urgentes em produção. O chefe dela, um dos fundadores e mais um pessoal me recebeu lá muito bem, tomamos um whisky e eles me contaram um pouco da história e dia a dia deles. O Yammer hoje é uma aplicação Rails monolítica que cresceu demais, inclusive acho que foi esse o tema da palestra no Gogaruco. Agora está em processo de modularização. Mas eles estão indo bem, já que a empresa foi vendida a USD 1.2 bilhão para a Microsoft.

Repetindo - vocês já devem imaginar - prédio estilo industrial, paredes de tijolos, canos no teto e tudo mais. Outra Startup que se tornou uma empresa estabelecida, agora em processo de corporativização. Neste exato momento eles passaram do ponto de quantidade de pessoas que cabem no mesmo lugar. Estão para se mudar mas está bem apertado trabalhar todos no mesmo espaço. Foi interessante ver isso, foi o que me deu o insight sobre a dinâmica do crescimento de uma Startup, quando ela é pequena e ágil, depois o sucesso e crescimento (para alguns poucos, claro!) até se tornar uma empresa estabelecida que deixa de ser uma Startup, como uma Yahoo!, Google ou Facebook, se tornando grandes corporações estruturadas da maneira clássica, com departamentos, burocracia e tudo mais. É o preço inevitável dos poucos que atingem esse grau de sucesso.

Finalmente, minha ultima parada seria na Get Satisfaction. Graças ao mexicano Francisco Viramontes que me fez o convite de visita via Facebook. Pude conhecer outro tipo diferente de negócio. Diferente das outras Startups ela fica numa vizinhança um pouco mais distante na região de Mission District, na Bryant St., mais ao sul ainda de SoMa.

E como disse antes, essa semana a SalesForce.com estava realizando sua conferencia Dreamforce no Moscone Center. Como a Get Satisfaction faz parte do ecossistema de parceiros praticamente todos do escritório estavam no evento. Ela já não é uma empresa tão nova, tendo sido fundada em 2007 para criar comunidades onlines entre empresas e seus consumidores.

Mesmo assim eu pude conhecer o escritório e trocar algumas palavras com algumas pessoas. Impressionante como uma inocente cerveja no fim de expediente pode ser educativo, pois tive a oportunidade de ouvir algumas das histórias de bastidores das startups de São Francisco.

E esta foi a última empresa que tive a oportunidade de visitar em São Francisco. Infelizmente devido à minha estadia ter sido encurtada não pude visitar todas as empresas que queria nem reencontrar todas as pessoas que eu esperava, mas acho que foi bastante produtivo.

Uma coisa importante para os leitores, especialmente os que ainda vêem o mundo das startups com um certo entusiasmo irreal. Entendam: a maioria (se não todas) as que eu visitei acima são empresas sólidas, onde os fundadores todos já tinham excelentes conexões com toda a rede de investidores, são articulados na mídia, tem reputação entre o mercado. Além disso, a maioria das startups que inicia com potencial sempre é um excelente lugar para se trabalhar. Porém o objetivo de uma startup é fazer sucesso e crescer. O crescimento rápido nem sempre é o que todos gostariam pois o ambiente muda rápido, a cultura da empresa também muda. Mas isso é inevitável, o oposto disso é a empresa fechar. Muitos vêem apenas um desses "instantes", quando tudo parece bonito e perfeito. Esquecem como era o antes e como é o depois. Tudo muda, nada é do jeito que se quer para sempre. E para quem não gosta de mudanças a resposta é simples: a fila está andando.

Como disse no artigo anterior, participar do Techcrunch Disrupt nunca foi a intenção original. Um dos objetivos era ter uma visão melhor do tal boom de startups em São Francisco.

Foi minha segunda vez na Califórnia, a primeira foi em 2010, onde confesso que aproveitei muito pouco. Desta vez fui determinado a explorar o máximo que fosse possível apesar do curto espaço de tempo. E mesmo pensando dessa forma, por causa da correria, terminei por embarcar com absolutamente nenhum planejamento ou agenda com compromissos.

A primeira coisa a dar errado foi viajar exatamente num grande feriado brasileiro, 7 de setembro. O segundo erro, foi não ter escolhido uma escala diferente de Miami (dica: Dallas/Fort Worth ou Houston são sempre opções superiores). O resultado foram quase 3 horas esperando na fila da imigração, o que me fez perder a escala e me deixou preso quase o sábado inteiro no aeroporto.

Terminada a longa espera, finalmente cheguei no final da noite. Uma outra dica para quem não sabe é que do aeroporto você pode pegar o Bart - Bay Area Rapid Transit, um dos sistemas de trem, que te levam diretamente ao centro da cidade.

Não sou um especialista da divisão geopolítica da região, mas pra mim a referência sempre foi a Market St. Você encontrará paralelas a ela como Mission St. para baixo, e perpendiculares a ela onde a ruas são numeradas e ordenadas, como 5th St. Muitas das estações seguem abaixo da Market St. Quanto mais puder ficar próximo à região da Union Square, melhor, na minha opinião.

Em termos de "bairros" ou regiões principais que eu imaginava, temos ao norte da Market St. as regiões de Civic Center, Tenderloin, Downtown, Chinatown. Ao sul da Market fica Castro District, Mission Dolores, Mission District, South of Market (SoMa), Financial District, Mission Bay. Não tive tempo de visitar as áreas de Castro, Mission Dolores e Financial. A Market St divide esses bairros de leste a oeste e esse trecho é curta o suficiente para poder andar inteira a pé. Para ter uma idéia, fiz 26 checkins no Foursquare em SoMa, 10 em Mission Bay, 10 em Downtown, 6 em Mission District, 5 no Civic Center, 3 em Tenderloin e mais alguns avulsos espalhados pela cidade.

Mas como disse, quase não planejei minha viagem então meu agente de viagem escolheu um hotel chamado Embassy que fica próximo à Polk St. com Turk St. Não é exatamente um local ruim, mas como seguro morreu de velho, não recomendo andar sozinho à noite pela Turk. Na prática acredito que não existe muita coisa para temer mas você encontra uns tipos estranhos por lá. Aliás, uma coisa que eu não esperava era encontrar tantos mendigos pelas ruas. Na maior parte são bem inofensivos, mas você esbarra com um a cada metro que anda pelo centro. Dizem que a cidade tem muitos abrigos e cuidados por isso eles estão por lá.

Falando em estranho, o hotel em si não é ruim. Ele é um pouco antigo, mas bem cuidado, um pouco apertado mas com quartos razoáveis e limpos. Porém o hotel é vizinho e acima de um bar-baladinha chamada Noble. Quem tem problemas de sono leve ou insônia provavelmente não iria gostar. No meu caso, capotei sem problemas. E a curiosidade foi que de manhã cedo, do lobby do hotel abre uma porta, fechada durante a noite, que conecta à tal balada, que já está limpa e servindo o café da manhã. Um ambiente inesperado pra um café, pena que não tive tempo de ir nessa balada.

Nesse domingo, segui com minha primeira missão: conseguir conexão para voltar a ficar online. A internet dos hotéis são sempre ruins. A vantagem de São Francisco nessa região é que tudo fica próximo, e andar 2 ou 3km não é nenhum desafio já que boa parte da cidade é plana. Então fui até um lugar que já conhecia: Westfield, perto da 5th St. com a Market St., um Shopping Center onde eu sabia que encontraria um quiosque da T-Mobile.

Dica: meu iPhone antigo não era desbloqueado por isso um SIM card pré pago não seria bom pra mim. Então comprei um Hotspot WiFi 4G, que se conecta via celular mas cria uma rede WiFi móvel que meu iPhone e qualquer outro dispositivo pode se conectar, e assim meu iPhone passou a funcionar em qualquer lugar. Outra opção seria um Android baratinho para fazer tethering.

E com a conexão de volta, finalmente, consegui encontrar meus amigos Santiago Pastorino, José e Sebastián da WyeWorks, tomando café num Starbucks próximo. Depois disso fui almoçar e continuei procurando amigos via Twitter, Facebook, foi quando encontrei o Alex MacCaw como mencionei no artigo anterior.

Ao mesmo tempo que encontrei o Alex também consegui me conectar com o brasileiro Vinicius Baggio que muitos dos leitores aqui já devem conhecer, atualmente trabalhando na Pivotal Labs. Acabei conhecendo também outra figura interessante: Martin Aumont, programador no Twitter. Um canadense - se entendi bem - que fala português perfeitamente inclusive com a malandragem brasileira. Foi uma excelente companhia nos próximos dias também, que gostei muito de ter conhecido. Ele fala português melhor do que eu falo inglês, e fica um puxão de orelha para quem ainda tem preguiça de aprender outras línguas.

Já havíamos nos encontrado novamente com os amigos uruguaios e outras pessoas, então o Domingo que iniciou comigo sozinho terminou em jantar num excelente restaurante tailandês Lers Ros Thai. Foi meu primeiro tailandês e recomendo para qualquer um que goste de comida asiática.

Da segunda-feira até quarta-feira foi o Techcrunch Disrupt, como já reportei no primeiro artigo desta série.

Em todos os dias, no começo da noite, algum patrocinador do evento estava organizando alguma festa. Festas informais costumam ser bons locais para conhecer mais pessoas. E normalmente havia mais de uma festa acontecendo na cidade ao mesmo tempo. No primeiro dia, porém, tive a chance de visitar o Transamerica Pyramid onde a Red Point e a e.Ventures estavam celebrando sua parceria para iniciar negócios no Brasil.

Já do lado Disrupt, depois do coquetel no Pyramid, fomos à balada Mighty patrocinada pela New Relic. A festa em si não estava ruim, mas para meus objetivos não me pareceu muito promissor, muito escuro, muito apertado, muito barulhento, por isso decidi sair cedo. Na verdade esse padrão se repetiu nos dias seguintes, não aproveitei muito nenhuma festa.

No Disrupt me encontrei com diversos brasileiros que estavam lá para expor suas Startups. Alexandre Gomes e sua trupe invadiram a cidade em peso. Literalmente, pelo que entendi eles vieram num grupo de pelo menos 20 pessoas, que inclusive alugaram 2 vans para conseguirem se locomover desde Redwood City, perto do meio do antigo Vale do Silício, até São Francisco - ótima idéia para grandes grupos. Mas também por isso, depois do Disrupt tivemos poucas chances de nos ver de novo. Mas foram excelentes companhias nessas festas, como na que foi no prédio da Zynga, que é vizinha do The Concourse.

E depois do Zynga, festa na Adobe, alguns quarteirões de distância.

No fim dessa semana, as últimas festas que pude participar felizmente tinham mais rostos conhecidos da comunidade Ruby, como a inauguração do escritório do Living Social onde pude reencontrar velhos conhecidos como Chad Fowler e Josh Susser.

Ou também a festa depois do evento Gogaruco (Golden Gate Ruby Conference), patrocinado pela Yammer, onde reencontrei mais velhos conhecidos como Glenn Vanderburg, Charles Nutter, e ainda pude conhecer pessoalmente alguns rubistas que só conhecia via Twitter, como Avid Grimm, que estava tentando incentivar todo mundo a dançar mas acabou quase sozinho na pista de dança. (#geeks, como ele diria).

E para quem estava na festa, fizemos uma rápida dança do chapéu com várias personalidades:

Nós latinos, estávamos invadindo as festas em massa. Galera do Uruguai (WyeWorks) e Argentina (Eventioz):

Eu não fui com a intenção de participar do Gogaruco, que aconteceu na mesma semana, sexta e sábado, portanto só participei rapidamente das festas no fim de quinta e sexta.

Tecnicamente eu tinha hotel reservado somente até o dia 12, quarta feira que seria o ultimo dia do Disrupt, depois eu deveria encontrar outro lugar, era parte da estratégia. De fato a região do Embassy não era o lugar ideal para se estar. Então encontrei outro razoável, na 5th St. com Mission St. chamado The Pickwick.

Além de ser melhor que o Embassy ele estava a um quarteirão da Market St. que é onde você quer ficar. O plano original era para eu ficar até a semana seguinte e depois mudasse novamente de hotel, possivelmente indo para outra cidade como Palo Alto, para conhecer mais do Vale do Silício. Infelizmente tive um problema familiar que me fez adiantar a volta do dia 24 para o dia 17. Por isso ainda não tive a chance de conhecer Palo Alto como gostaria, vai ficar para uma próxima jornada.

Depois de mudar para o The Pickwick, não lembrava que nesse mesmo dia haveria o tão esperado anúncio do novo iPhone 5 e, por coincidência, o local do evento seria o Yerba Buena, vizinho do Metreon e do complexo do Moscone Center. Então antes de ir para o último dia do Disrupt resolvi passear em frente ao Yerba. Como esperado, o local estava decorado para o evento da Apple com um grupo de pessoas do lado de fora acompanhando uma equipe acho que da NBC transmitindo ao vivo todas as novidades que eram anunciadas do lado de dentro. Obviamente eu não tinha como assistir do lado de dentro, mas foi divertido acompanhar um pouco do lado de fora.

No dia seguinte ao fim do Disrupt, quinta feira, resolvi fazer outra pesquisa. Queria conhecer opções de moradia para períodos mais longos, e esbarrei nos tais "Vantaggios" - dica do Vinicius Baggio, que quando se mudou ficou um tempo num desses. São como os nossos "flats", até mais para repúblicas. Se um dia você quiser passar um período mais longo, como um mês ou mais, um hotel não é uma escolha acessível, pois pagar USD 1 mil por semana é caro. Mas um Vantaggio pode ficar na faixa dos USD 1,5 mil pelo mês inteiro. Não são bonitos como um hotel, tem cara de albergue, mas são limpos o suficiente, e ainda oferecem serviços como limpeza uma vez por semana, alguns quartos com banheiro próprio, e áreas comuns como cozinha e até sala de internet.

Fui visitar um numa área até que boa, duas ruas acima da Market St., em Downtown, a poucos minutos a pé da Union Square, do metro e do Bart, ou seja, fácil de se locomover para qualquer lugar. Porém a recepção que tive não foi das melhores. O atendente que encontrei, vamos chamá-lo de José para facilitar, começou já meio que me dando uma bronca por aparecer sem ter marcado por telefone antes. Eu expliquei que não tinha problema e que podia voltar outra hora se fosse o caso, mas ele mandou esperar e ficou resmungando ...

Eu disse que queria informações e ele começou perguntando se eu era brasileiro. Então começou o muro das lamentações de como ele recebe muitos brasileiros, como eles reclamam muito, arrumam confusão e toda essa ladainha. Eu pacientemente escutei, engatei na conversa até que ele finalmente pareceu que foi com minha cara e ficou mais simpático. Até me mostrou alguns quartos e outras áreas comuns. Parece que existem outros Vantaggios em São Francisco muitos do mesmo dono. Uma vantagem é que se um dia ligar para reservar e não tiver espaço, ele consegue checar disponibilidade entre os outros da rede.

Outro detalhe importante é que se precisar, o ideal é reservar períodos longos (mais de um mês) com pelo menos três meses de antecedência. Se ligar somente um mês antes pode não ter vaga. Imagino que ele quis ser preciosista ou tentou vender seu peixe por mais do que vale. Mas certamente existem épocas do ano que lotam mais, já que ele disse que tem muitas agências de viagem que mandam estudantes, por exemplo - os tipos que ele parece desgostar bastante.

Por tudo que vi, no final das contas um Vantaggio parece uma boa opção para quem quer ficar um mês ou mais na cidade e pode planejar com bastante antecedência. Fica a dica.

Depois disso finalmente pude passar a fazer as visitas às empresas.

Sábado foi meu dia de compras. Eu prefiro ser prático, por isso minha recomendação, novamente, é a região da Union Square. Nesse dia estava tendo uma festa cultural então o lugar estava movimentado.

São Francisco não é um lugar que tem shoppings centers como São Paulo, eles tem muitas lojas de rua, mas diferente do que estamos acostumados não são lojas pequenas. O Empório Armani, por exemplo, usa o prédio de um antigo banco, com arquitetura que lembra um palácio romano. Algumas das grandes são a Macy's que não deixa de ser um Shopping Center. Tem a H&M, Gap e muitas outras. Essa região é um prato cheio para quem gosta de compras.

Domingo foi um dia diferente. Como disse antes, não é difícil ir a pé para qualquer lugar. A cidade é muito pequena com meros 600km2 (onde 400km2 é só água) e pouco mais de 800 mil habitantes. São Paulo tem 1.500km2 e mais de 11 milhões de habitantes. Dar a volta pelo perímetro inteiro da cidade não é algo inimaginável.

Você pode fazer tudo por perto e só de vez em quando pegar um carro. Mesmo assim tem o metrô, o Bart, ônibus em alguns lugares e o antigo bonde para quem quer turismo até as regiões com mais altos e baixos, característicos dessa cidade nos filmes, mais pra norte na região de Pacific Heights.

Outra alternativa eficiente é uma boa bicicleta. E muitos usam, constatando que muitas Startups tem áreas pra pendurar sua bicicleta dentro da empresa. Existem lugares onde você pode alugar, eu quase fui em uma que fica um ou dois quarteirões de distancia e onde disse que é o prédio do Twitter.

O Fábio Kung se tornou um bom ciclista desde que se mudou para lá. Parece que treina com frequência. Ele teve a ideia de me levar para conhecer mais da cidade de bicicleta. Me pareceu uma boa ideia para entrar no clima dos nativos. O Kung levaria sua esposa, o Martyn também e o Vinicius se juntaria a nós. Então acertamos de nos encontrarmos no Heroku no Domingo de manhã, onde eu poderia pegar uma bicicleta de lá. Este foi meu primeiro erro, a bicicleta que peguei era "bom" mas somente para distancias curtas, pois só tinha 3 marchas. Logo vocês vão entender porque isso foi um problema.

Além disso eu ainda estava indo nas festas e Sábado a noite teve a festa do Yammer. Depois disso eu e os camaradas uruguaios fomos para outro bar onde descemos muito whisky (ao pessoal da WyeWorks: "Necessiiita!" #piadainterna). Pra resumir digamos que acordei no dia seguinte bem desidratado.

Fui o primeiro a chegar no Heroku. O Pedro Belo e um amigo dele também se juntariam a nós mas pelo jeito a festa de sábado dele foi melhor que a minha, pois ele acabou furando. Depois de preparar a bicicleta, achar um capacete que me servisse (é obrigatório, assim como luz traseira que pisca no escuro) e me hidratar um pouco começamos a pedalar.

A idéia era simples, seguir para leste em direção a Embarcadero, uma linha reta. De lá subir pela costa onde dá para ver a paisagem do San Francisco Bay, com Alcatraz ao fundo. Seguindo a encosta chegamos a Fort Mason, do lado da Marina, e seguindo o contorno a Norte finalmente chegamos ao Golden Gate. Devo confessar que até atravessar a ponte eu até que estava indo melhor do que imaginava.

Porém a brincadeira estava só começando. A ideia original era atravessar a ponte e descer até a cidadezinha de Sausalito, de onde pegaríamos a balsa e voltaríamos para um dos Piers em Embarcadero. Porém o Kung está acostumado a pedaladas bem mais longas e me convenceu que o melhor era continuar contornando o lago até chegar em Tiburon.

Logo no começo vi que teria problemas, o caminho não era mais plano e uniforme, havia pequenas subidas, algumas leves, algumas pesadas. Aqui pegaríamos trechos de estrada e colinas. E fica minha dica: na dúvida, alugue uma boa bicicleta com um número de marchas em que você não precise se matar nas subidas. E outra dica, o selim é extremamente importante, tente encontrar o mais macio possível e também se puder use uma bermuda que seja acolchoada. Depois de Sausalito pedalamos provavelmente mais de 20km. Nas condições que eu estava, sendo amador do assunto, rapidamente me encontrei em sérias dificuldades pra acompanhar o pessoal. Mas quem está na chuva é para se molhar, e depois do "ponto sem volta", só restava ir em frente.

Perto de Tiburon, no trecho final já estávamos com fome e por coincidência, numa região que me pareceu meio como um parque, cruzamos com uma barraquinha de limonada onde duas pequenas meninas estavam vendendo limonada e cup cakes caseiros. Foi curioso porque eu achava que venda de limonada era coisa de filme e no ritmo de startups que estava, aquilo foi o exemplo canônico de "empreendedorismo". Essa pequena injeção de açúcar, pelo menos psicologicamente, fez alguma diferença para o gás final até nosso destino. Da próxima vez definitivamente preciso me lembrar de levar alguma solução de carboidratos.

Mas eles tinham razão, a visão é muito bonita e vale a pena o esforço extra ver a paisagem.

Pelo menos pudemos dar uma boa pausa em Tiburon e almoçar num excelente restaurante chinês do lado do píer onde pegaríamos a balsa. Depois de almoçar e circular pelo quarteirão comercial ao lado, pegamos a balsa no fim da tarde, com o sol já se pondo, o que nos forneceu mais algumas boas fotos.

E como se meu martírio não tivesse fim, a balsa nos deixa no Píer 39, acho que em Fisherman's Wharf. De lá ainda tínhamos que pedalar bastante de volta ao Heroku para devolver a bicicleta. Já era bem de noite quando chegamos. Foi fisicamente doloroso, mas o resultado valeu a pena. Eu não pedalava há mais de uma década, foi bom ver que eu ainda conseguia.

Na segunda-feira, como reportei no artigo anterior comecei cedo para ir tomar café da manhã na Pivotal. Me encontrei com a Sarah Mei na festa da Living Social e do Yammer e havia combinado de ir visitá-la no café. O Vinicius chegou logo depois e me mostrou o resto do escritório. O resto do dia está no outro artigo.

No meu último dia, depois de visitar a Get Satisfaction, eu e o Francisco fomos comer um bom hambúrguer na Mission Bowling Club.

Por coincidência, novamente graças ao Facebook um outro amigo de longa data conseguiu se juntar a nos por lá. Chikodi Chimaé uma figura interessante, já trabalhou como jornalista e muito mais.

Em 2009 ele estava, como eu agora, pesquisando mercados de tecnologia pelo mundo. Ele esteve no Brasil e me entrevistou para um artigo do Techtrotter. Não nos encontramos mais pessoalmente desde então, e muita coisa mudou muito, por isso para mim foi recompensador poder conversar com ele novamente e contar tudo que aconteceu desde então.

E com isso minha viagem chega ao fim. É impressionante o que se pode fazer em poucos dias. Todos os dias eu acordava muito cedo e ia dormir muito tarde e não teve um único dia que fiquei parado num dos hotéis, para onde eu voltava somente para dormir. Ficou faltando visitar o grande Guilherme Chapiewski no Yahoo! em Cupertino, visitar por dentro os campus do Google e do Facebook e outros pontos importantes no Vale do Silício. Há muito ainda que eu poderia fazer, mas acho que consegui cumprir meus propósitos.

São Francisco é uma excelente cidade, vou adorar visitá-la novamente. Mas pessoalmente é um lugar que eu não pensaria em morar por um período longo de tempo. Quero dizer, apesar dos pesares eu sou de metrópoles. Por mais confortável e agradável que seja qualquer outra cidade, eu nasci na selva da pedra e provavelmente vou morrer na selva de pedra ;-)

Este foi um ano atípico em relação a viagens. Por causa da correria na empresa só consegui relatar sobre a viagem a SãoFranciscoagora. E desta vez é hora de relatar sobre minha travessia pela Europa. Esta viagem foi particularmente interessante pois eu nunca estive na Europa, além de conexões de vôos.

O resumo é muito simples, o ponto de partida foi um convite dos meus amigos Ninh Bui e Hongli Lai, da Phusion, para participar da conferência BubbleConf, que eles estavam organizando em Amsterdã, Holanda. Seria um evento voltado a uma platéia criativa, empreendedora e técnica ao mesmo tempo. Ao mesmo tempo meu amigo Ofer Baharav, CEO da startup VideoVivo recomendou que eu visitasse Tel Aviv, em Israel, pois segundo ele é um dos mercados mais vibrantes de startups fora dos Estados Unidos. Finalmente, durante o ano ouvi mais de uma vez que deveria também conhecer Berlim, na Alemanha, que parecia ser o pólo mais importante de startups da Europa Ocidental. Foi assim que defini meu circuito de visitas.

A viagem se iniciou 2 semanas depois que retornei de São Francisco, então já dá para imaginar a correria. A viagem iria durar dos dias 9 de outubro a 19 de outubro, 10 dias apertados para visitar 3 países diferentes de uma só vez.

O maior desafio de todos? Infelizmente eu não sei falar holandês, nem alemão, nem hebreu. Felizmente com inglês é possível se virar razoavelmente bem, mas muito se perde em não saber fluentemente a língua local. Felizmente, tirando Berlim, tanto Amsterdã quanto Tel Aviv foram bastante confortáveis para se comunicar somente em inglês. Em Amsterdã eu ficaria do dia 9 ao dia 13 de Outubro.

Ao chegar no aeroporto de Schipol você sente que o lugar está tentando te recepcionar bem. A cidade tem programas como o I am-sterdam que deve ser sua primeira parada se não sabe para onde ir. De lá já descobri que existe um serviço de shuttles (micro-ônibus) que te leva diretamente até seu hotel. Mais cômodo que isso impossível.

O hotel que fiquei, o Arenaé muito charmoso, confortável e convidativo. Ela fica na 's-Gravesandestraat 51 (e a primeira coisa que aprendi é que "straat" é "rua") na região Leste em Oosterparkbuurt.

Aliás, parecido com São Francisco a cidade é minúscula. Ela tem área útil de 166 km2 e uma população de pouco mais de 1,300 milhão de habitantes, pouco maior que São Francisco. Mas são cidades completamente diferentes. Amsterdã tem aquele ar "europeu" que vemos em filmes, casas com paredes de tijolos, prédios pequenos, estreitos e baixos. A cidade é bastante organizada, ela tem o curioso formato de um semi-círculo com diversos canais formando seus raios. No centro desse semi-círculo fica o centro.

A parte mais importante da cidade é circundada mais ou menos pela Mauritskade (perto de onde eu estava), seguindo a oeste ela se torna Stadhouderskade, depois Nassaukade. Você normalmente vai estar dentro desse semi-círculo. Nessa região, se tiver a disposição, dá para ir de ponta a ponta a pé em menos de 2 horas. Estamos falando de um diâmetro que deve ter menos de 10 km, pouca coisa mesmo.

No meu caso, era muito simples andar o equivalente a uns 3 quarteirões atravessando o canal de Mauritskade até Saphartistraat, uma paralela interna ao circuito que falei acima, para pegar o bonde (tram) urbano até Leidseplein que é o início da área comercial da cidade. Novamente, não é uma cidade de grandes Shopping Centers como estamos acostumados, mas lojas de ruas em ruas apertadas. Se você é paulista, imagine uma 25 de Março - muito mais limpa e organizada, claro.

É onde você vai encontrar a Apple Store (sim, geek), uma das mais bonitas da Europa. De Leidseplein, novamente tendo o semi-círculo em mente, uma das radiais que vai em direção ao centro é a Leidsestraat. Seguindo por ela e atravessando 5 canais uma hora você chega na Rokin, uma das ruas principais do centro.

Seguindo pela Rokin até o fim chegamos na Dam Square, uma praça histórica famosa que liga a Rokin com a Damrak. Seguindo pela Damrak até o fim vamos cair na Estação Central. Agora, se cairmos para a direita, direção leste, já estamos na região conhecida como Red Light District. Sim, aquela famosa.

Um pouco mais para à direita e estamos na região de Nieuwmarkt de onde eu podia pegar o metrô em direção Sul, passando pela estação de Waterlooplein e descendo em Weesperplein, de volta à Sarphatistraat, que é perto do hotel.

Como podemos ver, é uma região bem pequena para se explorar. Em particular gostei bastante da facilidade de pegar os bondes da GVB, são bondes de superfície, que andam no meio das ruas principais. Não foi muito óbvio entender como o sistema funcionava de primeira, na prática você entra pelo meio do vagão onde encontra um cobrador. Pode comprar um passe de ida, ida e volta, ou por períodos, como diário. Com o cartão em mãos você passa na frente de uma máquina na entrada e na porta de saída para marcar as viagens. Para mais detalhes sobre como se locomover pela cidade leia este excelente blog post, teria me ajudado muito se eu tivesse encontrado antes.

A maioria das pessoas deve ter duas curiosidades, a primeira é sobre a Red Light District, então vamos matar essa curiosidade de uma vez. Sim, ela existe, não ela não é nada demais, pessoalmente achei até muito comportado. Antes de mais nada o termo "Red Light District" serve para qualquer área urbana com concentração de serviços sexuais. Aqui em São Paulo seria como uma Rua Augusta. A de Amsterdã se chama De Wallen. Ela é "Red Light" porque as garotas de programa (profissão legalizada por lá) alugam casinhas que tem porta de vidro pra rua, acendem uma luz vermelha por trás e se exibem em trajes curtos para quem quiser ver.

Tem diversas casas de show como a Casa Rosso, mas não esperem grande coisa. Dentro é basicamente um teatro, você senta e assiste. Os shows? Strip teases, shows de sexo ao vivo. Os garçons (bem impacientes) servem as bebidas pra você e você só fica sentado. É programa leve, vai muito casal, velhinhos e turistas sem noção. Detestavelmente entediante. Não recomendo. Existem outras casas com serviços mais interativos como lap dance, pelo que ouvi dizer, como no Bananenbar. Coisa pra americano, não tem nada mais entediante do que lap dance. Sério mesmo.

E a coisa é bem suave mesmo, em alguns cantos mais movimentados tem até super mercado onde passam mães e filhos e do lado tem as meninas expostas. Não tem muito pra ver mesmo. Falando em mercado uma pequena dica, todo lugar tem uma Albert Heijn. Não é hiper mercado, pra eles é mais como uma loja de conveniência, pra nós é um mercado de bairro. Muito prático pra pequenas compras, recomendo.

Muito mais interessante do que a Red Light District são os Coffeeshops que no centro você encontra um do lado do outro, não tem como errar. Eles vendem tudo menos café, e se prepare pra encontrar os lugares cheios de turistas. Se tiver um bom amigo pra te levar num menos turístico é melhor. Por sorte encontrei com meu camarada Otávio Fernandes que deve estar arrependido de ter me levado lá até agora. Já explico.

Nos coffeeshops você escolhe qual tipo de maconha quer comprar, eles tem um cardápio variado. Pega papelote pra enrolar, um papelão pra fazer o bico (isso foi novidade). Leve uma tesoura pra ajudar. Com o equipamento certo nas mãos, um pouco de habilidade e você enrola o melhor baseado que já fumou. Só que se você for como eu, vá muito devagar! Sério! O Otávio foi amigaço de me aguentar tendo a pior ressaca que já tive, depois de meia dúzia de baforadas! (sim, muito fraquinho, eu sei ...)

E falando do jeito de enrolar, aprendi que a gente enrola do jeito menos prático, aprenda como os holandeses fazem neste vídeo no YouTube. Bem melhor mesmo.

Depois desse episódio embaraçoso, no dia seguinte tive a oportunidade de visitar uma empresa local, a FingerTips (não! não o que você imaginou, melhor). Eles desenvolvem apps para iOS, OS X, web com Rails. São uma empresa de serviços, pequena de 4 pessoas, mas eles são bem integrados na comunidade. Lembram quando você ganhou suporte a Unicode no Rails antes do Ruby 1.9? Agradeça ao Manfred.

Fui almoçar com eles perto do escritório deles e no caminho cruzamos com o croata Mislav Marohnić, que também veio para o BubbleConf. Lembram do bom e velho Will Paginate? Sim, agradeça ao Mislav. Foi um encontro bem interessante porque o Mislav nos contou que já visitou o Brasil, inclusive viajando pelas estradas do interior até Olinda para o Carnaval de rua. Não preciso dizer que ele se divertiu bastante em nosso país.

Aliás, andando por essa região mais ao norte, perto da Estação Central, pude ver como os holandeses gostam de bicicletas. Isso já era notório porque em toda ponte atravessando os diversos canais você vê bicicletas presas, nas praças também, mas esta visão foi surreal.

A brincadeira que me contaram é que os holandeses nem estavam ligando muito pra Segunda Guerra até que os alemães vieram confiscar suas bicicletas ...

BubbleConf

Enfim, para variar eu estava atrasado pra fazer minha apresentação pro evento do dia seguinte então gastei o resto da tarde preparando meus slides. Felizmente não era uma palestra completa, era pra sessão de Lightning Talks então adaptei a palestra que fiz na RubyKaigi do ano passado.

Falando sobre o evento, foi o primeiro organizado pelos garotos da Phusion e devo dizer que sendo o primeiro eles estão de parabéns. Excelente local, ótima seleção de palestras, boa cenografia, boa recepção e programação.

O local foi no Pathé Tuschinski que é um teatro. O ambiente tem uma área principal com palco amplo, excelente infraestrutura de áudio e vídeo digital widescreen HD (foi estranho montar os slides em wide). A sala secundária para a programação paralela de Lightning Talks tinha o tamanho adequado.

A única restrição foi a área da entrada, o lobby, onde teve o almoço e coffee breaks, era um pouco apertado para tanta gente (cerca de 300 pessoas) e por isso a parte de socialização ficou um pouco comprometida. Além disso a programação foi um pouco rígida, e como num teatro quase ninguém fica fora das palestras para socializar como acontece em outros eventos, então ela foi bem orientada no conteúdo apresentado. Único ponto a melhorar.

A seleção de palestras foi interessante mas devo deixar claro que o nível era mais "motivacional" do que instrutivo. Destaque para a presença de Laurent Sansonetti falando sobre sua primeira experiência como empresário de startup.

Outro tema que achei muito interessante terem colocado num evento desses foi apresentado por Egin Lengton um advogado falando sobre a importância de compreender como compor uma empresa, diferenças entre ser um profissional liberal e uma empresa limitada, por exemplo, coisa que muitos empresários "wannabe" não sabem mas deveriam, obrigatoriamente.

Algumas foram um "entretenimento razoável" mas nada de conteúdo como o Mike Lee, da interessante da Appsterdam.

O grande destaque para mim foi o fechamento, apresentado por ninguém menos que Zed Shaw, considerado um dos mais famosos trolls que já fez parte da comunidade Ruby. Alguns levam suas trolagens a sério demais, mas não deveriam, pois por trás do seu estilo de comunicação abrasivo estão argumentações bastante sérias. Eu por outro lado sempre achei que ele fosse uma figura interessante e devo dizer que gostei muito de conhecê-lo pessoalmente.

Espero que ele publique os slides da sua palestra porque ela foi sensacional. Em resumo, ele disse de uma forma bem mais dura, direta e agressiva sobre um mesmo assunto que eu também apresento: as pessoas adoram uma boa história. Boas histórias vendem.

Só que muitos ainda acreditam que "boas histórias" é a mesma coisa que "receitas para o sucesso", e elas não são. Este atual mercado de startups tem várias alegorias, anedotas, historinhas que geraram diversas "receitinhas" que muitos levam muito mais a sério do que elas de fato merecem. Brad Feld, David Cohen, Eric Ries (Lean Startup), Jason Fried (37signals) todos tem excelentes histórias para contar. Porém ninguém deveria comprá-las por mais do que elas realmente valem: apenas como histórias, nunca como receitas, nunca como "boas práticas", muito menos como "dogmas" a serem seguidos.

O problema é que ser entretido por histórias coloridas é muito mais interessante do que aprender de fato a fundação: administração de empresas, contabilidade, economia, marketing, recursos humanos, etc (daí porque achei legal a palestra do Lengton). A fundação é mais chata, entediante, cinza, demorada, porém é o correto. É como querer competir na UFC lendo a biografia do Royce Gracie. Interessante, motivante, mas definitivamente não vai te proteger de quebrar todos os dentes no primeiro passo que der na arena. Simples assim.

Mas estou divagando, não sei se todas as palestras serão disponibilizadas, mas se forem recomendo assistí-las. Depois do evento fomos todos dois quarteirões para baixo, numa baladinha chamada Escape para um open bar. E finalmente um jantar para os palestrantes no Tokyo Cafe, um excelente restaurante para amantes de um bom sushi. Recomendo.

Turismo

Reservei o sábado para um visita mais turística, a manhã começou frio e com garoa. Minha primeira parada foi no Rijksmuseum. Em Amsterdã, existe uma região próxima à Leidseplein que é a Museumplein, uma área que concentra diversos museus. O Rijksmuseum em particular é o museu nacional da Holanda, dedicada à arte, artesanato e história. É um passeio muito interessante que recomendo a todos que passarem pela cidade, mas preparem-se para pegar fila no fim de semana.

Você verá um pouco de tudo da história da arte holandesa, como as famosas casas de boneca miniatura, a precisão no trabalho com prata e com porcelana, influências do comércio com o oriente, e assim por diante.

Outra curiosidade é que nossa tão conhecida Kombi, quem diria, é design holandês.

Eu teria reservado pelo menos meio dia inteiro só para apreciar esse museu como ele merece, talvez mais tempo ainda se pudesse, mas no curto período que eu tinha tive que andar um pouco rápido. Mesmo assim deu para apreciar algumas das obras de artistas renomados como Rembrandt e Vermeer. Rembrandt dispensa apresentações, um dos maiores pintores da história da arte Européia e obviamente o maior da Holanda.

Vermeer em particular para mim era curioso pela cultura pop da sua pintura Girl with a Pearl Earring porque inspirou um livro) e um filme) de mesmo nome estrelando Scarlett Johansson. Se estiver curioso assista agora mesmo a palestra de Tracy Chevalier para o TED.

Eu pretendia visitar o museu de Van Gogh também, que teoricamente era do lado, mas ele parecia estar fechado ou mudado de lugar, não entendi bem. De qualquer forma decidi ir mais pro centro da cidade atrás de outro museu, o Het Sex Museum, afinal estamos em Amsterdã. Nem se compara a um museu de verdade, claro, é mais uma pequena exposição num espaço bastante apertado e, como era fim de semana, bastante lotado de pessoas. Bem difícil apreciar uma exposição com tanta gente esbarrando o tempo todo, portanto reserve visitas a museu durante a semana - lição aprendida.

Este museu não tem nada demais além de ser uma curiosidade. É uma pequena exposição de peças eróticas e curiosidades sobre a história do sexo, peças que você provavelmente já viu alguma vez na vida ou que pode ver em melhor qualidade navegando 5 minutos pela Web. Basicamente você verá como o sexo era expressado através das décadas, desde equipamentos como cintos de castidade para tortura, sexo vintage, garotas pin-ups, pornografia mais explícita (e mesmo assim aquém dos níveis da Web atual). A parte interessante é a simples existência de um museu como esse no meio da cidade, coisa que em lugares mais hipócritas e "puritanos" não seria visto com "bons olhos". Não é um lugar escondido, mas uma área bem no centro da cidade, do lado de restaurantes. E não são só homens pervertidos que visitam, mas muitas mulheres, meninas, famílias, velhos. É simplesmente um museu barato de €4. Pode ser um lugar para se matar o tempo depois de ter passado por um coffeeshop.

Minha próxima parada seria visitar o Anne Frank Huis. Assista o filme O Diário de Anne Frank para se familiarizar, e se for a Amsterdã esse deveria ser o primeiro lugar a se visitar. É mais um capítulo da triste história dos judeus na Segunda Guerra. Infelizmente eu fui tarde demais, havia uma fila enorme literalmente dando voltas no quarteirão. Esperar na fila, no frio e na chuva não estava nos meus planos então acabei não visitando. Uma pena.

Aliás, a mesma recomendação vale para o centro da cidade: o fim de semana atrai muitos turistas. Se você é de São Paulo, imagine a 25 de março num sábado de manhã, é a mesma coisa. Deixe para fazer suas compras e visitas durante a semana se possível, porque as estreitas vielas de Amsterdã ficam com muito mais gente do que você gostaria de esbarrar num dia frio e de chuva.

Terminei o sábado visitando a Dam Plaza, o centro histórico de Amsterdã. Como expliquei antes ela liga as ruas Damrak e Rokin, perto da Red Light District. De curiosidade, o nome "Dam" era justamente da sua função de "represa" do rio Amstel. Um bom lugar para se tirar boas fotos, mesmo num dia chuvoso.

Domingo de manhã só me restava terminar no aeroporto Schiphol para minha próxima parada: Berlim, Alemanha (não perca a Parte 2 desta série). Uma pequena curiosidade para mim que nunca tinha visto foi o sistema automatizado para despachar malas. Um sistema self-service onde você mesmo etiqueta sua mala, coloca num compartimento e pronto, a esteira leva ao lugar correto. Nada de atendimento com pessoas. Muito mais eficiente, gostaria que nossos aeroporto aqui em São Paulo tivessem o mesmo sistema.

E assim termina minha estadia por Amsterdã, uma pequena e aconchegante cidade européia. Como minha primeira vez na Europa foi um lugar peculiar que me causou uma excelente primeira impressão.

No Domingo, dia 14 de Outubro me despedi de Amsterdã e fui para Berlim. Devo dizer que meu maior engano nesta parte da viagem foi que eu deveria ter saído de Amsterdã logo no Sábado de manhã, logo depois da BubbleConf, para ter mais tempo em Berlim. Eu aterrissei no Domingo a noite e já iria embora na Terça de manhã, tendo somente a Segunda-feira para fazer tudo. Foi de longe o dia mais denso de toda a viagem.

Aterrissei num dos maiores e mais importantes aeroportos da Europa, o Tegel. Ele tem um formato hexagonal curioso, estava cheio quando cheguei à noite. Diferente do Schiphol onde todos foram muito simpáticos e prestativos, devo dizer que fiquei extremamente decepcionado com a recepção na Alemanha. A primeira coisa que tentei fazer foi comprar um SIM Card para conseguir Internet via 4G ou 3G. Perguntando descobri que poderia comprar um numa casa de câmbio. O velhinho que me atendeu não falava quase nada de inglês ou não estava com vontade nenhuma de tentar. Aposto na segunda opção.

Ele me vendeu um SIM Card pré-pago da porcaria da Blauworld (nunca comprem Blauworld). O manual estava todo em alemão, perguntei o que eu tinha que fazer mas ele não estava nem um pouco com vontade de ajudar. Acabei comprando por uns €10. Como ele não queria me ajudar fui até o balcão de informações para pedir ajuda. A resposta da atendente? "Por que eu tenho que ajudar você a ler?" Com essa resposta desisti de tentar ajuda. Desisti de tentar ativar o SIM Card também pois ligando nos números da Blauworld a URA só falava em alemão.

Saí do aeroporto para descobrir como chegar ao hotel. O funcionário dos ônibus foi outro que não foi de muita ajuda. Ele me indicou o ônibus que passaria na região de Alt-Moabit, onde fica meu hotel. Perguntei quando deveria descer e a única coisa que ele disse foi: "Pergunte ao motorista."

Fácil dizer, mas o ônibus estava lotado de gente com malas, estando no meio do ônibus não era exatamente simples chegar até o motorista. Depois de alguns pontos vi um passageiro com internet no smartphone e pedi ajuda pra ele me mostrar o Google Maps. Vi que estava mais ou menos próximo mas não sabia se o ônibus ia fazer a entrada pra onde eu precisava ir, resolvi pular do ônibus antes e terminar de táxi mesmo. Culpa minha por não falar alemão, claro, mas foi irritante.

Fiquei hospedado no hotel Golden Tulip Park Consul um hotel bem pequeno, com uma recepção no primeiro andar onde você precisa subir de escadas com sua mala. Inconveniente. Pelo menos o quarto era razoável, com vista para o parque na frente. A internet no quarto obviamente não era grande coisa mas tentei o máximo que pude ativar meu SIM Card e carregá-lo. O site da Blauworld é super mal feito, muda de inglês pra alemão, as mensagens de erro não fazem sentido. Finalmente desisti, joguei o SIM Card fora e deixei pra me virar pela manhã.

Felizmente atravessando a praça na frente do hotel havia uma área comercial e encontrei uma loja da Vodafone. Agora sim, de volta com acesso à Internet pude começar a me movimentar pela cidade. Eu estava em Alt-Moabit, uma região à oeste do centro da cidade, que seria mais pra direção de Mitte, na divisa do que era a antiga Berlim Ocidental e Oriental.

Berlim é uma cidade mais no meu estilo: grande, com uma área de quase 900 km2 e mais de 3,5 milhões de pessoas. Definitivamente não é uma área que você pode cobrir a pé num único dia como nas outras viagens que fiz recentemente. Não me admira que a receptividade não seja grande coisa, é como provavelmente em qualquer grande cidade, incluindo a minha.

Alt-Moabit até Mitte não é longe, coisa de uns 2km se estiver com disposição para ir a pé. Mas eu não tinha tempo a perder, por isso foi bom saber que poderia contar com um dos melhores sistemas de transporte públicoà minha disposição. E isso não é uma hipérbole, o sistema de metrô, trens, bondes é todo interconectado. De cara as palavras que você deve procurar são U-Bahn (o metrô subterrâneo) e o S-Bahn (os trems de superfície). Com essas duas redes você pode ir a qualquer lugar. Berlim é dividida em três zonas, chamadas de A, B e C, comprando um bilhete para o dia todo na zona AB era o que eu precisava.

Outra coisa impressionante: não há catracas nas estações, você compra o bilhete numa máquina automática, valida o ticket em outra máquina (prestem atenção, de primeira eu não percebi que elas estavam lá), entra no trem e vai para onde quiser. Somente em um país realmente civilizado isso é possível. Ninguém pensa em "vou aproveitar para andar por aí de graça", mesmo porque parece que existem fiscais que podem parar você a qualquer momento, por isso seja civilizado, pra variar.

Poderia passar vários artigos tecendo adjetivos para o sistema de transporte público europeu mas veja este outro artigo que faz esse trabalho melhor do que eu. Na prática, confie nas rotas do Google Maps. De qualquer forma, só tome cuidado porque nas linhas da S-Bahn você precisa prestar atenção ao número dos trens na mesma linha, alguns tomam caminhos diferentes do que você quer. No Google Maps ele indica o número da linha que você precisa pegar. Minha primeira parada foi na estação Warschauer Straße. A partir dali poderia caminhar alguns quarteirões para um dos trechos dos restos do famoso Muro de Berlim. Imaginei que estando em Berlim, pelo menos esse ponto turístico eu deveria tentar visitar.

Não preciso descrever a importância histórica da Queda do Muro. Como primeiro checkpoint fiquei contente de ter conseguido chegar sem nenhum problema. Grande diferença andar por uma cidade desconhecida com a ajuda da Web. Disse e repito: a primeira coisa que você precisa fazer quando chegar numa nova cidade é arranjar um SIM Card com Internet, depois disso fica tudo trivial.

Logo em seguida eu havia conseguido contato com um pessoal do Groupon. Não lembro exatamente qual caminho fiz, mas lembro de ter caminhado pelo Lustgarten, outra excelente região para visitar com mais calma da próxima vez.

O Groupon fica na Oberwallstraße 6 onde fui recebido por Jonas Fleer, Alexandre Campelo, Jens Günther, Tino Montalbano e Dietrich. Peguei eles no meio do almoço mas foram bastante simpáticos em me receber. O prédio que visitei é novo, mudaram para lá fazia poucos meses. O Groupon em Berlim é um enorme complexo que deve ter perto de 800 funcionários e mais de 100 desenvolvedores. Pelo que me explicaram o Groupon da Europa é a plataforma em Java que suporta a maior partes dos Groupons do mundo. O Groupon de Chicago é o único diferente, inclusive usando Ruby como plataforma em vez de Java.

Minha primeira conversa se não me engano foi com Tino e Dietrich. A conversa com eles foi interessante, o Tino é de RH e estava interessado em discutir comigo maneiras de mudar a imagem do Groupon. O que eu não sabia é que na Europa o Groupon não parece ser bem reconhecido entre desenvolvedores, sendo mais reconhecido como uma empresa de vendas - o que de fato ela é. Por isso eles tem tido dificuldades em encontrar e contratar bons programadores, mesmo na Alemanha. Eles querem mudar isso participando e organizando mais tech talks internos, eventos. Gastei bastante tempo com eles explicando as características dos diferentes tipos de eventos de tecnologias que existem, o que eu achava ser o melhor caminho e muito mais. Foi pelo menos uma hora de conversas para lher dar mais fundação nessa tarefa árdua de se integrar à comunidade de desenvolvimento.

O curioso é que eu lhes disse que ano passado eu havia já convidado o programador Ivan Moscoso do Groupon de Chicago para palestrar no Rubyconf Brasil 2011, ou seja, eles já tinham gente em casa com experiência em palestras que poderia servir de exemplo aos demais desenvolvedores. Mais coincidência ainda foi que depois da nossa conversa eles me levaram para um tour pelo prédio e num dos andares cruzamos com ninguém menos do que o próprio Ivan, que tinha acabado de chegar de Chicago. Foi engraçado eu apresentar um funcionário do Groupon para outro funcionário do Groupon, mas é assim que serendípede funciona.

Depois a visita continuou com o Jens Günther, se não me engano, que me mostrou mais das equipes de desenvolvimento. Em sua equipe trabalha também um brasileiro, o Alexandre Campelo, que se mudou do Groupon do Rio para Berlim recentemente.

Outro fato curioso foi que ele me contou como eles são divididos em equipes "departamentais" (equipes especialistas) e que a direção da empresa determinou que queriam mudar sua estrutura para "feature teams", um tema que eu pesquiso e experimento faz anos, inclusive tentei implementar na Locaweb entre 2008 e 2009, numa organização de tamanho semelhante em termos de desenvolvedores, e que implemento na minha empresa hoje. Contei a ele sobre os pontos positivos mas principalmente sobre os problemas que eu já sei que ele vai enfrentar. Espero ter ajudado. De qualquer forma, mais serendípede.

A visita pelo Groupon foi interessante, não é uma estrutura muito diferente do que estou acostumado em qualquer grande corporação. Não estou muito por dentro das últimas notícias, mas parece que o Groupon também não anda muito bem das pernas, mas isso não é visível para quem está só olhando de passagem.

Além do Groupon eu já estava em contato com o camarada Vitor Pellegrino que trabalhou por algum tempo na minha empresa antes de se mudar para morar em Berlim. Ele me apresentou a outro brasileiro, o Caio Filipini, que se mudou também não faz muito tempo. Ele trabalha na SponsorPay e me convidou para visitar seu escritório.

O espaço onde eles trabalham parece um tipo de co-working, mas é num complexo de pequenos prédios bem peculiar, bem "europeu", vamos dizer. Parece que ocupam a maior parte desse espaço e devem ter pouco mais de 100 funcionários nesse estágio, sendo uns 20 deles desenvolvedores. Não é uma equipe muito grande e isso é uma vantagem para eles continuarem a acelerar no seu produto. Eu particularmente nunca tinha ouvido falar neles, mas a SponsorPayé uma grande plataforma de advertising e marketing direcionado através de moeda virtual em games sociais, redes sociais e mundos virtuais, MMOs. Pense que você, enquanto consumidor, pode ser "pago" em moeda virtual por consumir propaganda de alguma campanha para gastar depois num Farmville. Se entendi bem é algo assim.

O Caio me apresentou ao seu chefe, Juan Vidal, Diretor de Engenharia. Ele é um programador ativo também e dentre outras coisas criou o site Hascore, um site de empregos que dentre outras características é um dos diretórios mais completos de todas as startups ativas em Berlim (330 cadastradas atualmente). Ele me deu dezenas de insights sobre o mercado de startup, foi a primeira conversa onde pude sentir que aprendi alguma coisa mais realista sobre esse romantizado mundo de startups. Ele inspira muita confiança e experiência no que diz e faz, se tiver a oportunidade de conhecê-lo garanto que terá uma ótima conversa.

Confirmando algumas coisas que eu já imaginava, por mais que existam mais de 300 startups em Berlim, 90% deles não deve durar muito tempo. É a famosa curva de Paretto que eu tanto gosto de descrever. As maiores de Berlim são o Groupon, SoundCloud, SponsorPay e mais algumas poucas, o resto não tem tanto destaque. Outra coisa: as leis trabalhistas européias são realmente tão ruins quanto ou piores do que as brasileiras. Um exemplo: quanto mais tempo de casa você tem como funcionário, mais difícil é para ser demitir (o que obviamente leva à acomodação; proteção por tempo e não por mérito nunca funciona). Diferente dos Estados Unidos onde você pode demitir e no mesmo dia o funcionário já vai pra rua (como deve ser).

Outra coisa é dificuldade de encontrar bons profissionais em qualquer lugar. É um problema que existe no mundo todo como eu apresento há anos: não existe escassez de boas vagas para bons profissionais, o problema é que 90% do mercado é péssimo. O SponsorPay é um grande exemplo dessa dificuldade porque dentre seus cerca de 20 programadores, eles divididos em pelo menos uns 10 países. Eles buscam bons profissionais onde estiverem para se mudar para Berlim. É tão notório que cada programador tem uma bandeira do seu país de origem em sua mesa. A preferência parece ser que o desenvolvedor se mude para trabalhar junto com os outros no escritório, um sinal que deve ter a ver com a recomendação do Juan no livro The Inmates Are Running the Asylum, oposto à romantizada e nem sempre tão prática conversa sobre trabalhar remoto de casa.

Já estava ficando tarde então infelizmente não pude conversar tanto quanto gostaria com todos eles. A partir dali eu peguei o U-Bahn até Moritzplatz em Kreuzberg, em direção a Prinzessinnenstrasse 21. Esse é o endereço de um co-working bem famoso na região, a Betahaus onde fica a equipe do Travis-CI. Além da Betahaus, próximo dali existe o co-working Co-Up onde fica o pessoal da CouchBase. O Jan Lehnardt me mandou tweet sobre o local mas infelizmente ele não estava lá nesse dia. A Betahaus e a Co-Up parece que são conhecidas por concentrarem muitas startups que usam Ruby, então são bons locais para visitar quando estiver em Berlim.

Quando estava saindo de Amsterdam o Josh Kalderimis estava chegando lá, então nos desencontramos, mas ele sugeriu que eu visitasse o resto da equipe em Berlim e lá fui.

Quem participou da Rubyconf Brasil 2011 também conheceu outro integrante dessa equipe, o Konstantin Haase, committer do Rack e do Sinatra. E se você já usou o suporte à internacionalização do Rails também deve conhecer Sven Fuchs que conheci quando contribuí para as traduções em português na época. Os três formam a equipe por trás do software as a service e do projeto open source conhecido como Travis, um sistema de integração contínua que vem crescendo rápido, principalmente pela rápida adoção da comunidade Ruby.

É sempre bom rever bons amigos, especialmente os que conhecíamos apenas pela Internet e finalmente tive a oportunidade de conhecer pessoalmente. Eles tem um pequeno escritório na Betahaus e operam da forma mais enxuta possível, cada um faz um pouco de tudo, do técnico ao administrativo.

Aproveitei para aprender um pouco mais de história e confirmar outro fato que outros já haviam me explicado. Uma das razões para Berlim ter se tornado um dos pólos de startups da Europa é o preço mais acessível dos imóveis, especialmente na área Oriental, como lá em Kreuzberg. Nos anos 90, quando o muro caiu, a população da região ex-socialista do Oriente migrou para o lado Ocidental. O governo criou diversos incentivos para repopular e reconstruir o lado Oriental. Outro detalhe das leis trabalhistas é que quem paga o salário dos sindicalizados são os sindicatos, e do lado Oriental eles recebem cerca de 75% do que se recebe do lado Ocidental, para atrair indústrias para o lado Oriental, dentre outros incentivos. O baixo preço dos imóveis também atraiu uma nova classe de jovens artistas e empreendedores, especialmente para regiões como Mitte, o que tornou essa região mais "hipster" e, claro, mais atraente para as novas startups.

Em Berlim você recebe razoavelmente bem comparado ao resto da Europa - talvez não tanto comparado à Inglaterra -, mas por outro lado o custo de vida e conforto é muito melhor que em Londres. Portanto as startups ou estão concentradas em Berlim por essas razões de custo-benefício, ou vão para Londres porque, bem, porque Londres é Londres.

Outro fato interessante foi saber que semanalmente o pessoal do Travis-CI empresta o espaço do seu escritório para um grupo de estudos do RailsGirls de Berlim. Foi um fato interessante porque eu acho que é assim que os RailsGirls deveriam evoluir. Um evento de 2 dias é muito bom para as garotas se conhecerem, conhecer o ecossistema, mas a partir daí elas poderiam se reunir para continuar os estudos e continuar aprendendo cada vez mais. Espero que esse grupo sirva de exemplo a outras RailsGirls pelo mundo. Uma dica que elas deram para outras garotas: levem comida nos encontros semanais!

Finalmente, já estava de noite quando me dirigi para a SoundCloud me encontrar com o Vitor Pellegrino e seu chefe, o também brasileiro e ex-Thoughtworks Austrália, Philip Calçado. Foi só pegar o U-Bahn de novo no sentido oposto e descer na Bernauer Straße, agora em Mitte. A SoundCloud fica na Brunnenstraße 141A, um prédio para onde eles mudaram recentemente. Na verdade eles tem outros prédios mas este (o Moonbase) é onde fica o pessoal de desenvolvimento. Pelo que me contaram estão construindo um novo logo atrás para onde vão se mudar em breve.

Cheguei a noite porque estava tendo algum tipo de evento e eu ia pegar carona no happy hour deles. O prédio em si na verdade era um prédio residencial convertido em escritórios, então é como estar andando dentro de apartamentos e encontrar uma mesa grande com computadores no meio da sala. Na cobertura eles tem uma área aberta onde estavam os comes e bebes. A empresa está com mais de 150 funcionários se entendi bem, e eles também tem uma equipe bem diversificada com pessoas da Espanha, Itália, Israel, Brasil e muitos outros lugares.

O Philip agora é o "the Boss" de engenharia e comanda o desenvolvimento dessa rede social de música. Os planos parecem ser de torná-la algo como um iTunes. O Vitor se mudou bem recentemente, questão de poucas semanas e com a mudança para esse novo prédio ele agora mora a poucas quadras a pé do trabalho. Como disse antes, a comodidade de ter prédios comerciais acessíveis perto de casa ou perto de trem e metrô é definitivamente o melhor atrativo dessa cidade para empresas em geral.

Sendo meu último compromisso do dia, já que havia anoitecido, pude relaxar um pouco mais e conversar com o pessoal. Em particular gostei muito de trocar idéias pela primeira vez com o Philip. Sua reputação o precede, seu nome não é desconhecido no mundo Java do Brasil, especialmente para quem participa do Guj da Caelum (aliás, o Caio Filipini é um ex-Caelum, outra excelente referência). Nós só nos encontramos pessoalmente uma única vez quando eu organizei a Rails Summit, não lembro se foi na edição de 2008 ou 2009, mas foi muito rapidamente. E só agora, 4 anos depois, tive a oportunidade de conversar com ele. Foi interessante ouvir suas opiniões como ex-insider da Thoughtworks, acho que aprendi algumas lições com ele.

No final eles me levaram a uma barzinho chamado Mein Haus onde pudemos relaxar e conversar mais um pouco.

Como disse no início, este foi um dia bem corrido. Mesmo pulando o tempo de almoço, não deu para fazer muito mais do que isso num único dia, mas pelo que consegui, pelas pessoas que conheci, pelas conversas que tive e o que pude absorver, acho que foi mais proveitoso do que estava esperando.

No dia seguinte, saindo do hotel peguei o U-Bahn a um quarteirão do hotel e depois conectei com a S-Bahn até a estação de Ostkreuz onde eu pegaria o trem para o aeroporto, desta vez em Schönefeld. Eu saí com mais de 3 horas de antecedência do hotel, sabia que levaria pelo menos 1 hora e meia para chegar até o aeroporto, imaginei que teria tempo de sobra.

Porém o último capítulo desta história, em Israel, começa antes mesmo de eu conseguir fazer o check-in na El Al Israel Airlines, e isso fica para o último capítulo dessa série.

Como disse no final do meu relato sobre Berlim, a Israel começaria bem antes, no aeroporto de Schönefeld quando estava indo fazer o check-in. Acontece que eles tem diversos agentes antes do check-in que escolhem algumas pessoas para entrevistar, extensivamente. Infelizmente eu fui um dos escolhidos. E não estamos falando de perguntas padrão do tipo "Alguém além de você mexeu na sua mala?". A agente quis saber porque eu estava em Berlim, porque eu vim de Amsterdã, quem eram as pessoas com quem falei, informações do hotel, tive que abrir meu notebook para mostrar meus emails, tweets, ela abriu o notebook dela pra checar se meu blog, o site da minha empresa realmente existiam. Acho que levou quase 1 hora nessa entrevista.

PS: eu estava em dúvida sobre considerar Israel na "Europa", mas parece que ele é Ásia, mas considerado Europa para fins de esportes por exemplo :-)

Depois disso você faz o check-in e passa pela inspeção padrão que todos já conhecem. Mas na área de embarque, antes de entrar no avião da El Al Israel Airlines, você passa por uma segunda inspeção das malas e detectores de metais manualmente por todo o corpo. Não tem como passar um alfinete sem eles verem! Considerando a situação em Gaza ultimamente não dá para culpar o excesso de cuidado.

Mas os obstáculos não acabam aqui. Dizem que o aeroporto Ben Gurion é considerado o mais seguro do mundo. Chegando lá dá para entender porque. Logo na imigração eu já fui novamente separado e tive que esperar uma meia hora uma sala. Acho que eles fazem algum tipo de checagem de antecedentes e tudo mais. Mas depois desse último obstáculo finalmente consegui entrar em Israel. A primeira impressão, apesar de tudo, é o de estar num lugar bem mais civilizado do que se poderia esperar. O aeroporto tem instalações de primeiro mundo.

Lembram-se do meu martírio para conseguir um SIM card no aeroporto Tegel na Alemanha? Aqui foi absolutamente trivial. Havia uma loja de aluguel de cartões SIM Card. Todos os atendentes falavam inglês perfeitamente bem, foram bem atenciosos, me deram várias opções para minha estadia. Em poucos minutos já estava de volta à Internet. Todos os serviços de aeroporto deveriam ser como esse.

Antes de embarcar, eu havia twitado que estava indo para Tel Aviv e alguns israelenses foram muito gentis em me responder. O primeiro que já me ajudou logo no aeroporto, via Twitter, foi Omer Rauchwerger. O primeiro choque é ver tudo escrito em hebreu ou árabe. Diferente de holandês ou alemão onde você pode pelo menos tentar identificar algumas palavras ou sílabas, aqui não dá para entender absolutamente nada. Deve ser a sensação de ser completamente analfabeto. Felizmente Tel Aviv é amigável a turistas então existem diversas traduções de placas e sinalizações nos principais locais.

No próprio aeroporto você identifica a existência de um trem que pode te levar de um lado para Jerusalém e de outro para Tel Aviv. Você compra tickets em máquinas automáticas que felizmente tinham opção para inglês. Nesse caso basta comprar o ticket de ida para Tel Aviv. Pegando o trem você espera umas 3 estações (aproximadamente meia hora de viagem) e desce em Tel Aviv Merkaz (Centro), também conhecido como Savidor. Da estação eu estava a menos de 2km do Vital Hotel.

Uma dica importante: assim como aqui nos aeroportos de São Paulo, nunca pegue táxi de taxistas que te abordam na saída. Procure a fila oficial (fácil de identificar, sempre tem um funcionário coordenando uma fila). E dentro de qualquer táxi sempre peça para ligar o medidor, caso contrário eles vão querer te enrolar para fechar um preço que vai acabar sendo o dobro do normal. Aliás, fique esperto no geral, todo comerciante de rua vai querer passar a perna em turista, por padrão.

Voltando ao hotel, devo dizer que foi uma excelente escolha. Ela fica conectada ao Weizmann Shopping Center com acesso a partir da recepção do hotel. O atendente que me recepcionou foi provavelmente o mais simpático e prestativo de todos os tempos. Conversando com ele foi que decidi como ocuparia meu dia seguinte: fazendo um tour com guia por Jerusalém. Ele se encarregou de acertar tudo para mim.

O hotel é muito bem equipado, moderno, limpo e de todas as cidades que passei até agora foi a que ofereceu o melhor serviço de internet. O único que dava para fazer ligações por Skype decentemente. Já era noite e o Omer também me recomendou um bom restaurante para jantar, então como já estava equipado com internet resolvi sair para caminhar pela cidade e foi uma excelente escolha. Meu primeiro destino foi o restaurante Brasserie M&R com ótimas opções de culinária francesa. Nessa lista, por exemplo, ele está entre os 3 melhores restaurantes para ir em Israel. Uma excelente opção, um pouco cara para meus padrões mas ainda assim acessível.

Novamente as garçonetes do restaurante falavam excelente inglês e foram muito simpáticas e receptivas. Já percebi que tirando os comerciantes mais agressivos, a maioria das pessoas é sempre muito educada e receptiva a estrangeiros, fato que me deixou positivamente impressionado.

Depois da excelente refeição fui andando pela rua Frishman até a beira da praia. Aliás, diferente de Amsterdã e Berlim, finalmente um clima mais próximo ao que estou acostumado, na verdade um pouco mais quente do que eu gosto, mais próximo do clima do Rio de Janeiro. E não é para menos já que eu estava à beira do Mediterrâneo. As praias, mesmo a noite, oferecem uma excelente vista e é uma ótima opção para caminhar. E assim como nas outras cidades européias, a sensação de estar seguro novamente me deixou bem mal acostumado.

Meu hotel ficava no centro-leste da cidade, portanto andei em direção oeste para a praia e depois peguei uma paralela chamada Bograshov para retornar, passando pelo Dizengoff Center. Diferente das outras visitas, esta cidade tem diversos Shopping Centers, uma ótima opção se estiver procurando por ar condicionado nesta cidade mediterrânea. De lá subi até a Sderot e rapidamente já estava de volta à Weizmann. Uma ótima noite.

A cidade de Tel-Aviv, novamente é uma cidade minúscula. Tem meros 52 km2, a área urbana tem 176 km2. Ela é a segunda cidade mais populosa de Israel e mesmo assim não tem mais que 406 mil pessoas. A cidade mais populosa é Jerusalém, com pouco mais de 800 mil pessoas e uma área de 125 km2. E não é para menos, o país inteiro ainda tem menos de 8 milhões de pessoas. Como perspectiva se lembrem de São Paulo que tem sozinha mais de 11 milhões de pessoas. Se tiver mais tempo do que eu, recomendo continuar a linha de trem que mencionei antes até a Universidade de Tel Aviv e também ir até Haifa, a terceira cidade mais populosa de Israel, com quase 270 mil pessoas.

Além do famoso Porto de Haifa esta cidade é berço de Pesquisa de Desenvolvimento para empresas como Intel, IBM, Microsoft, Motorola, Google, Yahoo!, e muitas outras de alta tecnologia. Na Universidade de Haifa fica o IBM Haifa Labs. Se Tel-Aviv é São Francisco então Haifa é Palo Alto. Infelizmente não tive tempo de visitar essa cidade, mas certamente está na minha lista para a próxima vez.

A cidade de Tel Aviv na verdade é Tel-Aviv Jaffa. Ela é uma cidade mais ou menos "vertical". Sua história iniciou no sul, com os árabes de Jaffa. Tel Aviv foi fundada pela comunidade judia de Jaffa e logo cresceu mais rápido. No final elas foram fundidas numa única cidade, Tel-Aviv Jaffa. Eu não cheguei a ir até Jaffa, infelizmente, mas dizem que se quiser experimentar um dos melhores humus que já comeu, precisa ir até o restaurante Abu-Hassan. Era um lugar que eu queria ter ido mas também não tive tempo. Fica de recomendação.

Turismo por Jerusalém

O tour que eu escolhi foi de grupo pequeno (business), é mais caro mas mesmo assim por USD 100 compensa. Você definitivamente não quer grupos de mais de 15 pessoas, e os pacotes mais baratos podem comportar 30 ou mais pessoas e aí é extremamente desconfortável. Obviamente em um único dia é impossível ver tudo que Jerusalém tem por isso escolhi o pacote para andar por dentro da cidade antiga, a Velha Jerusalém. O serviço de turismo vai te buscar direto no seu hotel o que é bastante cômodo para quem tem pouco tempo a perder.

Uma coisa que eu não tinha noção mas que vocês já devem ter percebido é como Israel é pequeno. Ir de micro-ônibus de Tel Aviv até Jerusalém é uma viagem que não dura mais que 40 minutos. Sem ter nenhum conhecimento eu imaginava que elas eram distantes (para mim distante é ir de São Paulo ao Rio) mas aqui a viagem é mais como ir de São Paulo a Sorocaba.

Jerusalém, ao contrário do que eu poderia imaginar, também é uma cidade moderna. Tem hotéis muito bonitos, a arquitetura da cidade toda são casas e prédios com pedras claras que dá um tom "creme" à cidade. Ela é razoavelmente arborizada então é um cenário muito bonito. Já o que se chama de Velha Jerusalém é o que está atrás dos antigos muros e é conhecida também como Cidade de Davi. Se você imagina que visitar a Europa é ter um gosto do passado, na Velha Jerusalém estamos falando de outro tipo de passado: do tipo que tem uma história de mais de 3 mil anos. Acho que nenhum lugar parece mais fora do tempo do que essa cidade. O importante aqui não é a religião (e aqui você vai encontrar judeus, cristãos, islãs e muçulmanos), mas sim o "peso histórico" que esse lugar carrega, e História é uma coisa que eu respeito muito.

A primeira grande parada antes de entrar na Velha Jerusalém foi no Monte Scopus, não conheço a história mas parece que foi ponto estratégico durante a Guerra Árabe-Israelense de 1948 e a Guerra de 6 dias de 1967.

Em seguida nos dirigimos para o famoso Monte da Oliveira onde dizem que o messias vai retornar primeiro no fim do mundo. Esse lugar é um enorme cemitério onde judeus vem sendo enterrados há 3 mil anos, tendo mais de 150 mil covas. Paga-se caro para ser enterrado nesse local, onde também se acredita que quando o messias chegar, essas são as pessoas que serão ressucitadas primeiro. Ou algo assim. Se quiser ver o Monte das Oliveiras ao vivo existe até um canal de TV com câmeras apontadas ao Monte das Oliveiras, para capturar o momento que o tal messias retornar. Tem doido pra tudo.

Finalmente, nos dirigimos até a Cidade de Davi e Solomão. Deixamos o micro-ônibus e daqui iríamos a pé. Ao entrar pela segurança da cidade (novamente, revista do que você carrega em bolsas e mochilas), o primeiro lugar que podemos ver é o famigerado Muro das Lamentações. Dizem que em igrejas e sinagogas você tem uma comunicação indireta com o todo poderoso, mas nesse muro é ligação direta, tipo fibra ótica de alta velocidade mesmo, sem intermediários. A área na frente do muro é dividido, uma área grande para homens e uma área menos para mulheres. Ironicamente a área das mulheres é mais cheia que a dos homens. Parece que os homens já não ligam muito para isso, mas as mulheres ainda levam os pedidos mais a sério. Se você já não é judeu e tem as vestimentas corretas, eles tem kits que você pode usar antes de entrar nessa área sagrada.

Eu pessoalmente fiquei só observando e me veio à cabeça o nome em inglês do Muro, chamado de Western Wall, Kotel ou Whaling Wall. Sendo que "whale", enquanto verbo é como "apanhar", "tomar uma sova", mas enquanto substantivo é uma baleia. E ainda quando Twitei que estava visitando o Muro das Lamentações meu caramada Gleicon ainda me respondeu "visitando o Twitter?". Pronto, minha Teoria da Conspiração é que a famosa tela da Baleira (Fail Whale) do Twitteré na verdade inspirado no "Whaling Wall". Verdade ou não, é uma história engraçada para se contar.

Depois disso o guia nos levou mais para dentro da cidade. Sinceramente não consigo lembrar de tudo que ele explicou, especialmente porque me faltam as bases históricas para conectar os pontos. Mas passamos por diversas vielas cheias de comerciantes. Lembram daqueles filmes que mostram cidades árabes ou do oriente médio cheio de comerciantes? É tipo isso mesmo. Aliás, por recomendação do guia, tome muito cuidado ao fazer compras nessa região, como disse antes esses comerciantes de rua obviamente sabem que você é um turista ingênuo e farão de tudo para te vender as coisas mais caro do que são. Se decidir comprar pechinche o quanto puder, lembre de estar sempre convertendo de cabeça de Shekels para Reais, mais ou menos divida o preço em Shekels por 2 e terá em Reais. Por exemplo, uma garrafa de água custando 10 Shekels (5 Reais) obviamente está muito caro.

No meio da cidade paramos para almoçar, onde pude comer um excelente Shawarma. E também entramos numa joalheria (dizem que ela é certificada para poder vender ouro, no mercado de rua vão te vender bijuteria como ouro). Mas cuidado, os preços são bastante salgados, é para quem tem muito dinheiro mesmo. E a lábia dos vendedores é ligeira "é baratinho, leva esse crucifixo que é só USD 1.000 e eu te dou a cordinha de ouro por meros USD 100, pechincha." De jeito nenhum.

Finalmente chegamos à Via Dolorosa, onde dizem que Jesus deu seus últimos passos antes de ser crucificado. Essa rua possui nove das catorze estações da cruz, as cinco últimas na Basílica do Santo Sepúlcro, que foi nossa próxima parada. Se eu entendi o que a Wikipedia explica, conhecemos o termo "Via Crucis" que é o trajeto que Jesus fez. Via Sacra é o exercício da reprodução que os fiéis fazem desse trajeto. O trajeto em si foi feita na rua cujo nome é Via Dolorosa. Os passos desse trajeto são as Estações da Cruz, reproduzida em toda Igreja Católica. Vivendo e aprendendo.

A Basílica do Santo Sepúlcroé o lugar mais sagrado do cristianismo, dizem que mais ainda do que a Igreja de São Pedro em Roma. Esse é o lugar onde Jesus foi crucificado, sepultado e onde ressucitou no Domingo de Páscoa. As áreas de interesse começam logo que se entra, à direita, com o Calvário ou Gólgota, uma elevação de 5 metros onde dizem que Jesus foi crucificado.

Na entrada, logo à frente está a tal Pedra da Unção, a pedra onde dizem que o corpo de Jesus foi preparado para ser enterrado. Muita gente ficava bem emocionada tocando essa pedra, imagino que é porque imaginam que o corpo de Cristo efetivamente descansou sobre essa pedra antes de ser enterrado. É uma grande pedra.

Finalmente, andando mais à esquerda está a edícula do Santo Sepúlcro propriamente dito, onde tecnicamente o Jesus foi enterrado. Tinha uma fila enorme não entendi bem para que. A Basílica em si é enorme, tem mais do que eu descrevi, um andar subterrâneo. Em algum lugar por ali dizem que foi enterrado também José de Arimatéia, mas vou deixar isso para quem entende mais dos contos da Bíblia.

Saindo da Basílica fomos até o fim do percurso, no caminho passamos por um tal Muro de Solomão, mas não entendi bem sua história. A única coisa que sei é que ela está obviamente em pedaços e podemos caminhar sobre a linha por onde ela passava antes. Provavelmente tem a ver com essa notícia de 2010 sobre a descoberta desse muro. Existem dezenas de escavações por toda cidade.

Saímos da Velha Cidade, voltamos ao micro-ônibus e de lá fomos à nossa última parada e, na minha opinião, a melhor parte do passeio, por uma enorme margem. Fomos visitar o Museu do Holocausto, Yad Vashem. Em primeiro lugar eu completamente ignorava que um lugar como esse existia. Ela é uma enorme área de 180 mil m2, destinada não só a ser um museu de exposição, mas um centro de documentação, pesquisa e educação sobre o Holocausto.

O guia nos avisou que tudo era proibido, comer, fumar, beber, etc, incluindo tirar fotos (de fato, notei funcionários à paisana fiscalizando quem estava tirando fotos). Antes de entrar eu imaginava que passaria rápido e seria somente mais um museu. Tínhamos somente uma hora. Eu pretendia obedecer a norma de não fotografar, mas depois de entrar no museu eu mudei completamente de idéia.

A arquitetura é muito interessante, ela é um zigue-zague que te guia de sala em sala mostrando todos os aspectos da história da Segunda Guerra Mundial da perspectiva dos judeus. Ela conta a história de como Hitler subiu à posição de ditador da Alemanha, como ele começou a invadir os países vizinhos. Principalmente como a ideologia do Nazismo considerava os judeus um problema e a apresentação da sua Solução Final, a criação dos guetos, a transferência para os campos de concentração e o genocídio de 6 milhões de judeus (dos 9 que existiam na Europa na época), sendo 1 milhão de crianças.

Ao final do museu existe a Sala dos Nomes, uma enorme sala em formato cilíndrico com um cone enorme no topo. Ficando abaixo desse cone é possível ver as fotografias de pelo menos 600 judeus mortos. E nas paredes do cilindro estão as Páginas das Testemunhas, uma coleção de mini-biografias dos 6 milhões de mortos que estão sendo coletados com o tempo.

A exposição em si é espetacular, ela te guia por cada episódio do acontecido, através da ordem das salas que você tem que percorrer e dos materiais em exposição que incluem não somente textos, fotos, objetos mas também centenas de horas de áudio e vídeo com testemunhos, documentários, notícias da época. Principalmente nas partes que se falam dos guetos e campos de concentração existem pequenas salas mais isoladas para te fazer assistir vídeos de testemunhos e entrar no clima sombrio e melancólico. O áudio vem de diversas direções, a forma como as coisas estão expostas, tudo contribui para criar uma experiência de imersão.

Lembram da Lista de Schindler? Pois é, está em exposição em Yad Vashem.

Sinceramente, 1 hora é muito pouco tempo. Esse museu exige no mínimo um dia inteiro de dedicação apenas para começar a apreciar tudo que ele tem a oferecer. Mesmo depois que você sai do pavilhão principal, Yad Vashem é uma enorme área com diversos outros prédios e monumentos. Dentre eles estão o Yad Layeled, o memorial das crianças, e a Avenida dos Justos Entre as Nações, com mais de duas mil árvores plantadas em nome de pessoas não judias que se arriscaram para ajudá-las.

Infelizmente tivemos muito pouco tempo, se um dia retornar a Israel, reservarei um dia inteiro dedicado somente a visitar Yad Vashem novamente.

De Volta a Tel Aviv - Startups

O dia foi bem proveitoso, bastante inspirador de certa forma por passar por uma carga tão grande de história de uma só vez. Na volta para Tel Aviv, já no começo da noite, entrei em contato com outra pessoa que fiquei conhecendo apenas via Twitter recentemente, Ben Lang. Quando twitei que vinha para Israel, algumas pessoas no Twitter me falaram sobre o site Mapped in Israel, um completo diretório de Startups, aceleradoras, co-workings, investidores e tudo mais sobre esse mercado. Ela lista atualmente 790 startups em Israel (lembram como em Berlim, que tem metade da população do país de Israel tinha cerca de 330?). Se quiser pesquisar mais sobre o mercado de Israel este é um excelente lugar para começar. Um site menor, que serve para complementar esse é o RoR Israel que lista mais de 50 empresas que utilizam Ruby on Rails em Israel, criada por Boris Dinkevich.

Como o Ben estava com tempo justamente quando meu micro-ônibus estava começando a deixar o grupo em seus hotéis, pedi ao motorista para me deixar no meio do caminho e peguei um táxi até Carlebach 4. Ele estava num pequeno bar-restaurante, sentado numa mesa na rua com seu notebook - aliás, outra coisa impossível de se fazer aqui no Brasil. O Ben é jovem, acho que tem seus 18 anos agora, se mudou dos Estados Unidos com sua família e já é bem conhecido, tem mais de 11 mil seguidores no Facebook, já escreveu para sites conhecidos como Techcrunch e Business Insider. Ele foi muito simpático, me explicou mais sobre o mercado e como acabou de entrar para o exército de Israel por vontade própria, e devo dizer que ele sabe o que está fazendo - mais sobre isso no fim do artigo.

Estava acontecendo algum evento de Startups na região - e segundo ele acontecem vários toda semana - e ele estava matando tempo antes do after party que aconteceria ali por perto. Comemos um bom Falafel de rua e fomos pra um bar-balada numa cobertura, devidamente chamada de "Roof Top", que oferece uma área aberta com excepcional vista para a cidade. Chegamos um pouco cedo, não havia quase ninguém, então ficamos ali conversando um tempo.

Logo pessoas que conheciam o Ben se aproximaram e com isso fiz alguns contatos, incluindo Mayer Reich, da startup Rank Above uma plataforma de sucesso que oferece ferramentas e serviços no domínio de SEO, toda feita usando Ruby e Merb (!). Fiquei de visitá-los no dia seguinte. Também pude brevemente me encontrar com Roy Carthy da Initial Capital, que recentemente iniciou negócios no Brasil também.

Eu tinha acabado de voltar do turismo por Jerusalém e estava bem cansado, então depois de conversar com algumas pessoas por algum tempo decidi fechar o dia e retornar ao hotel para descansar. O dia seguinte também seria corrido.

Meu último dia em Tel Aviv começou com a visita à Rank Above. Não era muito longe, pouco menos de 2 km então decidi ir caminhando em mais um dia quente. Devo dizer que mesmo no calor a cidade é bastante agradável para caminhar, então recomendo se possível.

A Rank Above é uma empresa que já tem 5 anos, o Mayer veio de Nova Iorque e montou uma equipe em Israel. A empresa não deve ter mais que 15 pessoas no total, com meia dúzia de desenvolvedores Ruby. Eles tem um escritório até que espartano mas confortável. Ficamos conversando sobre Ruby, em particular eles estavam interessados na minha opinião sobre migrar de Merb para Rails.

Ao mesmo tempo o Omer me apresentou, de novo via Twitter, ao Vitaly Kushner um programador Ruby ucraniano que se mudou pra Israel faz muitos anos. Ele tem uma pequena consultoria de Rails chamada Astrails. Ele e seu outro sócio Michael Mazyar foram me buscar no escritório da Rank Above para almoçarmos. Fomos comer num restaurante de comida búlgara. Eles me contaram como atuam com Rails faz muitos anos mas mesmo assim ainda não conseguiram crescer. Eles obviamente são muito experientes e sabem disso, o problema que todo bom desenvolvedor tem é delegar para programadores menos experientes, especialmente se você se torna preciosista e o código dos outros sempre é pior que o seu. Por isso, eles são em 6 pessoas dividindo múltiplos projetos por pessoa ao mesmo tempo, o que causa muito estresse e mais medo ainda de escalar. Conversamos bastante sobre o que eu tenho feito em consultoria porque eles ficaram interessados em saber como eu escalei de 2 programadores para mais de 30 em menos de 1 ano. Espero que tenha ajudado.

Nesse fim de tarde eu havia combinado com o Omer que eu participaria de um encontro de usuários Ruby da região chamada Ruby Underground. Algumas semanas antes de iniciar essa viagem toda, eu havia publicado no blog que talvez viria pra Tel Aviv e o Omer foi o primeiro a se manifestar. Ele organizou o encontro na empresa onde trabalha, a suíça Klarna. Eu faria uma palestra sobre a comunidade Ruby Brasileira e as novidades do Rails 4.

Depois do almoço com o Vitaly e o Michael eu ainda tinha algum tempo então pedi para me deixarem no Azrieli Center Mall que era perto do prédio da Klarna. Depois de algum tempo, resolvi ir até o encontro. O prédio da Klarna fica próximo à estação de trem e do Azrieli dava pra ir a pé sem nenhum problema.

A Klarna é uma solução de pagamento para ecommerces, por exemplo, com uma solução onde o cliente recebe o produto antes de realizar o pagamento. O escritório de Tel Aviv é bem amplo, moderno e organizado, com uma área especial para eventos junto à uma cozinha e terraço. Caberia até 100 pessoas sentadas sem problemas.

Acho que havia quase 80 pessoas presentes, e devo dizer que eu estava um pouco nervoso pois seria mais uma palestra que eu terminei durante a viagem e ainda não tinha conseguido testar o tempo, mas acho que consegui passar tudo que queria com clareza no tempo exato de uma hora, um recorde!

Tive a oportunidade de conhecer diversos rubistas, muitos ainda iniciantes durante o encontro e no final do evento fomos todos para um happy hour no pub Lee Bloom. Conversei bastante com Daniel Szmulewicz que além de Rubista e programador experiente, também é filósofo por formação, e eu gosto pouco de filosofia (nah) então dá pra imaginar que a conversa foi bem longe.

Enfim, foi um último dia muito proveitoso até o último minuto. Tive a oportunidade de conhecer mais empresas e entender bem mais sobre esse poderoso mercado Israelense. No dia seguinte infelizmente eu já tinha que retornar. Deixo apenas registrado que a volta por Ben Gurion não é mais fácil que a entrada, novamente com múltiplas etapas de revista - lembra da recomendação de chegar com 3 horas de antecedência? Bem, em Israel isso não é recomendação é obrigação, caso contrário você não embarca. Mesmo com tudo isso, volto ao Brasil com vontade de retornar a Israel o quanto antes. De todos os lugares que visitei nos últimos anos, nenhum lugar me deixou com mais vontade de retornar do que Israel, e para um cara desapegado como eu, isso é muita coisa.

Por que Israel é tão Avançado?

Quero aproveitar esse final para que todos vocês, leitores, pensem nisso: o que faz um país de menos de 8 milhões de pessoas, somente 60 anos de idade (ela declarou sua independência faz pouco tempo), cercada de inimigos em constante estado de guerra, sem recursos naturais, ser a segunda do mundo em startups, atrás apenas dos Estados Unidos? Ou seja, ela está à frente de países maiores, com mais recursos e pacíficos como Japão, India, Coréia, China e muitos outros europeus. Brasil então, está na rabeira da rabeira em comparação.

Por que Israel é tão mais avançada? Essa é a pergunta que os autores Dan Senor e Saul Singer se propuseram a responder no conhecido livro Startup Nation. Eles focam em dois pontos que argumentam ser os principais, o serviço militar mandatório e a imigração. Eu já sabia que o serviço lá era obrigatório mas não tinha parado para pensar no que isso significava. Aqui no Brasil é obrigatório apenas para homens por 1 ano. Em Israel é obrigatório para homens por 3 anos e mulheres por 2 anos. Ou seja, todo mundo no país passou por uma formação no exército muito mais difícil do que em países como o Brasil.

Diferente do que muitos podem imaginar, o exército evoluiu muito da imagem que temos de anedotas e histórias. Os autores argumentam que o Israel Defense Force (IDF) ajuda a criar bons empreendedores com reais capacidades e, por causa do tempo de serviço, também com muitos contatos. A IDF dá experiência a esses jovens para exercitar responsabilidade num ambiente onde a hierarquia não é tão rígida, onde criatividade e e inteligência são altamente valorizados. Soldados da IDF recebem poucas ordens vindas de cima para baixo e são incentivados a improvisar, mesmo que signifique quebrar algumas regras. Soldados de patentes mais baixas chamam seus superiores pelo primeiro nome, e se eles vêem seus superiores fazendo algo errado eles devem dizer isso. (Aliás, conceito que tento explicar há tempos e parece tão difícil de se fazer entender.)

Olhando meus pares no mundo em geral e principalmente no Brasil, sinto que uma estrutura como o IDF proporciona está em grande falta. Hoje os garotos são muito molengas, choram por qualquer coisa, fazem birra, fazem cortina de fumaça reclamando para esconder a própria incompetência, não sabem receber críticas, tem medo de cara feia, tem medo de dizer o que estão pensando, são vergonhosamente covardes só falando mal pelas costas achando que ninguém está prestando atenção, enfim, uma grande decepção. Muitos reclamam por picuinha em trabalhos de 3 meses. Esses adolescentes israelenses passam 3 anos - 3 anos! - servindo no exército.

Difícil dizer que esse é o fator fundamental, mas que certamente faz uma diferença de ordens de grandeza com certeza faz. Esses garotos de Israel, quando terminam seu serviço no IDF certamente saem muito mais próximos a se tornarem adultos de verdade. Os garotos daqui, por sua vez, estão chegando aos 30 anos com mentalidade de adolescente mimado, acostumado a receber tudo de mão beijada. É lamentável.

Some a isso alguns outros fatores que já mencionei durante o artigo: todos falam inglês fluentemente. No Brasil não dá pra dizer que alguém fala inglês decentemente. Além disso, ao contrário do Brasil que tem um enorme mercado consumidor interno, Israel só tem 8 milhões de pessoas, é muito pouco, ou seja, toda startup lá precisa pensar desde o dia 1 em ser uma aplicação web ou mobile já internacionalizada e focada no mercado exterior.

Finalmente, outro fato: empresas grandes como IBM, Motorola, Intel abrem escritórios em países como Índia ou Brasil para terceirização de mão de obra barata. Na cidade de Haifa, que mencionei antes, eles abriram centros de R&D, Pesquisa e Desenvolvimento, coisa que não vemos no Brasil. São só alguns fatores. Determinantes? Não sei, mas são muitos fatores derivados da necessidade de sobrevivência num ambiente hostil. Isso sempre evolui uma população muito mais do que abundância de recursos e muita paz.

Lembram que o jovem Ben Lang me disse que decidiu entrar no IDF voluntariamente? (Como estrangeiro, ele não era obrigado.) Acho que ele também leu Startup Nation. Antes mesmo de entrar pro IDF ele já demonstrou ser mais adulto com 18 anos do que muitos de 25 ou mais que eu conheço. Fiquei bastante impressionado ao ouvir isso. E imaginar que todas as pessoas à minha volta, nas empresas que visitei, no encontro de Ruby, eram todos com formação militar de 3 anos, eu não conseguia me conter mas ficar empolgado com as possibilidades e potencial que eles tem comparado às comunidades que eu estou acostumado.

Esses são pessoas de ação e não de dramas. Enquanto os meninos estão fazendo birra, eles estão construindo a segunda maior economia de startups do mundo. Louvável.

This year I had the opportunity to visit 4 fantastic cities across the USA and Europe/Asia. It all started in this first post. There were several goals including getting to know those cities personally as I've never been there before, then meet great people and great companies, and finally try to understand more about this fledgeling new tech startup world.

I wrote about my journey in 6 articles, originally in Brazilian Portuguese. You can use Google Translate that's available in all of them, I'm curious to see if they work well enough. The journey starts in September 2012 and ends in October 2012. Here are the articles:

• Trip to San Francisco - Part 1 - Techcrunch Disrupt
• Trip to San Francisco - Part 2 - Visiting Companies

• Trip to San Francisco - Part 3 - People and Tourism

• Trip to Europe - Part 1 - Amsterdam, Netherlands

• Trip to Europe - Part 2 - Berlin, Germany
• Trip to Europe - Part 3 - Tel-Aviv, Israel

PS: I was in doubt about considering Israel in "Europe", seems like it's actually Asia but it's considered in Europe for sports :-)

I also posted hundreds of photos organized in Facebook Albums that you can access here:

• San Francisco
• Amsterdam
• Berlin
• Tel-Aviv/Jerusalem

Finally, I've documented my every move while there through Instagram, you can see them all here

Enjoy!

Pra constar, esse artigo não tem versão alternativa ao TL;DR :-)

Em 2007 eu escrevi dois artigos sobre "consultorias" entitulados Um Desabafo e Um Desabafo II. Dêem uma lida para entender o contexto. Eu gosto de reler meus artigos para ver se eu ainda escreveria a mesma coisa. O primeiro artigo é um conjunto de dicas para que um consultor melhore a si mesmo. No segundo artigo descrevo o maior pecado numa consultoria. Eu escrevi os artigos quando já tinha alguns anos em diferentes empresas, em diferentes indústrias e a mais recente tinha sido anos em consultoria.

O primeiro artigo é muito simples e o que eu recomendei na época é o que ainda recomendo hoje: melhoria contínua. Dois pontos do artigo original:

Não adianta apenas ficar mudando de emprego, por dois motivos: não necessariamente um novo projeto vai lhe trazer coisas novas (as chances de ser apenas mais um cadastro, são grandes). E deixar para aprender apenas quando já se precisa, em um projeto, já é tarde demais. Você será ultrapassado por outros que sabem o que você já deveria saber. É obrigação de um bom programador saber das coisas antes, não depois: depois que um produto de péssima qualidade entra em produção o resultado será ruim tanto para seu cliente quanto para sua reputação.

Para de reclamar. Reclamar cria uma mentalidade negativa, irrita os outros e não leva a nenhuma solução. Reclamar é mais uma desculpa, um barulho que esconde o verdadeiro problema. O problema é esse: você está reclamando do trabalho, do projeto, do chefe mas na realidade gostaria de estar reclamando de si mesmo. Reclamar é apenas a externalização da frustração de ser como é e não conseguir ser mais. E isso não é uma incapacidade física, é apenas preguiça mental.

Para mim, a grande vantagem de se trabalhar numa consultoria em vez de ficar numa única empresa? É estar exposto a diferentes projetos, diferentes empresas, diferentes pessoas e diferentes formas de lidar com cada tipo de problema.

Veja por esse lado: um consultor é visto como um "pária". O funcionário de uma empresa, em particular, não tem motivos pra gostar de um consultor porque ele é chamado geralmente pra fazer seu serviço, em menos tempo, com melhor qualidade e ganhando mais. Na prática, se o consultor é bem sucedido é porque os funcionários estavam fazendo um péssimo trabalho antes. Não é sempre assim, mas essa é a visão geral.

Do ponto de vista do consultor, é um trabalho difícil porque ele precisa se inserir num contexto de empresa que o funcionário teve meses pra se acostumar, descobrir o que precisa ser feito e porque ele não aconteceu, fazer mais que todo mundo com menos autoridade e menos conhecimento. Um consultor é efetivamente como um mercenário, somos chamados para fazer o trabalho que ninguém mais conseguiu.

Obs: já antecipando a liberdade de interpretação da metáfora "mercenário", já esclareço que quero dizer "aquele que é chamado pra resolver o problema que ninguém mais conseguiu" e não "ser pago pra fazer qualquer coisa que pediram, inclusive a coisa errada". Esclarecida a metáfora, vamos em frente.

É disso que gosto. E por isso um bom consultor não pode cometer o erro de regredir à mente de um funcionário-padrão, da mesma forma que um mercenário não pode querer se comparar com o soldado raso, ele precisa ser o soldado e o general. Quando eu era consultor o que mais me agradava era ter consciência dessa posição, de entrar num cliente sabendo que eu precisaria resolver os problemas que os internos não resolveriam. Sentir essa pressão de andar na linha de frente sem saber o que iria enfrentar no meio da selva. Poder conversar com os subalternos, com os chefes deles, com os departamentos ao redor e conseguir mapear o terreno para descobrir o melhor caminho entre os campos minados. Poder discordar diretamente do meu cliente ao mesmo tempo que oferecia uma solução melhor que ninguém tinha pensado. Esse é o exercício de todo bom consultor.

O segundo artigo, Um Desabafo II, é centrado num problema que já vi muitas consultorias pequenas e médias terem: má saúde financeira. Esse é "O" principal problema:

Quando uma consultoria dá sinais de problemas financeiros, é o sinal vermelho: pule fora o quanto antes. Não pense duas vezes. Se o cliente resolve dar chilique, se o cliente resolve atrasar a fatura, se o cliente resolve enrolar, nada disso é problema do consultor: é justamente para isso que pagamos esse seguro à consultoria: para que ela se coloque entre o cliente e você. O consultor, trabalhando corretamente as horas apontadas, tem direito de receber nas datas que constam nos devidos contratos.

Uma grande consultoria, de nome estabelecido há pelo menos uma década, é capaz de ter um preço de venda (taxa para cliente) até 5 vezes maior que o preço de compra (taxa pro consultor), ou mais. Mas na maior parte do mercado isso é a exceção. No meu caso o máximo é 50% da taxa de compra. E do faturamento bruto total quase 2/3 é a folha de pagamento. Essa é a realidade do mercado de serviços. Com uma margem apertada - sem contar os outros custos operacionais e investimentos - o controle comercial e financeiro é fundamental. Você sabe que uma consultoria é competente quando não precisou reclamar do seu pagamento nem uma única vez, sabendo que é um setor de mercado onde os clientes nunca pagam em dia.

Existem diversas vantagens para um consultor trabalhar junto com uma boa consultoria e não como autônomo ou freelancer. Ser compensado nas datas corretas é uma das principais. Porque se for para ser pago de forma instável ou às vezes sofrer calote, a opção de freelancer volta a ficar atraente. Por isso quando decidi montar minha consultoria essa foi uma das principais preocupações e uma regra nunca violada foi: todo mundo recebe o combinado em contrato nas datas estipuladas.

E depois de mais de 1 ano, um dos períodos mais instáveis numa empresa de serviços, essa regra prevaleceu intacta.

Mas não é só isso que uma boa consultoria oferece. A palavra "consultoria" é um grande guarda-chuva, infelizmente distorcida pelo seu uso indevido. Eu divido a definição em pelo menos 3 grandes nichos. Primeiro as agências: nesse caso a consultoria é especificamente de marketing e publicidade - quando muito - e a parte de software normalmente é de baixo valor no orçamento total, às vezes entregue mais como um "brinde", e a execução é de baixa qualidade porque as peças são voláteis, temporárias e não precisam durar muito tempo. Por isso que qualquer coisa diferente disso feita num estilo de agência dificilmente funciona bem.

O segundo nicho são as famigeradas fábricas de software, e nesse caso a grande maioria das pessoas não é "consultor", é apenas "executor procedural" mesmo. Isso porque uma característica fundamental não existe: contato direto entre o programador e o cliente. Ele trabalha num processo definido, onde recebe ordens de serviço, precisa cumprir uma quantidade fixa de horas e sua única tarefa é cumprir as tarefas que já foram detalhadamente estabelecidas, em papéis fixos. Existem variações, mas no geral fábricas são dirigidas por um processo que tenta ser determinístico, e para isso os tipos de software costumam ser limitados: cadastros e formulários e fluxos de formulários, especialmente em intranets de empresas ou integrações com backoffice.

O terceiro nicho, as "consultorias", onde existem de fato "consultores", são raros. Pressupõe-se que o tipo de profissional numa consultoria é superior à de uma agência ou uma fábrica.

Para entender esse nicho, precisamos entender qual a desvantagem de ser um freelancer. Um freelancer precisa ser uma mini-consultoria, ele precisa fazer seu próprio marketing pessoal, estabelecer relacionamentos e network comercial robustos, saber negociar corretamente valores, escopos, prazos, fechar bons contratos (e a maioria dos freelancers fecha verbalmente porque não sabe como funcionam contratos), emitir notas fiscais, faturas, etc. Ah sim, e no meio disso ele ainda precisa programar. A compensação dele tende a ser maior por causa desse overhead, mas também por esse motivo sua produtividade e qualidade tendem a ser menores. E não executando esse overhead corretamente, significa negócios de baixa confiança, fechados verbalmente - como nunca se deve fazer.

Uma boa consultoria retira esse overhead e o faz de maneira superior. É uma troca de serviços, meu conceito ideal de "trocas voluntárias por mútuo benefício", porque a alternativa de não estar numa consultoria é atuar como freelancer ou virar funcionário mesmo numa empresa cujo core-business não necessariamente é software (mesmo uma tech startup eu diria que nem sempre o core-business é o software, na verdade eu diria que em raras vezes, reflitam). "Serviços" um mercado livre onde as trocas são essencialmente voluntárias: uma troca de serviços por compensação, como deve ser.

Existem empresas onde software é o core-business, como em consultorias de software. E outras onde ela não é, como empresas de comércio, onde o software é acessório e não negócio principal. Ou empresas de hospedagem onde o core é indiscutivelmente a infraestrutura e operações.

Esse é outro aspecto que aprendi sendo consultor: identificar o core-business. Se uma empresa considera o software como "lucro" é lá que ela vai investir, é onde existe futuro. Se ela for considerada "custo", é onde tende-se a não investir, a substituir o que se tem por alternativas mais baratas. E isso faz todo sentido. Porque investir em software numa empresa onde o core é vendas? Ou onde o core é finanças? Software e programador são custos assim como licenças de Word ou Excel, não é diferente disso. Se o objetivo é crescer profissionalmente, deveria-se procurar empresas onde software faz parte do core. Se quiser um emprego tranquilo, poucas atividades, rotina - porém com o risco invisível de se tornar rapidamente obsoleto e sujeito a cortes - procure emprego em empresas onde o core não é software.

Voltando à diferença com freelancer, um consultor não precisa se preocupar com marketing, com negociação de contratos, com áreas jurídicas, faturamento, fluxo de caixa, RH. Como um bom mercenário, ele recebe uma missão e deve cumprí-la. Mais do que isso, uma consultoria é capaz de fechar os projetos que jamais seriam acessíveis a um freelancer, é capaz de oferecer a segurança de entrega que um freelancer não tem como oferecer. Além disso uma boa consultoria não termina contrato com seu consultor porque um projeto acabou, é outra coisa que um freelancer tem problemas: ao acabar um projeto existe um ciclo de vendas que costuma levar tempo. Um bom projeto pode levar de 1 a até 2 meses de negociação para se fechar, do contato inicial, propostas e ajustes, até a assinatura do contrato final. Um consultor não precisa se preocupar com isso, basta se preocupar em entregar os projetos com consistência e qualidade que a consultoria se encarrega do overhead de manter um pipeline saudável de projetos sempre entrando.

Agora esse é o ponto chave: "como um mercenário". Essa é a parte mais indefinida do modelo. Eu acredito que um bom consultor não precise de um "chefe operacional", o tradicional "gerente", que define as ordens de serviço, assume a comunicação com o cliente, faz a politicagem na empresa e diz o que cada "funcionário" deve fazer. Claro, existem consultores sêniores e júniores e os júniores sempre vão se espelhar e aprender com os sêniores, mas isso não os torna necessariamente seus "chefes". Um bom "consultor" é como um bom "mercenário", ou ele sabe o que precisa ser feito, ou vai dar um jeito de descobrir como fazer - da maneira correta.

"Autonomia"é a palavra chave que todo mundo aprendeu a repetir que nem um relógio cuco. Todo mundo só se lembra da parte "liberdade" da palavra, mas convenientemente esquecem da parte "responsabilidade".

"Ah, mas eu sou responsável". Não, não é. Seu nome não está na formação societária da empresa, onde caso a empresa tenha prejuízo, vá à falência, tenha que lidar com suas dívidas, você também precise pagar junto. Como um consultor contratado, não existe esse risco. Portanto, legalmente, você nunca será responsável, até se tornar sócio - que é uma possibilidade real para quem se torna um excelente sênior, uma possibilidade que existe na minha empresa e já foi exercida recentemente com a entrada de 2 novos sócios.

Portanto, se a consultoria lhe dá a "liberdade" de lidar com um projeto da forma como um "consultor" precisa, sem intermediários, sem um chefe operacional, sem uma coleira curta, é porque existe uma confiança muito maior do que qualquer outra empresa jamais daria a um funcionário. Porque se alguma coisa der errado, o consultor tem zero riscos, a consultoria arca com 100% de todos os riscos. E esse é outro fator crucial que alguns não entendem: é como comprar seguros, você andaria com um carro novo sem seguros? Essa é outra função da consultoria, ser o seguro do consultor onde ele pode treinar em projetos onde tecnicamente não tem "responsabilidade" e ainda adquirir conhecimento, capacidades, networking, e com zero riscos.

Era o que eu mais gostava na consultoria onde eu trabalhei entre 2002 e 2007. Eu entrei lá como um programador júnior, praticamente um trainée, mesmo depois de já ter pelo menos 5 anos anteriores de experiência, para mim era tudo novo e por isso era voltar alguns passos pra trás para aprender. E eu aprendi. Em alguns projetos o desafio era puramente técnico, implementar software em plataformas, ferramentas ou linguagens que nunca tinha usado antes. Em outros projetos o desafio era coordenar o trabalho com meus colegas da melhor maneira possível. Em outros, o desafio era se comunicar com o cliente para descobrir o que ele precisava e executar a melhor solução. Finalmente o desafio passou a ser vender, convencer o cliente da solução correta.

Nunca tive um cargo de "gerente", "pré-venda", "arquiteto", mas atuei em todas essas posições, alternando de projeto em projeto de acordo com o que a situação mais precisava. Num momento eu era o único desenvolvedor alocado por um curto período pra resolver um problema técnico que ninguém conseguia. No outro eu era quem estava montando uma equipe de 10 pessoas, contratando e coordenando. Em todas elas eu fazia o que eu sabia que deveria fazer: resolver problemas. Porque um consultor que cria problemas não é um consultor, é apenas mais um funcionário.

A compensação de um consultor também é diferente de um funcionário. Parte de porque funcionários crescem mais devagar é porque sua compensação aumenta automaticamente quase que independente de sua performance individual. Mesmo as empresas mais bem equipadas, com avaliações formais e tudo mais, sempre vai estar à mercê dos que em vez de trabalhar em prol do crescimento, trabalha em prol de descobrir buracos no sistema para trabalhar menos. Perfil de funcionário público, pejorativamente. Os aumentos anuais vem automaticamente, trocas de cargos programadas, enfim, um ambiente ruim para quem busca crescimento profissional. Um consultor, assim como um freelancer, cresce por performance, por atuação e por quanto mais os próprios clientes entendem que o consultor merece mais. Cansei de conhecer excelentes consultores que, quando mudavam de consultoria, o cliente ia junto com ele por causa da performance excepcional. Hoje eu não vejo mais isso, só ex-funcionários anti-éticos tentando negociar com o cliente da consultoria por fora, apenas no discurso. E que bom cliente cai somente na lábia de um ex-funcionário que claramente não entrega resultados?

O maior problema numa consultoria, é quando um consultor tende a regredir ao estágio de funcionário-padrão. O sintoma: em vez de estar buscando resultados, está buscando desculpas para não executar seu trabalho como deveria. Existe uma grande diferença entre quem reclama e continua entregando resultados bons e consistentes - que é o que ele se propôs ao assinar o contrato de serviços com a consultoria - e quem reclama e entrega cada vez menos e com baixa qualidade - tecnicamente já indo contra o que combinou quando foi contratado. Especialmente quando se inicia movimentos de "sindicalização" (entre aspas, pejorativo, porque sindicalizar num mercado não monopolizado nem cartelizado não faz sentido), é aquele que produz pouco e começa a agitar as pessoas ao redor para criar "movimentos", a estratégia de criar cortinas de fumaça para tirar a atenção de si; onde se começa a espalhar calúnias, injúrias e difamação sobre os colegas, os clientes e a empresa onde trabalha. É fácil identificar, é sempre aquele que quer "falar por você, pelo bem do grupo."

Exatamente por isso toda consultoria tem uma taxa de turnover mais alto que empresas normais. E elas precisam ter. É o dilema de toda consultoria. Entendendo que empresas de serviço tem seu capital intelectual nas pessoas. Desligar um funcionário, ainda mais um consultor, é perder um ativo importante de trabalho, relacionamento e tudo mais. Por isso mesmo quando uma empresa de serviços desliga pessoas, é uma estratégia consciente cujo único objetivo é assumir um erro (de contratação) e dar um passo pra trás pra dar dois pra frente rapidamente. Parte disso eu descrevi no artigo Net Negative Producing Programmer.

A única situação onde existem demissões que prejudicam uma empresa é quando ela já apresentou sinais de fraqueza financeira, na forma de atraso de salários. De qualquer forma, nem todos nasceram ou querem ser "consultores", e isso alguns só descobrem com o tempo, tudo é uma questão de perspectiva. Para começar, um bom consultor sabe falar por si só, não precisa de intermediários. Também deveria saber que todo mundo conhece todo mundo nesse mercado. Reputação e credibilidade são moedas de troca. Basta pensar: que tipo de empresa gostaria de contratar alguém que difama as empresas anteriores por onde passou?

Algumas vezes um consultor não compreende as vantagens da sua posição. Mais autonomia sempre vem com mais responsabilidade, e mais responsabilidade sempre significa mais desafios e mais dificuldades. Todos pedem "quero mais desafios", mas poucos são os que assumem esses desafios quando eles aparecem dizendo "deixa que eu resolvo". Muitos procuram um trabalho de "funcionário", no sentido de deferir as responsabilidades (o famoso "eu só trabalho aqui"), e tecnicamente não há problema nisso, nem todos nasceram pra se tornar solucionadores de problemas. Alguns preferem trabalhar numa coisa só, se relacionar com um grupo menor de pessoas por um período mais longo de tempo, limitar as perspectivas porque não tem vontade de cultivar - e manter, porque não basta só conhecer - um grande networking, sentir pelo menos uma "falsa ilusão" de "estabilidade" - palavra que perdeu sentido nos anos 90 depois dos movimentos de outsourcing e globalização. Ou então uma "falsa ilusão" de "propósito", aderir a uma "idéia".

Posso fazer um artigo inteiro sobre "aderir a idéias ou ideologias", mas resumo em dizer que na maior parte é uma falsa expectativa por falta de experiência e exposição a uma perspectiva maior. Como disse antes, a vantagem de uma consultoria é possibilitar esse tempo de exposição a tipos diferentes de idéias, de pessoas, de situações e perspectivas que serve para aparar as arestas grosseiras das ilusões, nos ensinando como funciona o mundo real. Porém existe esse fator incômodo chamado "tempo", e a maioria dos jovens hoje cada vez mais tem menos paciência e são mais imediatistas do que eu era no meu tempo. E a ironia é que meus sêniors na minha época me chamavam de impaciente, e mesmo assim pra mim sempre foi natural dar um passo pra trás pra andar dois pra frente.

Sobre quem quer abrir seu próprio negócio, muitos tentam se justificar com frases como "vou trabalhar por mim e não pelos outros." Essa frase é uma enorme falsa premissa. Na prática mesmo você "nunca" trabalhou "pelos outros". Alguma vez você já trabalhou de graça? Sem compensação nenhuma? Se você recebia uma compensação, um pagamento, então por definição você trabalhava para você mesmo, trocando sua capacidade e qualidade de serviço por dinheiro. Quando abrir sua própria empresa, novamente vai trocar sua capacidade e qualidade de serviço por dinheiro. Quanto mais cedo e sem experiência fizer isso proporcionalmente maior será as chances de não dar certo. Não deveria ser uma frase difícil de entender, mas novamente compreensão vem com conhecimento e experiência, não com imprudência.

E o que define uma "consultoria" para mim? Filosoficamente eu gosto de pensar nela como uma "meta-empresa", uma empresa que tem partes de outras empresas e precisa ser melhor do que elas. Não quer dizer que sempre será melhor, mas sim que essa é a "missão" a ser continuamente perseguida. Uma carreira em geral é exatamente isso mas ser um consultor é assumir essa missão mais explicitamente.

No fim meu objetivo sempre foi não repetir o que descrevi no meu artigo de Desabafo de 2007: constituir uma empresa financeiramente saudável, conquistar clientes e fechar contratos que um freelancer não conseguiria, com segurança para ambas as partes, criar uma rotina que não exige trabalhar mais que 8 horas por dia e 5 dias por semana, criar equipes em forma de células exclusivas pra cada cliente sem a intermediação de um "chefe operacional", dando a oportunidade de cada consultor de aprender todas as funções não-técnicas que mencionei acima.

2012 foi um ano de aprendizado e experimentação, com muito mais problemas do que eu poderia antecipar, mas felizmente meus anos de consultoria me deram a fundação para que esse problemas fossem encerrados. Honestamente não consigo imaginar eu mesmo, em 2002 - quando comecei em consultoria - conseguindo lidar com as mesmas situações de hoje e tomando as mesmas decisões difíceis.

Se eu tivesse aberto uma consultoria em 2002 - ou qualquer empresa - eu teria fechado, a não ser que tivesse "sorte". Mas, apostar em jogos de azar não é o que faz um bom consultor.

Feliz Ano Novo! Nos vemos em 2013.

Atualização 15/01: Este é outro artigo Why 2012 was the best year ever dizendo a mesma coisa: estamos muito melhor hoje do que em qualquer outro momento do passado. Por que parece que não? Porque muita gente alarmista diz o contrário. E por que eles espalham que o mundo está pior? Óbvio, para que elas possam se sentir "heróis" de fazer "alguma coisa", para elas te fazerem sentir pior por não fazer como elas. Claro, sempre devemos estar melhorando mas não às custas de alarmismo irracional e pânico.

Resolvi começar este ano de 2013 com um artigo que espero que ressoe como uma mensagem positiva para iniciar bem este ano. A mensagem é simples:

O mundo hoje é bom, muito bom, e está ficando cada vez melhor.

Por outro lado fico frustrado toda vez que vejo gente teoricamente "estudada" que prefere acreditar que o mundo está piorando, que estamos pior hoje do que estávamos ontem. Hoje somos "impessoais", não brincamos mais na rua, não temos mais solidariedade, queimamos nossas florestas, todas as corporações são vilãs, o povo sofre mais.

Deixe-me dizer que eu, respeitosamente, discordo de todas essas e todas as outras idéias de que estamos piorando. Um dos motivos simbólicos deste artigo hoje é porque passamos por 2012, uma das últimas profecias conhecidas de "Fim dos Tempos" e passamos por ela como se não fosse nada (aliás, nunca foi nada mesmo).

É claro, qualquer um que lê as notícias sabe que temos metrópoles cada vez mais superlotadas, surtos de violência acontecendo o tempo todo em várias partes do mundo, ainda temos diversas guerras acontecendo no Oriente Médio, intolerância religiosa e terrorismo, desastres naturais que "parecem" resultado do famigerado "Aquecimento Global".

Tudo isso verdade. Nada disso é sintoma algum de que o mundo está piorando.

O Mundo está melhor

A despeito de todas as profecias cataclísmicas, vou resumir rapidamente: o mundo é melhor hoje do que já foi 50 anos atrás, 100 anos atrás ou milênia atrás. Felizmente existe gente de ciência, fazendo pesquisa e trabalho sério, que conseguiu acumular dados durante anos e anos e hoje temos como comparar ítem a ítem. Uma dessas organizações é a Gapminder que disponibiliza todos esses dados para vocês podem ver com os próprios olhos.

Recomendo assistir as palestras no TED de Hans Rosling interpretando esses dados. Ele vai demonstrar como nas últimas décadas nós de fato aumentamos a expectativa de vida da maioria das pessoas do mundo, melhoramos a qualidade de vida, diminuímos drasticamente os níveis de pobreza, diminuímos a malnutrição, diminuímos as diferenças. Em resumo, a grande maioria das pessoas hoje vive melhor, com mais conforto e por mais tempo. A violência também está diminuindo como mostra essa palestra do Steven Pinker pro TED. O livro Abundance de Peter H. Diamandis também vai lhe dar mais dados dessa nossa era de abundância.

E mesmo o tão temido Aquecimento Global é constantemente questionado. Muitos cientistas não estão convencidos com os dados que temos. E não é importante se o Aquecimento Global é "real", claramente existe gente ganhando muito dinheiro e notoriedade a partir do "medo" causado por esse possível fenômeno natural. Assista ao documentário Cool It onde o pesquisador Bjorn Lomborg desmistificará cada um dos ítens que você - leitor deste blog - certamente não parou para pensar até agora.

Exemplo: se o protocolo de Kyoto tivesse tido sucesso como os lobistas queriam, ela apenas diminuiria a temperatura do mundo em 0.008 graus Fahrenheit até o ano de 2100! E se a política climática da União Européia diminuiria a temperatura em somente 0.1 graus Fahrenheit ao custo de ridículos USD 250 bilhões anualmente pelo próximo século! Com metade desse dinheiro poderíamos acabar com a pobreza, a fome e as doenças do mundo.

Mesmo se todo mundo dos Estados Unidos passasse a dirigir Prius, isso não colaboraria com 0.5% do carbono que tecnicamente deveria ser cortado até o meio do século. E mesmo se todo mundo nos Estados Unidos passassem a usar somente lâmpadas que economizam energia, isso não colaboraria com 0.2% do carbono a ser cortado.

O comediante George Carlin foi quem explicou isso da forma mais clara que já vi:

Estão entendendo?

A Quem isso Beneficia?

Nenhum "pequeno ato", como reciclar uma latinha de alumínio, individualmente hoje faz muita diferença - não se preocupe, também não faz mal por si só. O que realmente faz a diferença são os avanços contínuos da ciência. Foi a experimentação disciplinada e acúmulo de conhecimento que um dia nos levou à agricultura, eliminando a possibilidade de fome com a superpopulação do mundo - coisa que vem regredindo com modas como "comida orgânica", que nega anos de evolução da tecnologia agrônoma que garantiu que nossa geração existisse.

Agora a razão desse artigo é questionar o óbvio: a quem tudo isso beneficia? A resposta que parece mais óbvia são as grandes corporações que sabem tirar vantagem financeira disso. Mas eles não são o problema. O problema são as pessoas que tornam isso fácil pras corporações, transformando todas essas discussões em julgamentos morais.

Hoje em dia se eu digo que não ajudo nenhuma causa "social" eu sou culpado de alguma forma pela desgraça de alguém. Uma história que me perturba até hoje foi contada por um amigo meu que respeito muito. Me contou como ele, que é um empresário bem sucedido, se sente um pouco culpado por ter mais do que os outros. Por isso, quando pode, ele oferece esmola e coisas do tipo. Um dia, se me lembro direito, um desses mendigos esnobou essa esmola. E esse meu amigo não sabia se podia se sentir frustrado como estava se sentindo.

Essa é minha longa discussão sobre os Direitos do Homem. E para deixar bem claro vou dizer em todas as palavras: eu não tenho nenhuma obrigação de ajudar ninguém, da mesma forma como ninguém tem nenhuma obrigação de me ajudar.

A palavra-chave aqui é "obrigação". Eu sempre tenho a escolha de ajudar ou não, mas nunca a obrigação. Exercer essa escolha é uma opção individual que não deve ser julgada por ninguém.

O mundo é simples: tudo aquilo que eu produzi, pelo meu esforço, é meu e de mais ninguém. Se eu quiser doar a alguém, é uma escolha minha. Se eu quiser jogar fora, é outra escolha absolutamente válida minha. E ninguém pode ter direito a algo meu, e ninguém pode julgar o que faço com algo meu. A recíproca é verdadeira: eu nunca terei direito a nada de ninguém de graça, e nunca devo julgar o que os outros fazem com suas próprias posses. É simples.

Esmola e doação é a mesma coisa. Eu darei a quem quiser, quando quiser e se quiser. E não julgo ninguém que doe ou que não doe. Agora, me deixa muito irritado alguém ter a audácia de achar que pode me julgar pelo que eu faço com algo que é inteiramente meu. Volte à minha história: porque esse meu amigo precisa se sentir "culpado" por algo que ele não tem culpa? Tudo que ele ganhou foi pelo próprio esforço e suor, é dele. Mais do que isso, o trabalho dele possibilitou muitos empregos, possibilitou inclusive que outras empresas existissem, gerando riqueza indireta a muita gente. Porque ele precisa se sentir culpado por não dar de graça algo que é dele?

Essa é a prostituição da mente que pessoas que trabalham sofrem diariamente. Quanto mais trabalham, quanto mais se esforçam, quanto mais ganham, proporcionalmente mais se sentem culpados, mais se sentem julgados pelos outros. E quem são esses "outros"?

Este é o verdadeiro alvo do meu artigo, quero explicitamente expor os que se beneficiam dessa orgia de falso-altruísmo e ignorância. Pessoas carismáticas, que falam bonito, com discursos inspiradores (principalmente quem fala em justiça, inspiração e motivação), que usam muita hipérbole, que apresentam quase nenhum dado com fontes de credibilidade.

Todos usam os mesmos discursos, as mesmas formas pomposas e sem conteúdo, eles mostram vídeos com o mundo se despedaçando, pessoas apáticas, criancinhas, falando os mesmos "Devemos ..", "Precisamos ..." de sempre:

"Precisamos nos unir", "Precisamos ser mais solidários", "Precisamos nos preocupar mais", "Precisamos pensar no próximo", "Precisamos largar o celular e nos conectar de verdade", bla, bla.

BULLSHIT!

Qualquer um que diz muitos "Precisamos", falando sempre em primeira pessoa do plural "nós", está claramente querendo ser o ditador de um grupo. Alguém que individualmente tem pouca capacidade e por isso incita mais gente para ganhar a credibilidade das massas. E uma vez que existe um certo número de pessoas, qualquer coisa que ele disser parece ter alguma validade.

E isso só é possível porque permitimos. Porque não olhamos os dados, não procuramos saber os fatos, nos emocionamos facilmente por qualquer vídeo bem montado que tenha animais, paisagens, crianças, especialmente se mostrar vídeos de crianças em alguma região miserável do interior da África. Batemos palma a todos esses demagogos.

E sabe o que fazem demagogos como esse quando tem massas seguindo? Fazem todos os que estão efetivamente trabalhando, criando e produzindo riquezas no mundo se sentirem culpados. Fazem suas massas olhar para essas pessoas e pressioná-las para "compartilhar" sua propriedade, fazendo-as se sentir mal caso não dividam. E elas fazem isso não de forma violenta, mas de forma "alegre", colocando as pessoas de propriedade no meio de suas massas e dizendo coisas como "pessoal, esse cara não seria hiper-legal se doasse o que tem para nossa causa?" batendo palmas e sorrindo sarcasticamente, ao mesmo tempo que envergonha, coloca o produtor na parede, sem saída.

Isso senhores, chama-se estelionato. É uma atividade fraudulenta, criminosa e, obviamente, ofensiva. Vamos ser claros: eu não vou me sujeitar ao sofrimento de atos criminosos. E você também não deveria.

A lição aqui é simples. Se alguém vem lhe falar de outra pessoa, ou grupo, faça a pergunta, "a quem isso beneficia?". Se alguém lhe diz "a empresa tal deve estar falindo já que não tem dinheiro nem pra doar pra essa causa social tão importante". Por que essa pessoa repassando a informação se importa? A quem isso beneficia? E mude a pergunta: "por que a empresa não doar significa necessariamente que ela está ruim financeiramente?". Claro, porque a alternativa "porque a empresa não tem interesse em doações" parece "moralmente ruim" demais para ser considerada. E justamente essa alternativa é a mais óbvia. Porém chegamos num ponto tão degradante da moral que ela é quase considerada um crime.

Não caia na conversa

Por isso prestem atenção: o mundo hoje é melhor do que ontem. Não tenha dúvidas disso. E doações, participar de causas sociais, são todas coisas válidas. Mas julgar os outros por não participar não é: é um crime.

Qualquer empresa, qualquer trabalhador, realiza uma operação muito simples: trocas. Um trabalhador troca o valor do que produziu por dinheiro. Uma empresa troca um produto que produziu por dinheiro. Já uma pessoa que participa de causas sociais troca sua capacidade de trabalho por outro tipo de dinheiro: consciência. Todo tipo de doação é uma transação financeira do seu dinheiro ou posses por "você se sentir bem consigo mesmo". É efetivamente uma troca comercial como qualquer outra, afinal você já viu alguém doar com o objetivo de se sentir mal por isso depois?

E isso é mais óbvio quando você encontra os famigerados solidários-de-fim-de-semana. Gente que quer comprar karma positivo por estar frustrado, deprimido, infeliz consigo mesmo. Daí resolve querer participar dos movimentos de "salvar o mundo", doar dinheiro, doar tempo, doar trabalho ou algo assim. Mas tão logo se cansam disso logo estão na praia, num churrasco jogando futebol, debaixo do sol na piscina. Mas agora eles estão "moralmente com crédito" e se colocam na posição de julgar os outros dizendo "eu ajudei e você não".

Só para constar, não estou falando de todos que são solidários. Muitos levam isso a sério de verdade, são anônimos na maioria dos casos, porque elas não estão nisso pra chamar a atenção mas sim pra ajudar os outros. Porém o tipo que estou falando está no negócio de "se sentir bem" e isso requer atenção, requer dizer pros outros como são pessoas boas, como todos deveriam fazer como elas para se sentir bem da mesma forma. Como viciados oferecendo drogas porque elas fazem se sentir bem.

E elas estão preocupadas com as criancinhas? Veja o trauma que as estão fazendo passar contando falsas histórias de fim do mundo:

Agora, a existência de pessoas assim é justamente mais uma evidência de como nossos tempos hoje são melhores. No começo do século XX ninguém estaria dando nenhuma atenção a "causas sociais" como hoje, muitos sequer tinham o que comer direito, não tinham roupas, morriam por doenças comuns.

Só que esse grupo está cada vez mais incômodo, mais chato. Se não ficou claro, eu sou totalmente a favor de causas sociais sérias, e odeio totalmente os hipsters-solidários-de-fim-de-semana. Existem movimentos sérios que merecem respeito sendo manchados por esses grupos. Quer realmente se doar a uma causa? Por favor junte-se a organizações como a Cruz Vermelha, trabalhe nisso tempo integral, e nunca obrigue fisicamente ou moralmente alguém a tomar a mesma escolha que você.

Aliás, isso vale para causas sociais mas também para qualquer tipo de "causa". Fiquem espertos pra variar, tem muita gente esperta querendo que você faça o trabalho sujo por eles. Suspeite de qualquer um que fale por "nós", pelo "bem de todos" ou qualquer demagogia barata desse tipo.

O mundo hoje é melhor, verifique os dados, ela está cada vez melhor e tudo que precisamos fazer é trabalhar e produzir mais e mais riquezas. É assim que o mundo chegou ao ponto de hoje e é assim que ele vai continuar melhorando. Não é retirando (pejorativamente também dito como "compartilhando") riqueza dos outros, é produzindo mais.

Atualização 18/1: O LSM mudou de endereço graças a entrada de um novo patrocinador. O evento será na Telefonica agora. Rua Martiniano de Carvalho, 851 - Bela Vista - São Paulo/SP

Nos dias 1, 2 e 3 de Fevereiro no Brooklin, São Paulo, estarei colaborando como mentor na Lean Startup Machine. Se estiver interessado não esqueça de se inscrever

Sobre o Lean Startup Machine

O Lean Startup Machine acontece em um fim de semana de muita informação e trabalho prático, pois trata-se de um evento de educação empreendedora que se propõe a ajudar as empresas a construírem produtos inovadores que exploram oportunidades reais de mercado.

São três dias intensivos de trabalhos em que se ensina sobre a metodologia Lean Startup, bem como suas aplicações para produto, cliente e desenvolvimento de modelo de negocio. O evento começa com uma serie de ‘pitches’ que ajuda os participantes a organizarem-se em equipes para desenvolver suas hipóteses de problemas, de soluções e uma serie de premissas essenciais para o sucesso do seu modelo de negocio.

Isso feito, cada equipe cria um MVP ‘produto mínimo viável’ e literalmente vai para a rua coloca-lo a prova. Esse contato com o consumidor real permite que sejam validadas (ou não) as premissas mais arriscadas. Todo o processo força as equipes a refinar suas soluções e rever os problemas até que as reais necessidades (e desejos) dos clientes sejam atendidas.

O ponto alto do evento acontece quando as equipes retornam, depois de muitas experiências na rua, e apresentam seus ‘pitches’ com as soluções criadas pelo uso do processo. Não se trata de uma competição, mas a dinâmica do workshop brinca com a apresentação dos pitches e elege um vencedor de acordo com a melhor utilização do processo e demonstração do aprendizado.

Atualização 30/01: Em sequência às brecha que publiquei anteriormente tivemos mais uma sequência, novamente envolvendo parsers, desta vez foi com o parser JSON padrão usado no Rails. A brecha foi identificada como CVE-2013-0333 e afeta as versões de Rails 2.3.x, 3.0.x mas felizmente não afeta as versões 3.1.x, 3.2.x ou se seu parser JSON for o yajl. De qualquer forma, se não puder atualizar a versão da gem do Rails, crie um arquivo como config/initializers/json_parser_replacement.rb e coloque este conteúdo:

ActiveSupport::JSON.backend = "JSONGem"

Se estiver usando Ruby 1.8 lembre de instalar a gem 'json' ou a 'json_pure' e reinicie a aplicação. Esta brecha de segurança é altamente crítica, para se ter uma idéia, hoje (30/01) o site Rubygems.org, o repositório canônico de todas as gems que usamos foi comprometido por esta brecha. Eles estão auditando todas as gems para saber se alguma foi comprometida:

TL;DR - Halt your deploys until give an all clear on @rubygems_status. We're double-checking all gems to ensure they have not been tampered.

— Nick Quaranto (@qrush) January 30, 2013

O Nick Quaranto e diversos voluntários que se reuniram via IRC no canal #rubygems e outros sub-canais fizeram uma grande intervenção e aproveitaram para modernizar a infraestrutura toda do rubygems.org, movendo dos servidores da Rackspace - possivelmente, embora improvavelmente, vítima de rootkit - para AWS, automatizando tudo com Chef. Acompanhem todo o histórico aqui.

Esta semana (13/01) tivemos as maiores brechas de segurança da história do Ruby on Rails. Elas foram classificadas com os codinomes CVE-2013-0156 e CVE-2013-0155. Antes de ir mais longe, se você é responsável por uma aplicação Rails em produção e não sabia disso não perca tempo e faça o seguinte imediatamente:

Crie um arquivo config/initializers/disable_parsers.rb com o conteúdo:

Para aplicações Rails versões 3.2, 3.1, 3.0:

ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML) ActiveSupport::XmlMini::PARSING.delete("symbol") ActiveSupport::XmlMini::PARSING.delete("yaml")

Para aplicações Rails versões 2.3:

ActionController::Base.param_parsers.delete(Mime::XML) ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('symbol') ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('yaml')

Agora cheque seu arquivo Gemfile.lock, se encontrar a gem multi_xml em versão abaixo da 0.5.2 modifique seu arquivo Gemfile para ter a linha:

gem "multi_xml", "0.5.2"

Execute bundle update multi_xml e recheque seu Gemfile.lock para ter certeza que ela tem somente esta versão. Caso alguma outra gem dependa exclusivamente de uma versão menor do que essa leia este Gist e crie o arquivo initializer que ele sugere para colocar na sua aplicação. Normalmente você não procura por essa gem explicitamente, mas se você usa o HttpParty, então ela virá como dependência.

Não estou brincando, é sério: atualize imediatamente!!

Entendendo a brecha de segurança

Agora que você já atualizou suas aplicações e está em segurança, vamos entender mais sobre esse assunto.

Em todos os casos o problema real não é no framework Ruby on Rails, mas sim nos parsers de XML (XmlMini) e YAML (Psych) e a forma como elas são utilizadas. O framework Rails, por causa de suas características de responder a rotas "REST" significa que ela aceita e produz estruturas serializadas em XML e YAML para servir como endpoints de APIs. É uma prática muito comum hoje em dia.

Em particular, o parsing de XML vem habilitado por padrão (eis uma das brechas) e o parsing YAML é opcional (mas é possível embutir um objeto YAML dentro de um pacote XML e ter as duas desserializadas!). Para quem não sabe o que isso significa vamos dar um exemplo simples. Se abrirmos o rails console podemos fazer o seguinte:

:001 > { a: 1, b: "foo", c: true }.to_xml
 => "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<hash>\n  <a type=\"integer\">1</a>\n  <b>foo</b>\n  <c type=\"boolean\">true</c>\n</hash>\n" 

:002 > { a: 1, b: "foo", c: true }.to_yaml
 => "---\n:a: 1\n:b: foo\n:c: true\n"

Tecnicamente, isso é o processo que chamamos de "Marshalling", ou seja, transformar um objeto num formato string. Podemos gravar esses strings num arquivo (vide arquivos como config/database.yml), trafegar pela rede, ou persistir num banco de dados. A intenção é "congelar" o estado de um objeto num formato persistente, de tal forma que podemos desligar a máquina virtual e ao religá-la, podemos recuperar o estado do objeto no processo chamado de "Unmarshall":

:003 > Hash.from_xml("<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<hash>\n  <a type=\"integer\">1</a>\n  <b>foo</b>\n  <c type=\"boolean\">true</c>\n</hash>\n")
 => {"hash"=>{"a"=>1, "b"=>"foo", "c"=>true}} 

:004 > YAML.load("---\n:a: 1\n:b: foo\n:c: true\n")
 => {:a=>1, :b=>"foo", :c=>true}

No exemplo acima estamos fazendo exatamente isso: unmarshall ou desserialização. É assim que podemos trafegar estruturas complexas, é assim que endpoints de APIs podem trocar informações.

O problema é que formatos "ricos" como YAML permitem que quase qualquer coisa seja representada em formato texto e recuperada depois. Inclusive formatos binários e código executável (!) E é assim que nasce o problema.

Como programadores, para variar, nós assumimos só o caso mais simples e mais direto: que as aplicações vão receber estrutura que contém tipos simples como números, strings, arrays com primitivas simples, do tipo que você encontrar num config/database.yml. Porém sabemos que existe uma relação inversa entre flexibilidade e facilidade com segurança. Quanto mais flexível for alguma coisa, menor será sua segurança.

Adaptando um trecho do excelente artigo Rails' Remote Code Execution Vulnerability Explained temos este código:

code  = "puts 'pwned'; exit 1"# Construct a YAML payload wrapped in XML
payload = <<-PAYLOAD<fail type="yaml">
        --- !ruby/object:ERB
          template:
            src: !binary |-#{Base64.encode64(code)}</fail>
PAYLOAD

E esse código gera este YAML:

<failtype="yaml">
        --- !ruby/object:ERB
          template:
            src: !binary |-
              cHV0cyAncHduZWQnOyBleGl0IDE=</fail>

Estão entendendo? É possível passar código arbitrário serializado num string YAML. E é possível também embutir esse YAML dentro de um XML e o parser XML irá desserializar ambos.

E isso não se trata de somente um SQL Injection. Sequer precisamos de um banco de dados. Os exploits que já estão à solta vão dar acesso a shell, à linha de comando, onde você pode executar qualquer coisa e tomar a máquina, incluindo tudo que estiver dentro dela, incluindo banco de dados, código-fonte, senhas e o que mais tiver nela. Por isso é crítico!

Tudo isso não é tecnicamente um "bug", no sentido de um código tecnicamente quebrado. Ele é de fato um "bug de segurança", no sentido de permitir qualquer tipo de código de passar por ele sem uma checagem mais rígida. Porém nós programadores sempre pensamos no caminho mais curto primeiro e acabamos esquecendo de checagens como essa. Precisamos ser mais cuidadosos.

Agora vem o problema: os programadores no Ruby on Rails também não sabiam disso e usaram os parsers "assumindo" que eles cuidavam disso (e por consequência nós também assumimos que estava tudo seguro). E aqui vem outra dica: muito cuidado com o que você confia. É impossível saber tudo, mas esse é um ponto importante porque estamos assumindo que o usuário irá passar um conteúdo a nossa aplicação, estamos delegando essa informação a uma biblioteca de terceiros, e estamos assumindo que essa biblioteca vai "saber o que fazer".

Porém é questionável porque era permitido embutir um YAML dentro de um XML. Não sei de onde isso veio e qual foi a motivação, mas pelo menos estamos retirando essa anormalidade, como bem explica o artigo da Revision Zero.

Sabendo essa única informação: o parser YAML permite desserializar objetos binários, que inclui código possivelmente executável, ainda não é tudo. Agora precisamos analizar o framework Ruby on Rails e ver se em algum momento ele permite executar esse código que pode vir no YAML. E de fato ele executa, e com isso temos uma porta escancarada.

Exemplo do exploit você pode encontrar no excelente framework de testes de penetração Metasploit. Aliás, recomendo utilizar esse framework daqui pra frente em todas as suas aplicações para garantir que pelo menos as brechas já conhecidas sejam detectadas antes de você colocar sua aplicação em produção.

Protocolo de Segurança

Eu não sou um especialista em segurança, mas existem certas coisas que deveriam ser óbvias mas nem todos entendem.

Primeiro, assinem a lista de segurança dos frameworks principais que você utiliza. Em particular para nós, assine a lista Ruby on Rails: Security e acompanhe o site RoR Security. Não precisa ser paranóico, não é toda brecha de segurança que é crítica.

Assine também blogs como do próprio Metasploit. Quando você ler frases como:

"... this is more than likely the worst security issue that the Rails platform has seen to date."

Isso significa nível de criticidade altíssima, prioridade zero, alerta vermelho, acordar de madrugada e fazer a atualização imediatamente!!

Foi exatamente o que eu fiz no momento em que li essa notícia (e já atrasado 4 horas desde o anúncio). Imediatamente o protocolo foi enviar emails para meus ex-clientes (porque eu não tenho mais acesso ao ambiente deles), atualizar todos os projetos em andamento na minha empresa, realizar o deployment de todas as aplicações que estavam instalados em produção.

Isso é necessário porque estamos tentando evitar um Zero Day Attack. Esse problema estava ativo em todas as aplicações Ruby on Rails feitas nos últimos 4 anos pelo menos, era uma vulnerabilidade desconhecida publicamente, o que não significa que alguém já não sabia e já não estava explorando esse buraco.

Quando um pesquisador sério descobre uma vulnerabilidade, ele não twita, ele não publica no Facebook, nem faz barulho no HackerNews. A ética diz que ele deve enviar aos canais oficiais de segurança (eu entendo que o melhor é avisar alguém do Rails Core diretamente, em privado). A partir do aviso privado, os responsáveis do canal devem tratar isso como prioridade absoluta porque tirando uma cortesia, o autor da descoberta não precisa esperar para publicar sobre a vulnerabilidade.

Foi o problema recente da vulnerabilidade no sandbox de Applets do Java onde a vulnerabilidade não foi tratada como deveria.

Em algum "momento", a vulnerabilidade é exposta em público, seja pelo próprio canal de segurança oficial (quando o Aaron publicou a descrição da vulnerabilidade e como consertá-la), ou seja por alguém que "vaza" a informação e ela se torna disponível.

A partir de agora ela é Zero Day ou Zero Hour, enfim, a partir de agora você, suas aplicações, seus clientes estão todos expostos. Sua casa está sempre com a porta trancada, mas você sempre esquece a janela dos fundos aberta, mas ninguém sabe disso. A partir do momento em que essa informação vai a público, alguém pode ou não tirar proveito dela. Se você tiver senso de criticidade, vai largar tudo que está fazendo e ir correndo para trancá-la a tempo, certo?

Não tente corrigir um problema e criar dois

Seguindo a mesma metáfora, não adianta nada agora você pegar seu carro e sair acelerando e passando por todos os faróis vermelhos. Afinal sua casa vai continuar aberta e escancarada se por acaso você sofrer um acidente no meio do caminho. Agora você tem dois problemas.

No caso do CVE-2013-0156é o que poderia ter acontecido. Se você ler superficialmente vai ver que basta atualizar sua aplicação para as versões 3.2.11, 3.1.10, 3.0.19, 2.3.15.

Excelente, basta atualizar seu Gemfile, executar bundle update rails e tudo está consertado. Errado.

Por exemplo, se sua aplicação estava no Rails 3.2.10 e tivesse um código parecido com o abaixo, ela vai quebrar no 3.2.11:

$.ajax('/home/index', {type: 'POST',contentType: "application/json; charset=utf-8",dataType: "json",data: JSON.stringify({ post: { comments_attributes: [] }}),error: function(response, status, jqxhr) { $("#response").html(response.responseText); },success: function(response, status, jqxhr) { $("#response").html("Request successful"); }
    });
});

Isso é um bug de regressão. Uma forma de corrigir é com este código (de acordo com este Gist):

classApplicationController< ActionController::Base
  before_filter :merge_json_params
privatedefmerge_json_paramsif request.format.json?
      body = request.body.read
      request.body.rewind
      params.merge!(ActiveSupport::JSON.decode(body)) unless body == ""endendend

E não só esse, se você estava numa versão abaixo da 3.2.8 e resolveu atualizar direto pra 3.2.11 vai esbarrar com este outro bug. Leia mais sobre esse bug aqui. O que acontece é o seguinte, até a versão 3.2.8 esse código funciona:

# 3.2.8
p = Post.new
p.category_id = [ 1, 2 ]
p.category_id # => 1
p.category_id = { 3 => 4 }
p.category_id # => 1

A partir da versão 3.2.9 ela vai soltar uma exceção NoMethodError:

# 3.2.9
p = Post.new
p.category_id = [ 1, 2 ]NoMethodError: undefined method `to_i' for [1, 2]:Array

O recado é óbvio: nunca atualize para versões mais novas de gems cegamente. Então o que devemos fazer?

EXECUTE SUA SUÍTE DE TESTES!!

É a única forma de checar com algum nível de segurança que sua pressa em corrigir o buraco de segurança não vai causar mais problemas ainda. Isso obviamente depende da qualidade dos seus testes.

Na dúvida, se nada estiver funcionando, no caso de um bug de criticidade altíssima como essa: desligue sua aplicação do ar. É melhor do que continuar exposto à vulnerabilidade e melhor do que introduzir bugs sérios que podem corromper os dados dos seus clientes. Suba uma página estática de manutenção, avise seus clientes, faça uma janela de manutenção. Só não se mantenha exposto.

Quando eu comecei o processo de atualizar as aplicações da minha empresa eu tomava o cuidado de, no mínimo, atualizar as gems, depois rodar todas as specs e só depois fazer o deployment em produção. Em dois casos eu caí nos bugs acima. O fallback foi usar o que escrevi no começo do artigo: criar o initializer para desativar manualmente os parsings.

O problema é que se você estava numa versão antiga como 3.2.6, existiram 5 versões a seguir adicionando novas funcionalidades. E novas funcionalidades são um pesadelo: significa instabilidade, código novo não testado.

Sem testes é impossível saber se sua aplicação vai continuar funcionando ao atualizar qualquer uma das suas gems ou adicionar código novo. É uma bomba relógio esperando para estourar e em episódios raros de emergências críticas como essa é exatamente como morar num apartamento sem extintores de incêndio.

"Ora, nunca vai pegar fogo aqui."

Só que no raro dia em que isso acontecer, você vai pagar pela negligência.

Alguns dias atrás me pediram para responder no Quora a pergunta "Ruby on Rails: Quais são algumas das piores práticas para aplicações Ruby on Rails?". Foi uma resposta que teve muitos votos positivos então resolvi que seria um bom post para meu blog. Segue minha versão extendida.

Existem diversas práticas ruins em desenvolvimento de aplicações em geral e em particular em Ruby on Rails. Eu mesmo já cometi e aprendi sobre várias elas na prática e em particular tive que pegar alguns projetos de resgate onde continuo vendo os mesmos erros acontecendo repetidamente, então vamos tentar resumir as principais que mais me irritam.

1) Primeiro de tudo é a ausência de testes, ou cobertura muito pequena, ou testes que são muito frágeis. Pessoal, isso é uma coisa básica! Se ainda não fazem isso comecem imediatamente a adicionar os malditos testes! Quanto pior for a qualidade e cobertura dos testes proporcionalmente mais caro fica manter e expandir uma aplicação, ponto final. Codificadores que não escrevem testes demonstram muito pouco respeito pela sua própria prática.

Já discutimos ad nauseaum (dica pra começar: "The RSpec Book") sobre testes nos últimos anos então o que não falta é material para aprender e as melhores práticas. Não me importo se os testes são feitos "by the book" escrevendo testes antes do código ou se os testes são adicionados depois do código, contanto que no final existam testes que eu possa executar e ter segurança de que não estou criando bugs de regressão, quebrando coisas que não deveria. Não custa quase nada adicionar os testes mínimos, então adicionem.

Ultimamente tivemos diversos problemas de segurança, muita gente simplesmente atualizou suas gems para as mais recentes para pegar as correções. Somente quem tinha bons testes viu que algumas dessas correções introduziam regressões. Quem não testou e só atualizou acabou colocando no ar versões com bugs.

2) Escreva nomes em inglês dentro do seu código. Não me importo se você é brasileiro, italiano, francês ou o que for. Nomes de classes, de variáveis, de métodos, tudo deve ser em inglês. Estamos num mundo globalizado, não é pensar muito longe que amanhã um americano vai mexer no seu código todo em português. Além do problema de consistência: a sintaxe da linguagem, todas as bibliotecas padrão, é tudo em inglês. É uma enorme dissonância cognitiva ter nomes em português no meio. É como você estar lendo uma revista em português com diversos parágrafos em inglês no meio. Não faz nenhum sentido.

E aproveitando outra coisa que muitos não fazem: não é obrigatório usar o sistema de localização do Rails. Porém no primeiro momento onde você se ver adicionando strings de mensagens dentro de models e controllers, pare! Existe local para isso, e é em config/locales. Não tem nada pior do que achar dezenas de mensagens espalhadas por todas as classes.

3) Hoje existem diversos frameworks e bibliotecas para front-end, seja para stylesheet (Bourbon, Bootstrap, Compass), para javascript (jQuery, Ember, Angular, Backbone), e diversas ferramentas (Sass, Coffeescript). Além disso temos toda uma convenção e estruturas em app/assets para organizar tudo issso. Parem de colocar styles e javascript inline espalhados pelas views! É sintoma de preguiça, de falta de conhecimento e tentativa de pular passos fazendo gambiarras. Não faça isso!

4) Não tente ser mais esperto do que seu ORM (Object Relational Model), no caso o ActiveRecord. Na enorme maioria dos casos, se você estiver usando find_by_sql por motivos de otimizar "performance", você está fazendo a coisa errada. Pior ainda, em quase todos os casos que já vi essa tentativa de otimizar na mão não só não havia esse ganho como ainda já vi adicionando buracos de segurança, como o famigerado "SQL Injection". Aliás, esse é um tema frequente: otimização prematura e desnecessária adicionando bugs de segurança.

Talvez 1% dos maiores sites do mundo precisem de SQLs realmente específicos otimizados manualmente depois de muitos testes em produção, com volume de dados e métricas bem definidas para provar a diferença. Mas a maioria de nós está nos 99% que não precisa disso: apenas aprenda a usar o ActiveRecord corretamente.

Por exemplo, o problema fazer N+1 queries desnecessariamente, como está explicado no guia oficial de ActiveRecord e que eu copio aqui:

clients = Client.limit(10)
clients.each do |client|
  puts client.address.postcodeend

Esse código vai fazer 11 queries no banco. A primeira para buscar 10 clientes e depois no loop para buscar o endereço de cada cliente. Isso é tão óbvio que ninguém deveria estar caindo mais nisso. O correto é fazer:

clients = Client.includes(:address).limit(10)
clients.each do |client|
  puts client.address.postcodeend

Nesta versão já estamos puxando os endereços ao mesmo tempo que puxamos os clientes, em apenas 2 queries: uma para puxar os clientes e uma única pra puxar todos os endereços de todos os clientes. Não precisou escrever nenhum SQL na mão, bastou saber usar o ActiveRecord corretamente para cair de 11 para 2 queries.

Complementando e enfatizando: aprendam tudo sobre as as APIs do ActiveRecord e como as queries são montadas. Uma coisa horrorosa que já vi diversas vezes foram tentativas de ser "esperto" e fazer código como este:

Subscription.all.select { |s| s.expired? }.each { |s| s.destroy }

Para ficar claro: isso NÃOé "usar as funcionalidades funcionais de Ruby". Isso é ser ignorante quanto bancos de dados e ORMs em geral. Só para ficar absolutamente claro, esse código deveria ser assim:

Subscription.where(expired: true).destroy_allSubscription.destroy_all(expired: true)

Lembrando que destroy permite chamar regras de negócio para cada objeto destruído e se usar deleteé um comando simples SQL para apagar do banco apenas. Depende o que você pretende fazer ao destruir o objeto. Além disso o campo "expired" deveria ser um escopo dentro do model. Como podem ver, uma simples linha pode ter múltiplas opções dependendo do que se pretende fazer. Novamente não tente ser mais esperto do que o ORM, ele provavelmente já tem tudo que você está imaginando, então não reinvente a roda e leia as APIs.

Outros sintomas básicos que já vi: chamar save(validate: false). Se você está desativando a validação que você ou sua equipe colocou, o que está acontecendo? Existem sim, casos específicos de cargas de dados controlados que talvez possam precisar disso. Na maior parte dos casos não precisa. Na maior parte dos casos é o programador que teve preguiça de entender a aplicação fazendo uma gambiarra pra cumprir sua tarefa de forma "rápida" e largou uma bomba relógio pra trás (falta de testes esconde erros que esse tipo de ação causa).

5) Não use um banco de dados NoSQL a menos que você tenha uma explicação técnica objetiva com argumentos que justifiquem a qualquer um de forma incontestável o porquê dessa escolha. Digo isso porque a maioria das vezes que alguém me falou em usar um MongoDB a resposta cai nas linhas do "vai que um dia precisamos". E não, a maioria de vocês não precisa de um banco de dados NoSQL. Para começar a maioria sequer entende a diferença entre documentos com schema flexível (MongoDB, CouchDB), estruturas de chave-valor (Redis, Riak), ou estruturas orientadas a coluna (Cassandra).

Primeiro que não sabem que existem esses diferentes tipos, então não sabem qual desses é o que realmente resolve seu problema, finalmente não tem idéia do trabalho que é dar manutenção em produção desse tipo de infraestrutura. Aprendam o seguinte: usem bancos de dados relacionais, de preferência PostgreSQL. Vocês não precisam de mais do que isso. Na maior parte do tempo é a preguiça de entender o modelo entidade-relacional e achar que o modelo NoSQL é "mais fácil".

Na minha experiência, ainda não cruzei com um projeto onde a presença de um banco NoSQL fosse indispensável. Em todos os casos que vi, eles acabavam fazendo o que um PostgreSQL faria com as duas mãos nas costas. "Ah, mas eu preciso fazer operações de geolocalização". Avaliem o PostGIS. "Ah, mas eu tenho alguns atritutos dinâmicos que variam, então preciso de uma schema flexível". Não necessariamente, provavelmente o suporte HStoreé tudo que você precisa.

Outros casos básicos: usar o banco de dados de produção pra produzir relatórios pesados. Ou o caso mais básico: ter apenas uma instância de banco para leitura e escrita. Não custa nada fazer o básico: uma instância master que é read-write e outra slave que é read-only. Mande as operações de escrita pra master e queries complicadas que consomem processamente para a slave. Mais do que isso, aprenda que a configuração padrão de todo banco de dados é ruim. Aprenda a fazer o tuning básico.

Em resumo: a maioria dos projetos ruins que peguei demonstravam baixo nível de entendimento tanto de bancos de dados relacionais em geral, baixo conhecimento de SQL (índices pessoal! índices!), e por consequência uso muito pobre do ActiveRecord.

6) Falando nisso, outra coisa irritante é pegar um projeto que precisa de mais do que um bundle e rake db:migrate pra começar a funcionar. Seja porque tem um SOLR a ser configurado, um Redis, alguns rake tasks customizados que precisam ser executados, etc. Pessoalmente, existe um arquivo chamado README na raíz de todo projeto que não está lá de enfeite! Não vai custar 1 minuto preencher as informações básicas do ambiente nesse arquivo e economizar horas da sua equipe e dos programadores que vão herdar seu sistema no futuro. Ou você mesmo, que vai passar um tempo sem mexer nesse sistema e quando voltar vai ter que se lembrar de todos os detalhes.

Aliás, aprenda o básico de administração de sistemas Unix-like (Linux) antes de sair reclamando que Ruby é lento, que bancos de dados relacionais são lentos, que o framework é inseguro. Como você pode reclamar da segurança do framework se todas as portas dos seus servidores estão abertos publicamente??

7) E falando em qualidade de código, cobertura de testes e segurança, usem as ferramentas que a comunidade criou e que vão ajudar muito na manutenção dos projetos. O CodeClimate vai checar a qualidade geral do seu código e também da segurança. Cheque o tempo todo, qualquer coisa abaixo de nível 3 é ruim. Configurem seu projeto no Travis-CI e, finalmente, executem o Brakeman e atualize essa gem em particular constantemente. Isso vai garantir o mínimo do mínimo do seu projeto.

8) Eu gosto de usar os gráficos de projetos do Github. Ele conta muito sobre os programadores envolvidos no projeto. E antes que alguém diga, não, não é a comparação de quantidade de linhas de códigos ou quantidade absoluta de commits. É o comportamento individual comparado no tempo. Depois de algumas semanas é possível ver o que seria o "normal" desse programador. Então você começa a ver que a produtividade começa a cair, especialmente nas primeiras semanas, então próximo à entrega vê que dá picos. Normalmente isso é o programador que começou subestimando as tarefas do projeto e perto da entrega se desespera e começa a vomitar código. Comportamento muito ruim porque isso leva a pular passos como pular testes, escrever código sem cuidado, sem segurança e fazendo tudo que eu falei acima que não era pra fazer.

Quando esse comportamento começa a acontecer você vê o sintoma seguinte: programador reclamando do projeto, reclamando que o gerenciamento está ruim, que o cliente é ruim, que o projeto é ruim. São as desculpas mais comuns de péssimos programadores que cometeram erros e jogam seus erros nos outros. Impressionante como esse comportamento tem alta correlação com o tipo de gráfico que mencionei no Github.

Nessa mesma linha vamos combinar: código que está somente na sua máquina não está "pronto". Pronto significa já no repositório, passando todos os testes no Travis-CI, feito deployment em produção e sem gerar bugs de regressão ou bugs de usabilidade que os clientes/usuários descobrem sozinhos na primeira vez que usam a nova versão. Aliás, por que diabos você saiu do escritório sem colocar o código em produção? Não há desculpa para isso. Cansei de ver programadores que "esquecem" de colocar o código em produção. O que você estava esperando? Um convite formal? Programador que demora pra colocar o código no repositório está fazendo as coisas erradas. Já mandei funcionários embora que depois dizem "ah, faltou eu fazer push do código no repositório". O que é isso? Tentativa amadora de fazer código como refém?

Bullshit!

Essas são algumas más-práticas. Existem mais, quais são as piores que você já viu? Comentem e eu vou incorporar as mais interessantes no artigo também.

O assunto não é nada novo, mas como caí nele esses dias resolvi anotar. Faz algum tempo que estou só desenvolvendo usando Vagrant, se ainda não conhece vale a pena ler o artigo Usando o Vagrant como Ambiente de desenvolvimento Windows do Nando Vieira sobre isso.

Em resumo é basicamente uma forma simples de configurar seu VirtualBox. Porém com isso vem alguns problemas, um deles é executar testes de aceitação, especialmente com Selenium. Isso porque o Vagrant vai subir um servidor VirtualBox headless, sem modo gráfico. E sem isso não dá para os testes abrirem o Firefox. Você pode executar em modo headless mas é mais divertido ver o Firefox abrindo e executando seus testes.

Para que isso funcione é simples: basta executar o Selenium em modo servidor e fazer a execução do Vagrant chamá-lo pela sua rede. Vamos passo a passo.

Assumindo que você já tem seu projeto Rails, vamos adicionar o seguinte no seu Gemfile:

gem 'capybara', :group => :test

Agora execute bundle para instalar a gem. Por padrão ele vai instalar o selenium-webdriver. Você pode usar o Capybara com o PhantomJS usando a gem Poltergeist mas em particular eu tive um problema onde nos mesmos specs que o Selenium executava perfeitamente no caso do Poltergeist eu estava recebendo erros de NotImplementedError que ainda não consegui debugar a causa.

Estou assumindo que seu projeto já tem Rspec configurado. Como normalmente o arquivo spec/spec_helper.rb já tem a linha Dir[Rails.root.join("spec/support/*/.rb")].each {|f| require f}, basta colocar as configurações num arquivo no diretório spec/support. Então podemos começar criando o arquivo spec/support/capybara.rb:

require 'capybara/rails'
require 'capybara/rspec'# Use this driver to start firefox with a profile called firebug, where you can leave firebug installed.# In OSX, run '/Applications/Firefox.app/Contents/MacOS/firefox-bin -p' to create a profile.Capybara.register_driver :selenium_firebugdo |app|Capybara::Selenium::Driver.new(app, :browser => :firefox, :profile => "firebug")endCapybara.javascript_driver = :selenium

Agora vamos criar outro arquivo, spec/support/capybara_remote.rb

# SELENIUM_SERVER is the IP address or hostname of the system running Selenium# Server, this is used to determine where to connect to when using one of the# selenium_remote_* driversSELENIUM_SERVER = "10.0.1.8"# SELENIUM_APP_HOST is the IP address or hostname of this system (where the# tests run against) as reachable for the SELENIUM_SERVER. This is used to set# the Capybara.app_host when using one of the selenium_remote_* driversSELENIUM_APP_HOST = "127.0.0.1"SELENIUM_APP_PORT = 3001# CAPYBARA_DRIVER is the Capybara driver to use, this defaults to Selenium with# FirefoxCAPYBARA_DRIVER = "selenium_remote_firefox"# At this point, Capybara.default_driver is :rack_test, and# Capybara.javascript_driver is :selenium. We can't run :selenium in the Vagrant box,# so we set the javascript driver to :selenium_remote_firefox which we're going to# configure.Capybara.javascript_driver = :selenium_remote_firefoxRSpec.configure do |config|

  config.before(:each) doif selenium_remote?Capybara.server_port = SELENIUM_APP_PORTCapybara.app_host = "http://#{SELENIUM_APP_HOST}:#{Capybara.server_port}"endend

  config.after(:each) doCapybara.reset_sessions!Capybara.use_default_driverCapybara.app_host = nilend# Determines if a selenium_remote_* driver is being useddefselenium_remote?
    !(Capybara.current_driver.to_s =~ /\Aselenium_remote/).nil?endend# CapybaraDriverRegistrar is a helper class that enables you to easily register# Capybara driversclassCapybaraDriverRegistrar# register a Selenium driver for the given browser to run on the localhostdefself.register_selenium_local_driver(browser)Capybara.register_driver "selenium_#{browser}".to_sym do |app|Capybara::Selenium::Driver.new(app, :browser => browser)endend# register a Selenium driver for the given browser to run with a Selenium# Server on another hostdefself.register_selenium_remote_driver(browser)Capybara.register_driver "selenium_remote_#{browser}".to_sym do |app|Capybara::Selenium::Driver.new(app, :browser => :remote, :url => "http://#{SELENIUM_SERVER}:4444/wd/hub", :desired_capabilities => browser)endendend# Register various Selenium driversCapybaraDriverRegistrar.register_selenium_remote_driver(:firefox)

Importante é modificar as constantes SELENIUM_SERVER para ser o IP da sua máquina local e o SELENIUM_APP_PORT para ser a porta onde o Capybara vai carregar o servidor de teste para o Firefox conectar. Essa mesma porta você deve configurar no seu arquivo VagrantFile e adicionar a seguinte linha:

config.vm.forward_port 3001, 3001

Importante: use uma porta que não conflite com nada. No caso não use o famigerado "3000" porque você provavelmente vai ter seu servidor de desenvolvimento carregado nela, mas tirando isso pode ser qualquer outra porta. Com esse mapeamento o firefox local fora do Vagrant vai conseguir conectar simplesmente carregando http://127.0.0.1:3001.

Uma última modificação é entender a seguinte situação: quando executamos specs, o Rspec vai sempre vai executar cada teste dentro de uma transação e dar rollback ao final para não poluir o teste seguinte. Mas quando o Capybara subir o servidor de testes para o Selenium/Firefox conectar as transactions não vão funcionar. Uma solução comum é usar o database_cleaner e trocar a estratégia de "transaction" para "truncation".

Mas existe uma forma mais simples que já foi publicada pela PlataformaTec. Nesse caso não precisamos do database_cleaner e consideramos o fato que o Capybara cria uma thread para subir o servidor e nesse caso podemos compartilhar a conexão de banco que já existe na nova thread e para isso podemos simplesmente criar um arquivo como spec/support/database_sharing.rb com o seguinte:

classActiveRecord::Base
  mattr_accessor :shared_connection@@shared_connection = nildefself.connection@@shared_connection || retrieve_connectionendend# Forces all threads to share the same connection. This works on# Capybara because it starts the web server in a thread.ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection

Só para garantir abra seu spec/spec_helper.rb e garanta que a seguinte configuração está com o valor certo:

RSpec.configure do |config|
  ...
  config.use_transactional_fixtures = true
  ...end

Isso garante que continuamos usando a estratégia de "transaction" e não precisamos carregar mais uma gem extra.

Finalmente, agora precisamos baixar o Selenium Server. Vá para o site oficial e baixe a versão mais recente que, no caso da época deste artigo é a versão 2.31.0. Considerando que você já tem Java configurado na sua máquina local (fora do Vagrant), podemos executar o servidor simplesmente fazendo:

java -jar selenium-server-standalone-2.31.0.jar

Pronto, agora basta criar suas features. Existem dezenas de tutoriais. Em particular, leia esta página do Wiki do Devise para autenticação integrando direto no Warden. Com isso já podemos executar os specs de aceitação do Capybara de dentro do seu box Vagrant e ver o Firefox executando na sua máquina host local.

Como último toque, vamos assumir que você está usando o excelente Travis-CI como seu servidor de integração contínua. É o mesmo problema, como executar o Selenium num box headless? Nesse caso não precisamos mesmo "ver" o Firefox e para isso basta fazer esta configuração no seu arquivo .travis.yml:

language: rubyrvm:
  - 1.9.3before_script:
  - cp config/database.yml.sample config/database.yml
  - bundle exec rake db:create db:migrate db:test:prepare
  - "export DISPLAY=:99.0"
  - "sh -e /etc/init.d/xvfb start"script:
  - bundle exec rake spec#whitelistbranches:only:
    - master

Isso deve ser o suficiente para que o Travis consiga executar seus specs de aceitação normalmente. Se por acaso você optar pelo Poltergeist, o Travis já tem os binários do PhantomJS instalados então não há o que se preocupar.

Se você é desenvolvedor com certeza usa frequentemente os excelente sites Stack Overflow e Stack Exchange, em termos de conteúdo técnico se você está tendo um problema a probabilidade de encontrar a solução num desses sites é enorme.

O co-fundador, Jeff Atwood, resolveu iniciar um novo projeto de fóruns. Se pararmos para pensar temos centenas de "blog engines" por aí, do famigerado Wordpress até o geeky Jekyll. Isso sem contar os inúmeros CMS como Joomla, ecommerces como Magento e Spree. Mas uma categoria que evoluiu muito pouco foram os fóruns e até hoje ainda vemos os antigos phpBB por aí.

Com isso em mente Jeff juntou uma equipe e desenvolveu o Discourse. Mais interessante ainda: ele desenvolveu tudo usando Ruby on Rails, Ember.js, PostgreSQL e Redis. Tudo está open source e ele está ainda em ativo desenvolvimento.

Uma coisa que temos na minha empresa, a Codeminer 42é um email interno "developers@codeminer42.com" onde os mais de 30 desenvolvedores espalhados em 4 escritórios que temos postam sobre os mais diversos assuntos técnicos, dicas, truques e tudo mais que acontecem nos projetos. Uma coisa que me perturba há um ano é que todos os novos Miners não tem um histórico aonde recorrer. Quando estive na Locaweb ajudei a instalar o MediaWiki que você pode acessar publicamente aqui. Eu gosto da idéia de criar um repositório de conhecimento. Por mais que um Stack Overflow e nosso velho amigo Google resolvam isso, é sempre bom não desperdiçar conhecimento criado na prática, no nosso dia a dia.

Por outro lado, somos uma software house Ruby, e até hoje eu não tinha visto um bom software para usar de base para criar esse repositório. Finalmente o Jeff nos presenteou com o Discourse e logo que o vi sabia que era o que eu queria. Mais do que isso ele tinha uma coisa que foi fundamental: integração com diversos providers OAuth, incluindo Google Apps que é o que a maioria das empresas como a minha usa como serviço de email. Isso é importante porque dá trabalho ficar gerenciando manualmente contas de todo mundo.

Se quiser ir direto ao assunto recomendo recorrer à Bitnami que já tem instalador pra OS X, imagem de máquina virtual para VMWare e imagem para Amazon e Azure. Baixe a imagem e a máquina já estará configurada e pronta pra funcionar. Mas pensando no velho "casa de ferreiro, espeto de ferro", resolvi eu mesmo configurar uma máquina do zero. Gosto de fazer isso como hobby.

Usei um box Ubuntu na Rackspace, criei um usuário chamado 'discourse'.

useradd -d /home/discourse -m discourse
passwd discourse

A partir daqui faço o resto logado com esse usuário com sudo su - discourse.

Não vou repetir o que já existe então veja a documentação no Github do Discourse para mais detalhes, em particular o artigo DEVELOPER-ADVANCED. Basta trocar o usuário "vagrant" pelo usuário que quiser. Antes de sair executando o passo-a-passo do link anterior, continue lendo até o final.

Algumas diferenças envolvem instalar o Redis não a partir do tarball mas simplesmente fazendo apt-get install redis-server.

Eu pessoalmente não acho ruim usar RVM, então instalei o RVM, com ele instalei o Passenger e de lá instalei o NGINX. Novamente, existem dezenas de tutoriais sobre o assunto, em resumo:

curl -#L https://get.rvm.io | bash -s stable --autolibs=3 --ruby
gem install passenger
rvmsudo passenger-install-nginx-module

Agora, subir o NGINX usando um initscript para que ele inicie sozinho se a máquina reiniciar:

wget -O init-deb.sh http://library.linode.com/assets/660-init-deb.sh
sudo mv init-deb.sh /etc/init.d/nginx
sudo chmod +x /etc/init.d/nginx
sudo /usr/sbin/update-rc.d -f nginx defaults

Só como referência, o passenger já vai configurar seu binário sozinho no NGINX mas meu /opt/nginx/conf/nginx.conf tem o trecho:

...
http {
    passenger_root /usr/local/rvm/gems/ruby-2.0.0-p0-turbo/gems/passenger-4.0.0.rc5;
    passenger_ruby /usr/local/rvm/wrappers/ruby-2.0.0-p0-turbo/ruby;
...

E no meio configuro a aplicação:

...
server {

  listen 80;
  gzip on;
  gzip_min_length 1000;
  gzip_types application/json text/css application/x-javascript;

  server_name discourse.suaempresa.com.br;

  sendfile on;

  keepalive_timeout 65;

  location / {
    root /home/discourse/discourse/public;
    passenger_enabled on;

    location ~ ^/t\/[0-9]+\/[0-9]+\/avatar {
      expires 1d;
      add_header Cache-Control public;
      add_header ETag "";
    }

    location ~ ^/assets/ {
      expires 1y;
      add_header Cache-Control public;
      add_header ETag "";
      break;
    }

    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header  Host $http_host;

    # If the file exists as a static file serve it directly without
    # running all the other rewite tests on it
    if (-f $request_filename) {
      break;
    }
  }
...

Feito isso, baixar o Discourse e configurá-lo:

git clone git://github.com/discourse/discourse.git
cd discourse
cp config/database.yml.sample config/database.yml
cp config/redis.yml.sample config/redis.yml
cp config/fog_credentials.yml.sample config/fog_credentials.yml.sample
bundle

Edite o config/database.yml e edite ambos os ambiente production e profile:

production:adapter: postgresqldatabase: discourse_productionpool: 5timeout: 5000host_names:
    - discourse.suaempresa.com.brprofile:adapter: postgresqldatabase: discourse_productionpool: 5timeout: 5000host_names:
    - discourse.suaempresa.com.br

Lembre de mudar o host_name para o domínio que tem registrado. Além disso, ao seguir a documentação do Discourse que linkei acima, lembre de que é para criar o banco de produção:

createuser --createdb --superuser -Upostgres discourse
psql -c "ALTER USER discourse WITH PASSWORD 'password';"
psql -c "create database discourse_production owner discourse encoding 'UTF8' TEMPLATE template0;"
psql -d discourse_production -c "CREATE EXTENSION hstore;"

E depois suba o dump de produção também:

psql -d discourse_production < pg_dumps/production-image.sql

O Discourse vem por padrão configurado para mandar emails usando o sendmail da máquina. No meu caso quis ser mais simples e usar o SMTP do meu Google Apps. Para isso edite os arquivos config/environments/production.rb e também o config/environments/profile.rb, substitua a configuração de :sendmail por:

config.action_mailer.delivery_method = :smtpActionMailer::Base.perform_deliveries = trueActionMailer::Base.raise_delivery_errors = trueActionMailer::Base.smtp_settings = {:address              => "smtp.gmail.com",:port                 => 587,:user_name            => "do-not-reply@suaempresa.com.br",:password             => 'suasenha',:authentication       => "plain",:enable_starttls_auto => true
}

Não deixe de executar o bundle exec rake assets:precompile para gerar os assets.

Além disso o Discourse necessita de mais dois serviços para funcionar, o excelente Sidekiq do Mike Perham para gerenciar filas, jobs e workers e o Clockwork do Adam Wiggins. Mas não queremos executar no shell como daemon e deixar por isso mesmo, afinal queremos que eles iniciem sozinhos quando a máquina iniciar.

Para isso resolvi criar dois scripts para o Upstart do Ubuntu em vez de initscripts tradicionais. Primeiro, via sudo criei o arquivo /etc/init/discourse-sidekiq.conf com:

description "Discourse Sidekiq"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on shutdown

respawn
respawn limit 5 20

script
  HOME_DIR=/home/discourse
  APP_ROOT=$HOME_DIR/discourse
  PIDFILE=$APP_ROOT/log/sidekiq.pid
  LOGFILE=$APP_ROOT/log/sidekiq.log
  RAILS_ENV=production

  exec su -c  "/usr/local/rvm/bin/rvm-shell '2.0.0-p0-turbo' -c 'cd $APP_ROOT; bundle exec sidekiq -e production -P $PIDFILE -L $LOGFILE' 2>&1" discourse
end script

Depois criei o /etc/init/discourse-clockwork.conf com:

description "Discourse Clockwork"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on shutdown

respawn
respawn limit 5 20

script
  HOME_DIR=/home/discourse
  APP_ROOT=$HOME_DIR/discourse
  PIDFILE=$APP_ROOT/log/clockwork.pid
  LOGFILE=$APP_ROOT/log/clockwork.log

  exec su -c  "/usr/local/rvm/bin/rvm-shell '2.0.0-p0-turbo' -c 'cd $APP_ROOT; RAILS_ENV=production bundle exec clockwork config/clock.rb >> $LOGFILE 2>&1'" discourse
end script

Com isso podemos iniciar os serviços assim:

start discourse-sidekiq
start discourse-clockwork

Isso deve ser suficiente. Leia a documentação oficial e entenda os passos que expliquei com calma.

Depois de instalado você pode ir para "http://discourse.suaempresa.com.br/admin/site_settings". O Discourse tem dezenas de configurações para customizar da forma como você precisa. Em particular considero os parâmetros a seguir importantes:

• company_domain (suaempresa.com.br) - é o domínio que registrou para seu servidor
• email_domains_whitelist (suaempresa.com.br) - para aceitar apenas usuário de dentro do seu domínio
• access_password - uma senha que somente seu grupo sabe. mesmo não podendo se registrar como usuário, qualquer um pode ler o conteúdo em modo "read-only". essa senha é uma pequena proteção
• allow_index_in_robots_txt (deschecar) - não precisamos que engines de procura indexem nosso site interno
• enable_yahoo_logins (deschecar) - no meu caso não preciso de integração com Yahoo! para autenticação
• enable_twitter_logins (deschecar) - no meu caso não preciso de integração com Twitter para autenticação
• enable_facebook_logins (deschecar) - no meu caso não preciso de integração com Facebook para autenticação
• s3_upload_bucket - é opcional para é o nome do bucket que você pode criar no Amazon S3, e nesse caso você também precisa configurar o arquivo config/fog_credentials.yml com o access key e secret key da sua conta
• default_trust_level (1) - o padrão é "0" que é o nível de "visitante", mas esse nível é muito baixo para seus usuários poderem participar

Pronto, agora basta seus usuários se registrarem com o email do domínio que você configurou como válido acima e eles poderão começar a discutir os assuntos de forma estruturada num fórum moderno.

Ron Jeffriesé um dos 17 signatários originais do Manifesto Ágil, um dos 3 fundadores do Extreme Programming. Ele publica artigos na e-revista da Pragmatic Programmers e na edição 46 de abril de 2013 ele publicou o artigo "Estimation". Pedi permissão ao editor Michael Swaine para traduzir o artigo para português porque é um assunto que eu já ia dissertar a respeito e o Ron, obviamente, já fez um trabalho melhor. Ainda há muito que quero dizer a respeito mas por agora vamos direto à tradução do artigo:

Dois meses atrás nestas páginas, Ron Jeffries nos falou que estimativas são do mal. Agora ele está de volta para nos dizer que é um mal necessário e, feito da forma correta, não é nem mesmo mal.

Sim, existem muitos abusos perpetrados por organizações em volta da noção de estimativa. Muitos desenvolvedores sofreram injúrias sobre esses abusos mais de uma vez em suas carreiras.

Infelizmente, isso nos leva à visão comum ingênua entre pretensos praticantes agilistas que ainda estão no início do aprendizado: eles querem abolir estimativas completamente. Isso provavelmente não é possível e certamente não é ideal. Nós temos a habilidade de estimar quão rapidamente conseguimos fazer as coisas, e as empresas podem tomar decisões melhores se nós compartilharmos o que sabemos.

Desenvolvimento de software não é uma máquina perfeita que cospe funcionalidades rapidamente. Eu sei que é confortável pensar que não temos responsabilidades nas preocupações de negócios como dinheiro, tempo ou datas. Mas isso não é verdade. O que construímos não é isoladamente somente influenciado por algum Lorde dos Produtos que decide o que vamos fazer e assume todos os riscos. Os executivos são os que tem a decisão final, mas muitas das decisões são melhor tomadas pela equipe - e não somente em como fazer as coisas, mas o que fazer. Nós temos a responsabilidade e ajudar a guiar os projetos, usando nossa criatividade e nosso conhecimento especial.

O Manifesto Ágil diz, "as melhores arquiteturas, requerimentos e designs emergem de equipes auto-organizadas" e é isso que queríamos dizer (ênfase minha). Desenvolvedores ágeis normalmente tem um bom senso de quanto tempo as coisas vão levar, e isso é um componente valioso de selecionar e refinar requerimentos. Desenvolvedores precisam ter a atitude de falar sobre possíveis custos do que lhes é pedido para fazer.

Preocupações com Estimativas

Realmente existem inúmeros problemas sérios relacionados a estimar um trabalho de software. Em um artigo anterior "Estimativa é do Mal", eu descrevi alguns deles. Vamos revisá-los:

• Backlogs pré-definidos de trabalho reduzem a criatividade e inibem ajustar o projeto para o sucesso.
• Demandar entrega de "tudo" em alguma data fixa é um truque que nunca funciona.
• Tratar estimativas como promessas levam a equipes conservadoras e resultados frustrantes.
• Tentar melhorar a "qualidade" das estimativas é uma atenção que poderia dar melhores resultados se voltados para melhorar a qualidade do produto.
• E assim por diante.

Naquele artigo, eu argumentei que o resultado desse foco é "Agile fraco". Em essência, equipes focadas em estimativas estão geralmente no lado fraco da balança entre custo e valor. Equipes melhores focam mais em valor e menos em custo. Eles ainda consideram custo, porque custo é um componente importante na entrega de valor. Mas valor é seu interesse primário.

É verdade que muitas equipes de primeira não estimam no real senso do termo. Eles trabalham em pequenas histórias, pequenas o suficiente que para conseguir um senso de progresso você pode apenas contabilizá-las. Eles trabalham nas coisas de maior valor primeiro - usando qualquer noção de valor que eles tem. Eles ajustam sua visão frequentemente, e ajustam no que vão trabalhar em seguida de acordo com o que está acontecendo. Eles trabalham para produzir um fluxo contínuo de software de valor, e eles entregam o mais frequentemente possível, normalmente diariamente.

Já que estimativa está frequentemente associado a equipes fracas e disfuncionais, e já que grandes equipes parecem trabalhar sem estimativas, muitos praticamentes de Agile fortemente resistem qualquer estimativa de qualquer tipo. E é uma coisa boa montar uma equipe - e uma organização - que é forte o suficiente para trabalhar sem estimativas. Mas isso é uma forma avançada de trabalho, nunca a forma para começar. Não é bom recusar a estimar, ou mesmo se sentir ressentido disso, em uma organização onde isso é necessário. Do contrário, nós precisamos aprender a fazer isso direito, de uma forma que influencie a organização positivamente.

Orçando Novos Projetos

Agora, vamos olhar a uma necessidade legítima, ajudando a organização a decidir se deve prosseguir ou não com um projeto.

Quando alguma coisa dá errado com nossa casa ou carro, e nós não temos todo o dinheiro do mundo, nós provavelmente recebemos estimativas para consertar essas coisas. Provavelmente consideramos alternativas: se o tampo do maleiro está riscado, devemos pintar novamente o carro inteiro para acertar a cor perfeitamente, apenas passar um spray no tampo, tentar polir os riscos, ou apenas viver com os riscos? Nós escolhemos a opção que parece ser o melhor uso do nosso dinheiro.

Pessoas de negócios orçando projetos tem o mesmo problema de alocar fundos. Eles precisam considerar como entregar o maior valor possível dentro do orçamento. Em uma pequena organização tentando criar maravilhosos produtos novos, a preocupação é ainda maior. Precisamos começar a gerar fluxo de caixa positivo antes do dinheiro acabar!

Em situações como essa, nós realmente precisamos ter estimativas. Precisamos saber se é uma decisão sábia ir em frente com o novo projeto. Pessoas de negócios já tem algumas estimativas em mente: quantas pessoas vão se interessar? Qual a porcentagem de prospects se tornarão compradores? Quanto os compradores vão pagar pelo produto?

Mas eles precisam decidir: podemos começar a trazer dinheiro suficiente para permanecer vivo antes do nosso dinheiro acabar?

O tomador de decisão sabe que todas essas estimativas são estimativas, e usa o melhor julgamento para colocar valor neles. Mas existe uma área chave que ele não conhece muito sobre: quanto desse produto pode ser feito, em qual data, por quanto dinheiro? Essa é uma questão técnica e isso precisa ser respondido por pessoas técnicas.

Sim, claro que nós também não sabemos. Nós realmente não sabemos quanto vai levar. Mas vamos encarar os fatos, nós temos uma idéia melhor de quanto tempo as coisas vão levar comparado ao pobre empreendedor, e ele precisa de nossa ajuda.

Eu acredito que nós conseguimos dar um chute melhor se vai levar uma semana, um mês, um trimestre ou um ano antes de começarmos a ter uma boa idéia de quão rápido conseguimos progredir. E esse chute, por mais abrangente que seja, é um chute melhor do que uma pessoa de negócios pode dar.

Não podemos somente dizer "Vamos tentar?" Parece que podemos dizer alguma coisa assim:

"Nosso equipe custa $10 mil por semana. Vamos começar a trabalhar nas partes mais importantes, mais arriscadas, mais informativas do seu produto, e criar um senso de quão difícil será e quão longo as coisas serão. Você nos verá construindo o que nos pediu. Você nos verá trabalhando. Você será capaz de decidir se quer continuar investindo ou parar."

Parece fazer sentido dizer que - a menos que seja os seus $10 mil do seu bolso saindo toda semana. Aí você tem mais perguntas. "Eu vou saber depois de uma semana? Eu vou ter que esperar um mês inteiro pra saber? Vou saber por Junho? Caraca pessoal, são uns $100 mil daqui até Junho. É dinheiro pra caramba! Me dêem um tempo aqui! Quanto que isso vai custar?"

Precisamos tomar as rédeas desse tipo de desafio. Devemos dar a resposta mais sólida que conseguirmos, mesmo quando não temos uma resposta absolutamente concreta.

Estamos pisando em areia. Como ficamos concretos?

A pergunta é, "Quanto tempo vai levar, e quanto dinheiro vai custar, para chegar num produto que as pessoas possam comprar?"

Gostaríamos de dizer, "Bem, comece a gastar algum dinheiro conosco, e se você se entediar, pare," mas isso não ajuda em nada. Podemos mudar essa idéia um pouco? Vamos começar com uma estimativa bem abrangente apenas para ter uma noção de onde estamos.

Nós provavelmente já temos alguma noção se vai levar uma semana, um mês, ou seis meses para fazer alguma coisa usável. Se é assim, vamos falar sobre isso. Nosso investidor já tem um valor em mente que ele pode gastar. Vamos descobrir quanto é isso, ou ter uma noção disso na conversa.

Suponha que nós imaginamos que talvez consigamos ter uma versão rudimentar mas usável do produto em seis meses, e o investidor está disposto a investir até $1 milhão até conseguir um fluxo de caixa positivo. $1 milhão é aproximadamente um ano do nosso tempo, e se levarmos 9 meses em vez de 6, precisaremos trazer $1 milhão em três meses para chegar a positivo. Vamos falar sobre isso. Quão rápido ele espera que o faturamento cresça com a primeira versão? Suponha que ele ache que o faturamento vá crescer rapidamente, de forma que ele se levarmos 9 meses, estamos bem. Isso soa arriscado para mim, mas parece que o projeto pelo menos parece bom o suficiente para explorar.

Lembre-se de como Agile funciona. Queremos que as pessoas de negócios estejam totalmente engajadas nas tomadas de decisão sobre gastar dinheiro baseado no que ele vê. Então vamos começar a pensar em selecionar funcionalidades, não apenas datas.

Estimativas que não vão te fazer se arrepender

"Ok, intuitivamente, nós achamos que podemos entregar uma versão inicial em seis meses, e achamos que se levarmos nove meses, o projeto seria viável. Isso parece bom, mas ainda soa arriscado. Odiaríamos ver você gastar tudo isso e chegar a lugar nenhum, e o que temos ainda são chutes grosseiros."

"Então vamos fazer o seguinte: vamos gastar duas semanas para produzir uma resposta mais concreta. Duas semanas vai lhe custar somente $20 mil, que é muito menos que $1 milhão. Nessas duas semanas, você vai trabalhar ativamente conosco nos aspectos mais importantes do produto. Algumas serão coisas de interface, algumas serão guiadas por riscos de negócio ou técnico que podemos prever agora. No final dessas duas semanas, nós decidimos se queremos continuar. Nosso trabalho será lhe mostrar, concretamente, o que podemos construir que nos convença se devemos prosseguir ou não. Seu trabalho será nos guiar descrevendo o que você quer, e trabalhar conosco para identificar riscos e preocupações."

"Se depois dessas duas semanas, as coisas parecerem ruins, nós saberemos disso e vamos recomendar que você pare. Se as coisas parecerem boas até então, vamos decidir juntos qual será o próximo ponto de decisão. Pode ser daqui a um mês, ou daqui a três meses. Francamente, estamos perfeitamente felizes de fazer isso a cada duas semanas."

"Sim, isso mesmo. A cada duas semanas vamos falar com você sobre o que fazer a seguir. Vamos fazer isso e mostrar para você. Se estiver bom o suficiente, continuarmos. Se não, paramos."

"Dessa forma, seu risco nunca será maior do que mis $20 mil. Você pode decidir se vai usar esse dinheiro para conseguir mais informação, para redirecionar seus esforços, ou ver se deveria gastar esse dinheiro de alguma outra forma."

"Podemos trabalhar dessa forma?"

Se ele disser sim, vamos começar. Se ele disser não, precisamos descobrir porque, e mesmo se esse projeto é para nós.

Isso é definitivamente estimativa, e é um tipo de estimativa que podemos fazer em conjunto com nossas pessoas de negócios em vez de em conflito com eles.

Nós estimamos, com alguma certeza, que podemos produzir informações úteis em duas semanas. Se acharmos que não conseguimos isso, melhor sugerir quatro ou seis ou oito semanas.

Mais do que isso, nós estimamos que um produto viável é provavelmente possível em seis ou nove meses. Se não tivéssemos nenhuma idéia, ou pior ainda, se sinceramente tivéssemos dúvidas disso, então não podemos legitimamente convidá-lo a descobrir - pelo menos não nos termos acima. Nós devemos a ele de dizer "Francamente, isso parece um projeto de dois, três anos para nós. Podemos estar errados: aqui está o que precisamos aprender para descobrir. Aqui está o que custaria para descobrirmos, e nossos melhores chutes agora é que a resposta será má notícia."

Algumas vezes temos uma boa idéia do que podemos fazer. Algumas vezes sabemos menos. De qualquer jeito, estimando o que sabemos, podemos desenhar experimentos - investimentos - que melhore nossa capacidade de decidir o que fazer.

Quando estamos falando de gastar o dinheiro dos outros, eu acho que devemos a eles pensar e agir dessa forma.

Isso é Estimativa, não Negociação!

Uma estimativa não precisa ser "Este projeto estará terminado na Terça, 14 de Maio, às 14:35h." Supõe-se que uma estimativa seja expressa com um intervalo de possibilidades. Seria perfeitamente OK dizer alguma coisa como, "Não vemos possibilidade de isso feito até Abril. Se tudo sair perfeito, podemos estar prontos até meio de Maio. Baseado na nossa experiência, estamos pensando em Junho, talvez Julho."

Se dizemos isso ou não, as chances são que sabemos disso, ou pelo menos suspeitamos. E se é isso que pensamos, o projeto precisa dessa informação. Entretanto, se colocamos dessa forma, seremos empurrados pra trás. Alguém vai nos desafiar para provar, sem sombra de dúvidas, que não conseguimos entregar até 30 de Abril, e se provarmos isso, eles dirão "Que tal 5 de Maio?" Bah, odiamos quando eles fazem isso. Então como podemos entregar informações que o projeto necessita sem jogar esse jogo?

Mova de Data Estimada para Velocidade Estimada

Vamos usar o método das Cinco Cartas de artigos anteriores, não para estimar uma data, mas para quebrar o projeto todo em sub-histórias pequenas o suficiente que nossa equipe faça, digamos, cinco delas em duas semanas. Claro que podemos acabar tendo apenas três prontas. Podemos ter seis mas duvidamos disso. Então chegamos numa estimativa em termos de velocidade:

"Quebramos o projeto em histórias menores. Acreditamos que com histórias deste tamanho, seremos capazes de fazer entre três a cinco a cada duas semanas. E ao fim de um período de duas semanas, tudo que fizermos estará visível, testado, integrado e funcionando. Então se forem cinco ou seis ou dois por semana, saberemos, e você saberá"

"Se você puder remover ou deferir algumas dessas histórias e ainda ter um produto viável, você terá o produto antes. Se puder simplificar, poderá ter o produto antes. Se adicionar histórias, ou tornar as coisas mais difíceis, você vai atrasar o produto pra depois."

"Depende de você. Podemos quebrar as coisas neste tamanho, podemos chutar nossa velocidade agora como sendo três itens a cada duas semanas, e você saberá a cada duas semanas o que está realmente acontecendo. Você pode usar essa informação para decidir o que fazer, o que deferir, a fim de você receber o melhor produto para quaisquer datas que escolher."

Ajude a Gerência a Aprender sobre Velocidade

Agora a gerência pode ainda querer negociar sobre isso conosco. Se eles tentarem adicionar os números para conseguir datas, e então começar a ajustar as datas, não negocie: devolva a conversa de volta à taxa de progresso. "A data depende de você. Se escolher fazer mais, será mais tarde. Se escolher fazer menos, será antes. Nós achamos que faremos entre três a cinco ítens a cada dusa semana. Podemos estar errados: se estivermos, você saberá tão cedo quanto nós."

Alguém pode tentar pressionar a velocidade. "Vocês não conseguem fazer sete a cada duas semanas? Assim poderiam terminar a tempo."

Lembre-se de como Agile funciona: desenvolvedores trabalham em um ritmo ótimo sustentável; os desenvolvedores não são responsáveis pelas datas; o lado de negócios é dona das datas, e é dona da responsabilidade de chegar nessas datas.

O trabalho dos desenvolvedores é entregar no melhor ritmo possível: "Nós achamos que conseguimos fazer três a cinco. Se conseguirmos por acaso ir mais rápido, você vai saber. Se formos mais devagar, você vai saber também. QUando vamos acabar depende disso, mas depende mais ainda, em quão pouco você nos dê para fazer. O que será colocado nessas datas depende de você. Você deve planejar em três a cinco itens a cada duas semanas, e checar o que está acontecendo de verdade."

Isso pode pressionar mais de uma vez para ir mais rápido. Mas temos os fatos à nossa disposição, da forma como estão. "Baseado na nossa experiência, teremos de três a cinco feitas. Não seria sábio assumir nada maior do que isso, porque provavelmente não vai acontecer. Se alguma coisa acontecer que nos faça ir mais rápido, todos nós saberemos e você poderá selecionar mais itens na versão."

Tudo isso, claro, tem muito mais a ver com comunicação, não sobre estimativa, e enfaticamente não sobre negociação. A estimativa foi trivial: fizemos logo no começo quando separamos os cartões. Agora estamos comunicando o que sabemos, o que chutamos, o que acreditamos.

Demos à gerência nossas melhores estimativas e taxas de produçõa, e nos comprometemos com elas, melhorando à medida que vamos evoluindo. Continuamos a deixar claro que o pessoal de negócios controla as datas escolhendo quanto trabalhos pedem.

Otimizando o Produto

Seja você a favor ou não de estimativas, você deve saber que Agile é sobre construir produtos incrementalmente, em boas condições, a partir do primeiro dia até o último dia, e tirar valor disso o mais cedo possível. Isso requer grandes capacidades técnicas, mas capacidades técnicas não são suficientes. As pessoas pagando por nosso trabalho precisam alocar seus recursos. Eles precisam gerenciar seu dinheiro, e eles precisam coordenar nosso trabalho com atividades e partes interessadas de fora da nossa equipe.

Para fazer isso de forma eficiente, eles precisa de informações de quanto tempo as coisas vão levar, que se traduz em quanto as coisas vão custar, e quanto tempo vai levar para começarmos a receber nosso dinheiro de volta. Eles precisam de informação que temos para realizar esse trabalho bem. O fato da nossa informação ser vaga, falha e incerta não é uma razão para não expô-la. Precisamos colocar nossa informação nas mãos deles, e fazer isso de forma que lhes dê a melhor oportunidade de usá-la da melhor forma possível.

Recusar a estimar não é a coisa certa de se fazer isso. Estimar é necessário, e comunicação efetiva da estimativa é necessária também.

A melhor coisa a fazer é desenvolver funcionalidades pequenas no melhor ritmo sustentável possível, e usar a informação gerada para ajudar as pessoas de negócios decidir o que pedir, e o que deferir. Para fazer isso, precisamos estimar. Nós dividimos história a tamanhos pequenos estimáveis, e estimamos nossa taxa de entregá-las. Esse tipo de estimativa não é mal de forma nenhuma: é incrivelmente útil e é o que as melhores equipes ágeis fazem.

Ron Jeffries desenvolve software há mais tempo do que qualquer pessoa viva. Ele possui graduações avançadas em matemática e ciências da computação, ambas ganhas antes de inteiros negativos terem sido inventados. Suas equipes construíram sistemas operacionais, compiladores, sistemas de bancos de dados relacionais, e diversas aplicações grandes. Os produtos de software de Ron produziram faturamento de mais de meio bilhão de dólares, e ele se pergunta porque não ganhou nada disso.

Envie feedback ao autor ou discuta o artigo no fórum da revista.

Se você sabe o que é Tail Call Optimization (TCO), provavelmente também já deve ter ouvido falar que Ruby não suporta TCO. Se você não sabe o que é 'tail call' vale definir:

Em ciência da computação, um 'tail call' é uma sub-rotina que acontece dentro de uma procedure como sua ação final; ela pode produzir um retorno que é então imediatamente retornada pela procedure que a chamou.

TCO também é chamado às vezes de Tail Recursion Elimination, que é uma parte de TCO na verdade. Esse nome é mais simples de entender. Todo programador sabe o que é uma recursão - uma função que chama ela mesma em algum ponto - e como isso deve ser evitado sempre que possível por uma versão iterativa, para fugir do perigo de estourar a pilha pois recursão tem limite.

O equivalente "hello world" de recursão é o bom e velho fatorial que, em Ruby, poderíamos escrever desta forma:

deffact(n)
  n == 0 ? 1 : n * fact(n-1)end

Dependendo da versão do Ruby que estiver usando ela vai estourar num número n não muito alto. No meu Macbook Pro, com Ruby 1.9.3-p392, essa execução recursiva estoura com stack level too deep (SystemStackError) no n = 8180.

Quem estudou Algoritmos e Estruturas de Dados aprendeu a tentar buscar a versão não-recursiva. No caso do Ruby temos a sorte dela ser expressiva para poder ser escrita da seguinte forma com a ajuda de closures:

deffact(n)
  sum = 1
  sum.upto(n) { |i| sum *= i }
  sumend

Esta versão vai aguentar valores muito mais altos que o vergonhoso 8180 da versão recursiva. Uma discussão que vi hoje o Rafael Rosa e o Henrique Bastos twitando fala sobre porque Python não suporta TCO. Então, curioso, resolvi investigar o que eu achava que sabia: de que Ruby também não tem TCO. Mas acabei encontrando esta issue de 5 meses atrás no Ruby Core sobre habilitar TCO que já existe no MRI 1.9 mas não é ativada por padrão.

Para possibilitar essa otimização, precisamos modificar a versão recursiva que mostrei antes para que ela não precise de um call stack, e para isso a última ação precisa ser direto a chamada recursiva. Então a nova versão (ainda recursiva) fica assim:

defself.fact(n, m = 1)
  n < 2 ? m : fact(n-1, m*n)end

No Ruby 1.9 você pode ativar o TCO e executar o código com tail call desta forma:

RubyVM::InstructionSequence.compile_option = {:tailcall_optimization => true,:trace_instruction => false
}RubyVM::InstructionSequence.new(<<-EOF).eval
  # código com tail call
EOF

Vamos fazer um teste com o seguinte código:

require 'benchmark'moduleTestdefself.fact_recursive(n)
    n == 0 ? 1 : n * fact_recursive(n-1)enddefself.fact_tail_call(n, m = 1)
    n < 2 ? m : fact_tail_call(n-1, m*n)enddefself.fact_iterative(n)
    sum = 1
    sum.upto(n) { |i| sum *= i }
    sumendenddeffact1(n)Benchmark.bm do |x|
    x.report { Test.fact_iterative(n) }
    x.report { Test.fact_tail_call(n) }
    x.report { Test.fact_recursive(n) }endend

fact1(8180)
fact1(10000)

Notem que vamos iniciar com o TCO desligado:tailcall_optimization => false e o resultado é o seguinte:

$ ruby factorial.rb
    user     system      total        real
0.030000   0.000000   0.030000 (  0.030289)
0.040000   0.010000   0.050000 (  0.056056)
0.030000   0.010000   0.040000 (  0.043861)
    user     system      total        real
0.050000   0.000000   0.050000 (  0.042917)
factorial.rb:14: stack level too deep (SystemStackError)

Vejam que rodando até o limite de 8180 temos pouca diferença entre as versões iterativa não-recursiva, recursiva com tail call e recursiva normal. Mas com o valor mais alto de 10000 as versões recursivas estouram como esperado.

Agora vamos ativar o TCO:

RubyVM::InstructionSequence.compile_option = {:tailcall_optimization => true,:trace_instruction => false
}RubyVM::InstructionSequence.new(<<-EOF).eval
  require 'benchmark'
  module Test
    def self.fact_recursive(n)
      n == 0 ? 1 : n * fact_recursive(n-1)
    end

    def self.fact_tail_call(n, m = 1)
      n < 2 ? m : fact_tail_call(n-1, m*n)
    end

    def self.fact_iterative(n)
      sum = 1
      sum.upto(n) { |i| sum *= i }
      sum
    end
  end

  def fact1(n)
    Benchmark.bm do |x|
      x.report { Test.fact_iterative(n) }
      x.report { Test.fact_tail_call(n) }
      x.report { Test.fact_recursive(n) }
    end
  end
EOF

fact1(8180)
fact1(10000)

Agora temos o seguinte resultado:

$ ruby factorial.rb
    user     system      total        real
0.030000   0.000000   0.030000 (  0.030832)
0.030000   0.000000   0.030000 (  0.033130)
0.030000   0.000000   0.030000 (  0.029922)
    user     system      total        real
0.040000   0.000000   0.040000 (  0.043725)
0.050000   0.000000   0.050000 (  0.046619)<compiled>:4: stack level too deep (SystemStackError)

Desta vez a versão com tail call sobrevive ao valor acima do meu limite de 8180 e a recursiva que não tem tail call estoura por causa da sequência de call stacks que ele é obrigado a fazer.

E podemos ir mais longe e chamar um valor bem maior como fact1(100_000):

$ ruby factorial.rb
    user     system      total        real
5.190000   1.290000   6.480000 (  6.474756)
5.650000   2.010000   7.660000 (  7.676733)<compiled>:4: stack level too deep (SystemStackError)

Novamente, podemos ver que a versão com recursão e tail call performance só um pouco pior que a versão iterativa não-recursiva.

Portanto, detonamos o mito de que Ruby não suporta Tail Call Optimization. Não sei ainda se existe algum efeito colateral mas pelo menos temos a opção de ativá-la e executá-la somente dentro da instância de RubyVM::InstructionSequence. Não consigo imaginar um caso de uso prático, então se souber de algum não deixe de comentar.

Muitos ainda devem ter dúvidas de onde colocar suas aplicações Rails. Nos últimos dias andei testando algumas alternativas.

Na prática está entre as opções:

1. Instalar do zero seu próprio servidor e se responsabilizar pela manutenção
2. Usar um PaaS (Platform as a Service) e deixar um serviço cuidar da infraestrutura por você

Em ambas as opções as peças mais importantes são:

1. servidor web (nginx, apache2)
2. banco de dados (SQL: PostgreSQL, MySQL; NOSQL: MongoDB, CouchDB, Redis, Riak), incluindo facilidade em escalar verticalmente (mais CPU/RAM) e horizontalmente (replicação)
3. load balancer (HAProxy), incluindo facilidade em aumentar os servidores web
4. opcionais (Memcached)
5. manutenção (aplicação de patches de segurança, backup)

No próximo artigo vou falar de outra opção que estou gostando, o AppFog, mas no geral o PaaS que oferece o melhor balanço entre funcionalidades, facilidade, serviços ainda é o Heroku. Se ainda não viu, leia meu artigo Enciclopédia do Heroku. A grande vantagem é realmente preocupação perto de zero com infraestrutura.

Tendo seu projeto, instale o Heroku Toolbelt e faça o seguinte:

# caso ainda não tenha feito login (uma vez só)
$ heroku login

# cria novo aplicativo e faz o deployment
$ heroku apps:create nome_do_seu_app --stack cedar
$ git push heroku master

De todas as funcionalidades a que mais se destaca frente aos concorrentes é a existência do Heroku Postgres que toda aplicação já tem por padrão e você pode escalar verticalmente com planos maiores. Na minha opinião essa é a funcionalidade mais importante que nenhum outro concorrente tem a não ser a Amazon com o RDS para MySQL.

Esse serviço é importante primeiro porque ele se preocupa com a manutenção por você, escalabilidade vertical (mais espaço, mais cache, mais conexões simultâneas), replicação "slave"/read-only com o recurso de Follows, backups e restores automáticos que você também pode manualmente fazer download dos dumps. O seguinte procedimento é tudo que você precisa fazer:

# para fazer backup e download do dump
$ heroku pgbackups:capture
$ curl -o latest.dump `heroku pgbackups:url`

# para carregar o dump na sua base local de desenvolvimento
$ pg_restore --verbose --clean --no-acl --no-owner -h localhost -U myuser -d mydb latest.dump

Pontos Importantes

Existem alguns pontos importantes que vocês precisam estar cientes antes de cair de cabeça no Heroku:

• não há MySQL, portanto se sua aplicação depende de SQL específica de MySQL, primeiro você será obrigado a reescrever para ser puramente ActiveRecord ou reescrever em SQL de Postgres.
• no plano "free" com 1 dyno, esse dyno é "reciclado" de tempos em tempos e quando vem uma próxima requisição existe o tempo de carga da aplicação que, dependendo do tamanho, pode dar um timeout e o usuário recebe um erro de "Application Error". Uma das formas de manter a aplicação no ar é usar serviços que monitoram HTTP e fazem requisições de tempos em tempos. Ou a forma "correta" que é pagar por pelo menos mais uma dyno
• os dynos tem tamanho fixo, aproximadamente o equivalente a 512Mb de RAM e 4 CPUs virtuais. Por isso a recomendação de usar Unicorn em vez de Thin e configurar para no máximo 4 workers, mas aí a limitação é o tamanho da sua aplicação. Mesmo uma aplicação pequena Rails pode consumir facilmente 128Mb, 256Mb ou mais de RAM. O uso de Ruby 2.0 pode economizar até no máximo uns 30% de memória graças ao recurso de Copy on Write.
• não há recurso de deploy com zero downtime. Quando você faz um deploy ele derruba todas as dynos e sobe todas de uma vez. Isso é necessário para manter a integridade dos dados (já que seu novo código pode ter alterado regras que afetam o banco). Por outro lado você não tem a escolha de fazer rolling deploys, onde web apps antigas vão sendo substituídas pelas novas sem derrubar as requisições atuais sendo atendidas (se você controla seu próprio servidor com Unicorn, existe o recurso de graceful restarts via sinal HUP). Se quiser experimentar, existe um recurso ainda não considerado estável chamado Heroku Preboot.
• não há acesso direto à máquina, e nem deveria mesmo existir já que o Heroku é quem se responsabiliza em dar manutenção na máquina. Mas você pode fazer coisas básicas abrindo uma conexão remota com bash ou direto executando algumas tasks rake ou comandos rails como heroku run rails console

Heroku "Router-Gate"

Existem alguns problemas que ainda estão sendo resolvidos. Algum tempo atrás a startup RapGenius descobriu um enorme problema no sistema de filas do Heroku aliada à entrada da stack Cedar. O Heroku se retratou e se desculpou. A situação é que o tempo total de espera para um usuário será o tempo de processamento da sua aplicação mais o tempo de espera na fila do Heroku (que em alguns casos pode tornar o tempo total até 5 vezes mais lento do que deveria). O paliativo para diminuir esse tempo é o seguinte:

• aumentar as dynos para o tamanho 2X de 512Mb para 1GB de RAM usando o comando heroku ps:resize web=2x
• esse novo dyno deve suportar um Unicorn com no mínimo 2 workers (cuidado com o tamanho da sua aplicação)

O problema é que a fila do roteador do Heroku manda as requisições aleatoriamente pras dynos que, por sua vez, também tem filas (nginx, unicorn). Significa que requisições que outras dynos menos ocupadas poderiam atender ficam represadas nas filas da dyno, que o roteador do Heroku não tem como gerenciar nesse momento.

Uma forma de "devolver" as requisições de volta ao roteador do Heroku, para que ele possa mandar para outra dyno, é usar o truque do Unicorn Killer cujo objetivo principal é evitar que workers cresçam indevidamente no uso de memória, obrigando o servidor a usar swap. Matar o worker o obriga a devolver as requisições e o roteador, teoricamente, tem chance de mandar para outras dynos (importante balancear número suficiente de dynos). Cuidado com os parâmetros, mas para habilitar o unicorn killer faça o seguinte:

# na Gemfile
gem 'unicorn-worker-killer'

# na config.ru
max_request_min =  ENV['MAX_REQUEST_MIN'].to_i || 3072
max_request_max =  ENV['MAX_REQUEST_MAX'].to_i || 4096

# Max requests per worker
use Unicorn::WorkerKiller::MaxRequests, max_request_min, max_request_max

oom_min = ((ENV['OOM_MIN'].to_i || 192) * (1024**2))
oom_max = ((ENV['OOM_MAX'].to_i || 256) * (1024**2))

# Max memory size (RSS) per worker
use Unicorn::WorkerKiller::Oom, oom_min, oom_max

Mude os tamanhos mínimo e máximo de 192 e 256, respectivamente, de acordo com sua aplicação. Junte isso ao número de workers configurado no config/unicorn.rb. O número de workers x o tamanho máximo de memória não pode ultrapassar 1GB de RAM.

Preços

Na prática, o que mais importa é quanto isso vai custar. Uma aplicação bem pequena teria minimamente o seguinte:

• 2 dynos (com uns 2 ou 3 workers Unicorn, o que lhe daria um máximo de 6 conexões simultâneas, ou seja USD 106.50)
• Heroku Postgres Dev (USD 0.00)
• PG Backups Auto - One Month Retention (USD 0.00)
• Sendgrid Starter (USD 0.00)
• Memcachier Developer (USD 0.00)

Ou seja, dá pra fazer pequenas aplicações gastando em torno de USD 50 a USD 100 por mês. Eu sei que alguns comparam preços com hospedans compartilhadas como Dreamhost. Não façam isso, hospedagem compartilhada é um péssimo modelo para qualquer site maior que um institucional de páginas estáticas. USD 100 por mês é considerado centavo no mundo de startups sérias.

Um produto em produção, com tráfego, dados, pode chegar ao seguinte:

• 3 dynos (2x, USD 178.50)
• 7 workers (7 x USD 36.00)
• Heroku Postgres Fugu (USD 400)
• Hostname SSL (USD 20.00)
• Memcache 250Mb (USD 40)
• New Relic Professional (~ USD 560.00)
• Pusher Big Boy (~ USD 200.00)
• Redis To Go Medium (~ USD 170.00)
• SSL Endpoint (USD 20.00)
• Websolr Platinum (USD 100.00)

Total: ~ USD 2,000.00

Parece caro? Considere isso muito barato. Esse é o cenário de um produto em produção. Quanto custaria para você o custo da infraestrutura (preços da Amazon AWS) e equipe de sysadmins 24x7 em tempo integral?

Notem que dá para diminuir os workers - se usar Resque - em no mínimo a metade ou mais se implementar o novo Sidekiq. Em projetos novos, não use Resque e nem muito menos Delayed Job, vá direto para Sidekiq.

Em particular, um dos elementos mais caros de qualquer instalação em produção é de longe o New Relic. Veja que nessa lista, ele é sozinho quase 30% do total. Se considerar só o custo das dynos o New Relic custa o dobro! O Banco de dados é mais barato, e ele é altamente utilizado!!

Estou à procura de alternativas ao New Relic pois apesar dele ser bom, considero que é muito caro para uma ferramenta que precisamos ver só de vez em quando para tomar alguma ação.

Mesmo com todas essas considerações, na dúvida, eu não recomendaria nenhum outro serviço. Existem diversas outras opções que pretendo explorar mas de cara, comece com o Heroku.

Como disse no artigo anterior, na dúvida, use o Heroku. Mas depois disso, alguns perguntam se existem outras alternativas. De fato existem várias. Agora é a vez de outra opções, o AppFog foi uma das mais interessantes que usei.

Ela tem algumas características semelhantes e outras diferentes do Heroku. Vamos a alguma delas:

• semelhante à maioria dos PaaS como Heroku, o AppFog também utiliza Amazon AWS EC2 por baixo. Mas diferente do Heroku ela permite escolher algumas das zonas geográficas e também outros IaaS como HP OpenStack e Microsoft Azure. Pra maioria das pessoas usar a zona US-EAST-1 que é a padrão é o suficiente.
• semelhante ao Heroku, você pode controlar tudo por linha de comando, basta instalar com gem install af e ler esta documentação.

• semelhante ao Heroku, ele também tem add-ons mas numa quantidade ainda muito inferior. Alguns dos principais estão lá como LogEntries, Blitz, Memcachier, Mailgun e outros.

• diferente do Heroku, ela vem pré-configurada com um número maior de perfis de aplicação, Java Grails, Java Spring, Node Express, PHP Wordpress, Python Django, Ruby on Rails e muito mais.

• diferente do Heroku, a precificação não é por número de instâncias. Em vez disso ele funciona num modelo "pré-pago" (mais sobre isso abaixo)
• diferente do Heroku, ela tem mais serviços próprios como MySQL, PostgreSQL, MongoDB, Redis, RabbitMQ

Precificação

A parte da precificação é onde a AppFog mais se diferencia dos demais, ao mesmo tempo oferecendo vantagem e desvantagem.

O que eles fazem é oferecer pacotes pré-pagos que inclui:

• limite de quantidade de RAM compartilhada
• limite de quantidade de instâncias
• limite de tamanho dos bancos de dados
• limite de endpoints SSL
• limite de RAM compartilhada entre os bancos de dados
• limite de transferência de gigabits na rede
• limite na quantidade de requisições por segundo

Por exemplo, tem 3 camadas no limite de 2GB: o free (que só permite domínio *.af.cm), o que não tem suporte a SSL e o que tem suporte a 1 endpoint SSL. Respectivamente o preço varia de USD 0, depois USD 20 e USD 50.

Esses 2 GB podem ser distribuídos entre servidores web, e até 8 instâncias de serviços (bancos de dados). O que dá pra fazer com isso? Em uma conta de USD 20 eu coloquei 7 sites pequenos, respectivamente com:

• 2 instâncias de 320Mb cada
• 1 instância de 160Mb
• 1 instância de 128Mb
• 1 instância de 256Mb
• 1 instância de 128Mb
• 1 instância de 192Mb
• 1 instância de 128Mb

Lembram que um dyno no Heroku é de 512Mb? O problema de um dyno fixo é que sites pequenos desperdiçam espaço e sites grandes não cabem. No caso do AppFog ele me deixa decidir quanto quero alocar para cada site até o mínimo de 128Mb. Então, em 2Gb ou eu faço 16 sites de 128Mb cada, como posso fazer uma única instância de 2GB de uma vez só.

Agora vem o problema: se eu quiser usar mais de 2GB (no momento, nessa conta que estou testando já usei 1.66GB e 7 dos 8 serviços) o próximo plano é de 4GB com 16 serviços por USD 100. Acima dele é de 16GB com 64 serviços a USD 380, e o maior é de 32GB com 128 serviços a USD 720.

Eu não diria que é caro, mas o preço salta em pulos muito grandes de um para o outro. No Heroku, acima de USD 36 por uma dyno, posso ir escalando em pulos menores de menos de USD 36. O modelo de negócios do Heroku é "on-demand" o do AppFog é "pré-pago". O pré-pago tem preço de entrada menor mas pode ficar caro mais rápido do que o Heroku dependendo do tipo de aplicação.

Na teoria os preços do Appfog são bem mais em conta que o Heroku. No caso anterior, estou gastando 10 instâncias de Heroku a aproximadamente USD 323, mais USD 400 de banco de dados. No AppFog eu teria que escolher provavelmente o plano de 16GB, que custa USD 380. No Heroku, o próximo salto com mais uma dyno iria de USD 323 para USD 431. No AppFog eu precisaria pular pro plano de USD 720.

A grande maioria dos sites não vai planos muito maiores que o de 4GB, que custa USD 100, o equivalente a 2 dynos no Heroku, sem contar banco de dados. Nesse caso o AppFog pode ficar no mínimo 2 vezes mais barato. Quando chegar no plano dos USD 380 ou USD 720 é que pode fazer um pouco mais de diferença, mas mesmo assim o AppFog ainda parece continuar mais barato.

Porém onde o Appfog sai mais barato, também não tem algumas funcionalidades cruciais.

Maior Problema

O maior problema do AppFog são os serviços de bancos de dados. Primeiro de tudo: ele não oferece serviços de backup e restore. Ele espera que você faça seu próprio backup, o que é um absurdo. Ou seja, se você tem dados de missão crítica, não use o AppFog até ele ter no mínimo backup e SLA para tempo de resposta em emergência.

Tem muita pouca informação sobre o tuning dos bancos de dados. Eu espero que não seja a configuração padrão que vem na instalação, que são sempre muito ruins para produção. O Heroku Postgres configura as instâncias com ignorantes GIGABYTES de cache.

Não dá pra escalar os bancos horizontalmente, fazendo master-slave. No Heroku Postgres existe a opção de Follows.

Como disse no artigo anterior, a funcionalidade matadora do Heroku é definitivamente o Heroku Postgresql. Eu não recomendaria o AppFog para clientes por causa dessa enorme deficiência no suporte a banco de dados. Não adianta nada conseguir escalar instâncias web se o próximo gargalo vai ser o banco de dados. É o dilema mais antigo da literatura web e o que a maioria dos PaaS ainda não resolveu decentemente.

Setup e Deployments

Depois de instalar a gem o processo é bem simples:

# só a primeira vez
$ gem install af
$ af login

Para criar a aplicação, a partir do diretório o código do seu projeto, faça:

af push sua_aplicacao --runtime ruby193

Ele vai fazer várias perguntas que devem ser simples de se responder:

Would you like to deploy from the current directory? [Yn]: y
Detected a Rails Application, is this correct? [Yn]: y
1: AWS US East - Virginia
2: AWS EU West - Ireland
3: AWS Asia SE - Singapore
4: Rackspace AZ 1 - Dallas
5: HP AZ 2 - Las Vegas
Select Infrastructure: 1
Application Deployed URL [teste.aws.af.cm]:
Memory reservation (128M, 256M, 512M, 1G, 2G) [256M]: 128M
How many instances? [1]:
Bind existing services to 'teste'? [yN]: n
Create services to bind to 'teste'? [yN]: y
1: mongodb
2: mysql
3: postgresql
4: rabbitmq
5: redis
What kind of service?: 2
Specify the name of the service [mysql-e4aa3]: teste-db
Create another? [yN]: n
Would you like to save this configuration? [yN]: n

Agora, toda vez que atualizar o código, para fazer um novo deployment faça:

af update sua_aplicacao

Existe um problema que o Appfog diz que sabe que existe mas continua me irritando profundamente. Depois de tentar rodar a aplicação ele precisa fazer o processo de rodar migrations, executar asset precompiling, e isso pode demorar. Parece que o comando fica preso e dá timeout, e com isso o aplicativo fica num estado não finalizado. Você precisa ficar tentando rodar o update repetidas vezes até finalmente ele conseguir subir.

Um dos problemas pode ser que sua instância esteja muito pequena em tamanho de memória e a tarefa de asset precompiling pode consumir muita RAM no processo e dar crash por falta de memória. Se a aplicação for muito grande em assets uma coisa que pode ser feita é gerar o precompiling localmente antes do update. "Parece" (não confirmei) que ele sobe os assets no update e aí o precompiling (aliado ao turbo-sprockets) não precisa repetir o processo no deploy.

Novamente, como no Heroku, ele não tem opção de zero downtime, para não tirar a aplicação do ar durante um deployment, então use um horário de pouco movimento para essas atualizações, especialmente por causa de problema atual de timeout de conexão.

A diferença do plano grátis para o plano inicial de USD 20 é que só no plano pago você pode apontar seu domínio. Para mapear a aplicação faça:

af map sua_aplicacao www.sua_aplicacao.com.br

E no seu serviço de DNS aponte o naked domain (sem subdomínio) como um redirect para o www e faça o www ser do tipo CNAME apontando para cname01.aws.af.cm. Esta documentação explica em mais detalhes.

Tunnel

Uma opção que inicialmente é interessante mas depois é bem chata é em como se conectar diretamente no banco de dados ou como rodar tarefas rake por exemplo. No Heroku é muito simples como expliquei no artigo anterior, no AppFog é um pouco burocrático.

Pra começar, uma coisa que não mencionei é o AppFog é construído sobre o CloudFoundry.org, o PaaS da VMWare que tem partes open source. Na Rubyconf Brasil 2012 o Martin Englund apresentou essa plataforma, assista à gravação da palestra.

Voltando ao assunto, a forma para acessar seus serviços é usar uma funcionalidade chamada caldecott. Em essência você pode criar um servidor que vai servir de túnel entre você e seu serviço, mapeando uma porta local. No caso ela usa a porta 10000 do seu localhost.

Para abrir um túnel é simples, apenas execute:

af tunnel

A partir daí basta escolher qual serviço você quer se conectar:

1: foo1-db
2: foo2-db
...
7: foo7-db
Which service to tunnel to?: 7
Getting tunnel connection info: OK

Service connection info:
  username : usM...XDS
  password : pCS...sN1
  name     : d92...05e
  infra    : aws

Starting tunnel to tinyclone-db on port 10000.
1: none
2: mysql
3: mysqldump
Which client would you like to start?: 1
Open another shell to run command-line clients or
use a UI tool to connect using the displayed information.
Press Ctrl-C to exit...

Se for um mysql você pode conectar assim:

mysql -u usM...XDS -ppCS...sN1 -h localhost -P 10000 d92...05e

Obviamente, vai aparecer um usuário, senha e nome do banco diferentes. Anote o seu e faça a conexão.

Agora, digamos que você queira executar alguma tarefa rake, ou mesmo abrir o console do rails. Para isso você vai precisar ter mais trabalho. Edite o arquivo config/database.yml local do seu projeto e adicione a seguinte configuração no final:

appfog:
  adapter: postgres
  encoding: UTF8
  pool: 5
  database: d92...05e
  username: usM...XDS
  password: pCS...sN1
  port: 10000

Agora você pode executar comandos assim:

RAILS_ENV=appfog rails console

Cuidado, se precisar de configurações de ambiente, copie o config/environments/production.rb para config/environments/appfog.rb

Não é confortável como um heroku run rails console mas funciona.

Paliativo para o Backup

Não ter um backup me deixa nervoso. Como paliativo (e um paliativo bem ruim, deixemos claro) fiz o seguinte script:

#!/bin/env ruby# add to your crontab:# * 5,13,22 * * * backup_appfog.rbAPPFOG_BIN = "#{ENV['HOME']}/.rvm/gems/ruby-1.9.3-p392/bin/af"BACKUP_DIR = "#{ENV['HOME']}/Documents/Appfog-Backup/"
dbs = %w(foo1 foo2 foo3)
dbs.each do |db|
  puts "backup: #{db}"`#{APPFOG_BIN} export-service #{db}> #{BACKUP_DIR}#{db}.log`end

dbs.each do |db|
  log = File.read("#{BACKUP_DIR}#{db}.log").split("\n")
  url = log.select { |line| line =~ /^http/ }.first
  puts "download: #{url}"`curl -o #{BACKUP_DIR}#{db}.dump #{url}`end

Customize para seu gosto (mudando nomes de diretórios e bancos de dados, claro) e adicione no crontab mais ou menos assim:

* 5,13,22 * * * /seu_diretorio_home_/.rvm/rubies/ruby-1.9.3-p392/bin/ruby /seu_diretorio_home_/backup_appfog.rb

Novamente, mude a frequência (no exemplo, ele só vai executar às 5h, 13h e 22h), local do executável do Ruby (dependendo se está instalado nativo, com RVM ou RBENV) e nome do script.

O dump que ele baixa é um arquivo em formato gz (tipo Zip). Use a ferramenta do mysql ou pg_restore ou outro dependendo do banco para restaurar local, por exemplo.

Outra forma (que não dá pra colocar no cron e rodar automaticamente) é abrir um túnel como expliquei acima e usar diretamente o mysqldump e pg_dump a partir dos dados de conexão que ele fornece.

Conclusão

Como disse antes, estou rodando já 7 sites na conta de USD 20 da Appfog. Como podem imaginar não são sites pesados e respondem rápido ao tráfego.

Me incomoda muito as atuais deficiências do banco de dados. Não ter backup é o pior deles, seguido por não conseguir facilmente escalar horizontalmente criando slaves read-only.

A ferramenta de linha de comando tem dezenas de opções, muitas até que o Heroku não tem, mas ela tem esse bug horrível de dar timeout e deixar o servidor em estado instável o que prejudica o downtime em todo deployment. Eles precisam consertar isso logo.

O estilo de "pré-pago" não funciona pra todo mundo. No meu caso, como não pretendo ir muito acima dos USD 50 com isso, é o suficiente. Pra muitos sites pequenos, o próprio plano de USD 20 vai ser mais do que suficiente e nesse sentido ele tem um custo muito mais barato do que o Heroku.

Escalar os servidores web horizontalmente é simples, mas novamente vai estar limitado a quanto o banco aguenta, e nesse momento não sei dizer porque ele não documenta isso (pelo menos eu não achei). Também gosto do fato de estar tudo implementado numa plataforma robusta como o CloudFoundry, que só tem a evoluir principalmente depois que a aquisição da Pivotal Labs pela EMC gerou o Pivotal One.

No geral é uma boa solução, especialmente se você quiser misturar num mesmo ambiente coisas como PHP (que o Heroku não suporta), com banco de dados MySQL (novamente, que o Heroku não suporta).

Outra coisa que muita gente se confunde: "preciso do meu próprio servidor, instalado do zero, porque tenho vários serviços não-web que preciso instalar e manter na mão, como SOLR, postfix, etc"

Não, a menos que você tenha uma operação grande, não precisa. Utilize os diversos Software as a Service (SaaS) que existem. Muitos deles oferecem planos gratuitos para pouca utilização - pois obviamente, se você vai utilizar bastante é porque sua aplicação fatura o suficiente pra pagar a infraestrutura, caso contrário porque investir nela?

O fator "caro" ou "barato" não é o valor em dólares, é o que você espera da aplicação que está fazendo. Se for hobby, para estudo, você não precisa se preocupar pois não tem consumidores pagantes a quem tem que responder. Se a aplicação gera dinheiro, significa que tem consumidores pagantes, e se há pagantes a infraestrutura, sua manutenção e suporte são custos, e custos devem ser equacionados com o valor cobrado, senão não faz sentido. Se é uma operação real, o tempo gasto dando manutenção e suporte na infraestrutura e serviços próprios deveria estar sendo melhor gasto planejando funcionalidades que atraiam mais usuários pagantes. O seu valor hora deve ser maior que o valor hora de serviços mundanos de infraestrutura, se não for, o modelo de negócios está errado.

Vejamos algumas opções de bons SaaS a considerar.

Enviar emails

Jamais configure um servidor de emails a menos que seja um especialista nisso. Muita gente contrata uma VPS, coloca uma aplicação que usa o sendmail da máquina e comeca a mandar email. Não sabe sequer o que é um DKIM ou SPF, muito menos que o IP da máquina vai cair numa blacklist de spam. Não vale a pena administrar múltiplos servidores, com múltiplos IPs, com múltiplas regras de filtros de envio. Use um serviço com o SendGrid. O plano básico de 40 mil créditos custa meros USD 9.95 por mês.

Full Text Search

Pra começar, "SELECT X FROM Y WHERE TEXTO LIKE '%XPTO%'", NÃO É SEARCH DECENTE. #prontofalei

A comunidade Java já nos fez o favor de deixar um legado importante, o famoso Apache Lucene, um dos melhores engines de full text search. E sobre essa engine existem duas peças de infraestrutura excelente, o primeiro, mais antigo e portanto com um ecossistema maior é o bom e velho Apache SOLR, o mais recente é o Elasticsearch. Na prática, pra maioria das aplicações web, tanto faz qual vai escolher.

Na dúvida, escolha utilizar o serviço Websolr. Por USD 20 por mês você pode subir até 250 mil documentos e ter até 2 índices gerenciados. Aplicativos médios provavelmente vão precisar chegar até o plano Platinum, de USD 100 por mês com 2 milhões de documentos e 10 índices.

É um pouco salgado, mas se você precisa de search decente, precisa pelo menos de SOLR. Agora, instalar um SOLR não é complicado, assim como instalar um PostgreSQL também não é. Mas de novo, a menos que você seja um sysadmin experiente, não coloque dados de seu cliente onde ninguém vai estar gerenciando. Se você instalar, você vai ter que dar suporte e se responsabilizar por tempos de queda do serviço, escalar em múltiplos nós se precisar de mais performance, recuperar backups se alguma coisa quebrar.

Mensagens Assíncronas

Sim, é super-hipster (ou pelo menos foi, até o ano passado), implementar seu próprio servidor de Websockets com Node.JS. Na prática, em produção, em aplicativos sérios, não faça isso. Está repetitivo mas novamente: se não for um bom sysadmin ...

Existem várias opções, dentre as que eu mais gosto está o Pusher. Um que está aparecendo mais agora é o PubNub. No caso do Pusher, USD 19 por mês para ter 100 conexões simultâneas é um bom número. No caso do PubNub, USD 15 por mês para até 100 conexões também, um pouco mais barato. A diferença é na escala, quanto mais cresce o Pusher parece ser melhor no custo/benefício.

Para utilizar existem diversos clients pré-prontos para múltiplas linguagens, existe um client em javascript para os browsers, com diversos polyfills (WebSockets, Flash, Long polling, etc). Chega a ser trivial implementar. Não vale a pena fazer seu servidor de websockets do zero.

Logging

Colocar em produção não é só instalar e acabou. Logs devem ser analisados constantemente sempre que possível. Muita gente simplesmente apaga os logs ou os ignora completamente. Essa ferramenta já não é para iniciantes, sua aplicação precisa já estar no ar com um bom tráfego para fazer sentido pagar para usar.

Um dos mais conhecidos e recomendados é o Papertrail, por USD 7 por mês você pode transferir até 1GB de logs. Outro que começou a ganhar mais tração é o Logentries. A vantagem do Logentries é que 1GB por mês é grátis, permitindo pesquisar só até a última semana de logs. Pra guardar por 1 mês, 1GB de logs, você começa pagando USD 5 por mês e o preço sobe segundo os fatores quantidade de GB tranferido x quantidade de GB armazenados por mês. Ou seja, o Logentries é um pouco mais barato que o Papertrail. Como ambos tem período de teste, use os dois para saber qual se adequa melhor ao que você quer.

Eu particularmente não fiz nenhum uso avançado de logs ainda, então não tenho um preferido entre os dois.

Monitoramento e Análise

Este é um ponto que eu ainda não estou satisfeito. O melhor ainda é o New Relic só que ele é tão caro que eu não recomendo a menos que você tenha sobrando mesmo. Ele salta de USD 24 por mês por servidor para USD 124 por mês por servidor. Com 2 servidores ou dynos, você já paga nada menos que USD 248 por mês!! Nem recomendo o plano Standard porque ele é capado demais pra ser útil pra alguma coisa.

Se for pra algo no nível do New Relic Standard, então é melhor usar serviços como o StatsMix, Hosted Graphite, Librato. Não tenho um favorito, então se alguém tiver boas experiências para compartilhar sobre isso, não deixe de comentar!

Teste de Carga

Quer saber quanto sua aplicação aguenta de tráfego antes de abrir o bico? Uma opção que eu conheço e gostei Blitz, por USD 40 você começa com 40 créditos, onde cada crédito equivale a 1 minuto e mil usuários. Então 40 créditos dá 10 mil usuários por 4 minutos. É um bom teste.

Outros

Existem diversos outros serviços que devem ser considerados. Nos artigos anteriores já disse que o Heroku tem serviço de PostgreSQL, que o AppFog também tem serviços de MySQL, que a Amazon com AWS tem o RDS (que suporta MySQL, Oracle e SQL Server).

Para DNS existem dois muito bons hoje em dia que recomendo, o Zerigo que eu uso e outro que já me recomendaram muitas vezes que e o DNSimple.

Outros mais comuns são de analytics como o Google Analytics mas hoje existem outros como o MixPanel para web e mobile, o KISSmetrics.

Estes foram apenas alguns exemplos considerados bons de SaaS que você pode depender para ter Service Level Agreements (SLA) razoáveis, para que nenhum cliente precise te ligar de madrugada num domingo a noite porque seu servidor resolveu dar crash e você não tinha procedimentos de recuperação automáticos implementados.

A opção mais antiga, antes de existirem os Platform as a Service (PaaS) como Heroku, AppFog, OpenShift e outros são os Virtual Private Servers ou VPS. Os termos confundem pois costumamos chamar de "cloud" as soluções que caem nas categorias SaaS (serviços), PaaS (plataforma), IaaS (infraestrutura) e muitos tendem a deixar VPS numa categoria à parte.

VPS são máquinas virtuais, assim como um VirtualBox, Parallels, VMWare na sua máquina local, só que hospedado no data center de alguém. Eu particularmente acho que VPS está na mesma categoria que IaaS.

Seguindo o modelo Amazon AWS a diferença entre seus EC2 e os VPS é que um VPS tende a se comportar mais como um servidor físico. Você controla ações que seriam de hardware como reboot, shutdown. Uma vez que uma VPS é criada e ligada, ela permanece ligada.

Um EC2, ou um dyno Heroku, são máquinas "voláteis". Elas podem ser "recicladas" sem que você precise saber disso. Ou seja, elas podem ser desligadas, clonadas, movidas para outro servidor físico. O tipo de controle de um IaaS é ser "elástico". A melhor forma de ser elástico é não depender da máquina ou do armazenamento e tornar simples recriar máquinas a partir de receitas (como de Chef) ou de imagens (AMI, VMI). Para recriação, os arquivos que compõe a aplicação não deveriam mudar.

Por isso mesmo, seja colocando uma aplicação no AWS EC2 ou num Heroku, a prática está em fazer coisas como uploads serem enviadas a um serviço de armazenamento permanente externo, como o Amazon AWS S3. Ou então montar um disco separado que é uma das opções com o Amazon AWS EBS (Elastic Block Store), de forma que novas instâncias possam montar esse disco separado (bom para bancos de dados).

A arquitetura da Amazon oferece os meios também para cenários em múltiplas zonas geográficas (multi AZ - multi-availability zones), o que em muito aumenta a disponibilidade do seu serviço, obviamente por um bom preço. A parte boa da solução da AWS é que os serviços que ela monta sobre sua infraestrutura usufruem dos mesmos benefícios. Por exemplo, o Amazon RDS (Relational Database Service) é o serviço de banco de dados MySQL, Oracle ou Microsoft SQL Server gerenciado pela Amazon. Uma das vantagem é que se você escolher, seu banco de dados pode estar distribuído no esquema multi AZ, espalhado em múltiplos data centers fisicamente diferentes, geograficamente separados, para a máxima disponibilidade em casos de serviços de missão crítica.

Enfim, deve estar claro que para a máxima flexibilidade a melhor solução é usar um IaaS robusto como a Amazon AWS. Concorrentes incluem o mais recente Microsoft Azure. O Rackspace Open Cloud quer ir nessa direção também, mas ele oferece bem menos. Não é necessário ter tudo que a Amazon para ser um "IaaS", ao pé da letra, se for uma "infraestrutura oferecida e gerenciada como serviço", é um IaaS, por isso eu disse que considero muitos do serviços de "VPS" também como IaaS. Se olha a lista na Wikipedia verá que ele lista muitos deles juntos.

Virtual Private Server

Vou considerar como VPS a funcionalidade de manter uma máquina permanente (não-volátil) com armazenamento de bloco permanente (não-S3), com rede privada entre as máquinas virtuais, como "VPS".

O termo VPS existe há muito mais tempo que o termo IaaS. Historicamente falando, o conceito de dividir os recursos da máquina física entre múltiplos usos existe desde o tempo dos mainframes. Qualquer OS que você esteja usando hoje, seja Windows, Linux ou OS X, é capaz de criar múltiplos usuários, executar processos em paralelo. Depois surgiu o formato onde é possível "virtualizar" o OS inteiro, onde cada usuário ou processo "sente" como se estivesse numa máquina física isolada.

Para controlar as máquinas virtuais (criar, desligar, etc) existem os "hypervisors", os monitores que existem diretamente sobre o hardware (XenServer, KVM, Hyper-V) ou dentro do OS que boota primeiro (VirtualBox).

Sobre ele são criadas máquinas virtuais que podem ser totalmente virtuais ou o que chamamos de para-virtuais. No primeiro tipo, o OS na máquina virtual realmente "acha" que está sozinha no hardware, é a mais lenta das opções. No segundo tipo, o OS sabe que existe o hypersor e se comunica com ela, o que a torna bem mais performática. Exemplos de opções de paravirtualização são Xen, OpenVZ.

Existe um terceiro tipo que eu diria, é um passo anterior à total máquina virtual, que é onde o kernel do OS tem a capacidade de dividir espaços virtuais sem precisar um segundo OS sobre um hardware totalmente virtual. Nesse caso dizemos que o kernel é capaz de criar uma "prisão", literalmente um "jail", onde os programas que rodam nesse espaço não deveriam saber sobre os outros jails ao seu redor. É uma opção de menor overhead (pois não precisa de um hardware virtual inteiro e outro OS instalado) mas não é 100% isolado (na prática o comportamento é como se fosse). Um exemplo é se existir algum exploit do programa num jail que consiga dar crash no kernel, todos os outros jails caem. Num sistema virtualizado, o programa com exploit conseguirá no máximo derrubar a máquina virtual onde está mas não as outras no mesmo hypersor. Nessa categoria de jails temos alguns conhecidos como chroot ou o mais recente LXC.

Alguns VPS usam soluções de paravirtualização, outros que preferem economizar recursos de hardware usam jails. Uma das vantagens da leveza do jail é poder, dentro de uma máquina virtual já paravirtualizada, ainda dividir uma segunda vez usando LXC sem grandes perdas. É praticamente uma Inception.

Os que eu mais usei até o momento na categoria VPS paravirtualizado são o Linode, Rackspace Cloud e WebbyNode. Se não me engano, todos eles utilizam máquinas Xen com XenServer.

Todos eles oferecem os mesmos serviços básicos, dentre eles:

• criação e gerenciamento de máquinas virtuais paravirtualizadas em Xen com acesso a root
• upgrade vertical facilitado (mais CPU, mais RAM)
• diversos sistemas operacionais (32-bits, 64-bits, Linux, Windows)
• serviços de fácil configuração de load balancer, DNS (IPs públicos, IPs privados de rede reservada interna)
• coisas essenciais como snapshots, procedimentos de backup agendados, monitoramento dos recursos
• suporte 24x7 (todos tem um tempo de resposta bom para tickets de problemas e dúvidas, nunca fiquei sem resposta)

No fundo é esse o essencial que se espera de qualquer bom VPS que se preze. Os preços só dos servidores variam mas precisa adicionar os diferentes serviços, facilidades, etc. Então não se atenha somente ao preço unitário de servidor:

• Linode: 1GB RAM, 8 CPU (1x priority), 24GB HD - USD 20.00/mês
• WebbyNode: 1GB RAM, 45GB HD - USD39.90/mês
• Rackspace: 1GB RAM, 1 CPU, 40GB HD - USD 43.80/mês

Pra dar uma noção, vejamos uma configuração mais com cara de "produção":

• Linode: 4GB, 8 CPU (4x priority), 96GB - USD 80.00/mês
• WebbyNode: 4GB, 180GB HD - USD 159.99/mês
• Rackspace: 4GB, 2 CPU, 160GB - USD 175.20/mês

Notem que quando se diz "CPU" estamos dizendo "vCPU" ou "CPU virtual". Ou seja, dentro da máquina virtual você vai enxergar a quantidade de CPUs, mas elas estão na prática competindo recursos do CPU de verdade com outras máquinas virtual. É isso que quer dizer o fator de "prioridade" da Linode. Apesar do número de vCPU ser mesmo entre os dois planos do exemplo, o segundo plano dá mais prioridade do CPU real para o tipo mais caro do que para o mais barato, obviamente. No caso da WebbyNode não havia denominação de CPUs na tabela de planos.

O valor de USD 20/mês por uma máquina de 1GB de RAM é o que muitos consideram mais "barato" do que um Heroku ou AppFog. Mas como disse, no caso da AppFog você tem 2GB pelos mesmos USD 20/mês. No caso do Heroku inicia em USD 36/mês por 1 dyno. Portanto, não é tão mais "caro". Começa a ficar mais caro quando se adiciona outros serviços como um banco de dados mais parrudo como um Heroku Postgres Crane que é USD 50/mês, ou o Amazon AWS MySQL instância pequena que pode chegar a USD 64/mês, ou com serviços como Websolr Cobalt que é USD 20/mês.

No exemplo, uma aplicação que precise acima da versão "free" no Heroku pode custar: USD 36 (dyno) + USD 50 (postgres) + USD 20 (websolr) = USD 106/mês; no AppFog custaria: USD 20 (já com banco de dados) + USD 20 (websolr) = USD 40/mês.

Digamos que você configure tudo na mão na Linode com uma máquina de USD 20/mês. No cenário mais "caro", você vai gastar USD 80/mês. Se você precisar dedicar 4 horas por mês dando alguma manutenção, significa que você está vendendo sua taxa horária a USD 20/hora. No caso da AppFog sua taxa horária seria de USD 5/hora. A justificativa é clara: você deveria estar não consumindo horas nisso e pensando em como fazer sua hora valer o triplo, quádruplo disso. Existe uma frase popular que diz o seguinte:

"Penny wise, Pound Foolish"

Traduzindo pra português seria algo como:

"Quem economiza centavos perde dólares"

Agora cuidado com a interpretação! Do jeito que eu disse parece que estou dizendo para só usar coisas caras em vez de economizar com o mais barato. De jeito nenhum! A única coisa que estou dizendo é que não existe uma única medida, a única coisa que faz sentido é custo/benefício, é a resposta à pergunta: "Vou ter o valor sobre o que estou pagando?"

Seu carro é um chevet 1981 caindo aos pedaços que male-male liga? Se te oferecerem um seguro barato de R$ 10/mês, ele vale a pena?

A resposta - caso esse cenário absurdo pudesse acontecer - poderia ser: "óbvio que não, é um pau velho!" Eu diria: "depende!" Digamos que o dono desse carro o use pra trabalhar e, com ele, consiga tirar R$ 100/mês. Só que o carro pode falhar a qualquer momento e se parar, não leva menos de 2 semanas pra reparar. Significa que ele vai perder no mínimo R$ 50/mês. Fora que a taxa de frequência é de pelo menos 3 vezes por semestre. Se num sementre ele gastaria R$ 60 num hipotético seguro e se parar as 3 vezes ele vai perder R$ 150, o seguro mais do que faz sentido.

Mesma coisa com servidores. Se seu cliente vale USD 20, coloque-o num servidor de USD 20. Se sua hora vale USD 5 e você não tem nada a fazer pra ganhar mais por hora, gerencie você mesmo.

Ou outro cenário mais comum: você está trabalhando num projeto pessoal, não tem compromissos com ninguém, está usando a oportunidade para estudar e aprender. USD 20/mês é hiper barato para se capacidar num categoria de trabalho que pode lhe render USD 40 ou mais por hora no futuro. Nesse caso não estamos falando nem de custo, nem de despesa, nem de gasto, mas de investimento.

Qual VPS?

Na prática, a WebbyNode é a menor das 3 ofertas, mas tamanho não é documento e nunca tive problemas com eles. Porém eles não possuem uma coisa importante para quem pretende escalar horizontalmente: load balancer. Porém, como eles tem a oferta de IP privado entre servidores da mesma conta, você mesmo pode instalar uma máquina de HAProxy e balancear entre os servidores web. Não é o ideal mas dá para fazer.

O Linode implementou o NodeBalancer a USD 20 extras por mês. Parece uma boa opção para balancear seus serviços rapidamente.

Da mesma forma a Rackspace o Cloud Load Balancer On-Demand, iniciando a USD 10.95 extras por mês. Ambos os balancers da Linode e Rackspace funcionam de forma similar.

Não sei se eles usam um load balancer via software simples como HAProxy ou algo mais robusto e sofisticado como o bom e velho F5 BIG-IP. Se tivesse que chutar eu diria que a Linode usa o HAProxy e a Rackspace usa o F5 ou Barracuda ou Cisco ou todos :-)

O Rackspace é o mais caro, mas por investir e usar a plataforma de IaaS OpenStack ele é bem mais sofisticado e oferece bem mais opções. É quase um Amazon AWS simplificado ao principal. Uma das coisas que ele tem que mais me interessa é o Cloud Database que - segundo eles - é melhor do que o Amazon RDS. Como já devem ter lido nos meus artigos anteriores sobre Heroku, AppFog, já devem ter entendido o quão importante é um bom serviço gerenciado, robusto, seguro e escalável de banco de dados.

Por causa disso minha escolha - caso precise garantir um bom serviço específico de banco de dados - seria colocar na Rackspace Cloud.

Para produtos menores, que tem 1 ou 2 servidores (recomendado, mínimo de 1 web, 1 banco) tanto o WebbyNode quanto Linode oferecem bom valor pelo preço.

Começando a pensar como um Sysadmin

Como já disse diversas vezes, a menos que você tenha uma boa experiência e conhecimento tendo trabalhado como sysadmin em um grande data center, não se responsabilize pela saúde de infraestrutura com um cliente pagante. Delegue o serviço e repasse os custos.

Ser um sysadmin é muito mais do que saber dar um apt-get install em pacotes. Para uma breve introdução a instalar um ambiente Rails completo do zero, leia meu artigo Ruby e Rails no Ubuntu 12.04 LTS Precise Pangolin.

Fora isso você precisa no mínimo:

• Firewall - o básico de iptablesé essencial e não, deixar porta de MySQL aberta na internet pública é uma péssima prática. Já vi isso e é um desastre esperando para acontecer. E novamente, não faça "copy e paste" de uma configuração que já existe. É o mesmo que colocar um cadeado que todo mundo tem uma cópia da chave, ou usar um cadeado que um estranho que te deu. Você pode estar deixando coisas abertas sem saber.

• Tuning de Banco de dados - todo banco de dados, na configuração padrão, é horrível. E todos sem prática basicamente fazem um apt-get install mysql-server e dão por encerrado. No mínimo - no mínimo! - comece a estudar o site da Percona e a uma configuração um pouco melhorzinha pelo wizard deles. Mas mesmo só isso não é suficiente, você precisa saber monitorar os serviços, avaliar a utilização dos recursos, processamento e customizar os parâmetros de acordo com seu servidor e sua aplicação. Não é algo que se faz uma vez e esquece. PostgreSQL também precisa de tuning. Tem aplicações que falham porque não conexões suficientes disponíveis no banco. Ou estouram a máquina porque tem demais e consome todos os recursos. São múltiplos fatores a se preocupar.

• Daemons - tem gente que inicia uma aplicação Rails com Unicorn executando unicorn config/unicorn.rb & e larga assim! Ou seja, quando o servidor precisar reiniciar por alguma razão o Unicorn não vai subir. Você obrigatoriamente precisa e um init script (/etc/init.d/) ou se estiver no Ubuntu um script de Upstart (/etc/init/) para que o OS saiba como subir sua aplicação. Um exemplo para Resque que uso é assim:

description "Resque worker configuration. Run with ID"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on shutdown

respawn
respawn limit 5 20

instance $ID

script
  HOME_DIR=/home/minha_app
  APP_ROOT=$HOME_DIR/apps/minha_app/current
  PIDFILE=$HOME_DIR/apps/minha_app/shared/pids/resque-$ID.pid
  LOGFILE=$HOME_DIR/apps/minha_app/shared/log/resque-$ID.log
  echo $$ > $PIDFILE
  chown meu_user:meu_grupo $PIDFILE
  chown meu_user:meu_grupo $LOGFILE
  exec su -c "export PATH=$HOME_DIR/.rbenv/shims:$HOME_DIR/.rbenv/bin:$PATH; cd $APP_ROOT; bundle exec rake environment resque:work QUEUE=* RAILS_ENV=production PIDFILE=$PIDFILE >> $LOGFILE 2>&1" minha_app
end script

Esse é um exemplo rústico (obviamente mude minha_app e outros parâmetros de acordo com o que você usa).

• Monitoramento - daemons podem morrer, o Upstart cuida de vários aspectos disso mas não de tudo, e em muitos casos você pode precisar de uma ajuda extra. Nesse caso recomendo o Monit. Não recomendo usar God ou semelhantes pois fica minha pergunta: "God monitora seus daemons, e quem monitora God?" Monit é escrito em C, leve, robusto, bem testado, raramente dá problema. Um exemplo de um trecho de configuração de Monit é assim:

check process memcached with pidfile /var/run/memcached.pid
    start program = "/etc/init.d/memcached start"
    stop program = "/etc/init.d/memcached stop"

check process postfix with pidfile /var/spool/postfix/pid/master.pid
    start program = "/etc/init.d/postfix start"
    stop program  = "/etc/init.d/postfix stop"

check process resque-0 with pidfile /home/meu_user/apps/minha_app/shared/pids/resque-0.pid
    group resque
    start program = "/sbin/start resque ID=0"
    stop program = "/sbin/stop resque ID=0"
    if changed pid 6 times within 6 cycles then stop

Se por acaso um serviço cair e ele não se recompor, você pode tentar subir. Se ele não subir em algumas tentativas pare de tentar subir e avise alguém. Enfim, várias estratégias que podem ser configuradas dependendo do serviço. Novamente, você precisa compreender muito bem o comportamento de cada serviço antes de criar essas estratégias.

E não deixe só por isso. Coloque sistemas de monitoramento para ficar constantemente avaliando a saúde do seu sistema. Recursos como CPU, RAM, disco, tráfego (in e out), daemons rodando, etc. Você precisa saber o comportamento do seu sistema em condições normais e em condições extraordinárias. Coisas simples como não saber configurar um mero logrotate e deixar seus logs consumirem todo o espaço em disco.

• Backup - todo bom sistema tem como agendar tanto imagem/snapshot completo da máquina quanto especificamente de serviços como banco de dados. Você precisa dos dois. Precisa inclusive testar procedimentos de restauração - erro mais comum é agendar backup e quando precisa descobrir que ele não restaura como esperava, ou que você esqueceu de selecionar tudo que precisava colocar no backup. Cuidado que tem algumas opções onde o backup é guardado na mesma máquina que você está "backapeando". Obviamente nem preciso dizer que é uma péssima idéia: se sua máquina der problema, seu backup vai ficar inacessível. Sempre jogue o backup em algum lugar externo. Mantenha backups rotacionados, diários, semanais, mensais para fins de auditoria se precisar. Nunca, jamais, guarde dados sensíveis como número de cartão de crédito ou senhas como texto!!!

• Disaster Recovery - seu sistema caiu. O que aconteceu? Você precisa ter os meios de realizar diagnósticos rápidos (sistemas de monitoramento), avaliar o que deu errado na raíz (condição do erro), criar novos procedimentos para que o mesmo erro não se repita. Mais do que isso, já ter pronto procedimentos a serem seguidos para cada tipo de situação. Um exemplo: jamais fazer uma atualização do binário de banco de dados sem antes fazer um backup completo dos dados.

Existem muitos outros fatores a se considerar, mas esse é o mínimo. Eu não sou um sysadmin experiente, mas o básico que sei é o suficiente para entender que infraestrutura é algo que deve ser levado a sério. O famoso "está rodando"é totalmente insuficiente. "Rodar" é muito simples, qualquer idiota consegue. Manter de pé e, principalmente, recuperar rapidamente e com integridade se algo der errado, é que diferencia os adultos das crianças.

Finalmente, existem várias opções. Avalie bem o que cada serviço oferece de acordo com os requerimentos funcionais da sua aplicação e do seu cliente e escolha. A vantagem é que hoje existem opções para todos os gostos e tamanhos.