Categorias
Tech

Não tenha pressa para ser um artista melhor

Você tem pressa para ser um artista melhor? Vive se comparando com os quadrinistas, desenhistas ou qualquer outro tipo de artista nas redes sociais? Quer receber dicas que vão fazer você evoluir rapidamente do dia pra noite?

Bem… tenho uma notícia péssima pra você.

Se continuar assim, você pode acabar desistindo de ser artista!

Como ser bom do dia pra noite?

Eu recebo constantemente mensagens como estas:

  • Quero ficar bom no desenho, como faço?
  • Como saber se a minha história é boa?
  • Como sei se meus personagens são bons?

Todas estas perguntas são muito válidas, mas a resposta pra elas costuma ser um pouco difícil de digerir por quem está perguntando.

Ela é mais ou menos assim:

“Você precisa estudar (inserir aqui a competência) e praticar muito, mostrar para as pessoas, receber feedback, melhorar e continuar durante meses ou anos”.

É normal que a pessoa não goste de ouvir isso, afinal isso quer dizer que precisa estudar, praticar e receber feedback por muito tempo.

Só que você acessa sua timeline do Instagram e vê aquele monte de artista incrível mostrando seus trabalhos maravilhosos… aí vem a frustração.

“Quero ser assim também!”

As redes sociais mostram a parte bonita da vida das pessoas, não a parte de suor e lágrimas.

Artistas só publicam aquela arte que acham que ficou muito boa. E mesmo que publiquem seus estudos, tipo sketchbooks, vão publicar apenas aqueles que eles acharam que ficou muito bom.

O mesmo acontece com quem cria histórias. As histórias que ficaram ruins, que não deram certo, ficam todas escondidas. Só aquelas que julgam ser realmente boas é que vão a público.

As redes sociais não foram feitas para exaltar o estudo e a pratica, ou seja, o suor derramado.

Foram feitas para exaltar as conquistas e receber confetes por isso, claro! Quem não gosta de receber comentários elogiando uma história que fez ou uma arte que criou?.

Aprofundando o assunto

Eu fiz um vídeo onde falo um pouco mais sobre o assunto, abordando os problemas das combinação como “pressa + comparação com outros artistas = frustração” ou “ansiedade + expectativas erradas = desistência“.

No geral, falo sobre não ter pressa para ser um artista melhor.

Assista para complementar a leitura desse texto e me deixe um comentário sobre o que pensa do assunto.

Links úteis para você

Quem sou eu para falar de pressa para ser um artista melhor?

Meu nome é Marcus Beck e meus objetivos são:

  • Entreter através das minhas histórias;
  • ajudar quadrinistas independentes a divulgar seus trabalhos através da plataforma Fliptru;
  • e trazer o máximo possível de informação sobre como criar uma história em quadrinhos para o maior número de pessoas possível.

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 meu canal do Youtube e também o meu blog, para ajudar quem está passando pela mesma situação que eu estive quando comecei.

Também sempre senti a necessidade de criar uma comunidade e uma plataforma onde quadrinistas nacionais pudessem publicar suas obras e entrar em contato com seus leitores.

Por isso em 2019 eu usei meus conhecimentos como desenvolvedor de software para criar e lançar a plataforma Fliptru.

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

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

Machine Learning está arruinando as timelines

Machine Learning é incrível.

Hoje em dia temos máquinas aprendendo o tempo todo e os dados se tornaram o novo petróleo. Quem tem quantidades gigantescas de dados de usuários tem grande valor de mercado. Isso acontece porque quanto maior a quantidade de dados mais as máquinas podem aprender sobre qualquer coisa. O que você gosta, o que você quer comprar, quais são as suas inclinações políticas e sociais, por onde você costuma andar, etc.

As possibilidades que podem ser criadas a partir da análise dos dados de uso de um aplicativo são incríveis. A ideia geral é que isso ajude na personalização de qualquer serviço que você usa.

Dois bons exemplos do uso de Machine Learning em redes sociais para mim são a página inicial do YouTube e a parte de Explore do Instagram. Ambos se ajustam muito bem ao tipo de conteúdo que eu me interesso nesses serviços.

Algo que poderia incomodar algumas pessoas sobre o uso de Machine Learning atualmente é a questão da privacidade, que é um assunto muito discutido nesse conceito de uso dos dados alheios.

Mas o que me chamou atenção e me incomodou mais ultimamente sobre o assunto é uma coisa que pode parecer muito mais boba e simples. As timelines das redes sociais.

A timeline tem esse nome porque deveria ser uma linha do tempo. É comum gostarmos de saber o que está acontecendo de mais atual com nossos contatos sociais e também aqueles influenciadores que seguimos.

Entretanto, com o uso do machine learning na maioria das timelines de todas as redes sociais, não temos mais uma linha do tempo. Temos uma lista de conteúdos que a máquina resolveu que é o mais interessante para o seu perfil. Perfil esse criado através da análise dos seus dados de uso da rede.

Eu tenho usado pouco as redes sociais ultimamente, meu acesso não passa de um por dia durante os dias úteis para algumas redes e um por semana para outros, e essa descrição que vou dar sobre a experiência que tenho pode não condizer com a experiência de alguém que usa muito as redes, portanto se esse for o seu caso enquanto lê, por favor, deixe um comentário me falando como funciona para você.

Toda vez que acesso uma rede acontece a mesma coisa: recebo conteúdos que foram postados há um bom tempo atrás misturados com conteúdos recentes. Cheguei a receber alguns com mais de um mês de idade na minha timeline.

Como eu disse antes, pode parecer bobo, mas eu não tenho interesse em receber coisas tão antigas para os padrões da internet. Isso é um pequeno problema que venho enfrentando, mas existe um pior. Pessoas que simplesmente não dão as caras mais no meu feed.

Você pode pensar “Ah, mas elas nem devem postar mais”. Foi exatamente o que pensei sobre essas pessoas até acessar seus perfis nas redes. Lá estavam conteúdos que eu gostaria de ter visto, provavelmente teria interagido, mas que nunca tive a chance.

A máquina decidiu que eu não deveria me interessar por um conteúdo de uma pessoa talvez porque ela poste de forma mais esporádica. Mas a máquina errou.

Eu não quero que a máquina escolha quem deve aparecer ou não no feed do meu aplicativo. Eu quero ter a opção simples de acessar as configurações da minha rede e escolher que a máquina não monte o minha timeline e deixe de escolher qual conteúdo eu devo ou não devo interagir.

Uma opção simples de configuração, mas que pode afetar todo um modelo de negócio de uma empresa que se baseia em análise de dados de uso para vender certo serviço de publicidade.

Como isso afeta o modelo de negócios das redes sociais? Vamos ver um exemplo.

Uma amiga minha vende produtos pela internet e o Instagram costumava ser sua maior fonte de clientes. Bem, ela teve uma queda gigantesca nas vendas assim que a nova timeline com Machine Learning entrou no ar neste aplicativo. Graças à isso agora precisa comprar posts patrocinados da rede social se quiser continuar conseguindo leads pelo app de fotos.

Você pode me perguntar se eu acho errado que se venda um serviço baseado no acesso dos meus dados. Bem, eu aceitei aquele termo de uso e sei que nada vem de graça nesse mundo. O Facebook não gasta milhões de dólares em servidores e funcionários para que você possa curtir aquela foto da sua tia. Ele investe para obter lucro.

É por isso que resolvi fazer uma mudança na forma como consumo conteúdo e voltar para algo que se usava muito na internet do passado. Escolher blogs e sites e seguir suas postagens através de um agregador de conteúdo, o Feedly. Ele também deve aproveitar meus dados para alguma coisa, mas pelo menos eu escolho de onde meus conteúdos vem, não é mesmo.

As redes sociais não são a internet. A internet é descentralizada por natureza. É por isso que apesar de publicar com certa frequência na minha conta do Medium eu também costumo postar sempre aqui no meu próprio blog. Fica aqui o link para um texto do Luciano Ramalho sobre o porque ter seu próprio site na internet.

Aguardo sua opinião nos comentários.

Até a próxima!

Categorias
Tecnologia

Primeiros passos com o GIT

GIT é um software de controle de versão utilizado por muitos e muitos desenvolvedores e empresas no mercado de tecnologia.

Um controle de versão serve para manter o histórico do desenvolvimento do código e também para ajudar uma equipe de programadores trabalhando no mesmo código a não fazer besteira no meio do caminho.

Vamos à um exemplo bem simples.

João está fazendo alterações no arquivo index.html ao mesmo tempo em que Carlos. João altera as linhas 30 até 50 do arquivo e Carlos da 80 a 100. Em algum momento os dois precisam juntar esse código para ter a versão final do documento que vai para o site joaoecarlos.com.

Isso é bem fácil, basta que um dos dois pegue a parte do código que o outro alterou e cole na posição correta no arquivo index.html. Está pronto para subir para o servidor, certo? Certo.

Então para que eu preciso do Git para ajudar o João e o Carlos?

Bem, basta dizer que se o João estivesse alterando entre as linhas 80 e 100 do mesmo arquivo teríamos um conflito entre o que o João fez e o que o Carlos fez. Não bastaria colar as alterações do João sobre as do Carlos, seria preciso que se analisasse linha por linha do que cada um fez para ver qual deve entrar e qual deve sair. Basicamente os dois precisariam sentar juntos e reescrever o código. Trabalho dobrado.

Agora imagine que essa reescrita de código pudesse ser feita de forma automática? Não seria ótimo?! Sim. Seria.

Aí entra nosso querido software de controle de versão! No caso dessa publicação estamos falando de Git, mas ele não é o único.

Vamos rever o exemplo do site joaoecarlos.com agora utilizando o Git em todo o processo.

João modifica o arquivo em seu computador. Ele salva localmente suas alterações e faz o commit com o Git que salva no repositório local quais alterações foram feitas. No final do processo ele executa um push e essas alterações ficam salvas em no repositório remoto.

Carlos faz alterações no mesmo arquivo e executa seu commit localmente. Quando ele for executar o push para o repositório o Git vai avisá-lo que seu código local não está atualizado com o repositório. Então ele executa um pull e baixa as alterações que João fez e o Git se preocupa em reescrever seu código para escolher quais linhas devem ficar em quais posições. Depois disso, Carlos pode verificar se está tudo certo com seu novo código e mandá-lo para o repositório com mais um push.

Pronto. É assim que funciona o Git… da maneira mais básica o possível, é claro.

O Git é muito mais do que isso, mas primeiro é preciso entender o seu conceito básico para começar a trabalhar com ele.

Vamos ver o passo a passo do que o João e o Carlos fizeram.

Aviso: todos os exemplos vistos nesta publicação são comandos executados em um console/terminal de linha de comando de um sistema operacional com base em Unix (MacOS ou Linux, por exemplo). Eles consideram que o Git já está instalado no seu ambiente de trabalho. Para ver como instalar clique aqui.

Primeiro eles precisaram iniciar o repositório Git localmente no diretório em que seus códigos estavam. Acessando via linha de comando eles entraram na raiz do código.

cd /Project/joaoecarlos/

Foi lá que ele iniciaram seu novo repositório com o comando:

git init

Para verificar os arquivos que o Git vai rastrear eles usaram o comando git status e viram algo como o exemplo abaixo.

On branch master
Initial commit
Untracked files:
  (use "git add <file>..." to include in what will be committed)
index.html
nothing added to commit but untracked files present (use "git add" to track)

Eles notaram que está escrito Untracked files logo acima do nome do arquivo. Isso quer dizer que o Git não está “rastreando” esse arquivo.

Com o comando git add . eles adicionaram todos os arquivos do seu projeto na lista de arquivos a serem rastreados. O . representa todos os arquivos e diretórios presentes nesse diretório. Eles viram algo assim:

On branch master
Initial commit
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
new file:   index.html

Agora eles tem um ambiente preparado para fazer o seu primeiro commit. Eles adicionaram o arquivo index.html à lista de arquivos que serão gravados nesse commit.

Com a execução do comando git commit -m "Primeiro commit" eles finalmente gravaram sua primeira “versão” do site joaoecarlos.com no seu repositório local.

[master (root-commit) d8cbc79] Primeiro commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 index.html

O atributo -m "Primeiro commit" é um encurtamento de uma parte do processo de commit que é muito importante: descrever o que foi alterado.

Todo commit precisa ter uma boa descrição do que foi feito. Isso facilita muito para o futuro, onde centenas ou milhares de commits foram executados em um repositório. Imagina se você precisa encontrar onde foi feita alguma alteração no passado?

Pode-se executar esse comando sem o atributo -m, mas em seguida o console irá abrir um editor de texto para que se escreva uma mensagem descrevendo o que foi alterado.

Bom, agora que nossos colegas do exemplo já tem um repositório local, precisam enviar isso para um repositório centralizado. Um exemplo de serviço muito bom (e bem conhecido) para criar um repositório é o GitHub.

Depois de criarem sua conta e seu repositório no Github, nossos desenvolvedores adicionaram esse repositório como remote nas suas configurações do Git.

git remote add origin https://github.com/user/repo.git

Esse origin que você vê no comando é um apelido que se dá para o repositório remoto em sua máquina. Por padrão estamos chamando de origin que é o mais comum que você vai encontrar por aí.

Adicionar o remote no seu repositório local serve para indicar de onde ele deve puxar o código atualizado e para onde ele deve enviar seus commits. É o repositório com o qual todos os desenvolvedores do projeto vão interagir e onde ficará registrado todas as informações sobre alterações e versões do código do seu projeto.

Agora nossos desenvolvedores de exemplo estão prontos para subir seus primeiros commits para o repositório no GitHub com o comando git push origin master.

git push origin master

Vamos analisar esse comando…

git push é a parte que diz que queremos enviar o que temos de commitsna nossa máquina para o repositório remoto, GitHub por exemplo.

origin master diz para onde enviar esses commits, como o apelido do repositório é origin isso significa que vamos enviar para o GitHub que adicionamos a pouco.

master significa o branch que estamos usando. Mais para frente vou falar sobre branch, mas por enquanto vamos assumir que estamos trabalhando apenas com o branch padrão, que é chamado de master. Ele já foi criado quando o João ou o Carlos executou o git init lá no começo.

voilá. O código dos nossos amigos está no repositório do GitHub.

Agora vamos dizer que o Carlos precise trazer as atualizações de lá. Ele executou os primeiros passos (git initgit remotegit add e git commit) na sua máquina local e agora quer atualizar o código com o que tem no repositório remoto.

git pull origin master

Assim como o git push nós estamos dizendo para o Git de onde queremos buscar as atualizações com o origin master.

Agora o Git já atualizou o código na máquina do Carlos.

Em outro momento vou falar sobre os conflitos, algo que pode acontecer nesse momento de sincronização (ou merge) quando se usa controle de versão.

Por enquanto é isso. Esses são os primeiríssimos passos para utilizar o Git como controle de versão em um projeto.

Esse texto foi produzido para quem nunca teve contato algum com controle de versão, para dar uma ideia geral de como é e para que serve.

Se você quer saber mais sobre Git, deixe um comentário que eu planejo mais publicações como essa, dando continuidade ao processo e explicando mais sobre outros fatores.

Postado originalmente no Medium.

Categorias
Tecnologia

Como utilizar Ajax no WordPress

Hoje vou dar uma dica de como utilizar ajax no WordPress.

Precisei fazer uma chamada assíncrona em uma página de template do WordPress em um projeto que estive trabalhando e fui pesquisar como funcionava. O WordPress tem seu jeitinho todo especial de executar requisições XHR.

O primeiro passo é escrever uma função (no arquivo functions.php) para executar o que você quiser que o backend faça nessa chamada Ajax. No caso do exemplo desta publicação estou enviando um email.

// Actions to send mail
add_action('wp_ajax_sendMyMail', 'sendMyMail');
add_action('wp_ajax_nopriv_sendMyMail', 'sendMyMail');

// Sending the email
function sendMyMail() {
  global $wpdb;

  $message = "Form data:\n\n Name: {$_POST['name']}";
  if (wp_mail('email@email.com', 
              'Title', 
              $message, 
              array('Cc:email@copy.com'), 
              array())) {
  	echo 'success';
  } else {
  	echo 'error';
  }

  die();
}

Linha por linha da função no functions.php

Usando o add_action do WordPress, registramos nossa função. No primeiro wp_ajax_sendMail estamos registrando a função para utilização no painel Admin do WordPress e com o wp_ajax_nopriv_sendMail registramos a função para utilização no frontend, onde o usuário não estará logado.

O formato desses dois tipos de actions específicas para ajax sempre devem começar com wp_ajax_(action) ou wp_ajax_nopriv_(action).

// Actions to send mail
add_action('wp_ajax_sendMyMail', 'sendMyMail'); 
add_action('wp_ajax_nopriv_sendMyMail', 'sendMyMail');

Depois vem a função em si, com as ações que você quiser. Como eu já disse, nesse exemplo é o envio de um email.

// Sending the email function 
sendMyMail() {
 global $wpdb;
 $message = "Form data:\n\n Name: {$_POST['name']}";

 if (wp_mail('email@email.com',
             'Title',
             $message,
             array('Cc:email@copy.com'),
             array())) {
  echo 'success';
 } else {
  echo 'error';
 }

No final usamos o die() do PHP para encerrar o processo.

 die();
}

A requisição Ajax

Agora vamos à chamada assíncrona no Javascript.

Fazemos uma chamada com o método $.ajax do jQuery normalmente, mas a diferença está na URL que utilizaremos nela e em um item que precisa ser adicionado nos dados enviados para o servidor.

$.ajax({
 type:"POST",
 url: "/wp-admin/admin-ajax.php",
 data: {
  action: 'sendMyMail',
  name: $('input[name=name]').val()  
 },  
 success: function(data){
  console.log(data)
 }
});

A URL deve ser sempre /wp-admin/admin-ajax.php e o nome da ação que você registrou no functions.php entra como um dado com o nome action junto com o resto dos dados que você irá mandar para o servidor.

url: "/wp-admin/admin-ajax.php",
data: {
 action: 'sendMyMail',
 name: $('input[name=name]').val() 
 }

E voilá!

Deixe suas dúvidas ou opiniões nos comentários abaixo.

Nos vemos na próxima.

Categorias
Tecnologia

Redirecionando posts para subdomínio no WordPress

Quando postagens já estão indexadas pelos mecanismos de busca, como Google e Bing, há algum tempo fica complicado mudar um blog do WordPress de domínio.

No meu caso eu precisava mudar apenas alguns posts de categorias específicas para um outro subdomínio do meu site. O objetivo era redirecionar os posts relacionados com artes para o meu novo blog sobre arte.

Depois de pesquisar um pouco acabei chegando em uma solução razoável.

Criei o novo blog com WordPress, importei o conteúdo das categorias específicas para o mesmo e coloquei em um novo subdomínio.

No meu blog atual, este que você está lendo agora, no arquivo functions.php do template adicionei o código abaixo.

add_action('template_redirect', 'redirect_category_posts');
function redirect_category_posts() {
 global $post;
 if (is_single($post->ID) && (
  in_category('ilustracoes', $post) || in_category('ilustracao-em-acao', $post) || 
  in_category('hqs', $post) || in_category('ecomic-hqs', $post) || 
  in_category('tailer-hqs', $post) || in_category('video', $post) || 
  in_category('quick-sketch', $post)
 )) {
  $new_url = str_replace('http://mbeck.com.br', 
                         'http://arte.mbeck.com.br',
                         get_permalink($post->ID));
  wp_redirect($new_url, 301);
  exit;
 }
}

Linha por Linha

A primeira linha adiciona uma nova ação ao template.

add_action('template_redirect', 'redirect_category_posts');

Em seguida eu crio a função e utilizo a global $post do WordPress. Nela teremos os dados da publicação.

function redirect_category_posts() { 
  global $post;

Adiciono uma condição para verificar se estamos em um post único através do $post->ID. Para verificar se encaixa em uma das categorias especificadas uso a função in_category do WordPress.

if (is_single($post->ID) && (
 in_category('ilustracoes', $post) || in_category('ilustracao-em-acao', $post) || 
 in_category('hqs', $post) || in_category('ecomic-hqs', $post) || 
 in_category('tailer-hqs', $post) || in_category('video', $post) || 
 in_category('quick-sketch', $post) 
)) {

Em seguida monto a URL que será utilizada para o redirecionamento substituindo o domínio antigo pelo novo com a função str_replace do PHP. Para pegar o link permanente do post eu uso a função get_permalink do WordPress.

  $new_url = str_replace('http://mbeck.com.br', 
                         'http://arte.mbeck.com.br', 
                         get_permalink($post->ID));

Lembrando que quando criei outro blog com o WordPress e importei o conteúdo do antigo eu utilizei exatamente o mesmo formato de URL (permalink) para os posts do novo blog que eu utilizava no antigo.

Para fechar, utilizo a função wp_redirect do WordPress, com um código 301 (código HTTP que significa movido permanentemente), e termino com um exit.

  wp_redirect($new_url, 301); 
  exit; 
 } 
}

E voilá! Está funcionando como o esperado.

Se ficou alguma dúvida comente abaixo.

Nos vemos na próxima.

Categorias
Carreira

Carreira Programador – Sou júnior, pleno ou sênior?

Trabalhar com desenvolvimento de software, ser um programador, requer muito mais do que conhecer uma linguagem de programação e alguns pacotes, exige diversas habilidades do ser humano. Agilidade, flexibilidade, criatividade e diversas outras. Isso não se consegue da noite para o dia.

O que tenho notado ultimamente em muitos profissionais é a pressa de chegar até o nível mais alto dos cargos. Se tornar um sênior o quanto antes, mesmo tendo apenas dois ou três anos de experiência no mercado de trabalho.

Em parte, isso é culpa das empresas que simplesmente estão desesperadas por programadores e oferecem cargos e salários super altos para pessoas com pouca experiência. Não que ter altos salários seja algo ruim ou que ter um nome bonito para o cargo no Linkedin seja um problema.

A verdadeira questão é a confusão que isso pode causar quando se tem alguém com poucos anos de experiência sendo a referência de uma equipe.

Sim, um programador sênior é uma referência para todos os outros membros de sua equipe. E o bom programador júnior é aquele que sabe que “ser o menos inteligente da mesa” é algo essencial para o seu crescimento.

Não existe uma regra para se definir quem é sênior ou quem é júnior, isso vai depender do plano de carreira de cada empresa.

O que existe é uma regra importantíssima para os programadores em qualquer nível de carreira, iniciantes ou experientes: Jamais pare de aprender!

“Tá, mas como eu vou saber que nível estou?” – Leitores

Como depende de cada empresa, fica complicado saber. Para dar uma ajuda vou mostrar uma listinha…

A lista

Aqui vai uma tradução de uma lista muito interessante que o DHH, criador do Rails e founder/CTO do Basecamp, publicou em uma conversa no twitter esta semana.

Essa lista faz parte do Basecamp Employee Handbook, o manual do funcionário do Basecamp, e clarifica um pouco sobre as competências que cada programador deve ter dentro da empresa para ser júnior, pleno ou sênior.

Lembrando que cada empresa define o que acredita ser o melhor para cada nível. Eu gostei e me identifico muito com o conceito deles. Por isso estou publicando aqui.

Programador(a) júnior

  • O trabalho é cuidadosamente revisado com substanciais idas e vindas.
  • Tem domínio dos recursos básicos da linguagem, mas pode ainda não ter familiaridade com algumas estruturas avançadas.
  • Tem problemas ocasionais para seguir padrões e compreender abordagens dentro das bases de código existentes.
  • Trabalha principalmente com escopos mais bem definidos e em problemas de rotina.
  • Costuma ter menos de 2 anos de experiência como programador profissional no domínio específico.

Programador(a) Pleno(a)

  • O trabalho é revisado com a necessidade ocasional de mudanças na implementação.
  • Compreende os padrões e abordagens estabelecidos nas bases de código existentes com facilidade.
  • Trabalha principalmente em funcionalidades ou problemas individuais com escopo claro e bem definido.
  • Costuma ter pelo menos 2-5 anos de experiência como programador profissional no domínio específico.

Programador(a) Sênior

  • O trabalho não precisa necessariamente ser revisado, mas a abordagem geral pode ser.
  • Totalmente capaz de desenvolver sozinho funcionalidades importantes do conceito inicial até a entrega (ao lado de um designer).
  • Pode fornecer feedbacks importantes sobre o trabalho de programadores plenos e juniores.
  • Especialização profunda dentro de pelo menos um ambiente de programação.
  • Proficiência básica em pelo menos um ambiente de programação adicional.
  • Costuma ter pelo menos 5-8 anos de experiência como programador profissional no domínio específico.

Eles ainda possuem um nível de Lead Programmer e um de Principal Programmer, que poderiam ser definidos como níveis de líder técnico, gerente de equipe e diretor(a) de departamento.

O que me chamou muito a atenção nesta lista é que o conhecimento técnico de uma linguagem faz diferença em cada nível, mas não é a única coisa a ser levada em conta. Lembre-se disso!

O que achou da lista? Deixe sua opinião nos comentários.

Nos vemos na próxima.

Categorias
Carreira

Carreira Programador – Quer trabalhar em uma startup?

Hoje em dia é comum ver pessoas interessadas em trabalhar nas empresas de tecnologia, principalmente nas startups dessa área.

Existe um certo glamour em trabalhar em uma empresa que tem como proposta mudar o jeito que as coisas são, a tal da “empresa diruptiva”. O conceito de inovação costuma partir de dentro da própria, a partir de sua cultura. Isso atrai profissionais com essas mesmas características.

Uma das coisas que chama a atenção nessas empresas é a liberdade de trabalhar em um ambiente menos engessado e mais focado em resultados do quem em como está o preenchimento do sua folha de ponto. Isso sem falar na menor burocracia interna e nos possíveis pequenos agrados, como doces e bebidas a vontade, além de jogos e outras coisas divertidas.

Ao mesmo tempo que tudo isso é muito atrativo existe também o outro lado da coisa. Nem todas as empresas são tão bem “estruturadas” quanto Facebooks e Googles por aí. Estou falando literalmente de grana. Bufunfa mesmo. A maioria não vai ter como pagar equipes enormes e especializadas.

Por isso o profissional que busca uma carreira em tecnologia, principalmente nesse tipo de empresa, precisa ser completo. Precisa ser um profissional “T” ou T-shaped skills.

Essa expressão se refere ao profissional que tem conhecimento em diversas áreas de maneira geral e em uma de maneira aprofundada. Por isso a letra T.

Eu não trago essa expressão da maneira convencional como recrutadores costumam falar, onde o profissional tem um monte de skills fora da área de tecnologia para ser um T. A trago pensando mais no conceito de desenvolvedor Full Stack, aquele que consegue lidar com diversas partes do desenvolvimento de software e não é apenas especializado em uma parte dele.

As equipes das startups costumam ser extremamente enxutas e por isso é preciso que os profissionais sejam muito flexíveis e saibam lidar com diversas partes do processo de desenvolvimento de software.

Conhecer uma linguagem de programação é algo que nem precisa ser dito, certo? Mas vou abordar algumas dicas sobre o tipo de conhecimento que poderia lhe ajudar a conseguir iniciar uma carreira nesse mercado.

1. Desenvolvimento web

A popularização da web deixou muito mais fácil para empreendedores tornarem suas ideias realidade e criarem startups. Conhecer sobre desenvolvimento para web pode facilitar muito a vida profissional de um programador.

Entender como funciona o frontend e o backend de uma aplicação web é indiscutivelmente uma das maiores vantagens para que um profissional possa trabalhar em boa parte das startups que existem por aí.

Conheça bem HTML e CSS. Brinque com o Bootstrap, que facilita muito o desenvolvimento da estrutura de um webapp. Mas não se esqueça que quase nada funciona na internet sem JavaScript.

Conheça bem JavaScript e só depois vá atrás de conhecer alguns frameworks como Angular e React.

2. Controle de versão

Os sistemas de controle de versão servem para gerenciar as versões do código que está sendo editado por um desenvolvedor ou uma equipe de desenvolvedores.

No caso da equipe é que ele se torna ainda mais imprescindível, pois cada membro da equipe pode trabalhar no mesmo código que outro e bagunçar a coisa toda. Eu apago uma linha aqui e você a modifica ao mesmo tempo… loucura!

Tenha familiaridade com o GIT e isso já lhe dará uma grande vantagem sobre outros candidatos.

3. Linha de comando

Ah! O famoso terminal… a tela preta com letras brancas (na verdade as cores são totalmente configuráveis).

Sem entender como funcionam os comandos Unix (Linux e MacOS) fica muito difícil trabalhar com a maioria dos frameworks e linguagens de script que temos no mercado.

Isso falando apenas de maneira geral, existem muitas tarefas que são muito mais fáceis sendo feitas pelo terminal, inclusive o uso do GIT!

Ter um conhecimento básico dos comandos do terminal não é difícil, basta praticar um pouco e eles passam a ser naturais. A medida que você precisar conhecer mais comandos para executar diferentes tarefas o seu repertório aumenta sozinho.

Se você aprender a escrever um ou outro shell script então… aí a coisa começa a ficar boa!

4. Já ter feito alguma coisa…

Ok, isso parece estranho. Afinal estou falando em começo de carreira por aqui.

O que quero dizer com “já ter feito alguma coisa” é ter participado de algum projeto ou ter um projeto pessoal concluído. Talvez em um freelance ou algo assim.

A ideia dessa “dica” é que você já tenha passado pela experiência de completar um projeto. Que tenha feito mais do que apenas estudar sobre o assunto. Que você tenha feito algo do começo ao “fim”. Algo que tenha lhe dado experiência em iniciar e terminar alguma coisa.

Conta ter feito um sistema para lembrar da lista do supermercado ou seu próprio blog, desde que você tenha conseguido começar, desenvolver e “entregar” (deploy). Isso faz muita diferença em um profissional.

Essa declaração pode parecer confusa, mas eu já trabalhei em muitos lugares e conheci muita gente dessa área. Em vários profissionais em início de carreira eu senti falta dessa saída da zona de conforto e da tentativa de fazer algo de verdade além dos exercícios de cursos ou tutoriais encontrados na internet.

E tem muito mais…

Eu poderia ficar escrevendo muito mais sobre cada um dos itens acima e ainda mais sobre outras coisas que ajudariam um profissional em início de carreira a se preparar para o trabalho em startups. Mas a ideia aqui é dar um rumo. Não adianta tentar aprender tudo de uma vez só!

Outro ponto importante é que ninguém nunca está preparado o suficiente. O que vai fazer diferença no futuro é a sua própria experiência. Então não tenha medo de concorrer à vagas e entrar com tudo no mercado.

Deixe um comentário se você acha que faltou alguma coisa ou se tem dúvidas sobre o assunto.

Nos vemos na próxima!

 

Categorias
Tecnologia

Criando um bot super simples para o Slack

Em uma das reuniões dessa última semana na empresa onde trabalho surgiu uma necessidade simples de comunicação: Precisamos que toda a equipe saiba quando um novo release de algum dos nossos repositórios for criado no Github.

Como usamos o Slack como ferramenta de comunicação interna, na hora já pensei:

“Esta é a minha chance de criar um bot para o Slack!”

Sempre tive vontade de fazer algo para o Slack, mas não tinha conseguido achar um tempo e nem um motivo específico para isso. Eu já imaginava que para esse objetivo, avisar sobre um novo release, não seria algo complicado.

Realmente não foi. Em apenas algumas linhas deu pra criar um bot que conecta os webhooks do Github e do Slack utilizando o Flask como meio-campo.

Abaixo o código final da primeira versão.

# coding: utf-8
import os
import requests
from flask import Flask
from flask import request

app = Flask(__name__)

slack_webhook_url = os.getenv('SLACK_WEBHOOK_URL')

@app.route("/", methods=['POST', ])
def webhook():
 action = request.json['action']
 release = request.json['release']
 repository = request.json['repository']

slack_data = {
 "text": "A new release from *{repo_name}* was {action}!\n"
         "Click <{release_url}|Release {tag_name}> for more details".format(action=action,
           repo_name=repository['name'],
           release_url=release['url'],
           tag_name=release['tag_name'])
}

response = requests.post(slack_webhook_url, json=slack_data)

if response.status_code != 200:
 raise ValueError(
   'Request to slack returned an error {}, the response is:\n{}'.format(response.status_code, 
      response.text)
 )

return ""

Pelo pouco tempo que passei lendo sobre como fazer um bot para o Slack eu entendi que você cadastra um Incoming Webhook e eles geram uma URL a qual você irá executar um request do tipo POST enviando a mensagem que você quer que um canal específico receba.

É realmente muito simples, porque a própria URL já carrega os tokens que são gerados para você.

Existem diversas outras funcionalidades que podem ser criadas em um bot para o Slack e a documentação deles cobre tudo. Mas vou falar apenas desse pequeno release-alert que criei.

Explicando linha por linha

Antes de começar a escrever o código vou precisar do Flask e de alguns outros pacotes. Então começo ainda na linha de comando do shell.

$ pip install Flask
$ pip install requests

Depois eu coloco a URL que gerei no Incoming Webhooks do Slack em uma variável de ambiente que chamo de SLACK_WEBHOOK_URL. Depois basta importá-la para dentro do código.

$ export SLACK_WEBHOOK_URL=<aqui vai a url do webhook do slack>

Agora crio meu arquivo Python chamado bot.py. Como estou usando o Flask, só vou precisar desse arquivo e praticamente nada mais.

Nas primeiras linhas começo importando o que vou utilizar e criando o app do Flask.

import os
import requests
from flask import Flask
from flask import request

app = Flask(__name__)

Trago para dentro do código a variável de ambiente que criei antes.

slack_webhook_url = os.getenv('SLACK_WEBHOOK_URL')

Agora vou começar a montar o meu endpoint. Ele receberá um evento POST enviado pelo webhook do Github. Para que isso aconteça você precisa cadastrar uma URL de webhook no settings do seu projeto no Github.

No meu caso, eu cadastrei a webhook no settings da organização, já que queria que todos os projetos da empresa disparassem o aviso. Mas funciona do mesmo jeito em qualquer um dos casos.

Quando cadastrei o meu webhook no Github especifiquei que gostaria de receber apenas os eventos relacionados ao release dos projetos.

Para testar o código localmente eu utilizei o ngrok. Explico como usar o ngrok em outra publicação.

@app.route("/", methods=['POST', ])
def webhook():

As primeiras linhas do meu endpoint capturam as informações que eu preciso do corpo enviado pelo POST do webhook do Github.

 action = request.json['action']
 release = request.json['release']
 repository = request.json['repository']

O Flask facilita recuperar informações de um corpo de um request JSON com o seu objeto request nativo. Basta chamar request.json e ele retorna um dicionário.

Agora eu vou montar o corpo da mensagem que enviarei para o Slack. O formato pedido é muito simples: um JSON com um campo ‘text’.

slack_data = {
 "text": "A new release from *{repo_name}* was {action}!\n"
         "Click <{release_url}|Release {tag_name}> for more details".format(action=action,
            repo_name=repository['name'],
            release_url=release['url'],
            tag_name=release['tag_name'])
}

Esse dicionário será transformado em um JSON pela próxima linha. O pacote requests já resolve isso para mim através do argumento json.

response = requests.post(slack_webhook_url, json=slack_data)

if response.status_code != 200:
 raise ValueError(
   'Request to slack returned an error {}, the response is:\n{}'.format(response.status_code, 
       response.text)
 )

return ""

No final do arquivo estou apenas tratando algum possível erro. Caso o requests retorne um status_code diferente de 200 eu levanto uma exceção.

No final retorno uma string vazia, porque cada endpoint do Flask precisa retornar alguma coisa para não levantar erros.

Para que meu bot fique disponível o tempo todo, fiz um deploy na minha conta gratuita do Heroku. E voilá!