Categorias
Tech

3 motivos para a falha de projetos de software

Trabalhando por muitos anos no desenvolvimento, já tive a oportunidade de participar de muitos projetos de software. Boa parte deles como membro de equipe, alguns como Scrum Master e outros como freelancer, fazendo todo o trabalho sozinho.

Isso me trouxe alguma experiência no quesito projeto de software.

Acompanhei projetos que deram muito certo e outros que nem tanto. Sobre estes sempre fica a pergunta: “por que este projeto falhou?”.

Cada projeto tem suas características específicas, mas para me aprofundar mais nos motivos gerais das falhas resolvi fazer uma rápida pesquisa para procurar artigos acadêmicos que falam sobre esse assunto.

Analisando alguns deles fica claro quais são os principais motivos listados.

  • objetivos não realistas ou não articulados
  • software que não atende às reais necessidades do negócio
  • requisitos de sistema, requisitos dos usuários e especificação de requisitos mal definidos
  • gestão de projeto deficiente
  • metodologias/práticas de desenvolvimento desleixadas
  • prazos e orçamentos do projeto
  • estimativas imprecisas dos recursos necessários
  • má comunicação entre clientes, desenvolvedores e usuários
  • uso de tecnologia imatura
  • pressões comerciais
  • satisfação do cliente
  • qualidade do produto
  • entre outros (lista completa neste artigo)

Como podemos perceber, são muitas as possíveis causas de um projeto de software ser malsucedido.

Essas pesquisas foram feitas com diversos projetos e estão em artigos espalhados por aí, mas eu quero focar naqueles motivos que já senti na pele, como um envolvido no projeto.

1. Requisitos de sistema mal definidos

Este é um caso muito mais comum do que se imagina. Acontece o tempo todo e já passei por diversos projetos com esse problema, por isso ele está no topo da minha lista.

Análise de requisitos é um processo complicado e demorado. É preciso da atenção de um profissional especialista e que vai conseguir levantar exatamente tudo que é preciso para que aquele projeto de software atenda às necessidades dos interessados.

Isso faz parte de projetos de softwares mais tradicionais e não necessariamente funciona do mesmo jeito em projetos ágeis, em empresas que necessitam de entregas mais constantes como as startups de tecnologia ou que possuem prazo e orçamento mais apertado como as fábricas de software menores.

Acontece que não ter um levantamento de requisitos tradicional não libera ninguém de levantar requisitos.

Talvez alguns gestores não entendam que o uso de métodos ágeis não é desculpa para que as descrições de tarefas sejam muito bem pensadas e completas.

“Gastar” tempo levantando requisitos bem definidos com os stakeholders (as partes interessadas no projeto) aumenta as chances de uma entrega mais assertiva e rápida do software.

2. Gestão de projeto deficiente

Eis um tópico extremamente genérico e que afeta muito os projetos de software. Uma má gestão pode significar diferentes problemas para a equipe, incluindo o tópico anterior.

Mesmo que as equipes ágeis sejam autogerenciáveis segundo a teoria, normalmente existe alguém que centraliza essa tarefa mais do que os outros membros. Além disso, em muitos casos, os executivos da empresa costumam não permitir tanta autonomia para que a equipe se gerencie.

A gestão de projetos deficiente acaba tendo um impacto muito grande na motivação da equipe, na falha de comunicação, na necessidade de retrabalho, na má administração dos recursos e dos prazos, etc.

Já presenciei alguns casos de má gestão e a responsabilidade pela falha do projeto costuma sobrar para os membros da equipe…

3. Qualidade do produto

Em alguns casos na minha experiência o produto tinha um potencial incrível, poderia trazer muito valor para os usuários… mas simplesmente não funcionou quando eles precisaram.

A qualidade do produto faz parte do valor agregado entregue em qualquer projeto.

É muito comum existir um membro da equipe focado nesse assunto. Uma pessoa para garantir a qualidade do software e mantê-lo sempre na sua melhor versão possível, sem erros e sem problemas de usabilidade.

Projetos de software que falham por falta de qualidade do produto não precisam de muita explicação, não é…

Eis um investimento que vale a pena, mas que muitas vezes é subestimado pelos responsáveis do projeto.

Entre outros…

Os motivos selecionados aqui são os que mais me chamaram a atenção por acontecerem em diversos projetos os quais eu participei. Por isso estão nesta lista em ordem de importância.

Na minha experiência pessoal eu não vejo um motivo específico para a falha de projetos de software e sim uma combinação de problemas que se acumulam e minam o projeto como um todo.

Em diversos dos casos que presenciei mais de um desses itens estavam combinados com outros também descritos na primeira lista retirada dos artigos pesquisados no início dessa publicação.

O que fazer?

Pessoalmente, acredito que uma das formas de evitar a falha de um projeto é ouvindo as pessoas envolvidas. Aproveitar a experiência de quem participa do desenvolvimento para tentar entender o que está acontecendo durante todo o processo.

Uma liderança mais aberta e que se importa com a opinião dos envolvidos tem maior chance de identificar um possível motivo de falha antes que o mesmo se torne irreversível para o projeto.

A chave é não esperar o projeto chegar em um nível crítico para então parar para analisar o que pode estar dando errado.

Por isso as empresas que mais crescem e entregam tecnologias incríveis valorizam tanto os profissionais que colaboram para que isso aconteça. Mantendo sempre um ambiente com menos fricção para comunicação e mais atenção ao que está acontecendo durante as iterações de desenvolvimento.

Para você, quais são os maiores motivos para a falha em projetos de software? Deixe sua opinião sobre o assunto nos comentários.

Até a próxima!

Categorias
Crônicas Tech

O antropomorfismo da inteligência artificial

Faça uma pesquisa simples por inteligência artificial no Google Images. Você verá dois tipos de imagens: robôs no estilo do filme “Eu, Robô” e cérebros parecidos com chips de computadores.

Toda vez que alguém fala de inteligência artificial na mídia a imagem utilizada é a mesma: uma máquina humanoide. O mesmo acontece com as empresas de tecnologia quando geram conteúdos para seus clientes em peças de marketing.

Por que usar uma representação física de um robô para representar inteligência artificial quando a maioria dos exemplos de uso real dessa tecnologia estão longe de ser “animar” máquinas humanoides?

A resposta é simples. A maioria das pessoas não tem ideia do que realmente é a inteligência artificial e a forma mais fácil de mostrar visualmente esse conceito é através da representação cultural do robô.

Graças a livros e filmes muito populares o inconsciente coletivo imagina a inteligência artificial como uma versão artificial de um ser humano. Até porque a origem dos estudos desse campo foi exatamente essa. Criar uma versão artificial da inteligência humana.

Além disso, o ser humano naturalmente antropomorfiza as coisas. Coloca sentimentos e aparência humanas em animais e objetos. Explicar isso é trabalho para psicólogos, então não vou nem tentar.

Esse antropomorfismo da intlegência artificial acaba criando um problema de percepção para a grande parte das pessoas.

Junte a forma como a mídia mostra a tecnologia, a cultura geral e a facilidade para antropomorfizar as coisas que todos temos e pronto. Você tem uma pessoa que se desloca para um escritório de uma empresa de tecnologia para conhecer o “robô” que está atuando para prestar algum serviço.

Não acredita? Pois já tivemos um caso exatamente assim na empresa onde trabalho.

Quem sabe até existam pessoas que imaginam que automatizar um processo é o mesmo que colocar robôs humanoides fazendo o serviço que os humanos costumavam fazer.

Por mais que sonhemos com androides que serão quase indistinguíveis de seres humanos, como a Sophia da Hanson Robotics tenta ser, isso não é nem de longe a verdadeira cara da inteligência artificial dos dias de hoje.

A inteligência artificial está em softwares que rodam em hardwares muito mais parecidos com o seu computador de casa do que com o Robbin Williams em O Homem Bicentenário.

Os computadores que aprendem não vão ser expostos somente como assistentes pessoais (vide Elli Q) ou jogadores de tabuleiro (vide AlphaGo). Eles já estão dentro de nossas vidas constantemente sem que possamos perceber.

Toda vez que você acessa seu Facebook, faz uma pesquisa no Google ou faz uma compra pela internet, a inteligência artificial está lá. Ela é virtual, muitas vezes invisível e pode estar facilitando (ou não) a sua vida sem que você saiba.

Hoje em dia, uma boa representação de inteligência artificial seria algo bem menos interessante para o público em geral…

Servidores de pesquisa de Inteligência Artificial do Facebook em Prineville, Oregon.

Talvez as próximas gerações já tenham uma informação mais precisa sobre como tudo isso funciona, mas por enquanto, o único jeito que achamos de fazer alguém empatizar com o assunto é mostrando humanoides para representar a tecnologia da inteligência artificial.

Vamos continuar vendo muitos robôs humanoides nas capas de revistas e sites de notícias pelo mundo a fora por um bom tempo.

Até a próxima!

Categorias
Carreira

Carreira Programador – Quanto ganha um programador?

Essa é para quem está começando ou quer começar na área de desenvolvimento de software

Existe uma visão distorcida da realidade desse profissional de tecnologia da informação que escreve códigos e desenvolve sistemas.

Um Analista de Sistemas em início de carreira, por exemplo, tem salário médio de R$ 4,2 mil. Em três anos, sua média salarial pode chegar a R$ 7 mil. Com mais de dez anos de experiência, sua remuneração alcança R$ 17 mil. Isso sem falar nas possibilidades de especialização: um profissional de TI no Brasil com mestrado recebe o piso salarial médio de R$ 9,2 mil e um Diretor Técnico e de Operações do mercado de tecnologia pode ganhar até R$ 50 mil. Fonte: Terra em 22/12/2016

Início de carreira com mais de quatro mil reais e em apenas três anos já estar ganhando sete mil… essa não é a realidade da maioria dos profissionais de TI que conheço. Eu tenho mais de 10 anos de carreira e ainda não cheguei perto dos 17 mil… o que é uma pena!

Quem sabe essa matéria levou em conta apenas aqueles que trabalham em regime PJ e não os que tem carteira assinada… de qualquer forma, não me parece algo tão realista.

Pessoalmente me preocupa que essa visão seja disseminada e possa levar pessoas a buscar essa área apenas pela possibilidade de ganhar muito dinheiro, algo que não acontece com tanta frequência.

Vamos começar pelo começo: Não existe apenas “o programador”, assim como não há apenas “o médico” e “o advogado”.

Existem diversas áreas de programação como desenvolvimento mobile, backend, frontend, o faz-tudo (chamado de full stack por quem quer ser chique), etc.

Além das áreas, ainda existem as tecnologias específicas. As linguagens de programação, os sistemas operacionais, os frameworks, as metodologias de desenvolvimento… tudo isso conta para saber quanto vai faturar um desenvolvedor.

Outro ponto importante é em qual cidade você vai trabalhar. Existe uma probabilidade maior para o programador ganhar mais se morar em alguns polos de tecnologia do país, principalmente em São Paulo, graças à lei da oferta/demanda. Muitas empresas precisando de profissionais e nem tantos disponíveis. Isso não quer dizer que não existam programadores ganhando pouco nessas cidades…

Para finalizar, mas não se limitando a isso, o tipo de empresa em que o programador trabalha também influencia, e muito, no seu salário. Startups, fábricas de software, pequenas empresas de desenvolvimento, agências, grandes bancos, etc.

Que tal alguns “estudos de caso” para exemplificar. Começando pelo mais comum…

Um programador júnior trabalhando em uma startup, provavelmente um full-stack, ganha um salário mediano ou até abaixo do mercado.

E um de quem pode estar faturando legal.

Uma empresa em que o produto é um aplicativo, por exemplo, que tem uma VC investindo milhões. Sendo um sênior em uma equipe de desenvolvimento iOS… Sim, esse daí deve estar ganhando muito bem, para os padrões brasileiros.

Esses são alguns pontos que gosto de levantar toda vez que alguém me pergunta quanto ganha um desenvolvedor de software.

Obviamente estes são pontos de vista que obtive durante anos como andarilho nesse mercado e podem diferir de outros profissionais tão ou mais experientes.

Qual o seu ponto de vista? Deixe seu comentário.

Publicado originalmente no Medium.

Categorias
Tecnologia

Essa nova tecnologia vai acabar com o que você usa hoje

Para entusiastas de martelo tudo é prego

Eu adoro ler sobre tecnologia e sua indústria pela internet a fora. É muito bom para descobrir algumas tendências e aprender sobre minha área de atuação.

Mas eu tenho notado um certo exagero em algumas publicações de nicho.

Alguns autores parecem querer reforçar que você precisa aprender essa ou aquela tecnologia porque é a única coisa que vai existir no futuro!

“Essa é a tecnologia que irá acabar com/substituir o que você usa hoje. Esteja pronto!”

Para ilustrar melhor o que quero dizer vou dar alguns exemplos.

Quando comecei a me informar sobre chatbots a primeira coisa que li nos textos do pessoal que já estava envolvido com isso é que os bots tomariam o lugar dos aplicativos mobile e até mesmo dos sites.

Afirmam isso com base em informações relevantes mesmo, como pesquisas que mostram que nos EUA as pessoas não estão mais baixando novos apps. Não é uma invenção, me parece apenas uma interpretação exagerada dessas informações.

Um tempo depois eu achei uma publicação que falava sobre arquitetura serverless. Lá o discurso era que em cinco anos ninguém mais estaria usando servidores.

Quando você faz parte de um nicho é muito fácil se deixar levar por opiniões exageradas em favor do que você está envolvido. Entretanto é preciso ser mais objetivo.

É claro que os chatbots podem assumir uma boa fatia de mercado dos aplicativos nativos (e vão, afinal eu sou um entusiasta ;D), mas não vão simplesmente acabar com eles do dia para a noite.

A mesma coisa para a arquitetura serverless… ninguém mais usando servidores em cinco anos? Um pouco exagerado, não acha?

Esses são apenas alguns exemplos, mas ainda podemos voltar um pouco no tempo e lembrar de algumas ondas que diziam que os aplicativos nativos seriam totalmente substituídos pelos híbridos e, já hoje em dia, substituídos pelos progressive webapps ou chatbots

Que tal voltar ainda mais, lá no começo da minha carreira nos grupos de Software Livre, onde achávamos que em breve os computadores com Windows seriam minoria perto dos usuários Linux… E quinze anos depois:

Market share de sistemas operacionais

Mesmo que a tecnologia seja muito rápida em sua evolução, dificilmente uma coisa mata outra tão rápido quanto as postagens que geram o hype afirmam.

Isso acontece porque cada negócio tem uma necessidade diferente, então cada tecnologia pode ser a melhor opção para cada tipo de necessidade. Uma não necessariamente mata outra. E não precisa matar!

Para que uma coisa seja boa ela não tem que destruir outra. Existe espaço, e até a necessidade, para tudo!

Eu escrevi o rascunho deste texto dentro de um Cabify, uso Uber com frequência e adivinha só: ainda existem muitos táxis por aí.

Se você gosta de algo e participa de um grupo sobre isso, como eu com chatbots por exemplo, seja um entusiasta sim! Discuta sobre, aposte nisso, mas mantenha os pés no chão. Entenda que o que você faz/gosta pode ser um ótimo martelo, mas nem tudo é prego.

Publicado originalmente no Medium.

Categorias
Tecnologia

Você não precisa de inteligência artificial para criar um chatbot

Nem Machine Learning e Processamento de Linguagem Natural

Todo mundo que trabalha com desenvolvimento de software sabe que, cada vez mais, existem as “expressões do momento” no mercado. É por isso que eu adoro o texto Hype Driven Development

Uma das mais faladas “expressões do momento” é a inteligência artificial. Ela está em todo lugar, em todas as matérias nas mídias e diversos artigos acadêmicos e começou a ficar extremamente popular no último ano.

Cuidado! Inteligência artificial vai roubar seu emprego!

Depois que o Facebook resolveu liberar os chatbots para sua plataforma de mensagens, chatbot também virou uma expressão do momento. Eu mesmo gostava do assunto antes, mas a partir do ano passado comecei a estudar e aprender ainda mais sobre esse tipo de software.

A partir daí todo lugar onde se vê a palavra chatbot também se vê inteligência artificial. É uma questão bem óbvia, afinal para um robô falar com um humano, ele precisa ter o mínimo de inteligência…

Mas será mesmo que preciso saber criar inteligência artificial para criar um chatbot?

Citando um ótimo texto do Caio Calado que explica o que são chatbots:

Chatbots são serviços baseados em regras e (às vezes) inteligência artificial, onde você pode conversar e interagir através de aplicações/aplicativos de mensagens.

A parte importante dessa citação são as palavras entre parênteses: às vezes.

Como ele explica no texto, existem dois tipos de chatbots. Os baseados em regras e os baseados em inteligência artificial. A maioria dos bots que encontramos por aí é puramente baseado em regras e eles não são ruins por causa disso.

As plataformas de mensagens oferecem diversas maneiras para que o usuário posso interagir com o bot. São botões, listas com links, webviews que abrem uma página externa, etc. Utilizando essas interações fica muito fácil saber o que o usuário quer fazer, sem necessidade de inteligência artificial.

Você não precisa fazer com que o bot tenha um entendimento profundo da lingua portuguesa e entenda cada detalhe de tudo que o usuário está falando para que ele cumpra o que propõe.

Um bot tem que ter uma naturalidade na interação, mas isso depende muito mais do design da conversação do que de inteligência artificial.

Um chatbot é um software. A tecnologia que você vai usar no seu desenvolvimento precisa ser compatível com as necessidades das funcionalidades dele.

Machine Learning, Processamento de Linguagem Natural (NLP) e Inteligência Artificial (AI) são importantes para os mais diversos tipos de aplicações, mas para aquelas que realmente necessitam dessas tecnologias.

Se o bot precisa aprender com dados e interações para melhor atender o usuário e cumprir o objetivo proposto, então Machine Learning é necessário. Se ele precisa classificar textos que o usuário venha a enviar, você vai precisar de NLP… e assim por diante.

Agora se ele fala informações sobre o clima, não precisa ser “inteligente” para bater papo com o usuário ou aprender com as interações. Afinal o objetivo dele é previsão do tempo! Ele só precisa saber onde o usuário está ou de onde ele quer saber a previsão.

Outro grande problema desse hype todo é que essas expressões técnicas assustam quem não conhece e podem acabar afastando pessoas interessadas na construção de chatbots por acharem que é um impeditivo não saber essas tecnologias.

O hype é algo que sempre existirá, mas não devemos nos guiar por ele. Pense no objetivo que o seu chatbot terá e nas funcionalidades que serão necessárias para atingí-lo. Se ele realmente precisar de Inteligência Artificial, então pare de ler e vá estudar matemática agora!

Publicado originalmente no Medium.

Categorias
Tecnologia

O que aprendi publicando um chatbot

A importância do feedback dos usuários

Um tempo atrás eu quis falar sobre chatbots na empresa onde trabalho. Temos um evento interno para compartilhar conhecimento, que começou há pouco tempo por aqui, e aproveitei a chance para mostrar para meus colegas como desenvolver e quais eram as ferramentas que o Messenger do Facebook oferece para a criação de um robô de conversa. Para meu lightning talk resolvi criar um chatbot experimental chamado Climão.

O Climão é um bot bem simples e apenas recebe a localização da pessoa e informa como está o clima no local.

Para isso eu usei um dos templates do Facebook Messenger que cria um botão para o usuário enviar a localização e fiz uma busca em uma API aberta de informações meteorológicas.

Publiquei o bot no Facebook Messenger e aproveitei o que apresentei na empresa para escrever um tutorial.

Após a publicação, algumas pessoas começaram a usá-lo, provavelmente porque leram o tutorial e resolveram testar o bot para ver como funcionava.

Foi aí que comecei a perceber que o Climão precisava de algumas melhorias…

Aprendendo com a experiência do usuário

A primeira pessoa que usou o meu chatbot acessou através de um link que enviei no WhatsApp. Esse link abriu o navegador no celular dela e a primeira coisa que ela me disse foi que o bot não estava funcionando.

Eu dei uma olhada no que ela estava fazendo e vi que ela não usou o botão de enviar localização e sim escreveu o nome da cidade. Pedi para que usasse o botão, mas ela reportou que ele não aparecia para ela.

Fiquei sem entender nada… mas pedi para que abrisse no aplicativo do Messenger e a partir daí tudo funcionou normalmente.

Acessando o histórico de mensagens da página do Climão percebi que mais algumas pessoas estavam tentando escrever o nome da cidade e não usando o botão de enviar localização. Isso era algo que eu não tinha previsto e portanto o bot não entendia e acabava reenviando o botão o tempo todo.

A primeira coisa que pensei foi que as pessoas não estão acostumadas a usar botões em chats, deve ser esse o problema.

Mas a realidade era outra.

Quando montei o bot para a apresentação, não dei atenção alguma para o texto que convidava o usuário à escolher a sua localização. Ele dizia: “De qual cidade você quer saber o clima?”. Isso fazia com que a pessoa pensasse que tinha que responder à pergunta.

Esse feedback veio da mesma pessoa que citei a cima. Algo que não havia me passado pela cabeça!

Isso podia mesmo ser um motivo, mas os dias passavam e eu via mais gente usando o Climão e escrevendo repetidamente o nome da cidade em vez de usar o botão.

Será mesmo que apenas a pergunta estava levando tanta gente à escrever a cidade? Por acaso, acabei descobrindo que não.

Lendo outro texto do Medium que falava sobre um chatbot, resolvi clicar no link para experimentá-lo. Foi então que o mistério se resolveu.

As pessoas estavam acessando o Climão pelo texto do Medium, assim como eu, provavelmente pelo celular, assim com eu, e estavam caindo direto no navegador, assim como eu.

Abrindo a página do Facebook pelo navegador do celular e clicando em “Enviar mensagem” você entra em uma página terrível de mensagem que não tem nenhuma das funcionalidades dos bots do Messenger. Nela você pode interagir com o bot apenas por texto!

No lado esquerdo a versão do navegador mobile e na direita o aplicativo do Facebook Messenger.

Isso poderia ser mais um motivo, além do “texto-pergunta”, que estava fazendo as pessoas digitarem ao invés de enviarem sua localização pelo botão.

Foi então que resolvi melhorar o bot, mesmo ele sendo apenas um experimento para um tutorial, achei que valia a pena a experiência de aprender com a interação de usuários.

Gastei um tempinho nele e fiz com que também aceitasse o nome da cidade escrita. Mudei a frase que pede a localização. Agora ele escolhe aleatoriamente entre algumas opções de texto que indicam ao usuário que pode digitar uma cidade ou apertar o botão de envio de localização.

Aproveitei para dar um tapa no visual da apresentação dos dados também. Ao invés de enviar apenas um texto, resolvi utilizar o template de lista que a API de envio do Messenger proporciona.

Interações “fora do contexto”

Um outro fato que me chamou a atenção quando analisei as mensagens enviadas pelos usuários foram as mensagens que estavam “fora do contexto” das funcionalidades do Climão.

Com “fora do contexto” eu quero dizer interações que eu não previ.

Coisas simples como um “Olá” e um “Obrigado” não eram tratadas, deixando o bot muito “robótico” e pouco natural na conversação. O Climão era antipático!

Dei uma atenção para o tratamento desse tipo de interação, mas não gastei muito tempo com isso ainda, afinal ele é apenas um experimento. Podemos dizer agora que ele não é muito simpático, mas pelo menos já é educado.

Algumas coisas ele responde, mas não chega a ser tão esperto assim…

Conclusão

Esse bot tem sido um experimento incrível. Além de ter aprendido muita coisa com um chatbot tão simples, ainda tenho ganhado uma experiência importante sobre como evoluí-lo para melhor se adaptar às interações com os usuários.

O feedback é a melhor maneira de se aprender. Saber onde você errou ou o que deixou passar depende muito dessa interação com diferentes pessoas. Por isso foi tão importante tirar esse bot do “desenvolvimento” e deixá-lo disponível para o público em geral.

Se você leitor tiver alguma sugestão para melhorar o Climão, deixe sua resposta abaixo. E se quiser ver o código-fonte, acesse o repositório no Github. Quer saber o clima atual em algum lugar? Mande uma mensagem pro Climão!

Publicado originalmente no Medium.

Categorias
Tecnologia

Como fazer tunelamento de localhost de forma segura

Veja como expor seu servidor local para a internet e para que serve isso

O tunelamento do localhost é uma maneira de ter um “link externo” que aponte para alguma aplicação que você esteja rodando localmente. Dessa forma podemos “expor” nosso servidor local de forma segura.

Mas por que eu iria querer isso? Podemos usar essa solução para diversas situações, principalmente no desenvolvimento web. Vou mostrar alguns exemplos de uso nessa publicação.

Para os exemplos a seguir eu estou usando o ngrok, um software que facilita muito isso e ainda mantém essa exposição totalmente segura.

Mostrar um desenvolvimento em andamento para o cliente

Digamos que você esteja desenvolvendo um site ou um sistema web para um cliente e quer mostrar o que você desenvolveu até o momento. O mais comum seria fazer o deploy do trabalho em andamento em um servidor web e disponibilizar o link para seu cliente.

Mas existe uma outra opção, podemos deixar o site rodando localmente e tunelar com o ngrok.

Você pode iniciar um servidor local com o SimpleHTTPServer do Python, por exemplo, e rodar o ngrok na linha de comando, como no exemplo abaixo.

$ python -m SimpleHTTPServer 8000
Serving HTTP on 0.0.0.0 port 8000 ...

Em outra aba do terminal você inicia o tunelamento.

./ngrok http 8000

Agora ele irá exibir o endereço que ficará disponível para seu cliente pela internet. Será algo como http://36096fff.ngrok.io.

Ao rodar, o ngrok vai aparecer assim no seu terminal…

Estamos iniciando um servidor HTTP local na porta 8000. Perceba que o comando de tunelamento recebeu os parâmetros http e 8000, indicando que é um servidor http e que está usando a porta 8000.

Testar um chatbot durante o desenvolvimento

Durante o desenvolvimento de um chatbot para o Facebook Messenger, por exemplo, não é possível testar sem um “endereço web”. É preciso que seja registrada uma URL nas configurações do seu chatbot do Messenger para que ele receba os eventos de mensagem.

Para entender melhor sobre isso, veja este artigo.

Para que você não precise fazer deploy de cada pequena alteração em um servidor web para testar no seu chatbot, crie um tunelamento, como no exemplo anterior, e registre o endereço gerado na seção webhook nas configurações do chatbot no Messenger.

Obs: Nem todos os aplicativos de mensagem se utilizam de webhooks para receber os eventos. No caso do Telegram, como neste link, não é necessário utilizar o tunelamento.

Testar endpoints de webhooks

Eu falei em webhooks no item anterior. Pra quem não sabe o que é, segue uma tradução livre de uma parte do artigo da Wikipedia:

Webhooks são “retornos de chamada HTTP definidos pelo usuário”. Normalmente eles são ativados por algum evento, como o push de código para um repositório ou um novo comentário postado em um blog. Quando ele acontece, o site origem faz uma requisição HTTP para a URI configurada para o webhook, enviando os dados do evento.

Existem diversos serviços que utilizam esse formato para enviar dados de eventos. Um bom exemplo é o Sendgrid ou o Mandrill, que usam webhooks para enviar os eventos de email (lido, marcado como spam, link clicado, etc.) para um sistema de terceiros que esteja usando sua API.

Outro bom exemplo são integrações com gateways de pagamento, como Iugu, PagSeguro ou PayPal, onde, mesmo durante o desenvolvimento, você precisa de um “endereço web aberto” para receber os eventos relacionados aos pagamentos, alterando o status de uma compra, por exemplo.

Para isso, abra um tunelamento com o ngrok e registre o novo endereço gerado por ele com o seu endpoint para receber os eventos webhook do serviço que você está utilizando.

Painel do ngrok

Uma funcionalidade interessante do ngrok é o seu painel, ou interface web.

Screenshot da interface web

Com ela você vê todas as requisições que foram feitas ao seu endereço web aberto. Com isso você pode verificar os dados que estão vindo com as requisições e ainda dar um “replay” na mesma, para testar novamente.

Para acessar, veja o endereço listado no terminal do ngrok como Web Interface e abra no seu navegador. Vai ser algo como http://127.0.0.1:4040.

Concluindo

Esses são alguns casos de uso para o tunelamento de localhost. Alguns deles eu já utilizei, como o teste de webhooks e a demonstração de desenvolvimento em andamento para cliente. Mas eu descobri mesmo que isso era possível ao ler um tutorial de criação de chatbot para o Facebook Messenger, então resolvi dar esse exemplo também.

Publicado originalmente no Medium.
Categorias
Tecnologia

Como criar um chatbot para Telegram

Essa publicação é baseada na minha primeira experiência criando um chatbot para o Telegram usando Python. O código fonte dessa experiência pode ser encontrado no meu Github.

The Botfather

O Telegram facilita muito a criação de bots para seu sistema. Além de uma documentação muito boa e uma API muito simples de usar, ele possui o BotFather, um bot que ajuda qualquer um a criar seu próprio bot.

Segundo a documentação do Telegram:

BotFather is the one bot to rule them all. It will help you create new bots and change settings for existing ones.

Então vamos lá. Para começar é preciso acessar o @BotFather e fazer o registro do seu novo chatbot.

Para qualquer criação ou configuração de bot é preciso acessá-lo. E como vamos criar um novo bot, acessamos o link @BotFather.

Lá você terá acesso a diversos comandos, dentre eles o /start, que irá apresentar a lista desses comandos e o /newbot, que serve para a criação de um novo bot.

Quando executarmos o /newbot ele pede algumas configurações, como o nome e o username que serão utilizados pelo bot. Nada complicado.

Seu bot será como um usuário comum do Telegram, com um “nome para exibição” e um “nome de usuário” (username) para controle.

Assim que forem preenchidos os dados necessários ele irá gerar um token para ser utilizado no seu script. Esse token é único e serve como uma “senha” para seu bot, portanto deve ser mantido em sigilo.

Para saber mais sobre o @BotFather, acesse a documentação do Telegram que fala sobre bots para desenvolvedores.

Armazenando e acessando o token

Agora que já temos o token do nosso bot, devemos guardá-lo em uma variável de ambiente para que possamos acessá-lo posteriormente no nosso script Python.

Na linha de comando, execute o seguinte:

$ export BOT_API_TOKEN="<aqui vai o token gerado pelo botfather>"

Agora você poderá recuperá-lo facilmente em seu script Python com apenas duas linhas de código.

import os
token = os.environ['BOT_API_TOKEN']

Obs: Esta é apenas uma sugestão de como armazenar essa informação. Você pode guardar seu token da maneira que achar melhor.

Implementando os comandos

Um pacote que facilita muito a vida de quem está desenvolvendo um bot para o Telegram é o pyTelegramBotAPI. Com ele basta adicionar decorators nas suas funções e elas passarão a atender aos comandos recebidos.

Podemos usar o seguinte comando para instalar o pacote via pip:

$ pip install pyTelegramBotAPI

Agora chegou a hora de implementar os comandos que controlarão o bot.

Vou abordar somente um tipo de decorator e de resposta a caráter de exemplo. Através da documentação do pyTelegramBotAPI você consegue facilmente implementar diversas outras formas de input e output para o seu bot.

Começamos o script em Python fazendo nossos imports e iniciando o telebot com o token do Telegram gerado pelo @BotFather, como no exemplo de código abaixo.

import os
import telebot
  
bot = telebot.TeleBot(os.environ['BOT_API_TOKEN'])

Agora é só começar a implementar os comandos. No exemplo abaixo eu estou implementando uma mensagem de boas vindas para os comandos /start e /help.

@bot.message_handler(commands=['start', 'help'])
def send_welcome(message):
    bot.reply_to(message, u"Olá, bem-vindo ao bot!")

No final do script adicionamos o método bot.polling() para inicializar o nosso novíssimo bot.

bot.polling()

Basta executar o script em linha de comando e o seu bot está pronto para começar a ser testado.

$ python bot.py

Para executar o teste, basta acessar seu Telegram e seguir o usuário com o username que você deu para seu bot lá no começo do processo, com o @BotFather.

E voilá!

Simples, não é? Veja como nosso script em Python ficou bem pequeno.

import os
import telebot
  
bot = telebot.TeleBot(os.environ['BOT_API_TOKEN'])
@bot.message_handler(commands=['start', 'help'])
def send_welcome(message):
    bot.reply_to(message, u"Olá, bem-vindo ao bot!")
bot.polling()

Publicado originalmente no Medium.

Categorias
Tecnologia

Como usar múltiplos databases no Django

Utilizando o Database Router de uma forma genérica

Existem diversos motivos para utilizar mais de um banco de dados no seu projeto de software. Um deles pode ser as réplicas, por exemplo. Neste caso o aplicativo escreve as informações em um banco de dados, mas lê de outro.

Um diagrama mostrando o banco primário e suas réplicas de leitura

A vantagem de usar uma réplica é que a escrita em banco é mais custosa do que a leitura. Então, se uma consulta for feita durante um processo de inserção de dados, dependendo da quantidade de dados que está sendo escrito no database, ela pode acabar ficando muito mais lenta, causando um problema de timeout ou até tirando seu sistema do ar.

Esse é apenas um dos exemplos que é abordado na própria documentação oficial do Django. Como mostra este link.

Obviamente, esse não é o único motivo para se ter mais de um database no sistema, podem existir inúmeros, incluindo o que me fez pesquisar sobre isso. Vou falar mais sobre o meu caso específico no final desta publicação.

Definindo os databases

O primeiro passo para utilizar mais de um database no Django é definir seus bancos de dados nas configurações do arquivo settings.py.

DATABASES = {
    'default': {},
    'primary': {
        'NAME': 'primary',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'spam',
    },
    'replica1': {
        'NAME': 'replica1',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'eggs',
    },
    'replica2': {
        'NAME': 'replica2',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'bacon',
    },
}

Com esse código, retirado da documentação do Django, estamos definindo um banco de dados principal MySQL e mais duas réplicas.

A partir de agora você pode alternar o banco manualmente chamando o using() do QuerySet. Ele recebe apenas um argumento, o nome do banco de dados.

>>> # Isso irá rodar a consulta no banco 'default'.
>>> Author.objects.all()
>>> # Isso também.
>>> Author.objects.using('default').all()
>>> # Já esse irá rodar a consulta no banco 'other'.
>>> Author.objects.using('other').all()

Acredito que esse approach não deve agradar muito o desenvolvedor. Ter que definir manualmente qual o banco a ser utilizado em cada query, não é lá muito prático, certo?

Pra evitar isso temos o Database Router, o roteador de banco de dados nativo do Django.

Criando um Database Router

O roteador de banco de dados simplesmente define qual banco é usado para cada tipo de operação.

No exemplo abaixo, também retirado da documentação do Django, mostro como rotear entre os bancos. Nesse caso, vamos ler das réplicas e escrever no primário.

import random
class PrimaryReplicaRouter(object):
    def db_for_read(self, model, **hints):
        """
        Consultas vão aleatoriamente para uma das réplicas.
        """
        return random.choice(['replica1', 'replica2'])
    def db_for_write(self, model, **hints):
        """
        Escritas sempre são feitas no banco primário.
        """
        return 'primary'
    def allow_relation(self, obj1, obj2, **hints):
        """
        Relações entre objetos são permitidas se ambos estiverem no 
        pool primary/replica.
        """
        db_list = ('primary', 'replica1', 'replica2')
        if obj1._state.db in db_list and obj2._state.db in db_list:
            return True
        return None
    def allow_migrate(self, db, app_label, model_name=None, **hints):
        """
        All non-auth models end up in this pool.
        """
        return True

Note que o roteador de banco de dados disponibiliza quatro métodos. São eles:

  • db_for_write()
  • db_for_read()
  • allow_relation()
  • allow_migrate()

Na leitura escolhemos aleatoriamente uma das duas réplicas e na escrita escolhemos o banco primário. Perceba que simplesmente retornamos o nome do banco, que definimos nas configurações de database no settings.py.

Para que o router seja aplicado, precisamos adicionar a constante DATABASE_ROUTERS no arquivo settings.py, como mostro abaixo.

DATABASE_ROUTERS = ['caminho.para.o.PrimaryReplicaRouter']

Este é um exemplo simplificado do que pode ser feito com os database routers. Apenas resumi a documentação do Django sobre o assunto até agora.

Partimos para algo diferente, então.

Uma solução mais genérica

Procurando sobre o assunto na internet, cheguei até esta postagem de 2011 que mostra uma solução mais genérica para o database router e ainda com possibilidade de utilizar para mais de um app do Django.

from django.conf import settings
class DatabaseAppsRouter(object):
    """
    A router to control all database operations on models for different databases.
    In case an app is not set in settings.DATABASE_APPS_MAPPING, the router will fallback to the `default` database.
    Settings example:
    DATABASE_APPS_MAPPING = {'app1': 'db1', 'app2': 'db2'}
    """
    def db_for_read(self, model, **hints):
        """"Point all read operations to the specific database."""
        if settings.DATABASE_APPS_MAPPING.has_key(model._meta.app_label):
            return settings.DATABASE_APPS_MAPPING[model._meta.app_label]
        return None
    def db_for_write(self, model, **hints):
        """Point all write operations to the specific database."""
        if settings.DATABASE_APPS_MAPPING.has_key(model._meta.app_label):
            return settings.DATABASE_APPS_MAPPING[model._meta.app_label]
        return None
    def allow_relation(self, obj1, obj2, **hints):
        """Allow any relation between apps that use the same database."""
        db_obj1 = settings.DATABASE_APPS_MAPPING.get(obj1._meta.app_label)
        db_obj2 = settings.DATABASE_APPS_MAPPING.get(obj2._meta.app_label)
        if db_obj1 and db_obj2:
            if db_obj1 == db_obj2:
                return True
            else:
                return False
        return None
    def allow_syncdb(self, db, model):
        """Make sure that apps only appear in the related database."""
        if db in settings.DATABASE_APPS_MAPPING.values():
            return settings.DATABASE_APPS_MAPPING.get(model._meta.app_label) == db
        elif settings.DATABASE_APPS_MAPPING.has_key(model._meta.app_label):
            return False
        return None

Agora basta mapear os apps com os databases no seu settings.py:

# Fonte: http://stackoverflow.com/a/18548287
DATABASE_ROUTERS = ['caminho.para.o.DatabaseAppsRouter']
DATABASE_APPS_MAPPING = {'nome_do_app': 'nome_do_db',
                         'nome_do_outro_app': 'nome_do_outro_db'}

No Meta do meu model eu defino o app_label, como no exemplo abaixo.

class Author(models.Model):
    name = models.CharFiels(max_length=120)
    class Meta:
        app_label = 'nome_do_app'

No meu caso de uso dessa solução, eu precisava que apenas um model lesse de um banco da dados diferente dos outros. Então, somente nele, eu adicionei o app_label mapeado com o banco de dados diferente.

Todos os outros models, que não possuem essa configuração, usam o banco default automaticamente, apenas o model com o app_label definido passa a usar o outro database.

Essa solução simplificou muito minha vida, pois agora eu posso continuar fazendo as consultas normalmente, porque o database router vai rotear tudo de maneira automática. Não preciso mais me preocupar com qual banco ele está buscando a informação em cada model.

Concluindo

Bem, é isso que tenho para mostrar. Sei que a abordagem é simplificada, mas foi a primeira vez que trabalhei nesse problema e quis dividir o que aprendi por aqui.

Espero que tenha ficado tranquilo de entender sobre o roteamento de banco de dados no Django. Caso eu não tenho sido claro em algum detalhe, entre em contanto.

Publicado originalmente no Medium.