Português

Existem 34 posts arquivados em Português

Hackeando o Organograma. Influenciando ativamente quem está acima de você

Essa semana li um texto interessantíssimo do meu amigo Muller Nascimento: Às vezes é a maçã e às vezes é o barril. O texto discute o que fazer quando o problema é quem toma as decisões. Isso não é simples e entendo que para a maioria das pessoas essa situação pareça insolúvel, mas não é. Hackeando o organograma, você pode liderar sua empresa, independentemente da posição que ocupa.

Minha sugestão aqui é que você assuma uma postura de liderança, sem se prender ao seu papel na empresa. Para isso, você vai precisar trabalhar em vários pontos ativamente. A maioria das pessoas vai fugir, ou achar que não vale o esforço, mas se você for uma das poucas pessoas a lutar terá aprendido muito no processo e poderá ser responsável por melhorar não só seu ambiente de trabalho, como a si mesmo e sairá dessa batalha um profissional muito mais capacitado e pronto para assumir posições mais difíceis.

Comunicação

Jeff Sutherland no seu livro Scrum, fala sobre a importância da saturação da comunicação para o funcionamento efetivo do time. É uma verdade dentro de um time de 5 ou 6 pessoas e continua sendo verdade para organizações inteiras, com centenas de colaboradores (ou maçãs 🍎 🍏, como chamou o Muller). Mas por quê ainda se fala tanto sobre a importância da comunicação ? Porque é sempre o primeiro problema pra resolver.

Para manter todo mundo na mesma página é que surgem as reuniões de alinhamento, planejamento, reuniões diárias (daily meetings), retrospectivas, etc. O único objetivo é compartilhar o máximo para que todos tenham contexto suficiente para tomar as melhores decisões. A boa comunicação e a saturação dela entre “líderes” e “liderados” é o caminho para uma relação mais harmoniosa e um trabalho mais efetivo.

Na prática: O que fazer quando seu líder não se comunica de maneira eficiente? Perguntas! Sempre que alguma coisa não estiver clara para você, você vai perguntar. Seu objetivo não é entender “Como fazer alguma coisa” ou “O que deve ser feito”. Seu objetivo primeiramente é entender o Objetivo por trás de qualquer tarefa. Entender o “Por quê” algo precisa ser feito vai te trazer a visão global de algo. Toda vez que não estiver claro, pergunte ativamente. Discuta os pontos que devem ser feitos, qual a melhor forma de fazê-los e quando algo não estiver claro para você como “por quê estamos usando a metodologia x ao invés de y?” ou “por que não tentamos fazer tal coisa”.

Fale com quem resolve

Falar com quem resolve é outro ponto que deve ser trabalhado se você quiser liderar de baixo para cima. Discuta abertamente os problemas da empresa com o seu chefe e não pelas costas para os seus pares. Falar com alguém que não tem o poder de mudar nada só vai soar como reclamação e vai contaminar o barril inteiro e ainda pode ter um efeito negativo sobre como os outros funcionários enxergam você. Se você levar isso para quem tem o poder de resolver, você estará ativamente buscando soluções.

Seja Humilde

Contudo, considere se você está sendo humilde. Eu sei o quão irritante pode ser ouvir isso, principalmente se você estiver de saco cheio com a sua empresa, porém ser humilde para considerar se o que está sendo feito tem sentido, ou se você tem o contexto completo para avaliar uma decisão é crucial para ser ouvido também. No livro, Extreme Ownership, Jocko Willink e Leif Babin explicam como o ego pode atrapalhar seu julgamento e sua tomada de decisões. Se você ouvir atenciosamente, maior será sua chance de entender melhor o cenário e com isso ter uma melhor base de argumentação, se necessário. No final de uma boa discussão os envolvidos vão sair melhores, entendendo mais os pontos um do outro. Mesmo que haja discordância, é mais fácil seguir por um caminho depois de entender quais são os trade-offs de cada alternativa.

Compartilhe Conhecimento

Uma outra estratégia que pode ser aplicada juntamente a todas as outras é compartilhar conhecimento. As diferentes visões para a tomada de decisão vem de diferentes repertórios. Nutra os demais membros do time com informações que você achou relevante para basear a sua visão. Indique textos, livros, podcasts, vídeos, ted talks, cursos e tudo que puder para seus líderes. As vezes um simples “Fulano, gostaria de discutir um texto com você”, pode ser suficiente para um aprendizado relevante na sua empresa. Ninguém sabe tudo e fomentar essas trocas só enriquece o ambiente e o aprendizado.

Vá embora, você não é uma árvore

Por fim, se a incompatibilidade de gênios é certa, não leve nada para o pessoal. Crie asas e voe para outro lugar. Foque nas coisas boas que você construiu e nos aprendizados que vai levar desta empresa para outra e vá atrás de algo melhor para você. Permanecer em um lugar que não tem nenhum sinal que vai dar certo pode te desmotivar e isso não prejudica só sua empresa, mas também as pessoas próximas (ninguém suporta reclamões) e principalmente sua imagem profissional, pois alguém desmotivado por um longo período pode ser visto como preguiçoso e/ou incapaz pelos colegas e refletir negativamente em futuras indicações.

Resumo

Algorítimo para hacker as organizações:

  1. Comunicação efetiva sempre! Pergunte até esclarecer pontos obscuros. Não assuma nada!
  2. Fale com quem pode resolver. Levar problemas para os seus pares não muda sua vida, só faz de você um bebê chorão ou uma matrona fofoqueira.
  3. Seja Humilde.
  4. Eduque quem estiver ao seu redor! Considere compartilhar com eles textos e livros sobre temas que acredita que eles não estão bem treinados. Essa é uma forma efetiva de feedback para liderar.
  5. Não leve nada para o lado pessoal. Muitas vezes temos que lidar com pessoas que não tem a mesma maturidade que temos. Se for o caso, bola pra frente

Vamos discutir?

Concordando ou não, deixe um comentário, eu realmente quero ouvir outras opiniões sobre esse assunto.

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

Crie um produto que as pessoas amem

Escrevo esse texto depois de por várias vezes ter tido problemas com o app da Rappi e mesmo assim continuar tentando usar. Eles resolvem um problema tão real que eu, como usuário, consigo não ligar para alguns bugs e mal funcionamento, justamente porque quero muito o serviço que tem ali. Com certeza essa é a primeira coisa pra se prestar atenção quando se vai criar algo que as pessoas amam.

Image result for meme xiaomi
Usuários que amam um produto se tornam evangelistas dele.

Quando em 2014 passei uns meses no Vale do Silício, eu ouvi essa frase algumas milhares de vezes. Toda startup ou “empresa caloura” como diz um amigo meu, está ou deveria estar em busca da construção de um produto que o usuário AME. Não é um produto que o usuário goste, nem um produto que o usuário use com frequência, mas sim: um produto que as pessoas amam.

Já pensou como é difícil AMAR um produto ou uma empresa? Para isso essa empresa realmente precisa estar resolvendo um problema de verdade. Uma dor daquelas que realmente incomodam. Veja que essa é a parte mais importante: enxergar justamente onde você pode mudar a vida/rotina de alguém. Encontrar essa dor é mais importante que as ferramentas que você usou, que o produto “acabado” ou que o tamanho do seu mercado.

Você conhece algum produto assim? Perguntei para pessoas próximas quais sites ou apps elas amam e as respostas foram essas: Waze, Strava, iFood, Inbox (que inclusive será descontinuado pelo Google) e muitos outros, sem contar os clássicos como o iPhone, iPod, Steam, etc… Pode ser que para você não seja nenhum desses, mas com certeza existe algum aplicativo, ou outro tipo de serviço/produto que você AMA.

Image result for iphone launching line
Filas de pessoas para comprar um novo iPhone

Encontrando um problema para resolver

Sempre que você se depara com uma dificuldade você está diante de um problema que você pode resolver. A questão é se ele vale a pena ser resolvido. Você pode achar que vale a pena criar mais uma marca de surf e que as que existem são poucas; ou você pode descobrir que bancos são irritantes para pessoas jovens e tentar construir um banco que atenda essas pessoas.

Além desses problemas em um nível macro, você encontrará muitos outros menores que ainda não estão bem resolvidos. Pode ser que na empresa que você trabalha existe um processo manual que poderia ser automatizado. Por quê não pensar nisso como um problema a ser resolvido? Talvez você possa automatizar isso para várias empresas e passar de funcionário para fornecedor. Coisas como essa acontecem bastante e muita empresa de sucesso foi criada assim, aproveitando um problema que precisava ser resolvido para outra empresa, mas que não era o core do negócio.

Resolvendo o problema

Independente do problema que você encontrou, a primeira coisa que você vai fazer é se tornar um especialista naquele assunto. Consuma o máximo de conteúdo que puder sobre aquilo, leia livros, assista vídeos, vá em eventos e aprenda sobre o problema que você encontrou. É realmente, um problema? Existe para mais alguém? Não é só algo da sua cabeça? Muitas vezes ficamos tão obcecados com nossas próprias ideias que não conseguimos apreender sobre o mundo ao nosso redor. Não fique fechado em seu casulo, converse com outras pessoas, pense se vale a pena investir nessa solução. Se você chegou a conclusão de que é necessário resolver aquele problema então chegou a hora de trabalhar em cima do seu primeiro protótipo: o produto mínimo viável.

Criando um MVP para validar uma hipótese

MVP é uma sigla muito famosa e pouco entendida. É o Minimum Viable Product ou Produto Mínimo Viável, em português. O MVP é um protótipo. É um experimento para testar uma hipótese. O mais importante nesse passo não é o MVP em si, mas sim o teste da hipótese.

A primeira coisa a se fazer é criar uma hipótese. Vamos imaginar como poderia ter sido a hipótese da NetFlix, no final dos anos 90. O cenário era de pessoas que se locomoviam até grandes locadoras para escolher filmes e depois de um ou dois dias, deveriam voltar na locadora para devolver o filme assistido. Imagine que a NetFlix achava um porre ter que sair de casa para alugar e ter que ir depois para devolver. Caso não devolvesse no prazo, as locadoras cobravam uma multa. Então, suponhamos, que a NetFlix montou a seguinte hipótese: “Já que nós acreditamos que as pessoas não querem ir até uma locadora, se oferecermos um aluguel de filmes em casa, elas vão usar o nosso serviço”.

Agora, com a hipótese em mãos, vem o MVP da Netflix. Para testar essa hipótese foi criado um catálogo de DVDs que eram entregados pelo correio. Você recebia o catálogo, pedia o filme por telefone e alguém entregava e depois vinha retirar o filme. Simples assim.

Veja, o MVP foi suficiente para testar a hipótese e para fazer o mais importante: Colocar a empresa em contato com os early-adopters, ou seja, os primeiros usuários. As pessoas que tem aquela dor latente de querer ter aquele problema resolvido e não ligam se seu serviço apresenta algumas falhas no começo, contanto que você esteja resolvendo o problema delas.

Image result for mvp
Exemplo de construção de um MVP, entregando valor para o cliente em cada iteração

Ouvindo os clientes para começar tudo de novo

A construção do MVP abre o contato entre sua empresa e seus clientes e essa é a parte mais importante para construir um produto que as pessoas amam. Primeiro, você precisa se despir do que você acha que sabe sobre o mercado ou sobre seus clientes. Você precisa escutá-los atentamente e observar como esses clientes usam e se relacionam com seu produto/serviço.

Esse é o momento de entender o que realmente importa para os usuários. Como você pode economizar ou criar tempo, dinheiro e recursos para eles. Como o usuário tem resolvido aquele problema sem a solução que você está oferecendo. Você melhora ou piora o processo dele? Ele está disposto a pagar por essa solução ou quando está de frente com um boleto acredita que aquele problema não era tão grande assim?

Repetindo o processo

Tanto faz se sua hipótese foi validada ou não. Em qualquer um dos casos você vai ter aprendido coisas novas nesse processo. Aprendido sobre seus usuários, sobre o mercado, sobre o seu próprio produto. Então é hora de partir para uma nova hipótese. Trabalhe em um novo MVP e parta para um novo ciclo.

Cada vez que você completar o ciclo você está iterando sobre ele, ou seja, você está utilizando todo o feedback que recebeu dos usuários e colocando como insumo sobre o mesmo processo de desenvolvimento do produto. Esse processo, segundo os princípios de Lean Startup (Startup Enxuta) é o Build-Measure-Learn (Construir-Medir-Aprender).

Resultado de imagem para construir medir aprender
Ciclo Build-Measure-Learn (Construir, Medir, Aprender)

O processo de construir, medir e aprender é o que vai garantir que você esteja construindo algo que as pessoas amem. Não é o seu instinto, não é o que você acha e não é o quanto você cobra. O processo vai garantir que a cada novo passo na construção do seu produto você esteja avançando na direção certa, na direção que traz mais resultado para os seus clientes.

Exercitando o método

Todo esse processo da Startup Enxuta se assemelha a um método científico. Você tem suas suposições e cria experimentos para testá-las. De acordo com o que você aprendeu com esses experimentos você confirma ou muda suas ideias iniciais, sem crise e sem dogmas.

Um exercício interessante para quem quer empreender é tomar nota de coisas que você vê no seu dia a dia sobre problemas e soluções existentes. Tente responder as seguintes perguntas no seu dia a dia:

Para conhecer outros produtos:

  • Qual problema esse produto/serviço resolve? Como isso era resolvido antes? A solução proposta é melhor e mais confiável que a anterior?
  • Quais produtos eu sou um early-adopter, uso mesmo que eles não estejam 100% prontos e apresentem problemas de vez em quando?
  • Quais novos lançamentos eu presenciei em serviços/produtos que trouxeram novos benefícios para mim e outros usuários?

Para treinar com as suas ideias:

  • Qual problema eu estou enfrentando que não tem uma solução boa e confiável o bastante?
  • Quem seriam os early-adopters, ou seja, pessoas que também enfrentam esse problema e estariam dispostos a testar uma nova solução?
  • Qual o MVP que eu poderia criar para ter certeza que tenho um problema real e que os early-adopters estão dispostos a usar meu MVP e pagar por ele, mesmo que incompleto?

Longe de ser um assunto novo, mas é sempre importante relembrarmos as bases. Escrevi despretensiosamente, mas gostaria de saber quais outros produtos/serviços vocês sentem que são early-adopters e usam mesmo quando enfrentam dificuldades para fazer o app funcionar?

Se gostou, compartilhe!

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.

Se gostou do post, me segue no instagram:

 

**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:

4 Melhores Podcasts sobre Tecnologia e Startups

Ouvir Podcasts é uma forma muito eficiente para se manter por dentro do que acontece na sua área.  Ouço vários Podcasts sobre tecnologia e startups, além de outros temas e tenho certeza que eles são importantes para que eu continue atualizado no meu ramo. Estar informado pode ser a diferença entre ser bom e ser ótimo.

Para quem não conhece, podcast é como um programa de rádio com a diferença de que você pode ouvir quando quiser, escolher os episódios e sempre ficará sabendo quando publicarem um programa novo. Podcast não é novidade mas não chegou a virar mainstream no Brasil ainda. Vai crescer muito este ano.

Meu aplicativo para assinar (baixar e ouvir) podcasts é o PocketCasts ele é pago, paga uma vez só e usa todos os dias, mas existem várias outras opções gratuitas aí para quem não quiser desembolsar os R$ 12 reais. Bora pra lista:

Hipsters.tech

logo do podcast hipsters.tech

Apesar do nome péssimo, clichê e modinha é na minha opinião o melhor podcast brasileiro. Tem um episódio por semana e é um programa muito bem formatado. Normalmente os episódios tem menos de uma hora e variam sobre desenvolvimento, design, empreendedorismo, etc.

Esse é um dos episódios que gostei bastante sobre Squads. Você pode dar uma olhada em outros episódios no site deles https://hipsters.tech

Software Engineering Daily

software engineering daily logo

Esse é um podcast gringo (em inglês). Eles soltam um episódio por dia útil, ou seja, é daily mesmo. Mesmo que não dê para ouvir todos os dias é bom ficar por dentro e olhar o que eles já fizeram. Tem entrevistas com gente da área de tecnologia e de startups, normalmente engenheiros e empreendedores de empresas renomadas e criadores das tecnologias que estão sendo discutidas. Você pode ver os episódios aqui

Talk Python to Me

talk python to me podcast logo

Esse podcast é mais específico para pythonistas, mas quem não gosta de python? Tem participações de caras muito fodas da comunidade como Kenneth Reitz, David Beasley e até do Guido Van Rossum.

O site é esse aqui: https://talkpython.fm/ . Meu único problema com esse podcast é que ele tinha a melhor música de abertura de qualquer podcast até o meio do ano passado, depois entrou uma música chata =P

Like a Boss

like a boss podcast logo

Esse é um podcast dos mesmos criadores do Hipsters. O objetivo é “trazer entrevistas com líderes, fundadores de startups e empresas inovadoras” nas próprias palavras deles. Está bem no comecinho, tem apenas 7 episódios.

Gostei bastante dessa entrevista com David Vélez, o fundador do Nubank.

Outros podcasts:

Eu gostava muito do ZOFE (Zone of Front-Enders) , mas infelizmente ele não tem novas publicações já faz tempo. O site está mais desatualizado que o podcast mas ainda assim dá para ouvir conteúdo do passado. Era realizado pelo Daniel Filho, um cara diferenciado que eu sempre via no melhor meetup de front-ends de São Paulo, o FEMUG-SP.

Falando em podcasts antigos, outro que curti bastante mas já não solta coisa nova é o Grok Podcast. Isso que é bom dos podcasts, eles podem ter acabado mas os episódios estão aí para sempre.

Um podcast que eu descobri recentemente foi o Castálio Podcast. Também fala bastante de Python. Por enquanto, só ouvi um episódio e foi sobre serverless. Aliás, dá pra ver o podcast sendo gravado ao vivo no youtube e mandar perguntas para eles.

Mais um podcast gringo que estou esperando ver como vai desenrolar é o Modern CTO. Me parece uma estratégia audaciosa para criar conteúdo para CTOs uma coisa que não se vê todo dia. Estou começando a acompanhar.

Bom, esses foram os meus podcasts favoritos sobre esses temas. Quem tiver outros podcasts que quiser indicar deixe nos comentários.

 

Tanto no pessoal quanto no profissional – Boas práticas do seu trabalho na vida cotidiana

Pedido de casamento em paris

Não é incomum ouvirmos histórias de pessoas que são bem sucedidas no trabalho mas sua vida pessoal é uma bagunça. Maus hábitos, sedentarismo, finanças descontroladas, não tem tempo pra nada e a culpa sempre recai sobre o trabalho.

Dependendo de como for sua rotina, pode ser que a culpa seja do trabalho, mas o mais provável é que a culpa seja sua mesmo. Se está cursando uma faculdade e trabalha 12 horas por dia e dorme pouco pode parecer que não cabe mais nada na sua vida, mas mesmo assim é possível melhorar algum aspecto.

Sempre gostei de estudar e usava isso como desculpa para muitas coisas quando era mais novo, inclusive para não estudar. Como fiz ensino médio e técnico ao mesmo tempo (um de manhã e o outro noturno) eu deixava algumas matérias do ensino médio de lado porque gostava mais dos assuntos de computação. Se fui mal em geografia logo me escorava mentalmente em estar indo bem no curso técnico e dizia pra mim mesmo que se estivesse apenas cursando o ensino médio, teria ido bem em geografia. É o velho e batido “quem quer dá um jeito e quem não quer dá uma desculpa”.

Esse mecanismo mental de compensação é natural do ser humano. No livro The Willpower Instinct, a professora de Standford Kelly McGonigal fala sobre como deixamos que um bom comportamento anterior seja uma desculpa para um mau comportamento no presente. Um fenômeno bem conhecido de quem está tentando emagrecer, logo depois de fazer um exercício acaba se dando de presente um rodízio de pizza. Mesmo que já esteja provado que é muuuito mais difícil emagrecer só fazendo exercícios.

Esse comportamento me acompanhou durante muitos anos. Sempre gostei de me ver como alguém que quer alimentar a mente com conteúdo interessante, estudando, tentando coisas novas e isso acabou sendo desculpa para nunca praticar esportes, por exemplo. Felizmente, tive a oportunidade de conhecer pessoas completas (Mente sã, corpo são). Parece que o dia dessas pessoas tem 40 horas. Elas trabalham, leem, praticam esportes, estudam, mantêm relacionamentos e tem amigos. Com certeza você conhece alguém assim também.

Mesmo assim, há 2 ou 3 anos estou querendo ser como uma dessas pessoas. Não só me dedicar no trabalho, bater metas, entregar resultados e projetos, mas também alcançar os meus resultados pessoais, bater as minhas próprias metas, melhorar em cada aspecto que eu puder melhorar. Pode parecer uma coisa de auto-ajuda e é. (Aliás, sempre desprezei o termo auto-ajuda, sempre me pareceu conversa para boi dormir, mas descobri que de cada livro, palestra ou TED Talk de auto-ajuda que eu assisto mesmo que tenha papo-furado terá algo útil para minha vida pessoal).

O que percebi é que muito das técnicas que usamos todos os dias no ambiente de trabalho para alcançar resultados são simplesmente esquecidas na nossa vida pessoal. Provavelmente sua empresa possui um planejamento, sabe quais são os objetivos, tem uma visão de longo prazo, tem valores, um budget e prioridades definidas. Mesmo que sua empresa não tenha tudo isso, você SABE que ela precisa ter. Por quê então a sua vida pessoal pode seguir dia após dia sem ter planos, metas, sem ter uma visão do que você quer para você e sem ter um orçamento para as áreas da sua vida?

1. Escreva um plano!

Um estudo que saiu no British Journal of Health Psychology fez um estudo com 3 grupos pedindo a cada grupo que fosse à academia pelas próximas 2 semanas. Ao primeiro grupo só foi feito o pedido. O segundo grupo além de ter recebido o pedido, também assistiram vídeos motivacionais (chamaram de grupo motivado). Já o terceiro grupo recebeu o pedido para ir a academia, assistiu os mesmos vídeos do grupo motivado e pediram que eles escrevessem a seguinte frase:

Durante a próxima semana eu vou praticar 20 minutos de atividade física vigorosamente na _____ (local) às __________ (horário)

Esse conceito é chamado de Implementation Intention (Intenção de implementação em tradução livre Fernandística). É basicamente quando você escreve as condições para terminar uma tarefa.

Os resultados foram :

38% do Grupo 1 compareceu à academia na próxima semana.

35% do Grupo 2 (Grupo Motivado)

91% do Grupo 3, o grupo que escreveu utilizando Implementation Intention.

Nunca subestime escrever um plano!

Anote no papel, no Evernote ou em qualquer lugar que você possa acessá-lo novamente depois.

2. Crie um sistema para atingir resultados

Somente focar em bater a meta é inútil. Não confie só na sua força de vontade para fazer você se mexer. Você precisa de um sistema que funcione para diminuir sua energia de ativação para realizar as tarefas até que elas se tornem um hábito.

Eu simplesmente não conseguia controlar o que comia ou bebia quando almoçava em restaurantes, assim resolvi que ia fazer marmitas para levar ao trabalho. Resolvi que ia preparar toda minha comida da semana aos domingos. Ao fazer dieta você começa a pensar que come todos os dias a mesma coisa e tudo vira motivo para ficar enjoado. O fato é que você não varia muito seus alimentos, mesmo quando não está fazendo dieta. Quando li isso no livro do Tim Ferris, The 4 hour body, percebi o quanto usei isso como desculpa para sair da dieta. Então resolvi ver uns vídeos no youtube sobre como preparar várias marmitas para a semana e voilá, cada vez menos falho em me alimentar bem na hora do almoço.

Criar um sistema serve para qualquer coisa, se você quer ler mais você precisa pensar que em determinado momento do seu dia ou da sua semana você vai precisar parar para ler. Se não separar esse tempo, você simplesmente não vai ler os livros que decidiu ler.

Na sua vida profissional você segue um sistema. Pode ser que você tenha que ligar para 10 clientes por dia, pode ser que você tenha que pesquisar 5 fornecedores para cada produto que você vai comprar, não importa. O sistema vai facilitar a sua vida.

3. Priorize

Você acordou 7h30 da manhã, foi no banheiro, levou seu celular, abriu o Facebook, deu uma scrollada, leu umas notícias, leu uns comentários e de repente são quase 9h00. Você já está atrasado, precisa tomar banho e começa seu dia naquela loucura para quando chegar em casa você entrar novamente nas redes sociais, olhar os grupos de WhatsApp, etc. Sua prioridade é essa merda de Facebook, simples assim. Desinstale ele do seu celular, assista menos TV a noite, leia menos jornal de manhã. Essa é a chave para criar tempo no seu dia. Se você gosta de postar coisas na sua rede social use o Hootsuite. Quer ler só o que saiu de interessante no jornal? Se inscreva em uma newsletter como o Canal Meio.

Muita gente acha, ou diz que se informa pelas redes sociais, quando na verdade as redes sociais e grupos estão é cheios de entretenimento e notícias irrelevantes. Aproveitar o tempo perdido nessas ferramentas é priorizar aquilo que você planejou. Acredite em mim, as notícias importantes, os acontecimentos e até mesmo os memes do momento vão chegar a você sem que você precise scrollar o seu Facebook por uma hora de manhã. Aproveite seu tempo no trânsito, arrumando a casa ou na esteira para ouvir Podcasts e aprender coisas novas, ouvir notícias ou ouvir um Audiobook.

Com certeza para ser bem sucedido na sua vida profissional você aprendeu a priorizar entre suas tarefas. Use isso na sua vida pessoal também.

4. Demita as pessoas tóxicas da sua vida

Já faz alguns anos que estou demitindo pessoas que não me acrescentam em nada na vida. Sabe aquela pessoa que quando você conversa com ela você se sente drenado? Pessoas que reclamam de tudo, ou reclamam dos outros, só falam de si, etc. Essas pessoas também tomam um tempo desnecessário da sua vida. Pessoas que em qualquer ambiente de trabalho seriam a maçã podre ou um fofoqueiro. Corte-as sem dó.

Mantendo somente amizade com pessoas interessantes você vai ver que pode aprender muito com elas. Até as notícias importantes que você deixou de ler para se dedicar a outra coisa chegarão a você através desse network bem selecionado de amigos que você vai manter.

5. Bônus: Meditação

Se você é um ateu, agnóstico ou cético pode ser que balance a cabeça ao ler sobre meditação, mas isso é cientificamente comprovado que melhora muito sua qualidade de vida. Não tem a ver com energia, com ki, com cosmo, com nada disso. Meditação é um exercício no qual você foca no agora, no seu corpo, na sua respiração e quando sua mente começa a viajar você percebe isso e volta para o que tinha que fazer. Isso vai melhorar sua produtividade, seu foco, sua resiliência e sua forma de lidar com suas emoções, afinal são partes de ser humano.

Se quiser melhorar tanto sua vida profissional quanto a pessoal comece a meditar. Já falei disso aqui no blog na retrospectiva do ano passado. E se depois de tentar achar que isso não é para você então pare uns minutos na sua manhã e escreva o que estiver na sua cabeça em um caderno. Prestar atenção em você é a importantíssimo!

Minha experiência pessoal

No começo de 2017 resolvi escrever um plano pessoal, pode chamar de resolução de ano novo, pode chamar do que quiser, mas o fato é que escrever o que eu queria para minha vida no ano passado foi extremamente importante para eu ter resultados na esfera pessoal.

Os objetivos que escrevi foram:

  • Chegar aos 88 Kg
  • Fazer atividade física uma vez a cada 3 dias ( ou 120 dias no ano)
  • Participar de uma corrida de 10 km
  • Fazer um curso de Machine Learning
  • Escrever pelo menos 6 posts no blog
  • Casar
  • Fazer uma viagem internacional
  • Fazer aulas de bateria
  • Tirar carteira de motorista
  • Fazer aulas de tênis
  • Economizar dinheiro
  • Ler 12 livros no ano

Todos os que marquei com fonte vermelha são os objetivos que não atingi. Todos os outros eu consegui, alguns até antes do tempo e fui capaz de dobrar a meta.

Lutei com meu peso nos últimos 10 anos, tentei por várias vezes praticar atividades físicas, mas sempre voltava para o sedentarismo. Muitas vezes usando a desculpa de que trabalho muito (50 a 60 horas por semana) e que não dá tempo para treinar. Em 2017 isso mudou. saí de 2016 que não fiz quase nenhuma atividade para 181 dias de atividade física em 2017. Bati os 120 dias em setembro e resolvi aumentar.

 

Para exercício considerei qualquer atividade física que fosse musculação ou aeróbica com 40 minutos de duração. Mesmo assim não cheguei aos 88 kg que planejara porque aprendi um pouco tarde como seguir uma dieta regrada, mas comecei o novo ano pesando 8 kg a menos que no ano anterior, com mais disposição e feliz em praticar atividades físicas diariamente.

 

O sucesso de ter atingido essa meta se deve muito a como eu a escrevi, que foi um pouco mais detalhada que as outras. Com minha meta financeira também fui bem mais específico, fiz um planejamento de como faria para diminuir minhas contas mensais e conseguir fazer minha viagem internacional e guardar dinheiro. Assim consegui no meio do ano ir para Nova York, Barcelona e Paris. Surgiu uma oportunidade boa para viajar com amigos e eu já estava me preparando financeiramente para poder viajar, por mais que não tivesse o plano inteiro pronto. A oportunidade aparece, se você estiver preparado vai poder aproveitar.

Uma coisa muito legal para mim foi conseguir ler os 12 livros. Nunca tinha lido tanto em um ano. Quando cheguei em outubro já tinha lido 8 livros mas achei que não conseguiria ler mais 4 até o final do ano. Achei que era muito! Bom, tive 2 conversas na mesma semana que me motivaram, uma com uma colega de trabalho que disse ler um livro por semana e outra com um colega que fiz no bar o HQBierman.  Comprei um Kindle com backlight para ler deitado antes de dormir, comecei a ir para a cama mais cedo e ler aos domingos e consegui. No último final de semana do ano eu consegui bater minha meta. Hoje me parece que 12 livros foi fácil, esse ano quero ler 16 livros.

Ler foi uma experiência ótima pra mim, foi uma conquista. Eu lembro de assistir uma TED Talk que o palestrante dizia que Líderes são Leitores (Leaders are Readers). Ler é fazer o download da experiência de outra pessoa para a sua cabeça. E não só os livros técnicos são bons para isso, mas qualquer um. Mesmo os livros que não gostei me ensinaram alguma coisa. Esses são os livros que li esse ano:

Quanto à outras metas, muitas não consegui bater por que foram metas idiotas. Jeff Sutherland criador do Scrum diz: Planejar é útil. Seguir cegamente os planos é estupidez. Quando eu decidi que correria 10 km , simplesmente não pensei que estou com condromalacia patelar e que não posso correr antes de ter perdido bastante peso e fortalecido os músculos das pernas. Também não senti tanta vontade de fazer aulas de tênis, simplesmente não quis arranjar tempo pra fazer isso, musculação e bike aos fins de semana estavam sendo legais o bastante pra mim. Até cheguei a procurar por aulas de bateria, mas quando vi os preços vi que não estava com tanta vontade assim.

Das outras metas, apesar de não tê-las concluído elas andaram e isso é ótimo! Estou matriculado em uma auto-escola, já tinha começado a fazer o curso de machine learning ( e assim acabei fazendo um outro curso de gerenciamento de projetos no Coursera)

Quanto ao casamento ainda não saiu, mas pude fazer um pedido à minha noiva em Paris:

Links interessantes:

Forget About Setting Goals. Focus on This Instead.

Ver no Medium.com

 

Guia para Deploy Django Python 3

crianças fazendo deploy

Tutorial de Deploy por aí é o que não falta, a maioria em inglês. Esse que estou criando é pra engrossar o caldo de deploys em português. Esse é um Guia Definitivo Rápido, ou não tão rápido, para fazer Deploy Django com Python 3. É um deploy para Kids.

A dificuldade de fazer um deploy reside nos detalhes. No fundo é fácil se você está familiarizado com as partes envolvidas. Você precisa saber fazer uma autenticação ssh, estar acostumado com a linha de comando, conhecer linux, saber configurar o projeto, entender o que é servir arquivos estáticos, gunicorn…. tá, tá… nunca é fácil e muito menos rápido, justamente por isso criaram um monte de ferramentas pra deploy. E hoje com Ansible, Docker e whatever kids are using these days fica fácil fazer o deploy mas muito abstrato entender o funcionamento.

Em alguns anos esse post será obsoleto pra sempre, com serverless e tudo mais acho que pouca gente vai querer saber como fazer um deploy django dessa forma. Mas, mesmo assim, se ajudar uma pessoa já está bom. Será um tutorial Old-Style.

O Servidor

Vou imaginar que você não tem um servidor, não tem uma conta na AWS, nem DigitalOcean, nem Linode, nada… Você pode criar uma conta em um deles, lançar uma máquina com as configurações que quiser (Na AWS é tudo mais complicado pra quem não está acostumado, se for sua primeira vez, prefira outro).

Pra esse tutorial estou falando de Ubuntu 16.04, que é o servidor que você mais vai ver por aí nesse momento nesses serviços. Você pode escolher um Debian qualquer também.

Configuração inicial

Configure o timezone do servidor

sudo locale-gen --no-purge --lang pt_BR
sudo dpkg-reconfigure tzdata

Atualize os pacotes:

sudo apt-get update 
sudo apt-get -y upgrade

Instalando Python 3.6 no lugar do Python 3.5

Agora substitua o Python 3.5 instalado, pelo Python3.6 (O Ubuntu que indiquei, ele vem com Python 3.5.1)

sudo apt-get update
sudo add-apt-repository ppa:jonathonf/python-3.6
sudo apt-get install python3.6
sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.5 1
sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.6 2

Você pode escolher qual versão do Python o SO vai usar ao chamar python3 com:

sudo update-alternatives --config python3

Se você se enrolar, dê uma olhada aqui.

Instale os requisistos do Sistema Operacional

Aqui tem alguns pacotes que eu sempre uso em um deploy.

sudo apt-get install python3-pip nginx supervisor git git-core libpq-dev python-dev 
python-virtualenv

Seu projeto pode ter outros requirements do SO pra instalar.

VirtualEnvWrapper para o Python3

Eu gosto muito do VirtualEnvWrapper, acho simples de começar um virtualenv, e deixa todos os meus virtualenvs no mesmo lugar, mas isso é escolha pessoal, se você não gosta, faça como está acostumado

Você instala o virtualenvwrapper, depois define a pasta dos seus virtualenvs (WORKON_HOME).

Para usar com múltiplos Pythons você vai precisar definir VIRTUALENVWRAPPER_PYTHON. No caso estou usando sempre o padrão que defini para o comando python3. Isso não é um problema porque você pode criar um virtualenv depois apontando qual python aquele virtualenv vai usar.

sudo pip3 install virtualenvwrapper
echo 'export WORKON_HOME=~/Envs' >> ~/.bashrc
echo ‘export VIRTUALENVWRAPPER_PYTHON=`which python3`’ >> ~/.bashrc
echo 'source /usr/local/bin/virtualenvwrapper.sh' >> ~/.bashrc
source ~/.bashrc

Crie seu VirtualEnv apontando qual python aquele virtualenv irá usar

mkvirtualenv nome_venv --python=python3

O VirtualEnvWrapper é muito fácil, para entrar em um Virtualenv que você criou, você pode usar:

workon nome_venv

Para sair do virtualenv:

deactivate

Para excluir um virtualenv:

rmvirtualenv nome_venv

Gere as Chaves SSH para autenticar no GitHub

Você não quer (e nem deveria) escrever a senha pra fazer o git pull do seu projeto no servidor.

Gere as chaves SSH

cd ~/.ssh
ssh-keygen -t rsa -b 4096 -C "[email protected]"
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

Veja e copie o conteúdo da sua chave pública (id_rsa.pub)

cat ~/.ssh/id_rsa.pub

Depois entre no seu github, em Settings > SSH and GPG Keys. Clique em New SSH Key, dê um nome pra essa chave, como (“chaves do servidor teste”) e em Key cole o conteúdo da chave pública id_rsa.pub

Faça o clone do seu projeto Django

Copie o link SSH do Github para fazer o clone, no caso estou usando um projeto que encontrei agora pra exemplo

git clone [email protected]:kirpit/django-sample-app.git

Entre na pasta do projeto e instale os requirements do projeto.

Lembre-se de estar no virtual env correto.

cd django-sample-app/
pip install -r requirements.txt

Agora faça as alterações que forem necessárias para o deploy django, como criar um arquivo de settings_local, banco de dados, ou qualquer outra coisa específica do seu projeto.

Depois de tudo certo, você ainda precisa rodar as migrações e gerar os arquivos estáticos (se estiver usando)

python manage.py migrate
python manage.py collectstatic

Configurando o NGINX

Nginx, assim como o Apache, tem um mundo inteiro só deles, nesse momento você precisa conhecer o básico.

Existe um diretório /etc/nginx/sites-available/ onde ficão os arquivos de configuração de sites disponíveis para o nginx servir e existe o diretório /etc/nginx/sites-enabled/ que é a mesmíssima coisa, mas o que estiver aqui o Nginx estará servindo mesmo.

Normalmente você cria o arquivo de configuração no sites-available/ e cria um link simbólico para o sites-enabled/

Nós vamos fazer isso. Primeiramente, vou excluir o site default do nginx

sudo rm /etc/nginx/sites-enabled/default

Agora crie o arquivo de configuração para o seu site. (Se você não está acostumado com o VIM, use troque vi por nano)

sudo vi /etc/nginx/sites-available/meusite

No conteúdo do arquivo, coloque isto, mudando os caminhos necessários:

server {
 listen 80;
 access_log /home/usuario/logs/access.log;
 error_log /home/usuario/logs/error.log;

 server_name nome-site.com.br;

 location / {
 proxy_pass http://127.0.0.1:8000; 

 #As proximas linhas passam o IP real para o gunicorn nao achar que sao acessos locais
 proxy_pass_header Server;
 proxy_set_header X-Forwarded-Host $server_name;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header Host $http_host;


 }

 location /static {

   alias /home/usuario/caminho_projeto/static/;

 }

}

Agora crie o link simbólico para o sites-enabled:

sudo ln -s /etc/nginx/sites-available/meusite /etc/nginx/sites-enabled/meusite

Reinicie o Nginx:

sudo service nginx restart


(Se você configurou tudo direitinho até aqui, ao acessar o site você verá uma página com um erro 502 Bad Gateway do próprio nginx)

Isso acontece porque ainda não tem nada aqui http://127.0.0.1:8000

Vamos colocar o site pra rodar nessa porta pelo gunicorn

Configurando o Gunicorn

Alguém vivo até essa parte? Cansa não, falta pouco.

No seu virtualenv (lembra workon nome_env?) instale o gunicorn

pip install gunicorn

Na pasta do seu projeto crie um arquivo chamado gunicorn_conf com:

bind = "127.0.0.1:8000"
logfile = "/home/usuario/logs/gunicorn.log"
workers = 3

Agora se você rodar o gunicorn, você vai ver seu site rodando:

/home/usuario/Envs/nome_venv/bin/gunicorn projeto.wsgi:application -c gunicorn_conf

Mas o que você pretende fazer? Rodar esse comando dentro de um screen e ir embora? Não dá né! Então, você vai usar o Supervisor pra controlar o funcionamento do gunicorn.

Configurando o Supervisor

Crie o seguinte arquivo de configuração

sudo vi /etc/supervisor/conf.d/gunicorn.conf

Com o seguinte conteúdo:

[program:gunicorn]
command=/home/usuario/Envs/nome_venv/bin/gunicorn projeto.wsgi:application -c /home/usuario/projeto/projeto_django/gunicorn_conf
directory=/home/usuario/projeto/projeto-django
user=usuario
autostart=true
autorestart=true
redirect_stderr=true

Depois é só avisar o supervisor que existe um novo processo que ele precisa controlar da seguinte forma:

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl restart gunicorn

E voilá! Um site rodando você terá!

Conclusão

Existem muito mais coisas envolvidas no processo de um deploy. Você precisa configurar um firewall, provavelmente precisará servir mais pastas estáticas, etc, etc, etc… Mas precisa começar por algum lugar.

Gostou? Me segue no insta

Populando um campo novo não-nulo no Django

Fala pessoal, esse é um post rápido no qual eu vou mostrar como popular uma migração criando um campo novo não-nulo no django

SAY WUUUUT?????

george costanza taking his glasses off

Seguinte, sabe quando você tem seu projeto rodando, banco de dados, models, front, em produção as porra tudo e então aparece um requisito novo e eis que surge um campo obrigatório, que ninguém pensou antes, nem o cliente, nem o product owner, nem ninguém! Essa é a situação!

Acontece que você usa as migrações do django e você quer que poder colocar esses campos usando os migrations, tanto migrando pra frente quanto pra trás, ok?

Chega de conversa, pra esse exemplo resolvi pegar um projeto pronto nas interwebz, acabei optando por um django polls feito em django 1.10 já pronto.

Então lá se vão os passos de sempre, clonar e criar virtualenv…

git clone [email protected]:garmoncheg/django-polls_1.10.git
cd django-polls_1.10/
mkvirtualenv --python=/usr/bin/python3 django-polls 
pip install django==1.10  # Nesse projeto o autor não criou um requirements.txt
python manage.py migrate  # rodando as migrações existentes
python manage.py createsuperuser 
python manage.py runserver

Obs: Esse projeto pronto que pegamos está com uma migração faltando, então se você estiver seguindo esse passo a passo rode um python manage.py makemigrations pra que seja criada a migração 0002 (que é só a mudança de um verbose_name)

Agora você acessa o admin (http://localhost:8000/admin/polls/question/add/) e cria o seu poll :

 

django polls admin
Aí você pode ir lá no app polls e ver sua pergunta, responder etc…
até aí OK, ainda não fizemos nada!

Bom, o ideal é criar mais umas perguntas com datas de publicação diferentes para a brincadeira
ficar boa.

Depois de começar a usar você vai perceber que qualquer enquete fica infinita no seu site, ou seja, todas as vezes que alguém entra no site ele tem a oportunidade de votar, você nunca encerra a votação.

Então nossa alteração no código será a seguinte: De agora em diante, todas as enquetes terão uma data de expiração. No momento do cadastro o usuário poderá colocar a data na qual a votação se encerrará e o usuário será direcionado diretamente para o resultado. Queremos que essa data de expiração seja um campo obrigatório! E para os que já estão funcionando na plataforma vamos determinar arbitrariamente que cada um tenha um mês de validade a partir da data de publicação.

Antigamente, antes de migrações como isso era feito em qualquer sistema? Via SQL você criava um campo que permitisse NULOS, depois você criava uma query que populava esse campo e por fim você alterava a tabela pra tornar aquela coluna obrigatória. Com as migrações é a mesma coisa.

Então vamos criar o campo novo nos models vou chamá-lo de expires_date:

expires_date = models.DateTimeField(‘expires at’, null=True)

E o model inteiro fica assim:

class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')
    expires_date = models.DateTimeField('expires at', null=True)

    def __str__(self):
        return self.question_text

    def was_published_recently(self):
        now = timezone.now()
        return now - datetime.timedelta(days=1) <= self.pub_date <= now
    was_published_recently.admin_order_field = 'pub_date'
    was_published_recently.boolean = True
    was_published_recently.short_description = 'Published recently?'

Agora vamos criar a migração dessa mudança:

python manage.py makemigrations

E ele criará a migração 0003_question_expires_date. O conteúdo é o seguinte:

class Migration(migrations.Migration):

    dependencies = [
        ('polls', '0002_auto_20170429_2220'),
    ]

    operations = [
        migrations.AddField(
            model_name='question',
            name='expires_date',
            field=models.DateTimeField(null=True, verbose_name='expires at'),
        ),
    ]

 

Vamos modificar o código dessa migration, NO PANIC!

Populando o novo campo

Primeiro criamos uma função para popular o banco com as datas de expiração:

def populate_expires_date(apps, schema_editor):
    """
    Popula o campo data de expiração das perguntas já existentes colocando um mẽs de validade para cada.
    """
    from datetime import timedelta

    db_alias = schema_editor.connection.alias
    Question = apps.get_model('polls', 'Question')

    for row in Question.objects.using(db_alias).filter(expires_date__isnull=True):
        row.expires_date = row.pub_date + timedelta(days=30)
        row.save()

Originalmente usei esse código em um projeto que utiliza múltiplos bancos de dados, então precisei usar o db_alias e achei interessante deixá-lo aqui. Quanto ao Question, estou dando um import desse model usando o apps.get_model pois nesse momento que estamos rodando a migração o campo ainda não existe para o projeto, pois a migração não acabou de rodar, então é melhor que importar do model.

Agora, dentro da migração existe uma lista chamada operations. Nessa lista vamos adicionar os comandos para rodar a nossa função e em seguida, vamos adicionar a obrigatoriedade do campo: ficando dessa forma:

operations = [
    migrations.AddField(
        model_name='question',
        name='expires_date',
        field=models.DateTimeField(null=True, verbose_name='expires at'),
    ),
    migrations.RunPython(populate_expires_date, reverse_code=migrations.RunPython.noop),
    migrations.AlterField(
        model_name='question',
        name='expires_date',
        field=models.DateTimeField(verbose_name='expires at'),
    )
]

Você pode ver que utilizamos o migrations.RunPython para rodar nossa função durante a migração. O reverse_code serve quando alguém for dar um unapply da migração, nesse caso não existia o campo, então não faremos nada.

Logo em seguida adicionei a migração que altera o campo e ele deixa de ter null=True. Também poderíamos ter feito isso em outra migração, só retirando essa informação do model (que precisa ser retirada agora de qualquer forma) e ter criado uma nova migração.

O model ficará assim:

class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')
    expires_date = models.DateTimeField('expires at')

    def __str__(self):
        return self.question_text

    def was_published_recently(self):
        now = timezone.now()
        return now - datetime.timedelta(days=1) <= self.pub_date <= now
    was_published_recently.admin_order_field = 'pub_date'
    was_published_recently.boolean = True
    was_published_recently.short_description = 'Published recently?'

agora você pode rodar o migrate tranquilamente:

python mange.py migrate

Pronto! Pra ver as alterações vou adicionar esse campo no admin, tanto para ser editado como no list_display:

class QuestionAdmin(admin.ModelAdmin):
    fieldsets = [
        (None,               {'fields': ['question_text']}),
        ('Date information', {'fields': ['pub_date', 'expires_date'], 'classes': ['collapse']}),
    ]
    inlines = [ChoiceInline]
    list_display = ('question_text', 'pub_date', 'expires_date', 'was_published_recently')
    list_filter = ['pub_date']
    search_fields = ['question_text']

E voilá, todos as Questions que você tinha no polls contam com um expires_date, obrigatório e com 30 dias adicionado por default para as Questions antigas.

É isso aí, agora tem esse campo que queremos! O projeto com as alterações está aqui: https://github.com/ffreitasalves/django-polls_1.10

Se gostou, compartilhe com os amigos e deixe um comentário. Se não gostou também! Abraços!

 

Fontes:

http://stackoverflow.com/questions/28012340/django-1-7-makemigration-non-nullable-field

http://stackoverflow.com/questions/29217706/django-view-sql-query-without-publishinhg-migrations

https://realpython.com/blog/python/data-migrations/

https://docs.djangoproject.com/en/1.10/howto/writing-migrations/#non-atomic-migrations

O que aprendi gerenciando 3 produtos em 2016

Há exatamente um ano eu fiz um balanço sobre como foi o meu 2015 e como saí de uma fase de total esgotamento para a empolgação com uma empresa que estava nascendo. Atendendo a pedidos (Meu pai queria ler a continuação, huahuahua) resolvi contar de forma breve(?) como foi esse ano pra mim, pra minha carreira e o que aprendi gerenciando 3 produtos diferentes na mesma empresa.

Sobre os Desafios e Conquistas:

No ano passado(2015), consegui entregar o LegalNote. Começou pequeno, como deveria ser, afinal era só um MVP e precisávamos validar se existia mercado pra ele, se os advogados teriam interesse em um produto minimalista para controle de processos. Diversas vezes aplicamos os brilhantes métodos do Lean Startup do Eric Ries e quando se fala de Lean Startup necessariamente se fala do ciclo Build – Measure – Learn (tradução livre: Construir – Medir – Aprender)

Rapidamente aprendemos que nossos clientes precisavam que nós expandíssemos nossos robôs (doravante crawlers) para todos os tribunais do Brasil e todos os diários oficiais.

Como missão dada é missão cumprida, começamos o ano com a difícil tarefa de expandir nossos horizontes sobre fontes de informação pública. Se você já precisou algum dia buscar qualquer coisa que seja em um órgão público deve ter xingado o site algumas vezes. Pois é, o desafio de acessar sites do governo para estruturar e dar inteligência àquelas informações, tentar buscar padrões, trabalhar com dados nada estruturados é uma dor de cabeça. Se você quer que as coisas fiquem fáceis para o seu cliente, elas terão que ser difíceis pra você. Muitas partes em movimento, sites que podem mudar de uma hora pra outra e quebrar o seu crawler, mudança de padrões que podem quebrar seus RegEx, etc… Mas conseguimos. Nossa primeira fase de expansão sobre tribunais e diários oficiais foi um sucesso…

… Mas com grandes poderes vem grandes responsabilidades. Ao longo desses anos trabalhando com startups me aprimorei em uma técnica pra atrair clientes com SEO. Usei pela primeira vez em 2013 e naquela época conseguimos alcançar clientes sem verba de marketing. Agora em 2016 usamos a mesma técnica e o resultado veio muito rápido. Muitos clientes e muitos processos.  Para vocês terem uma ideia, essa é a imagem que foi postada no Blog do LegalNote com os números da empresa em 2016:

O que aprendi gerenciando 3 produtos em 2016 - Fernando Alves

E pra todo número grande que você vê aí, tivemos um desafio de infra-estrutura. Desafios de escalabilidade, provisionamento de instâncias, controle e gerenciamento de filas, performance de banco de dados, monitoramento, performance de buscas, milhões de tasks, alta carga de emails e mais…

O bom é que todo problema traz consigo uma oportunidade pra aprender. Aprendi muito esse ano, muito mesmo, muito sobre performance, sobre escalabilidade, sobre AWS e principalmente sobre gerenciamento. Quando você é um chefe muito técnico existe uma grande possibilidade de você focar em desenvolver, afinal você é um cara mão-na-massa, mas na maioria das vezes isso não é o melhor pra você, nem para sua empresa. Você como gestor precisa o tempo todo facilitar para que as pessoas ao seu redor se desenvolvam. E o grupo sempre vai chegar mais longe que você, não importa quão bom você seja. Você precisa usar o seu conhecimento para alavancar a produtividade e o conhecimento das outras pessoas. Elas precisam melhorar o tempo todo e você também (Por isso fiquei emocionado ao ver a retrospectiva de final de ano de um cara brilhante que trabalha com a gente e ter lido a retrospectiva dele do ano passado)

Facilitar para que as pessoas se desenvolvam envolve:

  • Aumentar gradualmente o desafio que elas devem resolver
  • Estar disponível para conversar e tirar dúvidas
  • Se livrar dos impedimentos
  • Ouvir muito
  • etc

Só o que tenho aprendido como gestor dá mais alguns posts que prometo escrever esse ano.

Voltando ao ciclo, junto ao crescimento do LegalNote nós lançamos o Diligeiro. Primeiro a API ficou pronta, depois veio o lançamento do aplicativo Android, do WebApp e no segundo semestre lançamos o app para iOS

gerenciando-produtos-lançamento-diligeiro-ios
Almoço de lançamento do Diligeiro para iOS

Produto diferente, desafios diferentes. Logo aprendemos que os usuários queriam um chat in-app. Que foi a primeira feature a ser desenvolvida com o app já em funcionamento. Ficou tão legal, que outro dia mostrando para um pessoal no DevBeers tive que ouvir um “que é isso? é o Whatsapp?”

E foi através do Diligeiro que tive uma das minhas experiências mais gostosas como empreendedor. Há alguns meses precisei ir para Belo Horizonte participar de uma audiência. E conhecem aquela frase americana: Eat your own dog food, então a advogada que ia participar da audiência comigo na cidade foi contratada pelo aplicativo. Tudo correu bem, fomos à audiência e depois de sair do fórum a advogada me disse que estava praticamente só trabalhando como correspondente e utilizava o Diligeiro pra trabalhar. ( Explicando sucintamente: O Diligeiro é o Uber pra correspondentes jurídicos). Um mês depois recebi a decisão do Juiz através do LegalNote. Viagem completa dentro dos produtos da própria empresa, levantei comemorei, todo mundo bateu palma e a sensação que eu tive foi de uma vitória muito grande. E o diligeiro tem novidades por aí…

Caramba, ainda não parei de escrever…mas vamos lá. Dezenas de Milhares de pessoas físicas começaram a querer usar nossa ferramenta para advogados! Então porque não dar a essas pessoas o que elas querem?

gerenciando-produtos-shut up and take my money

Assim começamos a desenvolver um novo produto e lançamos agora no final do ano. É o SeuProcesso.com. Um court monitor para pessoa física.

Nossa corujinha

Ano que vem vocês ouvirão eu falar muito mais sobre o SeuProcesso.com

E como nem só de trabalho viverá o homem, pessoalmente esse ano foi incrível pra mim. Fiz o meu primeiro mergulho e foi uma das experiências mais extraordinárias que já tive. Viajei sozinho, fiz longas trilhas só ouvindo a natureza, fui em muitos parques, nadei, cantei, dormi, chorei. Li um livro que mudou minha vida (The Will Power Instinct) pq foi através dele que comecei a praticar meditação diariamente e o simples fato de sentar e respirar me deixa mais tranquilo, mais consciente de como estou me sentindo e olha que a vida inteira eu achava que isso era bullshit, só tentei dar uma chance ao HeadSpace pra começar a gostar e sentir diferença na minha vida. E o principal de tudo…foi o ano do Guanciale

Muito obrigado, 2017 tem mais!

Celery com múltiplas filas, retry e tarefas agendadas

No ano passado eu escrevi um post sobre Tarefas demoradas de forma assíncrona com Django e Celery, que serve para a maioria dos casos de uso do celery. O problema é que você pode querer e fazer muito mais com o celery, como ter filas diferentes para tarefas prioritárias, executar um retry após a falha de uma tarefa ou agendar a tarefa para ser executada apenas em outro horário ou outro dia.

Retry em uma Tarefa

Suponhamos que isso seja uma caveira que sua tarefa depende de uma API externa, conexão com algum site ou algum outro motivo que possa levá-la a um ConnectionError, por exemplo.

É provável que dentro de alguns instantes a API, site, etc. esteja no ar e que se você executar sua tarefa novamente ela funcione. Para isso podemos agendar um retry para esta tarefa:


from celery import shared_task
 
@shared_task(bind=True, max_retries=3)
def acessar_sistema_horrivel(self, meu_objeto_id):
    from core.models import MeuObjeto
    from requests import ConnectionError
 
    objeto = MeuObjeto.objects.get(pk=meu_objeto_id)
 
    # Se tiver ConnectionError tenta de novo em 180 segundos
    try:
 
        objeto.acessar_sistema_horrivel()
  
    except ConnectionError as exc:
        self.retry(exc=exc, countdown=180)

Interessante que dentro de uma função você está usando self.retry. Isso é possível graças ao bind=True no decorator do shared_task, que faz com que nossa função acessar_sistema_horrivel seja na verdade um método da classe Task. Isso nos obriga a colocar self como primeiro argumento da função também.

O número máximo de tentativas para executar essa tarefa é o max_retries=3 definido no decorator

ETA – Agendando a tarefa para começar mais tarde

Agora o cenário é o seguinte, seu sistema vai chamar uma tarefa assíncrona, mais quer que ela seja executada apenas daqui a uma hora.

Para isso podemos chamar a task setando a propriedade ETA (estimated time of arrival) e isso significa que sua tarefa só será executada depois daquele horário (não necessariamente para começar aquele horário, isso vai depender se você possui workers disponíveis, para agendar exatamente como no cron você pode usar o CeleryBeat) .

 


from django.utils import timezone

agora = timezone.now() 
 
# Depois é daqui a uma hora 
#(usei o replace pq quis mostrar, mas vc poderia usar o timedelta para somar também)
depois = agora.replace(hour=agora.hour + 1)
 
acessar_sistema_horrivel.apply_async((meu_objeto_id), eta=depois)

Colocando mais de uma fila de execução

Quando você executa o celery ele cria uma fila no seu broker (no caso do post anterior, era o RabbitMQ). A fila padrão chama celery. Qual a implicação? Se você possui várias tarefas assíncronas a serem executadas ficam todas na mesma fila, das qual os workers vão pegar as mensagens e executar.

Imagine que temos além da task acessar_sistema_horrivel, uma outra task chamada tarefa_demorada.

Então dado o seguinte cenário:

3 tarefas: uma lenta e uma mais rápida e a acessar_sistema_horrivel
1 fila
4 workers

E imagine que o sistema produziu 10 requisições da tarefa_demorada para serem executadas e em seguida produziu mais 10 da outra tarefa. O que vai acontecer? Seus workers ficarão todos ocupados buscando executando as requisições de tarefa_demorada que entraram primeiro e nenhum estará trabalhando na tarefa mais rápida.

A solução para isso é produzir filas diferenciadas para as tarefas prioritárias.


# CELERY ROUTES
CELERY_ROUTES = {
    'core.tasks.acessar_sistema_horrivel': {'queue': 'fila_horrivel'},
    'core.tasks.tarefa_demorada': {'queue': 'fila_demorada'},
    'core.tasks.tarefa_mais_rapida': {'queue': 'fila_rapida'},
}

Isso é suficiente para que as mensagens para essas tarefas sejam enviadas para essas filas do RabbitMQ. Detalhe, essas filas são criadas de forma permanente no RabbitMQ, mas isso também pode ser configurado.

Agora para rodar os consumidores para essas filas quando formos executar o celery podemos definir com o parâmetro -Q. No caso fica assim:


celery --app=nome_projeto worker -Q fila_horrivel,fila_demorada,fila_rapida --autoscale=10,5

Estamos iniciando os workers para todas essas filas. Neste caso estou colocando também o parâmetro autoscale, indicando para trabalhar com no mínimo 5 workers e caso haja muitas tarefas o celery adiciona mais workers até o máximo de 10. Isso é bom para economizar recursos do seu sistema, caso você tenha horários com mais produção de tarefas.

Como mostramos no outro post, para usar isto sob o supervisord, você pode modificar aquele mesmo script


[program:celery]
command=/home/deploy/.virtualenvs/meu_virtual_env/bin/celery --app=nome_projeto worker -Q fila_horrivel,fila_demorada,fila_rapida --autoscale=10,5
directory=/home/deploy/webapps/projeto_django
user=nobody
autostart=true
autorestart=true
redirect_stderr=true

Em seguida rodar o reread e o update, porque o arquivo de configuração mudou e reiniciar o supervisord para esse arquivo.


sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl restart gunicorn

Com isso seus workers vão executar tarefas de cada uma das filas, não travando os workers para só um tipo de tarefa. Há diversas outras formas de colocar seus workers para funcionar.

Chamando Tarefas Sequenciais

Outro problema comum, é precisar chamar duas tarefas assíncronas , uma depois da outra. Isso pode acontecer em diversos cenários, ex: o caso de a segunda tarefa receber como parâmetro o resultado da primeira, ou da primeira tarefa salvar algum dado e a segunda tarefa trabalhar aquele dado, etc…

Para isso nós podemos usar o Chain, que é o recomendado ao invés de chamar a segunda tarefa assíncrona com o delay dentro da primeira tarefa.


from celery import chain
from tasks import salvar_dados, trabalhar_dados
 
# Estamos chamando o método s das tasks, que as usa como subtasks de uma task gerada pelo chain.
chain(salvar_dados.s(meu_objeto_id) | trabalhar_dados.s())

A tarefa trabalhar_dados vai utilizar o return ou resultado da tarefa salvar_dados como parâmetro.
O chain em sí está gerando uma task, então para ele também serve chamar o apply_async com um eta definido, por exemplo:


chain(salvar_dados.s(meu_objeto_id) | trabalhar_dados.s()).apply_async(eta=depois)

Ignorando os resultados do ResultBackend

Se você só usa as tasks para executar alguma coisa que não precisa do return da task, você pode ignorar o ResultBackend e ter um ganho de performance.

A maioria dos casos não precisa guardar o resultado do return, então é só uma dica interessante se você já está salvando algo nos models, ou fazendo whatever diretamente dentro da sua task, coloque isso no seu settings.py:


CELERY_IGNORE_RESULT = True

 

Na verdade tem muito mais coisas legais no Celery, que ficarão pra um próximo post.

Fontes

http://docs.celeryproject.org/en/latest/userguide/tasks.html

http://docs.celeryproject.org/en/latest/userguide/optimizing.html#guide-optimizing

https://denibertovic.com/posts/celery-best-practices/

https://news.ycombinator.com/item?id=7909201

http://docs.celeryproject.org/en/latest/userguide/workers.html

http://docs.celeryproject.org/en/latest/userguide/canvas.html

 

Super Bônus

Celery Messaging at Scale at Instagram – Apresentação Pycon 2013