Categorias
Crônicas

A ansiedade para terminar logo suas HQs

Incrivelmente um dos assuntos que mais tem recebido engajamento nas minhas redes sociais é a ansiedade.

No mundo de hoje todos vivemos com esse mal, essa angustia constante de que não estamos fazendo o suficiente ou que devíamos fazer mais.

Na minha opinião um dos principais fatores para que isso aconteça são as redes sociais.

Elas nos ajudam demais como quadrinistas. Podemos divulgar nosso trabalho e atingir milhares de pessoas sem depender diretamente de editoras ou grandes portais.

Mas ao mesmo tempo, se você não atualiza constantemente suas redes corre o risco de “perder a atenção” das pessoas e ser “esquecido”.

Vivemos nessa pressão: poste páginas em andamento, pelo menos um desenho por dia, responda a todos que comentarem… e etc.

O medo de perder essa atenção e de querer postar mais gera muita ansiedade.

E a ansiedade pode atrapalhar a qualidade do trabalho, como eu falei em parte deste vídeo que está abaixo.

Eu não saberia dizer como evitar isso.

Acredito que é um mal que muita gente enfrenta e que não está no meu alcance conseguir resolver.

Só que falar sobre isso já abre uma porta para muita gente.

Quando eu postei o seguinte texto no meu Instagram tive muitas pessoas dizendo que foram palavras que elas precisavam ouvir.

As vezes fica difícil arranjar tempo nessa vida corrida pra parar e trabalhar no projeto de quadrinhos.

Muita gente passa por isso! Ainda mais quando criar HQ é um projeto paralelo. O que não devemos fazer é desistir por causa da ansiedade. Ansiedade de fazer logo… quando você vê que não está conseguindo, que está demorando porque a vida coloca um monte de obstáculos, lembre-se que você faz isso porque gosta. E que não deve ser mais um peso e sim um prazer!

Então, quando surgir aquele tempinho livre, sente e crie. Sem pressão e sem o “desespero” de ter algo pronto logo.

A tecnologia nos permite divulgar nosso trabalho pra muita gente, mas ela também causa essa ansiedade do imediatismo.

Por isso, continue no seu tempo. Sem pressa! ^.^

Eu nunca imaginaria que essa postagem pudesse levantar uma questão tão importante.

Eu escrevi apenas para desabafar um pouco sobre o fato de não estar conseguindo manter o ritmo de criação das páginas de quadrinhos e por isso estar me sentindo ansioso.

Quando escrevi percebi que era algo que outras pessoas poderiam estar passando também, então adicionei essa pequena catarse que tive sobre fazer o que gosta e por diversão.

Sei que a maioria da minha audiência, assim como eu, faz quadrinhos no seu tempo livre. Então imaginava que eles também sofressem com isso.

Nós nos cobramos de mais. E isso gera ainda mais ansiedade.

Então a ideia é simplesmente tentar relaxar um pouco e lembrar de fazer coisas que são divertidas também.

Sei que não vou resolver o problema do mundo com esse texto, mas gosto de escrever e estou me divertindo fazendo isso.

E se ajudar uma pessoa, nem que seja um pouco, a ficar menos ansiosa… então está valendo!

Links úteis para você

Quem sou eu pra falar de ansiedade e quadrinhos?

Meu nome é Marcus Beck e sou quadrinista e professor de quadrinhos. Meu objetivo é trazer o máximo possível de informação sobre como criar uma história em quadrinhos.

Publiquei minhas webcomics (quadrinhos online publicados na internet) por mais de dez anos e aprendi muitas lições sobre o que deve ou não ser feito para que as HQs sejam as melhores possíveis.

Quando eu comecei a criar meus quadrinhos eu gostaria muito que tivesse conteúdo sobre o assunto para que eu não tivesse que aprender tudo sozinho. É por isso que criei esse canal e também o meu blog, para ajudar quem está passando pela mesma situação que eu estive quando comecei.

Faço o possível para responder todas as perguntas, por isso fique a vontade para comentar com todas as suas duvidas. =)

Compartilhe:

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
Crônicas Tecnologia

Ser um Programador Ninja…

…ou Programador Rockstar ou Mago da Programação…


Este texto foi originalmente publicado no Medium. Leia a versão original clicando aqui e recomende se você gostar.


Alguns bons anos atrás, costumava ser cool ver uma vaga de emprego com a expressão “programador ninja” ou algo do gênero. Mostrava que a empresa era maneira, joinha e que tinha aquele ambiente de trabalho diferentão.

“Buscamos um programador ninja”

Hoje, a coisa é um pouco diferente. Quando vejo uma vaga que busca um programador ninja ou um mago da programação, eu já desconfio.

O problema não é a expressão em si, que hoje em dia é brega e não pinta mais a empresa como “diferentona”. O problema é que ela costuma vir com uma lista absurda de exigências…

O cidadão tem que comprovar anos de experiência em diversas linguagens de programação, tem que gostar de programar em seu horário livre (?!) e, às vezes, é um diferencial, se não obrigação, que o camarada tenha projetos paralelos.

Ou seja, o cara não tem que ser um programador… Ele tem que programar de tudo e o tempo todo. Se tiver vida pessoal, não serve para mago da programação.

O ninja-mago-rockstar da programação

Por algum motivo essas empresas acreditam que é preciso ser apaixonado pela programação para ser um bom profissional. E para demonstrar isso tem que ter aqueles projetos paralelos e, quem sabe, uns commits no seu Github nas madrugadas de sábado.

O que não percebem é que quem programa por prazer não necessariamente vai gostar de trabalhar no seu projeto de gestor administrativo ou de vendas. Hobbies que viram trabalho nem sempre são tão prazerosos. E isso não é tudo…


Nesta semana eu li um texto aqui no Medium chamado Programming Doesn’t Require Talent or Even Passion (Programar Não Exige Talento ou Mesmo Paixão). Eu recomendo a leitura para qualquer um que trabalhe na área.

Nele o autor fala que nunca antes uma habilidade foi tão mitificada como a programação.

“Você não precisa apenas ter talento, você também precisa ser apaixonado para se qualificar como um bom programador.”

É exatamente o que pedem nessas vagas de programador Rockstar dos dias de hoje.


Exemplo de uma vaga postada na lista Python BrasilNo texto citado, o autor ainda traz uma série de grandes nomes da área, como os criadores dos frameworks Rails e Django e da linguagem PHP, por exemplo, que demonstram claramente não serem grandes amantes da programação e muito menos gênios da magia do desenvolvimento de software.

“Na verdade eu odeio programar, mas eu amo resolver problemas.” Tradução da citação de Rasmus Lerdorf, criador do PHP.

Eu trabalho nessa área há cerca de treze anos e não tenho receio em dizer que os melhores profissionais que encontrei não eram grandes magos dos códigos. O que realmente importa nessa área é a entrega. É conseguir resolver os problemas apresentados de forma objetiva e simples e, quase sempre, em um curtíssimo espaço de tempo.

Um bom profissional da programação não precisa ser um gênio, um monstro, um ninja, um hacker… ele precisa saber resolver problemas e ter a capacidade e humildade de aprender o que precisar para atingir esse objetivo.

Além disso, esse mito atrapalha todo mundo que está envolvido ou quer se envolver na área.

“O mito do ‘programador gênio’ é extremamente perigoso. Por um lado, ele deixa o limiar de entrada muito alto, assustando um monte de aspirantes a programador. Por outro lado, também assombra os que já são programadores, porque isso significa que se você não é um mago na programação, você é ruim… …Programação é só um monte de habilidades que podem ser aprendidas e não exigem muito talento, e não é vergonha nenhuma ser um programador mediano.” Tradução livre de parte da citação de Jacob Kaplan-Moss, criador do Django.

Eu consegui aprender a programar, e nem sequer gostava disso…

“Depois de muito tempo percebi que eu tinha ficado melhor em programar e continuava sempre ocupando vagas em empresas nessa área, entretanto, sempre querendo sair para ‘trabalhar com o que gosto’.”

Esse é um trecho de um texto que escrevi em 2014 falando sobre a minha relação conturbada com a programação. Eu passei anos procurando trabalhar em outra área, porque realmente não gostava de programar.

O que mudou isso em mim foi conhecer o Python. Passei a curtir a simplicidade e objetividade de escrever códigos com essa linguagem. Hoje eu gosto do que faço. De vez em quando eu até programo por diversão no meu horário livre.

Eu não consigo me enxergar como um bom programador, mas sei que consigo atender as expectativas de quem me contrata. Resolvo os problemas e faço as minhas entregas. E isso me deixa orgulhoso do meu trabalho.

Não somos ninjas, gênios ou magos, somos profissionais da área de desenvolvimento de software. É isso que temos que ser das 9h as 18h, ou em qualquer que seja seu horário de trabalho, o que fazemos fora disso diz respeito somente a nós mesmos.

Quer ter projetos paralelos? Ama programar? Ótimo.

Mas se você gosta de nadar, andar de bicicleta, jogar futebol, passear com seu cachorro, ficar com sua família ou dormir por horas e horas no seu tempo livre, você continua sendo um programador.

Não é isso que vai definir sua qualidade como profissional.

Pode ser também…

Categorias
Crônicas Tecnologia

Lançamento do Diligeiro

Em novembro de 2015 recebi uma ligação de uma empresa na qual eu já havia feito entrevistas e testes meses antes. Nesta ligação marcamos uma reunião e na próxima semana lá estava eu ouvindo pela primeira vez sobre o Diligeiro.

O Diligeiro é um aplicativo para smartphone que serve para conectar advogados correspondentes com escritórios de advocacia ou advogados que precisam do serviço de diligência.

O meu desafio era criar o backend desse aplicativo, uma API. O seu grande diferencial é a geolocalização, mostrar aos correspondentes quais diligências estão mais próximas dele. Ou seja, seria minha primeira experiência desenvolvendo uma API e também a primeira experiência com Geolocalização. Estudei, experimentei e hoje posso dizer que aprendi muito.

Enquanto ainda desenvolvia todas essas coisas novas para mim, fui escalado para fazer também o frontend web do mesmo produto. Mais uma série de aprendizados, desenvolver um frontend web totalmente baseado em requisições de API. Mais estudos, experiências e aprendizados.

Nas últimas semanas o aplicativo para Android e a versão Web do Diligeiro foram lançados em formato Alpha e em seguida em formato Beta, para que os usuários pudessem começar a utilizá-lo e passarem seus feedbacks.

Nesta semana o aplicativo Android e o WebApp foram abertos ao público.

Foram seis meses de muito trabalho, muitos aprendizados e também muita diversão, graças à equipe incrível da TIA Tikal.

O trabalho continua, as melhorias e novas ideias para funcionalidades não param nunca, mas a fase inicial de desenvolvimento acabou. Agora é hora de deixar que os usuários decidam se todo o esforço valeu a pena. O aplicativo iOS continua em desenvolvimento.

Me sinto orgulhoso pelo resultado dessa primeira fase e agradecido a todos os envolvidos. A equipe do Diligeiro e a equipe do LegalNote, o produto irmão do Diligeiro que já está no mercado a mais tempo.

Categorias
Crônicas Empreendedorismo

Aprendendo com 2015

Que ano! 2015 foi o ano mais produtivo da minha vida inteira e também o mais difícil de todos.

Comecei o ano trabalhando numa empresa gigante, de renome, com bom salário, dinheiro guardado, mas extremamente infeliz. Tomei a drástica decisão largar tudo e empreender de alguma forma em fevereiro. Sem um produto, sem experiência, sem conhecimento suficiente… apenas um salto de fé. Um salto no escuro.

O dinheiro acabou antes do esperado. Continuei insistindo, achando que o que sempre me faltara era a persistência e dessa vez eu ia conseguir.

Persistência é uma qualidade. Teimosia, não

Por sorte, eu tenho pessoas na minha vida que me ajudam a ver as coisas de outro ponto de vista. Quando cheguei no fundo do poço, percebi que estava sendo teimoso e burro, não persistente. Foi então que uma batalha para me reerguer começou.

Desenvolvedor por mais de 12 anos, sempre trabalhei com PHP, mas eu queria trabalhar com Python. Havia passado o ano todo estudando e desenvolvendo nesta linguagem de programação, mas nas atuais circunstâncias eu estava aceitando qualquer coisa.

Pela primeira vez na vida, demorei meses para conseguir algum trabalho. Consegui alguma coisa, mas ainda não era o que eu buscava. Eu jamais achei que fosse encontrar o que queria trabalhando em uma empresa.

Foi então que dois dias antes da Python Brasil 2015 eu recebi uma ligação. No telefone uma pessoa com quem eu havia feito uma entrevista meses atrás, mas que não tinha me escolhido para vaga. Ele dizia que desta vez tinha a vaga ideal para meu perfil. Marcamos a conversa para um dia depois do evento. No outro lado da linha estava o CTO da Tikal, responsável por produtos como o LegalNote e o Diligeiro.

Era novembro. Os meses que passaram desde fevereiro pareciam décadas. Lá estava eu, finalmente trabalhando com Python e numa startup. Ainda era apenas uma salinha dentro de outro escritório. Me apaixonei pela ideia, pelo ambiente, pela oportunidade de começar um projeto novo, vê-lo crescer e se desenvolver.

Mas o que eu não sabia é que ali eu iria encontrar exatamente o que eu estava procurando. Pela primeira vez na minha vida eu me senti livre e ao mesmo tempo fazendo parte de algo. Descobri que essa combinação é possível. E descobri que essa combinação é exatamente o que eu procurava.

Esse ano foi o ano mais difícil da minha vida, mas também foi o ano em que mais aprendi. Aprendi sobre mim, aprendi sobre Python, aprendi sobre trabalho, aprendi sobre a paciência, sobre a ganância, sobre o que é ter muito e o que é ter pouco, aprendi que ser é mais importante que ter. Mas acima de tudo, aprendi que as dificuldades são degraus de uma escada que leva você para a maturidade, para o autoconhecimento e para a satisfação pessoal.

Obrigado, 2015, por me ensinar tanto.

Categorias
Crônicas Tecnologia

Sobre a Python Brasil 2015

Apesar de tantos anos trabalhando com desenvolvimento web e tecnologia eu nunca havia participado de uma conferência de qualquer tecnologia na minha vida. Como no último ano tenho mergulhado 100% no desenvolvimento com a linguagem Python, poucos dias atrás me inscrevi em cima da hora para a PythonBrasil[11].

Tudo começou com os tutoriais gratuitos que aconteceram na FATEC de São José dos Campos, cidade escolhida para a edição 2015 do evento. Diversos tutoriais e workshops sobre os mais diversos usos da linguagem Python e tudo de graça. O único problema era escolher qual eu deveria participar naquele horário, pois muitos aconteciam ao mesmo tempo em salas diferentes.

Na segunda-feira começou a conferência em si, no Novotel de SJC, com Keynotes,Lightning Talks (palestras de 5 minutos de pessoas que se inscrevem na hora para falar sobre algo) e palestras simultâneas divididas em quatro diferentes trilhas: pydata, web, carreira e iniciantes. No caso das trilhas, mais uma vez o “problema” de escolher a qual comparecer em determinado horário.

Neste mesmo dia a noite tivemos um #horaextra em um kart muito próximo do local do evento onde todo mundo se divertiu e teve mais oportunidade para conhecer pessoas incríveis. Jantei na mesma mesa que o David Beazley, que veio de Chicago para dar uma palestra incrível na terça-feira. E o cara é muito gente boa!

Na terça tivemos mais palestras, keynotes e lightning talks. E foi tudo muito legal e construtivo.

A comunidade Python é bastante aberta para novos membros e o pessoal da organização foi extremamente atencioso, apesar da correria que é organizar um evento desse porte.

Como todos com quem conversei me confirmaram, a melhor parte desta comunidade não é só o conhecimento que é compartilhado, mas também as pessoas que fazem parte dela.

Participar dessa conferência foi uma experiência muito boa, então já vou me preparar para o ano que vem, não quero mais perder as próximas PythonBrasil.

Publicado originalmente no LinkedIn Pulse.

Categorias
Tecnologia

Annyang para reconhecimento de voz

Nos últimos dias do ano passado comecei um projeto de chatbot para praticar Python e Flask, chama-se Jarvis. A ideia é que sempre que eu tiver um tempo livre eu adicione algumas coisinhas a mais nele.

Desde o começo eu gostaria que o Jarvis ajudasse na prática da lingua inglesa, principalmente na conversação. Foi por isso que comecei a pesquisar meios de fazer reconhecimento de voz (speech recognition) pela web.

A opção mais comum é a Speech API do Google, entretanto ela tem algumas limitações por ter um largo uso entre os desenvolvedores. Então fui pesquisar se existia outra opção. Nessa pesquisa encontrei o Annyang, um projeto em javascript para adicionar comandos de voz ao seus aplicativos web.

Ele é muito fácil de aplicar ao site, basta adicionar o script ao html e declarar os comandos de voz que o seu site irá atender.

<script src="//cdnjs.cloudflare.com/ajax/libs/annyang/1.4.0/annyang.min.js"></script>
<script>
    if (annyang) {
        // Let's define our first command. First the text we expect, and then the function it should call
        var commands = {
            'show tps report': function() {
                $('#tpsreport').animate({bottom: '-100px'});
            }
        };

        // Add our commands to annyang
        annyang.addCommands(commands);

        // Start listening. You can call this here, or attach this call to an event, button, etc.
        annyang.start();
    }
</script>

É importante adicionar uma verificação lógica na variável annyang antes de tudo, porque se o navegador não for compatível com o reconhecimento de voz seus comandos serão ignorados e não causarão erro algum. Isso pode ser feito porque no código fonte do Annyang a variável é iniciada como false antes de fazer a verificação de suporte do navegador e caso o mesmo não tenha este suporte, ela continuará falsa.

Caso você queira adicionar um comando que possa receber qualquer palavra depois (uma variável) continua sendo muito simples: basta adicionar um asterisco antes do nome da variável e declará-la como parâmetro na função anônima do comando.

var commands = {
    'tell me *chat' : function(chat) {
        $('#question').val(chat);
        $('#the-form').submit();
    }
}

No exemplo acima mostro como estou usando no projeto Jarvis. Basta o usuário pronunciar ‘tell me‘ e a frase que gostaria de dizer em inglês, então o sistema preenche o campo do formulário com a frase e em seguida executa um submit, fazendo com que o Jarvis responda em seguida.

Caso você queira ver o que está acontecendo enquanto ele tenta reconhecer o que você está dizendo, adicione um annyang.debug(); antes do annyang.start();. Isso fará com que ele apresente no seu console Javascript o que está sendo reconhecido em tempo real. Isso é prático porque ele nem sempre consegue reconhecer e você consegue perceber o que pode estar acontecendo.

Opinião

O Annyang funciona muito bem para aquilo que se propõe, que é o reconhecimento de comandos de voz, entretanto nem sempre ele consegue reconhecer uma frase maior, diferente da Speech API do Google, talvez por problemas com a entonação ou a pronúncia. Ainda não experimentei ele com um microfone melhor, apenas com o do meu notebook, e talvez isso faça uma boa diferença na porcentagem de sucesso. Mas ele é tão fácil de implementar que vale a pena experimentar e se divertir com os comandos de voz.

No caso do Jarvis ele não fica tão prático por causa da necessidade de um comando antes de cada frase e para a prática de conversação isso é um pé no saco, mas mesmo assim vou mantê-lo no projeto por enquanto.

Observação: O Annyang não irá funcionar com arquivos locais (acessando via file:///) pois o navegador (pelo menos o Google Chrome) irá bloquear a tentativa do script de acessar o microfone. É preciso testá-lo com um servidor http.

Categorias
Tecnologia

Aprendendo Python com Flask

Sou programador PHP desde 2001 e trabalhei somente com essa linguagem por muito tempo. Em 2012 eu tive uma pequena experiência, graças a um colega de trabalho, com Python através do framework para web Django. Comecei a fazer algumas aplicações simples para aprender. Mas logo após deixar a empresa que trabalhava, acabei parando por ali mesmo.

Este ano resolvi voltar a aprender o Python, gosto muito dessa linguagem e gostaria de ser proficiente nela. Como tudo que aprendo acaba sendo de forma autodidata, fui atrás de alguns tutoriais para voltar a estudar.

Para recomeçar, escolhi um tutorial muito interessante sobre Flask, um microframework para web escrito em Python. O tutorial chama-se The Flaks Mega Tutorial e aborda praticamente tudo que você precisa para fazer uma pequena aplicação web com Flask. Eu recomendo.

O Python e o Flask

Desde o primeiro contato que tive com Python, em 2012, eu achei sua sintaxe incrível. É muito simples e “readable“. Foi uma das primeiras coisas que me chamou atenção nessa tecnologia.

Quando você programa por muito tempo em uma linguagem específica, você acaba ficando viciado em certas coisas específicas dela. É muito gostoso poder experimentar uma forma diferente de programar e a sintaxe do Python deixa tudo mais interessante ainda.

Já o Flask tem me parecido extremamente prático para construir aplicações. Mas ainda estou muito no início para falar mais sobre ele. Só posso dizer que estou gostando bastante das facilidades que ele oferece.

Outra coisa que tem me chamado bastante a atenção com o Python são as empresas que tem migrado de outras linguagens para ele por conta da performance. Assisti diversas palestras e li publicações sobre empresas fazendo essa migração, mas não tenho informações o suficiente sobre isso para falar mais, por enquanto.

Vou continuar meus estudos e o que achar interessante vou publicando por aqui.