Weekly Deploy #02

Weekly Deploy é uma publicação semanal de liderança, tecnologia e empreendedorismo com coisas que usei, vi e aprendi e que estou achando interessantes. Edição #02

Saindo com um dia de atraso por motivos de: “ih, esqueci!”

Serviço que estou adorando

QuintoAndar! É realmente sensacional. Como primeira experiência senti que foi muito prático e ainda por cima não precisei lidar com a burocracia e falta de educação das imobiliárias tradicionais. Inclusive, achei a parte de compra de imóveis interessante.

App para Mac que comecei a usar

Alttab – O CMD+TAB do Mac nativamente alterna entre programas e não entre janelas, por isso comecei a usar esse programa que tem um comportamento parecido com o do Windows. Ótimo para quem estiver usando um teclado não Apple no Mac.

Texto sobre liderança técnica que achei interessante

How to Overcome the Technical Strategy Spiral – Essencial para quem se pergunta por quê não tem sido incluído em discussões mais estratégicas. Spoiler: Quanto mais você ignora e não participa desse tipo de discussão, mais por fora você estará.

Vídeo aleatório super útil sobre negociações

É sobre a famosa técnica da Ancoragem, mas sobre como agir quando já ancoraram você

Weekly Deploy

Weekly Deploy é uma publicação semanal rápida de liderança, tecnologia e empreendedorismo com coisas que usei, vi e aprendi e que estou achando interessantes. Esta é a primeira! Edição #01

Texto que estou lendo:

Maximizing Developer Effectiveness. Um texto pra refletir em quais melhorias fazer para proporcionar um ambiente propício para altíssima produtividade.

Livro rápido que estou retomando

Anything you want do Derek Sivers. Ele é um músico que aprendeu a programar PHP + MySQL e montou um site apenas para vender seus álbuns independentes. 10 anos depois, vendeu sua empresa, a CD Baby por 22 milhões de dólares para a Apple

Entrevista que estou assistindo:

Conversa fantástica com a Dra Carla Sarni, dona das franquias Giolaser, Sorridents e outras com mais de 700 lojas no Brasil. A história dessa mulher é sensacional. Empreendedorismo na veia.

Audiobook que ouvi novamente

The Willpower Instinct – Kelly McGonigal. Citado várias vezes neste blog, este é um dos livros que eu mais gosto quando preciso encontrar maneiras de mudar alguns hábitos. Li o Livro na esteira da academia, então ele já cumpriu um pouco do papel que eu esperava dele. XD

SaaS que comecei a usar

Linktree. Te dá acesso a uma página para você colocar títulos e links. Bom para colocar no seu perfil em sites que te pedem apenas um link como o Instagram.

Vinho que estou tomando

Continuo apaixonado pelo Portada. É um vinho meio seco português, um pouco adocicado e que harmoniza muito bem com coisas que eu adoro como pizza, massas e alguma carnes.

Criar um projeto do zero ou utilizar algo pronto? Como decidir o Buy or Make

Como tomar a decisão de Buy or Make? Ou em bom português, como decidir se você compra ou faz alguma coisa? Ou ainda, se você faz ou usa pronto de alguma forma, seja utilizando Open Source, contratando um SaaS, terceirizando, etc.

Não importa seu cargo, sua empresa ou em qual área você está inserido, com certeza você já precisou e ainda vai precisar tomar esse tipo de decisão. Neste vídeo eu vou explicar como você decide o Buy or Make e porquê você já deveria pensar assim:

Esse tipo de decisão entre comprar ou fazer algum projeto é referido por aí como Buy or Make (fazer ou comprar) e todo mundo vai precisar tomar esse tipo de decisão, seja o estagiário ou o líder da empresa.

Sendo assim, quanto mais cedo você começar a pensar nos trade-offs entre criar a solução em casa (in house) versus comprar um sistema pronto,
mais estratégico você vai estará sendo e melhor para o seu futuro.

Por certo, se você estiver numa posição de liderança e não estiver frequentemente pensando em BUY or MAKE, você corre o risco de estar desperdiçando recursos e perdendo oportunidades para o seu negócio.

Por onde começar?

Se você é uma pessoa que resolve problemas vão aparecer problemas do seu cliente ou da sua empresa cuja solução já existe no mercado e para a grande maioria dos problemas você vai encontrar uma solução pronta, que você vai usar como base pra criar a sua.

Para os demais problemas você vai escolher fazer do zero.

Como tomar essa decisão no dia a dia? Você sempre vai começar a resolver qualquer problema procurando pelas soluções existente e vai comparar o que existe com o que você precisa fazer. Depois disso, você precisa estimar o esforço em customizar aquela solução para o seu cenário e comparar com a estimativa de esforço para você criar sua própria solução.

Contudo, como um guia geral sempre tenham em mente a frase:
NÃO REINVENTE A RODA.
Use o que está pronto, use o que o mercado já está usando

No entanto, o único cenário em que isso não é necessário é quando um estudante quer aprender algo do zero e quer implementar uma solução para aprender com ela.

Livre-se do seu Ego

Sobretudo, existe uma batalha de EGO muito grande e diversas vezes você vai querer implementar algo do zero porque por arrogância você pode acreditar que vai criar uma solução melhor. Mesmo que você realmente possa, não é só porque você pode criar algo melhor que você deveria, Peter Drucker já dizia que “nada é menos produtivo do que tornar eficiente algo que nem deveria ser feito”. Por quê? Porque alocação de recurso e alocação de tempo são importantes demais.


“Nada é menos produtivo do que tornar eficiente algo que nem deveria ser feito” – Peter Drucker

Quando você decide FAZER alguma coisa, você está tomando a decisão de NÃO FAZER um monte de outras coisas.

Inegavelmente, não será fácil decidir o Buy or Make, isto é se você precisa criar a solução ou usar uma pronta, mas o básico que você precisa fazer é se perguntar se deveria fazer um ou o outro. Contudo, quando a solução não for ESSENCIAL para o negócio ou como se diz, se não for o CORE BUSINESS existe uma grande chance de que você deveria estar usando uma solução pronta ou contratando um serviço e não desenvolvendo do zero.

Comente o que você acha! Se você gostou, compartilhe com aquele seu amigo que quer fazer tudo do zero.

Obs:
Neste post comento um pouco sobre a importância de se livrar do Ego e ser humilde: Hackeando o organograma e influenciando ativamente quem está acima de você.

Créditos da música:
Music: 月华
URL: https://enjoymusic.ai

Tech Leads deveriam gerenciar pessoas?

Tech Leads deveriam gerenciar pessoas? Alguns líderes técnicos tem um frio na espinha só de pensar nisso. Outros, que já estão fazendo isso no dia-a-dia se lamentam e acreditam que essa é a grande dificuldade do trabalho deles e que deveriam focar só na parte técnica. Porém, na minha opinião, a resposta para essa pergunta é um grande e sonoro SIM.

No entanto, para muitos Tech Leads, essa é uma dor. É como se essa fosse a parte do trabalho que mais cria ansiedade, como aquela palpitação antes de ter um 1-1, ou se perguntando “Por que não pensei em falar isso naquela hora?” E ainda as avaliações de performance ou demissões. Muitos pensam que seria mais fácil quebrar esse papel em dois entre pessoas e tecnologia. Algumas empresas até fazem isso, mas eu não acredito nessa separação.

Por certo, você evoluiu por várias etapas no seu desenvolvimento técnico, conseguiu negociar soluções, simplificar problemas, fazer escolhas difíceis, trade-offs e navegar pela sua carreira para alcançar essa posição de liderança. Você foi forjado nesses desafios e seria um desperdício ignorar isso e se reduzir ao conhecimento técnico de uma linguagem, sistema ou framework. Aproveitar o que você sabe facilitará o caminho daqueles que você lidera e eles vão crescer com chances de se tornarem líderes também.

Porém, só para deixar claro. Sempre que eu usar a palavra líder, eu estarei falando no sentido de um facilitador, de um mentor, de alguém que está ajudando alguém a superar os desafios. Não gosto de pensar em líder como “chefe”. Aliás, não gosto nem dessa palavra.

Imagem do Mentor do He-man. 
Tech Leads deveriam gerenciar pessoas?
Mentor.
Para quem lembra do He-man

Deixa eu me explicar.

Por fim, fiz esse vídeo, no qual explico um pouco sobre o porquê eu acredito tanto que tech Leads deveriam gerenciar pessoas.

Esse assunto começou sendo discutido lá no meu instagram, me sigam: https://www.instagram.com/ffreitasalves/

Efeito Dunning-Kruger e a Síndrome do Impostor

Muito se fala sobre a síndrome do impostor, porém pouco temos visto sobre o outro lado da moeda que é o Efeito Dunning-Kruger.

Quantas pessoas você conhece que sabem tão pouco sobre um assunto mas se acham as maiorais, enquanto outras pessoas com muito conhecimento, sentem-se incapazes? Esses problemas são reais. Um deles podemos evitar com um pouco mais de humildade, no outro, com mais auto-confiança. Veja o vídeo que gravei para o meu instagram:

E esse vídeo tem uma continuação aqui, falando sobre as pessoas que usam a Síndrome do Impostor como bengala.

Contudo, mesmo falando que tem gente que usa isso como bengala, ainda existem muitos casos reais de quem sofre com isso, como nessa história que eu falei aqui.

O óbvio ululante para quem quer crescer na carreira de tecnologia

Tem uma pequena coisa que você precisa entender para ser um profissional de tecnologia melhor. É uma coisa óbvia que a grande maioria se esquece no dia a dia e depois não entende porque está demorando para evoluir como uma liderança técnica. Você precisa entender qual o objetivo da área técnica.

E não é só para liderança, mesmo um desenvolvedor no começo da carreira poderia crescer mais rápido se tivesse isso em mente.

O objetivo da área técnica é dar viabilidade para o negócio. Ponto!

O Poço e quando defecam em nós.. Óbvio. | by Sephiroth Computatrum | Medium

Tem que entender o negócio de verdade. Se interesse pelo problema a ser resolvido, traga alternativas, aprenda a negociar escopo, avalie quando dá pra entregar algo inacabado, mas com alguém operando no back-office, saiba quando poderia ou não comprar uma dívida técnica, enfim, tenha em mente sempre em como o resultado do seu trabalho vai impactar o negócio.

Entender isso faz toda a diferença para crescer mais rápido na carreira e para ser uma liderança técnica eficaz!

Publiquei esse texto ontem 15/Set/20 no meu Linkedin e depois usei os stories do Instagram para falar um pouco sobre casos desse tipo.

Me sigam por lá!

PS: Usei a famosa expressão do Nelson Rodrigues, “Óbvio ululante”, em homenagem a um brasileiro que era espetacular. Esse ano li “A Pátria de Chuteiras” que é uma coletânea de textos futebolísticos do Nelson Rodrigues e de lá podemos ver o quanto esse cara acreditou no brasileiro. Eu também acredito!

Culpa por estar descansando

Você passa o final de semana se culpando por estar descansando? 

Esse é um assunto que surgiu algumas vezes conversando com desenvolvedores na minha mentoria. A história é sempre parecida: Você tem pouco tempo durante a semana e no final de semana quando vai descansar ou se divertir, você pensa que deveria estar trabalhando ou estudando e se sente culpado.

Bart Bored | Capa twitter

Citando Yuval Harari no livro Homo Deus: “No mundo moderno, nós humanos tocamos o negócio. Por isso estamos sob constante pressão dia e noite”.  Essa pressão é normal, pois você sabe que é o grande responsável pelo seu sucesso e seu futuro, seja na carreira, na vida familiar, financeira, etc. Não dá pra terceirizar, é melhor aceitar que é difícil e fazer alguma coisa quanto a isso.


O que fazer? Planeje-se. E antes de inventar a desculpa de que “não adianta planejar minuto a minuto”, dê uma chance para o planejamento. Esse simples ato vai te dar muitos insights sobre o que você deveria ou não estar fazendo.

Pegue papel e caneta e escreva tudo que você gostaria de fazer, quais áreas da sua vida você precisa balancear, quanto tempo você gostaria de se dedicar para cada coisa e se planeje. Se você decidir que não vai usar o final de semana para esses objetivos então simplesmente fique em paz. Você vai ver que o problema não é estar se divertindo, é simplesmente estar com um monte de abas do Chrome em aberto na sua cabeça.

Descanso planejado não tem sentimento de culpa! Você só precisa estar OK com as escolhas que você fez para você. Se você não estiver confortável porque gostaria de estar investindo seu tempo em um negócio próprio, em um curso ou em uma atividade física, se planeje e execute.


Meetup Virtual de Flutter para Pessoas em Quarentena

Meetup virtual de Flutter para pessoas em quarentena

Eu estava querendo organizar um Meetup de Flutter mas com a quarentena até dei uma desanimada… Até descobrir a história de como o Meetup foi criado.

Depois do ataque ao World Trade Center em 2001, Scott Heiferman se reuniu com seus vizinho. Apesar de morar no mesmo prédio há anos, nunca havia falado com eles.

A situação em Nova York era tão delicada que acabou por aproximar as pessoas em suas comunidades locais. O espírito era de cooperação.

Depois desse encontro e de uma vigília na cidade, Scott se viu com questões como:

  • O que une as pessoas?
  • O que leva as pessoas a falarem umas com as outras?
  • O que leva as pessoas a se organizarem em grupos para fazerem coisas boas?

Scott diz que antes não era muito ligado a comunidades, porém estava intrigado e no ano seguinte resolveu criar o Meetup junto a mais cinco pessoas.

O Meetup é uma plataforma online que busca unir pessoas presencialmente. Contudo, desde a quarentena que nos foi imposta pelo COVID-19 eles mudaram o “in-person event policy” e estão incentivando os organizadores a criarem eventos online.

Aproveitei a oportunidade e criei o Meetup Virtual de Flutter para Pessoas em Quarentena

O ser humano é um animal social e espero que estejamos ainda mais unidos depois de passarmos por esta crise.

Deploy de aplicações SSR utilizando o Supervisord

Se você está construindo aplicações que renderizam do lado do servidor, o famoso SSR, utiliznado React (com o next.js) ou Vue.js (com o nuxt.js), você vai precisar de alguma ferramenta para controle do processos quando for fazer o deploy. Eu escolhi fazer o deploy de aplicações SSR utilizando o Supervisord, apesar de ter visto em vários sites o pessoal utilizando PM2 para este tipo de aplicação, acredito que o Supervisord é mais conhecido em um contexto geral, não só de quem é do mundo do node.
Se você já viu meu Guia para Deploy Django e Python 3, você já usou o Supervisor.

A razão número 1 para você ter um aplicativo React ou Vue utilizando SSR é por causa do SEO. O Googlebot não trabalha bem com páginas renderizadas do lado do cliente (CSR, o contrário do SSR) e por conta disso pode nem indexar suas páginas. Então, ter uma aplicação SSR dessas rodando no seu servidor, significa que você vai servir a aplicação utilizando o node pra rodar os javascripts que você criou. E para manter o seu comando node rodando, você não pode simplesmente abrir em um screen e torcer para que continue rodando. Você precisa colocar seu app em uma ferramenta de controle de processos como o Supervisord para inicializar sua aplicação caso o servidor reinicie ou sua própria aplicação dê algum pau.

Instalando o Supervisord:

sudo apt-get install supervisor

Agora, vamos criar um arquivo de configuração para a aplicação SSR:

sudo vi /etc/supervisor/conf.d/my-ssr-app.conf

That’s the content:


[program:myappname]
directory=/home/username/yourproject/
command=npm run start
user=username
autostart=true
autorestart=true

Então, precisamos avisar o supervisord que existe um novo processo para ele controlar


sudo supervisorctl reread
sudo supervisorctl update

E futuramente, quando precisar restartar apenas o seu app, use o nome que você colocou no arquivo de configuração.


sudo supervisorctl restart myappname

E é isso aí. Agora você sabe como fazer deploy de aplicações SSR utilizando o Supervisord.

I Know Kung Fu GIF from The Matrix (Now you know how to deploy ssr applications using supervisord)

Alguns links:

Post original em inglês

https://www.reddit.com/r/reactjs/comments/an16mx/how_does_seo_work_with_react/

https://medium.com/walmartlabs/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8

https://dev.to/stereobooster/server-side-rendering-or-ssr-what-is-it-for-and-when-to-use-it-2cpg

Criando um container Docker para um projeto Django Existente

Neste post, vou mostrar como criar um container Docker para um projeto Django já existente. Como exemplo, resolvi buscar por uma issue aberta no github que estivesse pedindo para ser dockerizada. Criei um PR para a Issue e usei como exemplo aqui.

Por quê você vai querer dockerizar uma aplicação web django que já existe? Bom, existem muitas razões, se você acha que não tem uma, faça pela diversão!

Eu decidi usar o docker em uma das minhas aplicações porque ela estava ficando muito difícil de instalar. Muitos requisitos do sistema, vários bancos de dados, celery, rabbitmq e por aí vai. Sem dockerizar cada vez que uma nova pessoa entra no time é um inferno pra setar tudo porque levava tempo demais.

O mundo ideal é que o programador tenha em seu ambiente de desenvolvimento o mais próximo que puder do ambiente de produção. Se você usa SQLite na sua máquina mas Postgres no servidor pode ser que tenha problemas de dados que são simplesmente truncados localmente mas que vão levantar erros na base de produção. Só para ter ideia de um exemplo.

Se você não sabe o que é o docker, imagine que é um imenso virtualenv que no lugar de ter apenas pacotes python tem o sistema operacional “inteiro”. Isso consegue isolar seu app de tudo que está no seu SO, bancos de dados, workers, etc.

Mão na massa

Ok, falar é fácil, vamos codar um pouco.

Primeiro de tudo, instale o Docker. Fiz isso no Ubuntu e no Mac sem nenhum problema. Já no Windows Home não consegui fazer funcionar.

Para dizer ao docker que sua aplicação é um container você precisa criar um arquivo Dockerfile:



FROM python:3.6
ENV PYTHONUNBUFFERED 1

RUN mkdir /webapps
WORKDIR /webapps

# Installing OS Dependencies
RUN apt-get update && apt-get upgrade -y && apt-get install -y \
libsqlite3-dev

RUN pip install -U pip setuptools

COPY requirements.txt /webapps/
COPY requirements-opt.txt /webapps/

RUN pip install -r /webapps/requirements.txt
RUN pip install -r /webapps/requirements-opt.txt

ADD . /webapps/

# Django service
EXPOSE 8000

Vamos lá, linha a linha:

Docker Images

FROM python:3.6

Aqui estamos usando uma imagem do docker hub. Isto, é um container pré-formatado do docker que permite que você monte sua máquina a partir daquela configuração inicial. Nesse caso, Python 3.6 é um container de um Ubuntu que tem o Python 3.6 instalado nele. Você pode procurar por containers no docker hub.

Environment Variables (Variáveis de ambiente)

Você pode criar todas as variáveis de ambiente que quiser com o ENV.

ENV PYTHONUNBUFFERED 1  # Here we can create all Environment variables for our container

Por exemplo, se você usa variáveis de ambiente para guardar sua secret key do Django é só fazer assim:

ENV DJANGO_SECRET_KEY abcde0s&&$uyc)[email protected]!a95nasd22e-dxt^9k^7!f+$jxkk+$k-

E usar no seu settings, desse jeito:

import os
SECRET_KEY = os.environ['DJANGO_SECRET_KEY']

Run Commands

Docker Run Commands tem um nome meio óbvio. Você pode rodar um comando “dentro” do seu container. Estou colocando dentro entre aspas porque o docker na verdade cria algo como sub containers para que não precise rodar os mesmos comandos novamente no caso de precisar dar um rebuild do container.

RUN mkdir /webapps
WORKDIR /webapps

# Installing OS Dependencies
RUN apt-get update && apt-get upgrade -y && apt-get install -y \
libsqlite3-dev

RUN pip install -U pip setuptools

COPY requirements.txt /webapps/
COPY requirements-opt.txt /webapps/

RUN pip install -r /webapps/requirements.txt
RUN pip install -r /webapps/requirements-opt.txt

ADD . /webapps/

Aqui estamos criando o diretório que guardará os arquivos do projeto: webapps/.

Workdir é uma instrução para mostrar ao docker em qual diretório ele vai rodar os comandos a partir dali.

Depois disso estou instalando as dependências do sistema operacional. Quando estamos usando requirements.txt no projeto, estamos colocando apenas os requisitos do python e não os do SO. Mais um motivo para querer usar o docker para desenvolver. Quanto maior seu projeto, mais requisitos de sistema operacional vão aparecer.

COPY e ADD

Copy e ADD são basicamente a mesma cosia. Ambos copiam um arquivo do seu computador (o Host) dentro do container (o Guest). No meu exemplo, estou apenas copiando o requirements para dentro do docker, para que eu possa dar pip install nos pacotes.

EXPOSE

Expose é para mapear uma porta do Guest (o Container) para o Host (seu computador)

# Django service
EXPOSE 8000

Ok, e agora? Como podemos adicionar mais containers para rodá-los juntos? E se precisarmos colocar um postgresql para rodar em um container também? Não se preocupe, vamos usar o docker-compose.

Docker-Compose

O compose é uma ferramenta para rodar múltiplos containers do docker. Só precisa criar um arquivo yml na pasta do seu projeto com o nome docker-compose.yml:

version: '3.3'

services:
  # Postgres
  db:
    image: postgres
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=postgres

  web:
    build: .
    command: ["./run_web.sh"]
    volumes:
      - .:/webapps
    ports:
      - "8000:8000"
    links:
      - db
    depends_on:
      - db

Aqui estou usando uma imagem do Postgres que também peguei no Docker Hub.

Agora vamos mudar o settings.py para poder usar o Postgres do container como banco de dados.

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'postgres',
        'USER': 'postgres',
        'PASSWORD': 'postgres',
        'HOST': 'db',
        'PORT': '5432',
    }
}

Quase lá, deixa eu falar um pouco sobre o arquivo docker-compose.yml,

VOLUMES

Lembra do vagrant?

Era uma vez o Vagrant. Ele era uma forma de rodar um projeto dentro de uma Máquina Virtual que permitia configurar e mapear portas fácilmente, provisionar requisitos do sistema e compartilhar volumes. Seu computador (o Host) podia compartilhar um volume com a máquina virtual (o Guest, ou convidado). No docker, o volume é exatamente a mesma coisa. Quando você escreve um arquivo em um volume que está compartilhado o arquivo também está sendo escrito dentro do container.

volumes:
  - .:/webapps

Nesse o caso, o diretório em que nos encontramos (.) é o que está sendo compartilhado com o container.

LINKS

links:
  - db

Você pode se referir a outro container que pertence ao seu arquivo docker-compose utilizando o nome dele. Como criamos um container com o nome db para o Postgres nós podemos criar um link para ele no nosso container chamado web. Pode ver que no settings.py nós colocamos ‘db‘ como host.

DEPENDS_ON

Para rodar sua aplicação, seu banco de dados precisa estar pronto antes do container web, senão vai dar algum pau!

depends_on:
  - db

Command

Command é o comando padrão que o docker vai rodar logo depois que você subir, ou seja, colocar os containeres para funcionar.

No nosso exemplo, eu criei um run_web.sh que vai rodar as migrações, coletar o static files e iniciar o servidor de desenvolvimento.

#!/usr/bin/env bash

cd django-boards/
python manage.py migrate
python manage.py collectstatic --noinput
python manage.py runserver 0.0.0.0:8000

Alguém pode argumentar que migrar assim automaticamente toda vez que subir o container pode não ser uma boa prática. Eu concordo. Você pode (e deve) rodar o migrate direto na máquina web. Você pode acessar seu container para rodar comandos assim (como no bom e velho vagrant ssh):

docker-compose exec web bash

Se você quiser , você pode rodar o comando sem acessar o container mesmo, apenas mudando o último argumento do comando acima:

docker-compose exec web python manage.py migrate

O mesmo para outros comandos:

docker-compose exec web python manage.py test
docker-compose exec web python manage.py shell

Rodando o Docker

Com nosso Dockerfile, docker-compose.yml e o run_web.sh no lugar, vamos rodar tudo junto:

docker-compose up

Você pode ver esse projeto aqui no meu GitHub.

Escrevi esse texto originalmente em inglês.

**EDITADO**

Antes eu estava usando run no lugar de exec. Mas o Bruno FS me mostrou que o exec é melhor pois está acessando exatamente o container que já está rodando e que o run na verdade está criando um novo container.

References: