App Engine e Django: No! hell!

Ultimamente tenho evangelizado a Plataforma como Serviço (do inglês PaaS – Plataform as a Service) Google App Engine (GAE), utilizando a linguagem Python. Uma pergunta me é feita de forma recorrente: “Renzo, é possível rodar Django no App Engine? Funciona bem?”. Isso era de se esperar, visto que Django é o framework web full-stack mais famoso dessa linguagem.

Versão curta:

Sim, é possível utilizar o Django no GAE com o porte não oficial: 

https://developers.google.com/appengine/articles/django-nonrel.

Contudo, você encontrará várias limitações:

http://djangoappengine.readthedocs.org/en/latest/installation.html

Na prática, você vive no pior dos dois mundos: não consegue utilizar nem o Django nem o GAE 100%, ficando com uma solução capenga. Então não use o Django no GAE!

Se você quiser usar o Django, use em um stack padrão para ele. Seja Heroku, Amazon ou Digital Ocean.

Se quer usar App Engine, use com suas apis. Apesar do medo do “vendor-lock-in”, em 4 anos nunca sofri com isso. Se for para portar para outro host, melhor é usar o Appscale (http://www.appscale.com/) do que Django. Use um framework full-stack feito exclusivamente para a plataforma:

https://github.com/renzon/tekton

Versão Longa:

DJango é um framework feito com SQL em mente. Suas apps, painel de adminstração, ORM e scaffolding dependem fundalmentalmente desse tipo de banco para funcionar 100%. Assim, querer portá-lo para NoSQL me lembra a célebre frase “para quem só conhece martelo, tudo é prego”.

Um dos grandes atrativos para iniciantes é o painel de adminstração. Aliado ao scaffold, é possível prototipar rapidamente aplicações web. Contudo, ao tentar rodar o DJango-Admin no GAE, as limitações do Datastore (https://developers.google.com/appengine/docs/python/ndb/) não permitem o uso integral do painel. Além disso, a plataforma em si já provê um painel de adminstração próprio, mesmo que mais rústico.

Mas as limitações desse banco existem por uma razão: escalabilidade. Elas estão lá para permitir que sua aplicação escale sem haver necessidade de alterar o código. E o fato é que depois de conversar com engenheiro de grandes sites, como Facebook e Globo.com, conclui que mesmo trabalhando com SQL, várias dessas limitações impostas acabam sendo necessárias nesse tipo de banco para se atingir uma grande escala. Como exemplo a eliminação de joins para facilitar o cache:

Outra grande vantagem do Django é seu ecossistemas de apps (módulos). Elas resolvem problemas recorrentes apenas com a instalação de uma biblioteca. Para exemplifcar, procurei no Google: “app django voting” e consegui uma para resolver votações online: https://code.google.com/p/django-voting/. Contudo, uma vez que se baseiam em Django + SQL, elas também não funcionarão 100% no GAE. Basta a app precisar de um simples join e sua funcionalidade não irá funcionar.

Tendo então comprometidas as duas grande vantagens, sobra ainda uma outra muito interessante: geração e validação automática de formulários a partir dos modelos. Isso é extremamente útil, evitando replicação de código e reduzindo sua complexidade. Porém, para utilizar os formulários, pelo menos o ModelForm, é necessário utilizar os modelos do Django.

Ao utilizar o ORM do Django, e algumas outras apis, você irá perder uma grande vantagem do ndb: chamadas assíncronas (https://developers.google.com/appengine/docs/python/ndb/async). Com elas é possível paralelizar as diversas buscas que devem ser feitas em banco de dados durante uma requisição. Assim é otimizado o uso de seus recursos gerando economia para seu bolso, uma vez que o modelo de cobrança é proporcional ao tempo de uso. Logo, mais uma vez um recurso não será utilizado 100%.

Ok, se te convenci nesse ponto de que usar Django no GAE é “martelar parafuso”, então a pergunta lógica a ser feita é: “O que uso para desenvolver?”

Quando comecei a usar a plataforma, o projeto Django-nonrel não existia. Da mesma maneira, o micro framework Flask também não. Mas o que percebi, acompanhando discussões Flask versus Django na comunidade Python é que microframeworks, como o primeiro, são preferidos por devs mais experientes, pela liberdade de escolha que proporcionam. Mas para devs iniciantes, um framework full-stack é mais adequado. E a razão disso é muito simples: para um dev iniciante, é melhor contar com as decisões feitas por profissionais mais experientes dentro do framework do que bater cabeça tentando criar suas soluções.

Essa conclusão então me chamou a atenção para a pergunta recorrente do início do post, que aqui repito: “Renzo, é possível rodar Django no App Engine? Funciona bem?”. Acabei meditando melhor, deixando meu preconceito contra frameworks full-stack de lado, tentando entender o que realmente essa pergunta queria dizer. Como fruto desse pensamento, acabei traduzindo a pergunta para “Existe uma forma de automatizar o código no GAE da mesma forma que faço com o Django?”. E a reposta é sim.

A solução então foi adaptar minha biblioteca, o Tekton. Ele foi construído em cima do framework padrão da documentação do App Engine, o webapp2. Sua versão inicial tinha a mesma filosofia do Flask. E por conta do que comentei sobre esse tipo de framework, essa é uma opção não familiar para devs iniciantes ou àqueles que conhecem as facilidades do Django.

Passei então a analisar os pontos fortes do Django e também do Rails. Minhas conclusões:

1. Seria legal ter scaffold para prototipação
2. Seria legal ter validação automática de formulários a partir de modelos
3. Seria legal ter a criação de código html a partir de modelos
4. Seria legal ter um ecossistema de apps mínimas para começar, e ir acrescentando outra com o tempo
5. Seria legal fornecer uma arquitetura para permitir o uso das API's assíncronas do Google, ao mesmo tempo em que se construa apps isoladas como as do Django
6. Seria legal documentar todas ferramentas
7. Seria legal criar uma comunidade em volta desse framewok

Para as primeiras 4 questões, segue o vídeo:

Para as demais:

Apps: 

Até agora escrevi 5 apps:

1. GAEBusiness. Arquitetura para camada de negócio que permite separar apps e ainda sim executar código utilizando as vantagens da API assíncrona;
2. GAEGraph. Lib que permite modelagem de dados no banco como um grafo. Prove várias features interessantes, como recuperação de nós, salvamento entre outras. Isso utilizando memcache para aumentar performance e reduzir custos;
3. GAECookie. App de segurança de cookie para validação de sessão e para evitar ataques CSRF;
4. GAEPermission. Plataforma de login com Google, Facebook e Passwordless. Também prove camada de segurança por lista branca (white-list) para controlar permissões em alto nível;
5. GAEPagseguro. Plataforma de integração com pagseguro.

Todas essas features podem ser conferidas em https://pt-dot-tekton-fullstack.appspot.com/ e também em http://adm.python.pro.br/

Quanto a documentação, vou reescrever todo o livro https://leanpub.com/appengine para conter essa nova abordagem. Após isso vou documentar todas apps no Github.

Por fim, fica a criação da comunidade. É isso que começo fazer agora! Assim, se você quiser participar desse projeto ou tirar dúvidas, fica o endereço do fórum para você se filiar:

https://groups.google.com/forum/#!forum/tekton-web

Até o próximo post!

Sistema de Login sem Senha

Ano passado meu amigo Dênis Costa me enviou um post fantástico sobre um sistema de login sem senha. A ideia principal é: “Para que pedir uma senha ao usuário se ele vai esquecê-la?”. Ou seja, se o “esqueci minha senha” vai ser utilizado com frequência, porque não simplesmente enviar um link de login por e-mail toda vez que usuário quiser acessar o sistema? Achei a ideia genial.

Procurei por alguém que oferecesse o login sem senha como serviço, aos moldes de um “login com Facebook”. Não encontrei. Decidi então desenvolver o Passwordless. Além de se poder utilizar como serviço, o projeto é livre:

https://github.com/renzon/pswdless

No processo de desenvolvimento mapiei os status para logar o usuário:

1. Usuário pede para fazer login em um site;
2. Site envia chamada para Passwordless;
3. Passworldless envia e-mail em nome do site;
4. Usuário acessa e-mail e clica no link;
5. Passworldless envia noticação ao site.
6. Site efetua o login

Desenhando o diagrama de sequência:

Além desse fluxo, também são importantíssimos os requisitos de segurança.

O primeiro deles é evitar o envio de spam. Isso foi mitigado criando um intervalo de tempo mínimo, atualmente 30 minutos, para que se possa enviar um e-mail de login para o mesmo usuário. Segue o teste automático:

def test_spam(self):
        site = mommy.make_one(Site, domain='www.pswd.com')
        user = mommy.make_one(PswdUser)
        ndb.put_multi([site, user])
        create_login = CreateLogin(user, site, 'hook')
        create_login.execute()
        # time.sleep(3)  # giving time because eventual consistency
        validate_cmd = ValidateLoginCall(site.key.id(), site.token, 'http://www.pswd.com/pswdless',
                                         user.key.id())

O segundo requisito seria proteger o link de login. Para isso foram implementadas as seguintes medidas:

1. Todo link é único, contendo um token aleatório e assinado via hash;
2. Todo link tem validade. Se em 10 minutos o usuário não clicar nele, ele fica inválido;
3. Todo link é descartável. Depois de utilizado, não mais é possível fazer login com ele.

Para todas essas medidas foram construídos testes automáticos:

class ValidateLoginLinkTests(GAETestCase):
    def _assert_error(self, token):
        validate_cmd = ValidateLoginLink(token, None)
        validate_cmd.execute()
        self.assertDictEqual({'ticket': 'Invalid Call'}, validate_cmd.errors)

    def _assert_wrong_status(self, status):
        login = Login(status=status, hook='https://pswdless.appspot.com/foo')
        login.put()
        cmd = client_facade.sign_dct('ticket', login.key.id())
        cmd.execute()
        self._assert_error(cmd.result)

    def test_invalid_token(self):
        self._assert_error('invalid token')

    def test_already_clicked(self):
        self._assert_wrong_status(LOGIN_CLICK)

    def test_already_got_detail(self):
        self._assert_wrong_status(LOGIN_DETAIL)

    def test_not_existing_login(self):
        cmd = client_facade.sign_dct('ticket', 2)
        cmd.execute()
        self._assert_error(cmd.result)

Depois de um certo tempo, outro amigo, o Giovane Liberato, acabou me enviando alguns links sobre o assunto:

1. https://medium.com/cyber-security/9ed56d483eb
2. http://lab.vtex.com/blog/como-matamos-a-senha/

Interessante notar a análise no segundo, onde colocaram dados sobre a aceitação dos usuários a um sistema de login sem senha de um comércio eletrônico.

Mas e você, qual sua opinião sobre um sistema de login sem senha?

Até o próximo post.

Primeiro ano de ITA

Após a grande batalha de 2003, em janeiro do ano seguinte seguimos do RJ para o ITA no meu carro eu, Alan, Papel e Raissan. Dada minha experiência no Naval, cheguei no CTA de “guarda alta”, pronto para trotes pesados.

O veterano que nos recebeu foi Átila, da turma 07. Tudo muito tranquilo, falou que deveríamos escolher um apartamento, mas que não poderíamos ficar todos juntos, 2 no máximo por ap. A razão disso era enturmar todos os ingressantes, evitando a formação de panelas.

Perguntei então sobre a rotina, se tinha revista no apartamento. Ele respondeu que o apartamento era nosso e que apesar de o ITA estar em uma base militar, ele não tinha a rotina de milico. Você não é obrigado arrumar sua cama ou até mesmo ir a aula. Ao saber disso, pensei: “Isso vai ser uma colônia de férias”.

Ficamos então eu e Raissam no apartamento 316. Lá já estava o Reginaldo José, vulgo Beraba, que recentemente ficou famoso por hackear o Facebook. Depois chegaram o Thiago (Granola) , Joaquim (Mantega) e Marcelo Gomes (Muskito).

Durante o primeiro mês ocorria a chamada integração. Durante o período os calouros eram reunidos para “bostejos”, que são bate papos onde veteranos explicam o funcionamento do ITA e seus valores. Aconteciam algumas brincadeiras, mas depois dos trotes do Naval, aquilo era muito tranquilo.

Além disso havia instrução militar no CPOR. No primeiro ano todos alunos são militares, visando cumprir o serviço obrigatório. Mas sendo a maioria dos alunos compostas por civis, ou seja, quem não optou por ser militar no vestibular, as instruções eram bem suaves.

Apesar de eu achar tudo ótimo, a maioria dos meus amigos de turma não estava acostumados com as novidades. Morar sozinho era um desafio. Os apartamentos eram velhos e com vários problemas. Certa vez chouveu e o esgoto inundou minha vaga e a do Raissan. Muitos reclamavam do trote. Mas enfim, para quem morava em alojamento, tinha que arrumar a cama todo dia e ir para aula fardado, o CTA e o alojamento (H8) eram um paraíso.

Terminado o período de integração começaram as aulas. Nesse período apenas tínhamos que ir no CPOR às segundas de tarde. E isso recebendo um salário, não sei como ainda tinha gente que reclamava. Nesse início mais uma vez boa parte da turma se frustrou. Alguns professores deixavam a desejar. Por conta da fama do ITA, a maioria pensava que só existiriam profissionais espetaculares. Em particular ,eu não me frustrei por já ter passado o mesmo Naval.

Depois de estudar nessas duas instituições e conhecer muitos amigos de colégios militares, cheguei na fórmula das boas escolas:

1. Processo seletivo acirrado
2. Média de aprovação alta
3. Provas difíceis, independente da qualidade do professor
4. Regras rígidas, com muitas culminando em desligamento.

A média no ITA é 6,5. São feitas em geral 3 provas: primeiro e segundo bimestre e mais uma prova final. Se não atingir a média, o aluno deve fazer segunda época no próximo semestre e atingir a média. Isso quer dizer que se você ficou com 6 de média, precisa tirar 7 na segunda época, com 5 é necessário 8 e assim sucessivamente. Mas mesmo que você atinja a média na segunda época, há ainda mais uma regra. Se você tirar menos de 8,5, você fica com o 'I' de insuficiente em seu currículo. Se durante todo o ITA você acumular mais do 5 Is, você é desligado. Se você repete maid de suas matérias, você tem que refazer todos as outras do semestre. Você só pode trancar duas vezes: uma por nota e uma por saúde. Na prática, em minha época o pessoal acochambrava para deixar você usar o “continue” da saúde mesmo que a razão verdadeira fosse nota.

Mas são essas dificuldades e o fato de morar juntos que faz com que os integrantes da turma sejam muito unidos. Os mais safos ajudam aqueles com maior dificuldade e assim se formam amizades para uma vida inteira.

Um valor interessante, herdado das escolas militares, é muito interessante: a Disciplina Consciente (DC). Basicamente o conceito pode ser traduzido como honestidade, praticado através da confiança nesse valor. Como exemplo, é comum um professor passar provas e não ficar supervisionando a sala. Mais ainda: dar uma prova para se fazer em casa, com tempo de duração e sem consulta. Isso cria um ambiente ímpar. Mas como as regras são rígidas, quebrar esse valor é algo muito sério. Alunos que são pegos colando são expulsos, apesar de algumas vezes já terem acochambrado e apenas trancado alunos pegos com a boca na botija. Mas isso é muito incomum.

Enfim ,o primeiro ano do ITA foi relativamente tranquilo para mim. A boa base que o Colégio Naval me deu, mais 1 ano de cursinho Roquette (infelizmente falecido há poucos dias antes da publicação desse artigo) contribuíram para isso.

Infelizmente no fim do ano (talvez tenha sido no segundo ano) o Raissan trancou por conta de notas. Além disso, estávamos divididos em dois grupos no ap. Granola e Beraba estudavam e eram regrados. Os outros, eu incluso, tocávamos o zaralho: vídeo game até tarde, séries de TV, saidões. Por conta disso, acabamos decidindo por dividir o ap no segundo ano. Mas o segundo ano fica para um outro post.

Enfim, o ITA é um lugar incrível onde você encontra pessoas sensacionais, fazendo amizades para a vida inteira. As regras rígidas, estudo puxado e a DC é fórmula para a fama da instituição, materializado pelo assédio das empresas para contratarem os que se graduam na instituição. Além disso, esse fatores contribuem para a “máfia iteana”. Ela consiste em uma rede de contatos de ex-aluno que costuma se ajudar, principalmente no quesito mercado de trabalho.

Enfim, um lugar espetacular que tive o privilégio de estudar e que aconselho a todos que se interessarem e estiverem dispostos a pagar o preço exigido pelo foco no estudo.

Nesse ano de 2004 ainda cheguei a ir no baile da Escola Naval. Foi interessante encontrar os velhos amigos de Colégio Naval e poder dar a volta por cima. No ano seguinte e também fui ao baile, com histórias mais interessantes para contar, mas fica para o próximo post.

Como Publicar um Livro na Internet

Conhece aquele ditado: “Há três coisas que todo ser humano deve fazer na vida para se sentir realizado: escrever um livro, ter um filho e plantar uma árvore”? Pois é, faço parte dessa turma. No início de 2014 achei que era hora de começar a escrever. Avaliei algumas opções para publicação e acabei optando por uma independente (self publishing).

Acabei encontrando o espetacular site de publicação independente LeanPub. O primeiro aspecto que achei fantástico foi poder fazer o lançamento de maneira “lean”. Isso quer dizer que é possível testar o mercado muito antes da conclusão do trabalho. O site provê uma “landing page” na qual você pode perguntar quanto as pessoas estariam dispostas a pagar. Fiz o lançamento depois de terminar o primeiro capítulo do App Engine e Python, você programa e o Google escala! Foi muito motivador fazer a primeira venda. Com certeza dá muito mais energia para escrever mais.

Outra funcionalidade fantástica é a geração do livro. Após o cadastro da conta o site compartilha uma pasta com você através do Dropbox. Dessa forma não há necessidade de se fazer upload e dowload. Ela contém os arquivos para geração do livro. O formato de escrita é o Markdown. Ou seja, para quem está acostumado a editar esse tipo de arquivo no GitHub, a curva de aprendizado é super suave. Com apenas um clique você tem a geração em formato epub, mob e pdf. É muito estimulante poder ver seu trabalho em um leitor eletrônico como o Kindle.

A simplicidade na geração do material é tanta que pensamos em fazer um teste no Python Pro. Começando pelo App Engine Fundamental, vamos ver se funciona fornecer as várias versões como material de apoio ao curso. Dessa maneira o aluno aprende com aulas ao vivo, exercícios e mais o livro para se aprofundar.

Enfim, tem vontade de escrever sobre algum assunto? dificuldade para publicar não é mais desculpa!

Se você gostou desse artigo, ajude um escritor independente curtindo a fan page: https://www.facebook.com/pythonappengine.

Até o próximo artigo.

Screencast no Linux

Screencast no Linux

Depois que comecei a fazer o curso AppEngine e Python: você programa e o Google escala!, muita gente me perguntou como eu estava fazendo o screencast no Linux. Então vou comentar as ferramentas que estou utilizando e algumas que usei, mas não funcionaram bem.

Qualidade do áudio

A primeira coisa que você deve prestar atenção quando for gravar screencast é o aúdio. Os microfones dos laptops atuais servem para você conversar no Skype ou Hangout. Já para gravação deixam a desejar, por conta dos ruídos e chiados.

Para resolver esse problema, comprei um microfone USB da Microsoft (Obs: o hardware da M$ costuma ser muito bom, apesar do Windows =P). Como a entrada de microfone comum (p2) costuma não ser muito boa para captação, escolhi esse modelo USB.

Captura de vídeo

Inicialmente eu tentei utilizar o Record my Desktop mas houve problemas. Ele grava utilizando a extensão ogv e o arquivo fica enorme. Além disso, na hora de fazer recortes durante a edição, o aúdio ficava dessincronizado com o vídeo. E quanto maior o recorte, pior ficava, inviabilizando o seu uso.

Existe também a opção de linha de comando que meu amigo Tony Lâmpada postou em seu blog. Mas ainda sim pode ser problemático se você estiver usando um monitor adicional.

Por fim o programa que estou usando hoje é o Kazam . Ele já possui opção de fazer o encoding em mp4; permite fazer o setup dos inputs de aúdio e vídeo, em termos harware; quadros por segundo e também que se faça o screencast de uma porção limitada da tela. Disparado o melhor que econtrei.

Edição de vídeo

Para edição, estou utilizando o Kdenlive. A interface de edição dele é simples e lembra um pouco a interface do do Camtasia, apesar de não ter tantos recursos. Mas para recortes é perfeito.

Screenshot

Apesar de não ter relação direta com vídeo, uso o Shutter para fazer screeshots. Ele permite fazer a captura de uma janela específica, economizando o tempo de você ter que recortar a imagem. Possui também recurso de timer para que você possa fazer a captura de acesso a menus de contexto de programas, o que é impossível apenas utilizando o printscreen.

Enfim, se o software era sua desculpa para não gravar aquele curso bacana que está na sua cabeça, agora isso não é mais problema.

Abraços e até o próximo post.

Google App Engine: a história de um prisioneiro feliz

No início de 2009 eu trabalhava em uma startup com Java, utilizando frameworks muito conhecidos da plataforma, como Spring e Hibernate. Decidi então, no fim do ano, construir um site de transmissão de fotos, visando entender todo o processo de desenvolvimento.

No início, comecei a fazer o setup análogo ao que já conhecia: instalei Maven e Nexus, comprei um host Java. Demorei cerca de um mês, utilizando meu tempo livre, para configurar todas ferramentas. Mas a aplicação iria transmitir muitas fotos pelas rede, meu cliente pretendia fazer promoções em sites de compras coletivas. Eu estava certo de que meu servidor não iria aguentar essa carga.

Foi justo nessa época que um amigo me apontou a solução. Ele comentou que o Google tinha criado um serviço, App Engine (GAE), que resolveria meu problema. Ele fornecia um ambiente de desenvolvimento e deploy simples, prometendo escalar sua aplicação automaticamente.

Para me convencer sobre o poder do GAE ele fez uma demosntração: em 5 minutos no almoço criou uma aplicação Hello World do zero e fez o deploy. Realmente fui convencido e a partir daquele momento passei a utilizar a plataforma. Nascia assim a primeira versão do site, após 3 meses de desenvolvimento, que se chamava Revelação Virtual.

O que permitiu o rápido desenvolvimento foram as facilidades que a plataforma possuía. Diferente do ambiente Java comum, toda documentação se encontra centralizada e existe API para resolver vários problemas comuns do desenvolvimento web, como envio de email, upload e download de arquivos, filas de tarefas, entre muitas outras funcionalidades.

Mas como qualquer escolha em tecnologia, sempre existem dificuldades. A maior delas é que o ambiente do GAE é muito particular, impondo restrições para que a plataforma possa realmente escalar de forma automática.

Como maior exemplo de restrição, cito o Big Table, banco de dados NoSQL distribuido. Nele não é possível fazer join e as pesquisas são limitadas. Ou seja, não existem diversas operações comuns aos bancos tradicionais. Sendo assim, para programar nessa plataforma são necessárias várias mudanças de paradigma para quem já programa em um ambiente mais ortodoxo.

E foi por conta dessa forma de funcionamento particular do GAE que me vi obrigado a alterar todo o backend de Java para Python. Por conta do problema de cold start  os clientes sofriam com uma grande latência da aplicação quando uma nova instância era necessária. Acabei testando o Python e resolvendo o problema construindo o microframework Zenwarch para carregar a aplicação web de forma preguiçosa. Mais do que apenas resolver o problema, acabei percebendo que o desenvolvimento em Python era muito mais produtivo e acabei me aprofundando em seu estudo.

Por conta dessa mudança, passei a frequentar a comunidade Python e suas conferências. Para minha surpresa, muitos pythonistas não conhecem a plataforma, sendo poucos os que a usam para sistemas em produção. A maioria usa o framework DJango e servidores linux, sendo necessário instalar toda a base para o website, como NGinx, Gunicorn, SupervisorD e outras ferramentas. Acabei aprendendo um pouco sobre essa estrutura trabalhando na empresa ZNC, justamente para poder compará-la com a estrutura do GAE.

Durante esse período na ZNC, pude constatar o grande poder que o Django fornece ao desenvolvedor, principalmente através dos painel de administração. Contudo, considerei a curva de aprendizado do framework em si relativamente alta. Além disso, as ferramentas necessárias para se poder fazer um deploy com um clique tornam todo o processo muito complexo. Definitivamente a simplicidade da plataforma do Google me deixou "mal acostumado". Ou melhor, me deixou “bem acostumado”.

Mas além da simplicidade, outro fator fundamental me faz preferir o GAE: o preço. A plataforma oferece uma cota grátis de uso que se renova diariamente. Isso permite que se teste o site sem haver necessidade de investimento, até que ele ganhe tração. Mais do que isso, você paga pelo que realmente utiliza. Ou seja, se o tráfego diminui, também cai o seu custo.

Mas durante minhas discussões com amigos em favor da plataforma, havia sempre um argumento difícil de refutar: o chamado lock in. Ou seja, ao utilizar o serviço do Google, você acaba por se tornar prisioneiro da plataforma por causa do uso de suas bibliotecas e APIs personalizadas. Meu amigos sempre me alertaram que se o Google alterasse sua política de preços, eu ficaria refém do serviço, por não poder portá-lo para outro lugar.

Minha única justificativa, no início, era de que durante esses 3 anos a empresa nunca havia mudado sua política de preços de forma que eu fosse afetado significativamente. Sempre eu comentava sobre o custo irrisório do serviço, respondendo para o pessoal com o título desse post: sou um prisioneiro feliz.

Hoje o lock in não é mais um verdade absoluta. Existe o projeto de código aberto App Scale que permite a migração de sua aplicação para outras infraestruturas. Mas realmente até hoje não portei nenhuma, apesar de saber que já conseguiram portar com sucesso a aplicação do QMagico usando esse projeto. Além dele, existe também o CapeDwarf.

O fato é que em minha última conversa sobre o assunto com amigos me incentivaram a contar mais sobre essa experiência. Decidi então escrever esse post e ir além: no início 2014 farei um curso, com vídeos gratuitos, sob o título “Python e App Engine: você programa e Google escala!”. Quem sabe não consigo outros prisioneiros felizes como companheiros.

Atualização: já iniciei o curso no fim de 2013, confira nessa playlist do Youtube.

Participação em Startups

O tema Startup tem surgido muito na imprensa e está relacionado massivamente à empresas de TI com possibilidade de crescimento vertiginoso. Em listas de e-mail ligadas ao assunto é muito comum encontrar diversas pessoas procurando um sócio técnico para desenvolver o produto. É justamente aqui que vou focar esse post, postando sobre a participação em termos de porcentagem. Você pode fazer análise para avaliar um cargo de Diretor de Tecnologia, também chamado de CTO (Chief Technology Officer). Mas a análise é genérica e serviria para qualquer outro sócio.

Para contextualizar, conto um pouco da minha vivência sobre o assunto: eu sempre gostei de empreendedorismo. Depois de 6 meses de formado, trabalhei em cada ano subsequente em uma empresa diferente: uma startup ligada ao setor de saúde, um curso de design e programação web próprio e por último em uma startup do setor de educação. Nessa última, chamada QMagico, fui CTO.

Durante as negociações com o QMagico, e mesmo depois que sai da empresa, já recebi várias propostas para trabalhar em startups. Eu já tinha pesquisado um pouco sobre definição de participação nesse tipo de empresa e em uma dessas ocasiões, decidi colocar em prática uma metologia para calcular minha participação. Como chegar em um valor para uma empresa nascente é difícil, decidi por utilizar o chamado “Custo de Oportunidade” para chegar em minhas conclusões.

De acordo com a Wikipedia, esse conceito pode ser assim definido: “O custo de oportunidade é um termo usado em economia para indicar o custo de algo em termos de uma oportunidade renunciada”. Ou seja, para se chegar em valuation para a empresa que ainda não tem um histórico financeiro a ser analisado, escolhi calcular seu valor de acordo com o custo de oportunidade dos envolvidos, bem como todo investimento que já tenha sido feito (Link para planilha):



Abaixo segue a explicação da planilha.
 

Salario de mercado 

Esse é o custo de oportunidade mensal de um colaborador. Ou seja, quanto se está deixando de ganhar para entrar na empresa. É interessante notar que o trabalho em uma Startup não é igual ao de mercado: Muitas vezes você vai ter que trabalhar muito mais, fazendo “hora extra”, é pago via pro labore + divisão de lucros. Não existe décimo terceiro, às vezes nem férias. Por isso, ao calcular seu salário de mercado, acrescente a ele de 20 a 100%, de acordo com os benefícios que você vai abrir mão.

Salário Startup

Esse é valor que você vai receber durante o período. É subtraído do salário de mercado para se chegar no seu custo de oportunidade mensal.

Investimento Startup

Aqui constam todos os valores investidos na empresa, seja em dinheiro ou material. Esse valor será acrescentado ao valuation da empresa, junto com o custo de oportunidade de todos os sócios.

Vesting

Para fazer jus à sua participação, principalmente se entrar em uma a empresa depois da fundação, é comum aplicarem um período de 5 anos de vesting. Isso visa mitigar os riscos para a startup. Simplificando, se você fizer jus a 20% ao final do período de vesting, você ganharia o mesmo em parcelas de 4% a cada ano. E apenas ao fim do período, o que se chama de período de cliff.

Entendendo as contas

Para se chegar ao valor da empresa, todos os sócios devem calcular seu custo de oportunidade que será investido durante o período de vesting. Sócios que estão há mais tempo devem acrescentar esse período para aumentar seu custo de oportunidade final e, consequentemente, sua participação. Ao custo de oportunidade é somado o valor que cada sócio colocou em dinheiro ou material. Fazendo essa soma, é obtido o valor do Valuation Atual, a partir do qual a participação dos sócios é definida proporcionalmente ao seu investimento.

A célula Custo de Oportunidade, à direita, contém a soma do custo durante o período de vesting, mais o valor que por ventura for investido pelo sócio. Abaixo dela, na célula de equity, consta a participação porcentual do sócio.

Nas células abaixo das mencionadas foi considerado um fator de multiplicação que tem a ver com mesma expectativa de um investidor anjo:  ter seu investimento multiplicado de 10 a 100 vezes no período de 5 anos. Quando eles não enxergam uma saída dessa magnitudade, não costumam investir. Se no plano de negócio a análise não chegar no valor que se espera ganhar, aí talvez não valha à pena participar.

E mesmo quando a análise chegue nesse valor, é recomendável tomar cuidado com os deslumbramentos de empreendedores. Ser ambicioso é bom, mas manter os pés no chão também o é. O site http://dealbook.co contém várias informações sobre operações de investimento e compra de startups brasileiras durante os últimos tempos. Assim, quando vejo previsões de vendas que em apenas 2 anos passam até dos valores pelos quais empresas já estabelecidas, como Buscapé, foram adquiridas, passo a duvidar da qualidade da análise feita.

Conclusões

Existem diversos processos de definição de participação em startups e eu quis mostrar o que para mim faz mais sentido. Já cheguei a discutir isso certa vez quando recebi uma proposta. Com essa mesma análise, tinha chegado à conclusão que minha participação na empresa seria de 33%. Fui contestado, pois me ofereciam 10%. Diziam que a minha pedida “não fazia sentido”. Respondi, então, que me mandassem uma planilha, como fiz, explicando como chegaram no valor de 10%. Obviamente não mandaram, 10% é uma “praxe” de mercado, mas é uma em que não entro de jeito nenhum, pois além do trabalho ser desgastante, raramente vai compensar financeiramente, mesmo que a startup dê muito certo. Segue esse post que fala sobre o assunto:

http://www.financialsamurai.com/2013/10/18/the-startup-riches-myth-selling-for-millions-and-being-rich/

Outra questão é que às vezes, como já aconteceu comigo, se escolhe por trabalhar em uma startup por outras razões: flexibilidade, clima divertido com amigos, oportunidade de tomar decisões ou liderar um time. Todas elas são válidas. Mas mesmo que você decida emocionalmente, fica a dica de fazer uma análise financeira racional, seja pela simples planilha que apresentei ou outra metodologia. Isso o faz entrar no negócio mais consciente.

Enfim, deixe seu comentários e também links interessantes que possam ajudar outras pessoas a pautarem suas decisões.

 Abs,
 Renzo Nuccitelli