É horrível trabalhar em startup

“É horrível trabalhar em startup”

Há 10 anos, quando comecei a saga das startups na minha vida eu ouvi muito isso e normalmente junto da frase “bom mesmo é trabalhar em empresa grande” ou a clássica “a melhor coisa é prestar um concurso público”.

As pessoas não poderiam estar mais erradas. Acho que o grande desafio que você tem na carreira está em gerar um impacto gigantesco e VER que você consegue mudar a sociedade através do seu trabalho.

Em uma empresa gigante, você consegue fazer isso, mas entrevistando pessoas que estão nessas empresas vejo que elas perdem a visão do impacto que geram, pois trabalham em times enormes e enfrentam muitas burocracias.

Numa startup, os times são menores, você veste mais chapéus, você faz as coisas de ponta a ponta. Com certeza você termina seu dia mais cansado, mas tenho certeza absoluta que você termina seu dia tendo aprendido muito mais e tendo prazer em trabalhar.

Você pode não concordar e ok, cada um sabe o que é melhor pra si. Mas se você está infeliz no seu trabalho, deveria tentar trabalhar numa startup e redescobrir o impacto que você pode causar na vida das pessoas.

Dá uma olhada nessa foto da startup e e me segue no insta!

Por que é importante entender a filosofia do facebook?

Se eu disser que perfeccionismo é só disfarce para medo e pra não agir, como diz Gary V, é capaz de você ficar reativo e pensar em um comentário contrariando mas desistir no meio, por não conseguir escolher as melhores palavras para usar

Estou pintando um cenário no qual o perfeccionista é um procrastinador, mas muitas vezes é apenas alguém querendo garantir tudo funcionando bem, sem riscos. O ruim é fazer isso quando os riscos só moram na sua cabeça e não estão nem perto dos riscos do mundo real. Por isso, as pessoas abandonam seus projetos, pois nunca estarão bons o bastante para serem lançados

Mas, imagine o que faria se não tivesse medo. Essa frase estava em um poster no escritório do Facebook ao lado da famosa “Move Fast and Break Things”. Um conceito forte que incomoda muita gente, mas precisa ser olhado dentro do contexto de uma startup

Sou um cara que tirou várias startups do chão, do zero, a partir de nada além da ideia e mesmo eu, que nunca fui perfeccionista, tive dificuldade para fazer um produto “incompleto”, colocar na mão do cliente e ainda cobrar por isso. Dá uma vergonha, como se ele fosse pensar “é esse tipo de profissional que você é?”

Mas lançar uma startup é uma corrida contra o tempo. É como se você começasse a empresa tentando escapar de um carro submerso, você precisa encher os pulmões, quebrar a janela e tentar se debater com roupas, cinto de segurança e um arrasto enorme até conseguir emergir vários metros acima e respirar novamente. Isso significa que se você não fizer um bom trabalho rápido, você vai morrer. Sua startup vai. E para um fundador pouco importa se é a startup ou ele quem morre, pois são uma coisa só

Move fast and break things é a filosofia perfeita para uma nova startup. Você precisa estar disposto a quebrar o vidro e deixar suas roupas para trás pra subr rápido para a superfície. Você precisa aprender rapidamente. Lançar vai te fazer aprender e se reposicionar no caminho certo

Claro que ir rápido e quebrar coisas não é pra qualquer contexto. Depois de 10 anos, o FB mudou para “Move fast with stable infra”. Não tem o apelo da anterior, mas com bilhões de dólares de clientes em jogo, é bom garantir tudo funcionando

Polêmica: Salários de desenvolvedores de Software

Se juntar a capacidade de ganhar dinheiro em tech com a facilidade da profissão para exercer trabalho remoto, você tem o cenário ideal para ter uma boa receita e viver em lugares com custo de vida mais em conta.
Enquanto isso as empresas estão cada vez mais preocupadas pois é certo que vai faltar mão de obra qualificada em breve.
Não sei quanto vocês aqui acompanham o twitter, mas quando eu entro lá parece que é um mundo sombrio e paralelo.
Você concorda que tech paga os melhores salários do mercado hoje em dia? Deixe aí sua opinião

Foco naquilo que dá pra mudar. Sempre! Claro que bons líderes, te impulsionam, te mostram oportunidades e te ajudam a se desenvolver, mas o poder de chegar lá é sempre seu. Se você não tem alguém que te ajude hoje, procure um lugar que tenha.

O que fazer quando seu chefe é ruim?

Imagine que sua equipe está performando mal, um culpa ao outro o tempo todo, o chefe culpa a equipe e vice-versa, ninguém está feliz de trabalhar ali, ninguém está entrosado. O que acontece se trocar o líder e colocar alguém melhor no lugar?

Tem uma história sobre duas equipes no treinamento dos Navy Seals. Uma delas estava em primeiro lugar e a outra equipe estava em último, 13 posições depois.

A primeira equipe trabalhava muito bem junta, estava animada e tinha muito entrosamento.

Porém, a última estava como a equipe que eu descrevi no primeiro parágrafo. Estava péssima, performando mal, sem confiança, brigando um com o outro.

Então o comandante, responsável pelo treinamento, resolveu trocar os líderes das equipes que estavam em primeiro e em último lugar.

Já ouviu aquela frase de que não existe equipe ruim, só líder ruim? Por quê se o líder for bom ele dá um jeito da equipe ser boa também? Pois bem, a equipe que estava em último lugar quando trocou o líder pelo melhor líder saiu da última posição para ir brigar pela primeira. Mas não quero focar no líder que era bom, quero saber o que aconteceu com o líder que era ruim.

Quando o líder ruim entrou na equipe boa, ela continuou indo bem, porque ele era ruim, mas a equipe não e uma equipe boa pode influenciar um líder ruim.

Não importa se você está em uma posição de liderança ou não, o fato é que pessoas boas transformam pessoas ruins em boas também.

É difícil? Claro que é, como tudo aquilo que vale a pena. Mas tenho certeza que você pode influenciar mudanças positivas por onde quer que você passe.

Post original no instagram, me segue lá:

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

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.

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: