Categorias
Crônicas

Retrospectiva 2017

Ao final de cada ano, desde 2015, comecei uma pequena tradição inspirada pelo meu amigo e chefe Fernando Freitas Alves. Escrever uma retrospectiva do ano que passou.

Talvez a parte mais importante seja parar para pensar em tudo que aconteceu. Minha grande motivação para escrever em 2015 foi o fato de que aquele ano me ensinou mais do que qualquer outro em toda a minha vida.

Já a retrospectiva de 2016 mostrou que ano passado foi de estabilização no trabalho e na vida pessoal. Apesar de não ter muitos avanços na parte da saúde, uma das metas que continuei tendo em 2017.

Como sempre faço em minha vida, em 2017 experimentei diversas maneiras de me manter em uma rotina mais saudável. Tentei algumas novas atividades físicas, como o Crossfit por exemplo, e infelizmente não consegui dar continuidade como deveria.

Também me arrisquei em técnicas de jejum intermitente para perda de peso e melhora da atividade cerebral… sem sucesso.

Graças a mais um ano de falhas na área da saúde percebi que preciso dar uma importância maior para este tópico na minha escala de metas para 2018. O primeiro passo já foi dado: horário marcado na nutricionista já para janeiro.

Mas tive uma pequena conquista nesse ano. Foi agora, bem no finalzinho, em dezembro mesmo. Foi uma amostra de que posso atingir algo se me esforçar um pouco. Parei de roer unhas! Graças a um aplicativo chamado Coach.me.

Roer unhas era um hábito que estava difícil de largar e por isso resolvi usar como um experimento desse aplicativo. Acredite se quiser, estou sentindo as unhas batendo nas teclas neste exato momento como há anos não sentia. Um pequeno passo, mas uma grande prova de que posso conseguir mudar alguns hábitos em 2018, certo?

Outra pequena conquista desse ano foi o café sem açúcar. Sempre tomei café muito doce, mas com a ideia do jejum intermitente veio a necessidade de tomar café ao natural.

O primeiro dia sempre é estranho. Você faz careta a cada gole, mas no dia seguinte eu já estava sentindo o gosto de diferentes tipos de café que temos disponíveis lá no escritório e decidindo os que realmente são do meu gosto.

No trabalho, que nos ocupa boa parte do tempo dentro de um ano, 2017 se mostrou estável. Continuo trabalhando como desenvolvedor na startup de legal tech Tikal Tech.

Com o lançamento de uma nova linha de produtos na empresa as coisas aconteceram rápido. Este foi o ano do ELI na Tikal Tech.

Graças ao desenvolvimento do ELI ICMS Energia tivemos uma experiência muito produtiva com arquitetura de microsserviços. Além de outras integrações interessantes como o Login Integrado do LegalNote para aplicativos ELI. Um sistema de gestão de acesso de usuários centralizado para diferentes aplicativos em Django.

Antes disso, mais pro início do ano, tive o prazer de participar da comunidade Chatbot Brasil. Até criei alguns chatbots e coloquei algum conteúdo por aqui sobre o assunto. Já na Tikal Tech implementamos o chatbot Corujinho na fanpage do SeuProcesso no Facebook. Foi uma experiência bem interessante.

Com o crescimento da empresa tivemos um aumento considerável no staff. Basta ver a  foto do pessoal na retrospectiva de 2015 e notar como as coisas mudaram! Veja a foto da equipe nesse ano.

Equipe Tikal Tech 2017

Falando em trabalho não posso esquecer das minhas férias. Este foi uma das grandes metas desse ano. Aproveitei  maravilhosos 30 dias de viagens e descanso merecido depois de muitos e muitos anos sem tirar férias.

O ponto alto foi a primeira semana em que eu e minha namorada passamos alguns dias em Paraty. Que lugar maravilhoso para aproveitar natureza, os locais históricos e, é claro, as praias e os passeios de barco. Que delícia!

Financeiramente 2017 também foi um ano muito bom para mim, pelo menos comparados aos últimos dez anos de perrengues e problemas para manter um orçamento estável. Graças à liberação do FGTS inativo consegui quitar algumas dívidas e até mobiliar um pouco minha vazia casa.

Mas o que realmente está fazendo a diferença é o estudo de finanças pessoais. Durante esse ano inteiro investi um bom tempo nesse tópico, seguindo canais de Youtube interessantes como o do Gustavo Cerbasi e o Me Poupe!, os quais indico muito a quem quer começar a sair do buraco.

Graças a isso, posso até começar a pensar em investir algum dinheiro para 2018. Nem que sejam apenas alguns trocados. A meta é montar uma reserva de emergência o quanto antes!

Para terminar, algo legal que voltei a fazer: desenhar.

Desenho desse ano! Yey!

Nesse ano de 2017 eu voltei a desenhar e até alimentei o meu canal que fala sobre criação de histórias em quadrinhos no Youtube. Separei os tópicos que falam sobre isso aqui no meu blog para um novo domínio separando assim os conteúdos.

Criei também um Instagram e voltei a alimentar a minha velha fanpage no Facebook.

Sempre adorei desenhar histórias em quadrinhos e manter um hobby divertido como esse é algo essencial para a qualidade de vida de qualquer um. Me fez um bem danado!

Participei pela primeira vez de um Inktober! Se quiser entender melhor o que é isso, é melhor dar uma lida na publicação que fiz no meu blog de desenho.

Bem, por cima esse foi o meu ano de 2017. Essa retrospecitva vale mais para quem escreve do que para quem lê, porque a parte mais legal é repassar o ano na sua cabeça. Rever o que foi feito e pensar em como melhorar no ano seguinte.

Se você leu até aqui, obrigado! Deixe seu comentário sobre como foi seu ano também!

Um abraço e até 2018!

Categorias
Tecnologia

Primeiros passos com o GIT

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

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

Vamos à um exemplo bem simples.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

cd /Project/joaoecarlos/

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

git init

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

git push origin master

Vamos analisar esse comando…

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

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

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

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

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

git pull origin master

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

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

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

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

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

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

Postado originalmente no Medium.