Nova versão do livro que ensina a criar aplicativos com Corona SDK

Se você não sabe o que é Corona SDK, leia este post!

Comprem o livro neste link para que o tradutor ganhe sua comissão! O site de compras é o PagSeguro do UOL e tenho 100% de qualificações positivas.

Foi em 2012 que conheci Corona SDK e que começou minha paixão pelo desenvolvimento amador de games mobile como hobby. Nesse mesmo ano conheci o livro Beginning Mobile App Development with Corona e decidi que ia ajudar o autor, o Dr. Brian Burton, a fazer a versão nacional chamada Criando Aplicações Móveis com Corona, sendo o primeiro livro em Português sobre o assunto, e até hoje um dos únicos materiais em nosso idioma. Cinco anos e centenas de compradores depois…

corona-sdk

Corona, mais forte do que nunca!

Quando conheci o Corona em uma revista da Info, era um framework indie de desenvolvimento mobile que suportava Android e iOS com programação em Lua. Tinha alguns milhares de desenvolvedores ao redor do mundo e era desenvolvido por uma empresa chamada Ansca Mobile, fundada por dois ex-engenheiros da Adobe, do time de games do Flash.

Hoje, a empresa se chama Corona Labs e seu framework é utilizado por mais de 200 mil desenvolvedores ativos ao redor do mundo, com uma imensa comunidade online, muito material e exemplos disponíveis e diversos aplicativos em seu portfólio. Com atualizações praticamente mensais, Corona é gratuito para todos desenvolvedores, e seduz a cada dia novos estúdios digitais e programadores freelancer que encontram no seu poder e simplicidade a amálgama perfeita para desenvolver aplicativos, games e livros interativos para Android, iOS, Mac OSX, Windows, Amazon Fire, Apple TV, Fire TV e Android TV.

Some a isso um tempo livre que entrou em minha agenda e a vontade de voltar a programar jogos e temos a combinação perfeita para lançar uma nova versão do livro que já faz cinco anos que foi lançado em Português, e cuja última atualização tinha sido em 2014.

corona-sdk2

O que há de novo no livro?

Corona evoluiu muito desde o seu lançamento, e o livro não apenas vem para corrigir erros antigos mas para expandir as possibilidades com o framework com muitas correções em códigos que deixaram de funcionar, um novo apêndice traduzido sobre a linguagem Lua, indicações diferentes de ferramentas e muitas páginas adicionais, sem mudar em nada o preço final! Veja as principais novidades da nova versão do livro:

  • nova biblioteca Graphics 2.0;
  • integração com Apple Game Center e Google Play;
  • suporte à JSON;
  • monetização com anúncios;
  • novas ferramentas para look & feel nativo;
  • mockups;
  • nova biblioteca Widgets 2.0;
  • Eventos do sistema e Ferramentas (acelerômetro, giroscópio, GPS, mapas e notificações)
  • Gráficos Avançados com filtros, geradores, efeitos compostos e LiquidFun

São quase 500 páginas de dicas, tutoriais, exemplos de games e apps completos e muito mais! Sério, tudo que você precisa saber sobre como criar games e apps com Corona SDK está neste livro.

Confira nesta resenha tudo o que há no livro!

Mas e quem comprou a versão antiga?

Obviamente não esquecemos dos antigos compradores e todos podem baixar a nova versão do livro gratuitamente. Para isto, basta acessar o link abaixo do site do autor e informar o e-mail que usaram para compra do livro. Pronto! Você receberá por e-mail uma cópia novíssima e atualizada do livro para aproveitar ainda mais o nosso framework mobile favorito!

Get Book Updates Here

 

Comprem o livro neste link para que o tradutor ganhe sua comissão! O site de compras é o PagSeguro do UOL e tenho 100% de qualificações positivas.

TDD: Como criar unit tests em Node.js com Tape

Ok, que testar suas aplicações antes de enviá-las para produção é importante todo mundo já sabe. Mas será que você sabe como testar eficientemente sua aplicação escrita em Node.js?

Neste tutorial veremos como utilizar o módulo Tape para criar testes de unidade (unit tests) em uma abordagem de desenvolvimento orientado à testes, o TDD (Test Driven Development). O mais legal é que não nos restringiremos apenas a testar funções isoladas (unit test), também vamos testar APIs completas em Node.js usando o módulo Supertest para forjar requisições HTTP (integration test).

Veremos neste post:

Vamos lá!

Introdução ao TDD

O Test Driven Development/TDD ou Desenvolvimento Orientado à Testes é uma técnica criada por Kent Beck, um famoso programador e autor de livros que atualmente trabalha no Facebook. Também são de autoria de Beck a metodologia ágil Extreme Programming (XP) que inclui técnicas como o TDD e o Pair Programming, que já falei aqui no blog.

A ideia do TDD é que você deve escrever primeiro os testes da sua aplicação, para depois implementar o código que fará com que eles funcionem. Isso pode soar um tanto estranho mas é uma ideia ousada que possui vários benefícios, tais como:

  • diminuição do número de bugs, uma vez que não existem features sem testes;
  • foco nas features que importam para o projeto, pois escrevemos os testes com os requisitos em mãos;
  • permite testes de regressão, para ver se um sistema continua funcionando mesmo após várias mudanças e/ou muito tempo desde a última release;
  • aumento da confiança do time no código programado;

O TDD é executado em um ciclo chamado de Red/Green/Refactor e prega que cada incremento pequeno de software (baby step) deve ser testado, para que bugs sejam corrigidos rapidamente assim que surgem. Ele prega que primeiro você deve escrever o teste, antes mesmo da feature ser implementada. Quando executar esse teste, ele irá falhar (Red), aí você codifica a feature apenas o suficiente para ela passar no teste (Green) e então você melhora o código para que ele não apenas seja eficaz, mas eficiente (Refactor).

Recomenda-se rodar novamente os testes e se após a refatoração a feature parar de funcionar,  roda-se o ciclo novamente.

O coração do TDD são os unit tests.

Introdução aos Testes de Unidade

Existe uma pequena discussão sobre a melhor tradução de “unit test” ser “teste unitário” ou “teste de unidade”. Acredito que seja uma discussão mais conceitual do que prática (como muitas discussões “técnicas” que existem por aí), então não entrarei nela aqui e apenas chamarei de “teste de unidade”.

Um unit test é um teste, geralmente automatizado, que testa uma única unidade da sua aplicação, geralmente uma única função, em um único contexto.

Cheio de “únicos” nesse parágrafo, não?

Mesmo com essa ênfase ainda existem muitas dúvidas e discussões acerca do que pode ser considerado um unit test ou não. Me aterei mais à prática e menos aos conceitos e resumirei como: se o seu teste testa apenas uma coisa (como uma função), chamarei ele de teste de unidade aqui, mesmo essa coisa internamente seja composta de outras coisas (como outras funções internas) afinal, parto do pressuposto que não temos como garantir que algumas funções do Node.js também não chamam diversas outras internamente.

Os unit testes são o coração do TDD pois é com eles que começamos a aplicar TDD. Mesmo que você não seja um “purista” e vá aplicar TDD 100% como manda os livros, tente ao menos passar a utilizar testes de unidade na sua aplicação, pois eles realmente valem a pena.

Um exemplo prático de aplicação de testes de unidade com TDD seria a criação de um método que aplica um desconto, em R$, ao valor de um produto, também em R$. Vamos começar escrevendo a função de teste dessa funcionalidade em um arquivo index.js, comparando o retorno da função aplicarDesconto com o valor esperado, o que chamamos de asserção ou assert (em Inglês):

Se aplicarmos um desconto de R$2 sobre um produto de R$10, o valor esperado como retorno é R$8, certo? Mas o que acontece se executarmos este bloco de código com o comando “node index” no terminal?

Dará um erro porque a função aplicarDesconto ainda não existe. Ou seja, sabemos o resultado esperado, mas não programamos a função ainda. Vamos fazê-lo agora, com uma simples subtração, no mesmo arquivo:

Agora se rodarmos o arquivo index.js no terminal novamente ele deve indicar que está funcionando, pois ao testar nossa função passando 10 e 2, ela retornará 8 e a asserção será verdadeira. Sendo assim, nosso trabalho com esta função terminou, certo?

Errado. E se o valor do desconto for superior ao produto? Você conhece alguma loja que te paga para comprar alguma coisa? Eu não!

Quando uma unidade de código (nossa função nesse caso) possui casos de uso variados, devemos testá-los sob cada contexto, em asserções separadas. Sendo assim, vamos criar um novo teste considerando que, um produto jamais possa ter um valor negativo, mesmo com descontos altos (ficando de graça nesse caso):

Note que essa é uma regra que inventei para esse teste. Se o desconto for maior que o valor, o produto deve sair de graça. Se mandar rodar esse arquivo novamente, verá que esse segundo teste não irá ‘passar’, embora o teste inicial continue passando.

Vamos refatorar nossa função aplicarDesconto para que contemple este cenário que acabamos de descobrir:

Rode novamente seu arquivo de testes e verá que agora os dois testes ‘passam’!

Criar todos os testes necessários para garantir que todas as unidade do seu software realmente funcionam é o que chamamos de cobertura de código (code coverage), cuja utópica marca de 100% deve ser sempre o ideal, embora praticamente inalcançável em sistemas complexos.

E se o desconto for negativo? Precisamos de um teste pra isso, pois um desconto não pode aumentar o valor original de um produto!

E se o valor do produto for negativo? Isso é claramente um erro de integridade dos erros, pois é economicamente impossível!

O quão ‘detalhado’ os seus testes serão vai muito do grau de importância que todas essas questões possuem para o seu negócio e o quanto domina  ele.

Algumas vezes, a sua nova refatoração para fazer com que a função atenda a um novo requisito (como não permitir descontos negativos, por exemplo) pode fazer com  que algum teste antigo deixe de passar. E isso é bom. Sempre que asserções deixam de funcionar durante os testes é hora de reanalisar o seu algoritmo e melhorá-lo. Antes descobrir essa falha durante os testes do que em produção, não é mesmo!

Agora veremos como criar testes de unidade mais profissionais usando o módulo Tape.

Criando Unit Tests com Tape

Você até pode escrever testes de unidade sem módulo algum, apenas usando Node.js puro como fiz acima, sendo que o mínimo que deveria fazer é separar as funções de verdade das funções de teste, em módulos.

No entanto, facilita muito a vida usar bibliotecas como Tape, Mocha e Chai. Para este tutorial vamos usar o Tape, que é uma das mais populares e permite fazer asserções de uma maneira muito simples, prática e padronizada, dando agilidade ao processo de unit testing ou TDD, caso leve a metodologia realmente a sério.

Vamos começar criando uma pasta para um novo projeto, chamado exemplotdd. Crie um index.js e um index.test.js nessa pasta. O primeiro será o arquivo da nossa aplicação e o segundo os unit tests do primeiro.

Abra o terminal e navegue até a pasta em questão. Execute o seguinte comando:

Esse comando serve para criação de um package.json para o seu projeto. Apertando Enter em cada uma das perguntas que ele lhe fará no console usa a configuração padrão. Atente apenas ao fato de que quando chegar a pergunta ‘test command’, digite o seguinte comando:

Apenas confirme as demais perguntas pressionando Enter e quando terminar, abra o arquivo package.json e verá algo parecido com isso:

Note que tem uma seção scripts ali. Nesta seção, definimos atalhos para comandos padrões que poderemos quer executar via NPM, como o comando “test” que é executado no console com:

Mas não vamos fazer isso agora, afinal, não criamos nossos testes com Tape ainda. Então instale agora a dependência do Tape digitando o seguinte comando:

E depois abra o arquivo index.test.js para configurarmos nosso arquivo de testes. Comece o arquivo carregando o módulo tape e o módulo que deseja testar:

Depois, escreva o primeiro teste de unidade como abaixo:

A função test espera o nome do teste e uma função de teste que realizará a asserção (assert). A asserção espera a expressão que indica que o teste passou e uma mensagem de sucesso, finalizando o teste em seguida (end). Essa é uma asserção bem simples e fácil de entender, não?!

Se você rodar agora com “node index.test” ou mais elegantemente com “npm test”, dará um erro como abaixo:

Isso porque essa função ainda não existe. Vamos criá-la tal qual criamos no exemplo anterior sobre testes de unidade, mas no arquivo index.js, exportando-a via module.exports:

Agora teste novamente com ‘npm test’ e verá uma saída bem interessante:

Essa saída do Tape mostra os testes que foram executados, o resultado de cada um e um total de testes e testes bem sucedidos, finalizando com uma mensagem de ok ou não.

Existe um outro módulo que dá uma melhorada nessa saída, o tap-spec, que você instala com ‘npm install tap-spec’ e altera o script de ‘test’ no seu package.json para:

Para testar esse novo módulo, vamos adicionar mais um teste de unidade, tentando aplicar um desconto superior ao valor do produto em nosso index.test.js (já fizemos isso antes, lembra?):

Executando com ‘npm test’, terá como resultado:

tap-spec
tap-spec

Com isso, depois de construirmos testes que cubram nosso código de uma ponta a outra, temos um recurso muito poderoso para fazer testes rapidamente e ver se todas funções da nossa aplicação estão funcionando.

Juntando este conhecimento com ferramentas de Continuous Integration (CI) como CircleCI e Jenkins, podemos incluir testes de unidade automatizados em nosso build para evitar que um código suba para produção com algum bug (um dia falarei disso por aqui).

Mas e como podemos fazer testes mais amplos, como testes em APIs escritas em Node.js? Afinal, é preciso subir um servidor Express para testar uma API, certo? Caso contrário não teríamos objetos de request e responde válidos…

Introdução a Testes de Integração

Chama-se de teste de integração aqueles testes mais amplos em que um teste acaba testando internamente diversas outras funções. Por exemplo, testar se uma chamada GET a uma API está funcionando não é exatamente um teste de unidade considerando que estaremos neste caso testando a chamada/request HTTP da aplicação, o roteamento, a função em si e o retorno/resposta HTTP.

Geralmente testes de integração são mais complicados de automatizar, principalmente quando envolvem interface de usuário ou elementos complexos de infraestrutura, como bancos de dados, embora não seja impossível.

Uma técnica muito comum para abstrair questões de infraestrutura são o uso de mocking. Mocking é o ato de falsificar algum elemento externo à sua aplicação, geralmente de infraestrutura, como se ele nunca falhasse. Por exemplo, uma função que acessa o banco de dados, em um teste que não importa o acesso ao banco, poderia ser mockada para retornar sempre o valor que queremos no teste, pois o que queremos testar é o uso do valor, não o acesso ao banco.

Existem diversos módulos no Node.js que facilitam esta tarefa de mockar objetos e recursos externos, mas particularmente não gosto desta técnica. Em algumas ocasiões é a única saída (alguém aí falou de integração com bancos e financeiras?) mas geralmente prefiro ter ambientes de testes ou simulá-los de maneira mais próxima à realidade.

Da mesma forma, existem diversos módulos no Node.js que facilitam automatizar testes que necessitem de recursos mais complexos. Um deles é o módulo Supertest, que permite que você forje requisições HTTP para testar suas APIs de maneira automática usando Tape ou qualquer outro módulo de asserções.

Testando requisições com Supertest

Basicamente o Supertest é um módulo que forja requisições visando testar webservers em Node.js e verifica o retorno das mesmas para automatizar testes deste tipo de infraestrutura, principalmente web APIs.

Para usar o Supertest, devemos primeira instalar sua dependência em nossa aplicação:

Note que aproveitei e já instalei outras duas dependências que vamos precisar para criar nossa API que aplica descontos. 🙂

Como o foco do nosso tutorial não é criar APIs em Express (coisa que já ensinei em outra oportunidade), apenas copie o código abaixo em um arquivo app.js:

Resumidamente, criamos uma web API usando Express que escuta na porta 3000 esperando por requisições GET /aplicarDesconto passando no path o valor e o desconto a ser aplicado. Internamente pega-se esses dois parâmetros passados no path, converte-os para inteiro e usa-se a função que criamos anteriormente (e cujo módulo index.js carregamos no topo deste arquivo) para calcular o valor descontado, retornando-o em um JSON na resposta.

Atenção ao if que inicia o servidor somente no caso do require.main for igual a module, pois isso evita que o servidor fique ‘pendurado’ mais tarde, durante os testes.

Se você executar esse arquivo com o comando ‘node app’ verá que ele funciona perfeitamente.

Já criamos o teste de unidade da função aplicarDesconto e garantimos que ela está funcionando, o que já garante boa parte do funcionamento da nossa API. Agora vamos criar testes de integração que garantam o funcionamento completo dessa chamada.

Para isso, vamos criar um arquivo app.test.js, que conterá todos os testes do app.js. Comece esse arquivo carregando o módulo supertest, o tape e o app:

Agora, escreva um teste usando tape, que nem já fizemos antes, mas usaremos o supertest dentro dele para forjar a requisição e ler a resposta, visando uma asserção completa, que integre todo o uso da API:

Quando chamamos a função supertest devemos passar para ela o nosso app. A função get define a requisição que faremos, enquanto que as funções expect definem características que indicam que nosso supertest foi bem sucedido, analisando por exemplo o Content-Type e o HTTP status code.

Por fim, quando a requisição é finalizada, podemos usar o objeto t do Tape para analisar um possível erro na requisição e até mesmo fazer asserções em cima do body da resposta, para ver se está retornando o que é esperado.

Mas e agora que temos dois arquivos de teste separados, como fazemos para automatizar a execução dos dois usando apenas um ‘npm test’?

Você pode guardar todos seus arquivos de teste dentro de uma pasta tests e no seu script de test no package.json colocar algo como:

Apenas tome cuidado com os caminhos que referenciam os módulos app e index dentro dos seus arquivos de teste.

Ou então criar um arquivo all.test.js que é um índice de testes que apenas carrega todos os módulos de teste e ele é referenciado no package.json como sendo o arquivo a ser executado.

Em ambos os casos, o resultado é este:

Todos testes executados
Todos testes executados

Atenção: qualquer tipo de conexão que você efetue deve ser encerrada ao término dos testes, caso contrário os testes ficam ‘pendurados’ aguardam o encerramento de todos recursos.

O if que coloquei antes do listen no app.js garante que o servidor não fique rodando eternamente. No caso de um banco de dados, o último teste deve ser sempre o de encerramento da conexão. E assim por diante.

Espero que tenham gostado do tutorial e que apliquem em seus projetos!

Curtiu o post? Então clica no banner abaixo e dá uma conferida no meu livro sobre programação web com Node.js!

Zona de Conforto: Neymar, Evaristo Costa e eu

Neymar
Neymar

O que o Neymar, o Evaristo Costa e eu temos em comum? Decidimos sair da zona de conforto recentemente.

Calma, já explico.

O Neymar, que era titular absoluto do Barcelona, campeão da Champions League e a atenção de toda mídia esportiva possível, decidiu largar o Barça e ir para o PSG, um time “inferior”, sem títulos expressivos a nível internacional, para construir história e claro, ganhar mais também, embora eu acredite que dinheiro não tenha sido o principal fator pra ele, considerando o quanto já ganhava no time catalão.

Neymar queria sair da sombra de Messi e buscar o título de melhor jogador do mundo, algo que estava bem complicado junto ao Barcelona.

Evaristo Costa, que embora não seja tão famoso mundialmente quanto Neymar, é muito famoso por quem assiste o Jornal Hoje, um noticiário diário próximo da hora do almoço que ele apresentava com Sandra Annenberg há 14 anos. Pois é, o Evaristo também estava em uma posição super confortável, assim como o Neymar, ganhando muito bem como âncora do telejornal e decidiu sair da maior emissora do país para tocar outro projeto ligado a entretenimento em uma emissora concorrente (é o que estão dizendo por aí).

Sim, ele também vai ganhar mais lá, mas acredito que o principal fator foi a sua vontade de fazer algo novo e diferente, de ser desafiado ou pôr em prática seus sonhos e aspirações que o jornal não permitia.

Se o assunto for fama, eu nem deveria estar nessa lista, mas confesso que me identifiquei com as atitudes recentes do Neymar e do Evaristo pois eu mesmo estava chateado com a zona de conforto na qual estava há alguns meses.

Evaristo Costa
Evaristo Costa

Meu último desafio

Em 2015 eu estava encerrando as atividades com minha startup Busca Acelerada e apenas lecionava à noite quando topei aceitar o desafio de ser o Gerente de Projeto de uma startup chamada Route. O desafio era imenso pois a startup já rodava no vermelho, sem um único cliente, há 3 anos e um beta que parecia eterno pois o escopo do projeto nunca era definido.

Não precisei pensar muito para aceitar a oferta que era boa não apenas financeiramente, mas para o meu currículo. Ao que tudo indicava, minha experiência anterior como CEO de uma startup fracassada poderia evitar que esta fracassasse também.

Durante um ano e meio gerenciei o projeto, ajudei a fechar o escopo do produto, ajudei a fechar com algumas dezenas de clientes e até mesmo meti a mão no código para entender melhor como o produto funcionava, tendo sido responsável pelas integrações com diversas ferramentas do mercado que nos ajudaram a converter mais clientes.

A situação era preocupante pois queimávamos R$40 mil por mês e o faturamento era ridiculamente baixo. Tracei algumas estratégias que envolviam pivotar nosso produto para nichos mais específicos mas não consegui convencer o CEO, que também era nosso investidor, de que o projeto ainda tinha futuro e ele foi encerrado um ano e meio depois de eu entrar na equipe. Quatro anos e meio depois da startup ter sido fundada.

Foi a segunda vez que vi uma startup afundar comigo dentro, mas não fiquei nem um pouco triste pois o desafio foi muito interessante, aprendi muito no processo, fiz novos amigos, agregou no meu currículo e o salário não era ruim. 🙂

O problema veio após o Route ser encerrado.

Route
Route

Entrando na zona de conforto

O CEO do Route também é o CEO da Umbler, startup de cloud hosting que está crescendo rapidamente no mercado nacional e está em vias de expansão para outros países ainda este ano.

O Route foi encerrado não apenas por ser um projeto que estava dando prejuízo, mas porque o CEO teve de escolher um projeto para se focar, e ele fez a escolha mais óbvia (e correta): a Umbler. Com isso, o projeto do Route foi encerrado e toda equipe foi absorvida no time da Umbler.

Foi nos dada uma pergunta bem simples para ser respondida: o que vocês querem fazer na Umbler?

As respostas não podiam ser mais óbvias: quem era do marketing, quis ir para o time de marketing. Quem era designer, foi pro time de front-end. E assim por diante, escolhas “seguras”.

No entanto, a Umbler já tinha um Gerente de Projeto, posição que eu ocupava no Route e eu tinha uma sinuca de bico pela frente: ou eu voltava a ser desenvolvedor (ou seja, uns dois passos para trás na minha carreira) ou “inventava” alguma coisa para eu fazer lá dentro.

Claro, eu também podia recusar entrar pra Umbler e voltar pro mercado, mas como estava lecionando em Gravataí à noite, era muito cômodo que o emprego diurno também fosse em Gravataí.

Eu devia ter associado que optar pelo que fosse mais confortável me deixaria em uma zona de conforto rapidamente, mas na ocasião não me ocorreu isso.

Umbler
Umbler

Atuando em uma posição de conforto

Acabei optando por sugerir uma posição de evangelismo técnico dentro da Umbler pois era uma posição disponível e que eu me encaixava muito bem. Como eu já faço esse tipo de trabalho como autor de livros, escritor aqui no blog, palestrante há 7 anos e estou começando com videoaulas, achei que seria o melhor a fazer. Na verdade era uma das poucas opções que eu via para mim à época sem ter de competir com a galera que já estava estabelecida na Umbler e que são meus amigos. Detesto competir com amigos. 🙁

Pra quem não sabe, cabe ao evangelista técnico levar ao mercado as inovações tecnológicas e tecnologias utilizadas e criadas pela empresa que ele representa. Como evangelista técnico de uma empresa de cloud hosting, cabia à mim educar nosso mercado sobre desenvolvimento web, ajudando a tornar a Umbler referência no assunto.

E foi muito legal, durante meio ano.

Não me entenda mal, amo ir a eventos, conversar com outros desenvolvedores, palestrar, ministrar workshops, escrever artigos e fazer videoaulas. Sério.

Mas não curti nem um pouco fazer “só” isso. Além disso, estar distante de projetos de software de verdade durante 6 meses me deixou muito preocupado. Para não enferrujar, eu “entrei” pra dentro de artigos técnicos, criei muitos projetos aleatórios e estudei muita coisa que não tinha lá muita coesão, mas que me pareceu importante saber caso eu precisasse voltar a programar “de verdade”.

Sempre critiquei os evangelistas técnicos que só enchiam linguiça, que não sabiam programar de verdade e que não conseguiam responder pergunta alguma mais avançada que o conteúdo da sua palestra. Certamente você já deve ter ido em alguma palestra assim, e é horrível. Um bom palestrante técnico é um profissional técnico, não um marketeiro. Sempre me considerei um bom professor e palestrante justamente por ter larga experiência de mercado como desenvolvedor, analista e até mesmo gerente de projetos (embora tenha bem menos experiência nessa função), resumindo: eu falo a mesma língua da minha audiência e sei as “dores” deles.

Eu estava com muito medo de me tornar um “programador de palco”. E se eu ficasse um ano ou dois como evangelista, será que conseguiria voltar a ser gerente ou analista caso necessário? Ou até mesmo um programador?

Fui aí que me deparei com uma dúvida ainda pior: eu estou crescendo como profissional? E a minha resposta foi rapidamente um não.

Zona de conforto = zero crescimento

Ler muitos artigos técnicos, fazer diversos projetos de exemplos e falar com muitas pessoas sobre o que você estuda e escreve não o faz um bom profissional. Isso é a “cereja do bolo”. Um bom profissional na área de TI, na minha opinião, é o que aplica corretamente o que estuda, caso contrário, é apenas um teórico.

Além disso, estar estagnado na área de TI é algo excepcionalmente pior do que muitas outras áreas, pois você não fica “estacionado”, mas é considerado “atrasado” rapidamente, ou seja, é muito mais nocivo do que parece à primeira vista.

Outra coisa que logo reparei e que me deixou muito apreensivo é que minha função primordial era ensinar. Mas o que eu estava aprendendo no processo? Com quem eu estava aprendendo alguma coisa?

Eu tenho 29 anos anos e 11 de TI, mas não sou nenhum “deus da programação” como alguns brincam por aí, tenho muito a aprender ainda, muito o que crescer. Estou muito longe de atingir todo o meu potencial e cada dia que passa que não aprendo algo novo é um dia perdido para mim. E caso você não saiba, aprender é muito diferente de estudar. E eu estava apenas estudando para criar os materiais necessários da minha função.

Note que, em nenhum momento, estou culpando a Umbler ou o CEO dela por isso. Foi uma decisão minha me tornar evangelista técnico em tempo integral. Fui eu que me meti nessa.

Fui aí que me surgiu a pior dúvida nos últimos anos: será que ainda sou “empregável”?

Alerta vermelho: zona de conforto!

Há 11 anos que trabalho com TI e em todo esse período fiquei desempregado durante apenas 3 dias. Sempre tive uma alta taxa de empregabilidade, sempre recebi ofertas mesmo sem estar procurando e isso em grande parte pois sempre me esforcei em ser um profissional diferenciado.

Quando pintou a desconfiança de que eu poderia estar perdendo essa característica que tanto me orgulho (sem falsa modéstia, por favor), eu surtei.

A posição de evangelista técnico não é lá muito comum e se eu continuasse me focando nela nos próximos anos ficaria extremamente dependente da empresa atual e das demais empresas que possuem essa posição disponível (que não são muitas aliás). Além disso, cada vez mais me distanciaria de tocar projetos de desenvolvimento que inclui as habilidades que demorei uma década para refinar: análise, desenvolvimento, gerenciamento, etc.

Ou seja, eu estava em uma posição confortável no presente, mas como toda zona de conforto, com um futuro incerto.

Eu não sou do tipo que fica procurando vagas de emprego, nunca fui (exceto quando estava tentando entrar no mercado de trabalho). Na verdade eu costumo olhar as vagas em busca de oportunidades para meus alunos. Se você me segue nas redes sociais já deve ter visto eu postando vagas, especialmente para iniciantes.

Em uma dessas buscas para ajudar o próximo me deparei com uma vaga que me chamou a atenção: coordenador técnico mobile, em uma banco de Porto Alegre, o Agiplan.

Agiplan
Agiplan

Descobrindo uma nova oportunidade

Nunca pensei em trabalhar em um banco antes, sempre me pareceu algo burocrático, chato, engessado e pouco inovador. No entanto a vaga era bem enfática em afirmar que o banco Agiplan estava justamente buscando mudar essa visão que todos desenvolvedores possuem dos bancos. Que estavam investindo pesado para mudar essas cultura, desde o ambiente até as posições. Claro que eu não acreditei nisso de primeira.

Fui investigar o site da Agiplan. Procurei funcionários no LinkedIn. Encontrei amigos em comum. Fiz todo o dever de casa que alguém que não quer entrar em uma roubada deve fazer.

Conversando com pessoas próximas que possuem vínculo com a Agiplan descobri que a financeira com 18 anos de existência havia se tornado banco há pouco mais de um ano, o que era bom, pois ainda não possuíam os vícios dos demais bancos. Descobri que o banco é de apenas um dono, o que é excelente, pois agiliza e muito a tomada de decisão. Descobri que eles estavam “roubando” talentos de diversas outras empresas ligadas à dinheiro, como pessoas importantes da Elo, da Caixa, PagSeguro, Santander, etc. E que eles pagavam bem e tinham PPR, o que não faz mal a ninguém, não é mesmo?!

Mas daí me surgiu a dúvida: será que eu conseguiria entrar como coordenador técnico mobile?

Atualizei meu currículo (que tem apenas uma página e sempre terá) e apliquei para a vaga que exigia pós-graduação e muita experiência na área. Conversei com algumas pessoas influentes lá dentro para que meu CV chegasse nas mãos certas e fiquei no aguardo. Depois de alguns dias sem resposta é fácil perder as esperanças, mas logo veio um desafio técnico que eu prontamente fiz da melhor maneira que pude com o tempo que me foi dado.

Depois vieram as entrevistas. Muitas delas. Eu estava de férias da Umbler e durante vários dias tive de interromper meu descanso para ir à sede da empresa que fica em um bairro nobre de Porto Alegre para conversar com diferentes gestores. Não é todo dia que se tem a oportunidade de ajudar na criação de um novo banco e eu não queria perder essa oportunidade, estava muito interessado na posição.

Finalmente fui aprovado no processo seletivo e me foi dada uma oferta bem generosa para sair da minha zona de conforto. Melhor do que passar na seleção foi o sentimento de saber que ainda estou no controle da minha carreira.

Mas quem pensa que tudo são flores, está redondamente enganado, e essa é a melhor parte.

Novos desafios. Enormes desafios.

Mario Sérgio Cortella diz que “mudar é complicado, mas acomodar é perecer” e é exatamente isso.

Eu estava em uma zona de conforto enorme: ganhava razoavelmente bem, morava a 15 minutos do serviço, trabalhava apenas com amigos (incluindo o CEO da Umbler) e em um cargo extremamente fácil para mim, que pouco me desafiava. Meus alunos da faculdade diziam que eu tinha o emprego dos sonhos, hehehe.

Saio da Umbler para trabalhar em outra cidade, com uma equipe completamente nova em uma empresa extremamente competitiva em um mercado dos mais competitivos: o bancário. Não há certeza alguma de que trabalhar no Agiplan é tão legal quanto dizem e que conseguirei coordenar a equipe do jeito ágil que gosto de fazer. A única certeza é o desafio.

E é o desafio enorme que se abre à minha frente que me motivou a aceitar a oferta, muito mais do que o dinheiro que me foi oferecido para trocar de empresa. Porque se eu conseguir transpor esses desafios crescerei como profissional, e muito.

Aliás, ao que tudo indica eu não trabalharei na posição a qual submeti, de coordenador técnico mobile, mas sim em algo ainda mais abrangente chamado Especialista de Sistemas, posição responsável não apenas por coordenar o desenvolvimento dos apps, mas pelo Internet Banking deles também.

Se isso não é desafio o bastante para não entrar em uma nova zona de conforto por um bom tempo, não sei dizer o que é!

Sem arrependimentos, apenas alegrias

Tenho o orgulho de dizer que sempre coube a mim direcionar a minha carreira para onde eu quisesse. Para isso, claro, já tive de abrir mão de salários maiores, recusar propostas ou mesmo me demitir algumas vezes. Tudo para não sair do caminho que decidi trilhar há 11 anos atrás.

Obviamente nem sempre acerto e esses últimos 6 meses, que eu chamo agora de “etapa de transição”, foi um período importante de auto-conhecimento, reflexão e reafirmação de valores em cima de um período que estava meio “perdido”. Isso pode acontecer com qualquer um e se você está em uma situação confortável demais, atenção, faça alguma coisa antes que seja tarde.

Em épocas de crise como essa que vivemos no país, vejo muitos profissionais com anos de experiência desempregados. Eles não entendem que não basta apenas ter anos de experiência, você tem de ter anos de “crescimento” no currículo. Se eu aperto o mesmo botão há 10 anos, isso não me faz mais capaz do que quando eu tinha 1 ano de experiência apertando aquele botão e posso ser facilmente substituído por alguém que aperta o botão mais rápido ou dois botões ao mesmo tempo. Ou por um software, mas essa é uma história ainda mais triste. 🙂

Não tenho arrependimentos e vivi muitas coisas fantásticas como evangelista de software nestes meses na função. Viajei por lugares incríveis e conheci pessoas mais incríveis ainda. Tive a liberdade de explorar tecnologias que tenho a esperança de poder usar na prática ainda e pude me manter lecionando mesmo após deixar meu cargo de professor na FAQI no semestre passado (esta por questão de agenda mesmo).

Para os próximos meses, devo me dedicar absurdamente à esta oportunidade que me foi dada e talvez até tenha que sacrificar um pouco a periodicidade das postagens aqui no blog (que é até um pouco insana se comparado à minha disponibilidade para escrever).

Mas tudo isso por uma boa causa: sair da zona de conforto!