Como organizar commits... com emoji!

XKCD comic

https://xkcd.com/1296/

Este artigo assume algum conhecimento prévio sobre Git e sistemas de gestão de versões.

Só porque sou hipster, vou começar a marcar os meus commits com emoji. Assim, ao analisarem um símbolo à esquerda, já sabem que tipo de commit é!

  • :wrench: (‘:wrench:’) Resolução de algum bug ou problema
  • :warning: (‘:warning:’) WorkInProgress?
  • :pencil: (‘:pencil:’) Algo relacionado com conteúdo textual (uma mensagem numa página ou uma label?)
  • :book: (‘:book:’) Atualização de documentação
  • :email: (‘:email:’) Algo relacionado com e-mail
  • :sunglasses: (‘:sunglasses:’) Estilização de componentes

Uh… contexto?

Não é por acaso que, dentro do sistema de revisão/versioning Git, toda a revisão (commit) requer uma mensagem. Afinal de contas, qualquer alteração ao código de um projeto deve ser justificada, e é de esperar uma descrição para a mesma. Como é que vou aprovar ou inverter uma alteração da autoria de outrém se não souber o motivo por detrás dela?

É, portanto, de esperar que existam pessoas com uma justificada preocupação pelo modo como estas mensagens são escritas (como este senhor, ou este senhor, ou este senhor).

Alguma vez ponderaste definir uma estrutura básica para uma mensagem relativa a um commit? Quiçá, para que seja possível analisar e rever o histórico de um projeto e das suas alterações? Ou mesmo apenas para reforçar alguma disciplina numa equipa desorganizada?

Metas do Programador - Parte 1

Existe, em diversos contextos profissionais, uma lista ‘virtual’ de metas que deverão ser atingidas por um trabalhador para este ser considerado ‘senior’. Digo ‘virtual’, isto porque nunca li um documento que reunisse todas estes supostos ‘feitos’… apenas tenho conhecimento deles por causa das frequentes situações laborais onde nos deparamos com um veterano a citar algo do género

Não serás um verdadeiro x até fazeres y

Segue-se uma lista, então, de tudo aquilo que considero ser tudo aquilo que um web developer deve fazer para ser reconhecido como um ninja da web… ou não, pois afinal de contas nem ‘senior’ sou *cofcof!

  • Correr um programa à primeira — esta aplica-se a tudo!
  • Atualizar um projeto com repositório remoto sem fazer o extremamente genérico git pull
  • Fazer um git rebase e não destruir nada (e sem conflitos)
  • Melhor ainda, fazer um git rebase tendo perfeita consciência do que está a fazer
  • Escrever um script considerado útil e com pelo menos 100 linhas de código em vim
  • Melhor ainda, construir uma aplicação web completa usando apenas vim… nada de editores de texto avançados ou IDEs!
  • Fazer qualquer trabalho em vim… ser um verdadeiro vi-ninja!
  • Ler um ‘reconhecido’ livro de programação a 100%… — admitam, só leram 10, se tanto, até fazer de pisa-papéis!
  • Trabalhar em conjunto com um designer para definir nomes comuns para componentes web — que nome se dá àquela coisa que combina uma imagem de fundo e texto no meio dela? Hero?
  • Trabalhar com dois cursores de rato — because why not?

Entretanto, espero ir atualizando esta lista com mais tarefas dignas de um hardcore… ou seja lá qual for a palavra hipster que se usa agora para definir ‘exemplo profissional a seguir e respeitado por colegas a nível local, nacional ou mesmo internacional’!

Hino ao Fail Stack

  • O fail-stack developer é aquele que sabe um pouco de muito… que na prática significa que sabe muito de nada!
  • O fail-stack developer é aquele que entra numa corrida até 8 pessoas e chega sempre em 4º lugar

O Fail-stack developer

A web é um ambiente complicado porque envolve diversas tecnologias: se deixares de lado uma boa parte delas, corres o risco de não conseguir montar um negócio sozinho, mas a alternativa é, na minha opinião pessoal, bem pior…

Em termos da web, existem duas especialidades gerais nas quais podem ser inseridas praticamente qualquer web developer:

  • Front-end developer
  • Back-end developer

Front-end

O Front-end-er é aquele que se especializa nas linguagens universais da web, e que são interpretadas pelos vossos browsers: html para estruturação de páginas/componentes, css (para estilização dessas mesmas páginas e/ou componentes), e o agora-omnipresente JavaScript, a linguagem de programação da Web. É este indivíduo que irá passar dores de cabeça a converter designs photoshop e desenhos em verdadeiros aglomerados de barras de navegação, painéis e imagens de destaque com um título. Possivelmente, é nas artimanhas, pequenos detalhes e animações que o Front-ender passa o seu tempo… Isto é, quando não está a tentar perceber o porquê do seu fantástico botão não apresentar bordas redondas num iPhone 3! Ou então o porquê daquele formulário todo personalizado e xispeteó — sim, a palavra existe! — não funcionar bem no Firefox desatualizado do avô do tio do teu malvado irmão gémeo!

A menos que este tenha veia de programador e se especialize numa das mais confusas linguagens de programação de sempre, o trabalho do front-end developer é próximo (mas não semelhante) ao de um designer, ao envolver conceitos de usabilidade e implementação de interfaces para a web. Este apenas usa o tal ‘JavaScript’ quando estritamente necessário e para desenrascar interações com os DOM (porque é hipster usar o termo neste tipo de temas). Caso contrário, é bem provável que este se preocupe mais com ‘oganização de código-fonte’ e repita constantemente termos como React-js, Angular-js e outros tantos terminados em jê-ésse. Também deve ser fã de SÁSSES e outras ferramentas intermédias que facilitam, depois de inúmeras dores de cabeça, o seu trabalho.

Back-end

O Back-end-er é um programador puro, muito próximo daquele que as universidades tencionavam que fosses: um engenheiro que sabe o que realmente é um HTTP (com ou sem S), e um FTP, e um SMTP e outros tantos TêPês… ele é que programa o teu ‘servidor’ PHP, Python ou seja-lá-qual-for a linguagem de escolha. É ele que monta os teus projetos em Djangos, Express, Laravel, e também é, normalmente, o responsável para determinar como é que são armazenados dados na tua aplicação, seja de utilizadores ou de produtos de uma loja ou… de perfis numa rede social! Quando uma página de resultados de pesquisa demora muito a carregar, é ao senhor do backend que se vão queixar.

Mas existem outras tantas tarefas que, apesar de consideravelmente distintas, também se inserem no domínio do back-end. Administração de sistema, por exemplo: quem vamos chatear quando um site está em baixo e não sabemos qual foi a causa? E quando é preciso configurar um servidor para enviar e receber e-mails? E para colocar um site numa máquina online? Administrador de sistema é, por si só, digno de ser considerado uma profissão a tempo inteiro!

E nem vou entrar na criação de APIs e outras tantas chinesices

Porquê este caminho todo? Qual é a mensagem?

A mensagem é simplesmente a de que não sou adepto do título front-end developer que, supostamente, é uma pessoa dominadora de ambos os domínios acima referidos. E tenho motivos para isso!

Ora, ser um front-end developer pode englobar princípios de estruturação, estilização, experiência de utilizador, programação de eventos em diversos níveis (dependendo do projeto) e ainda design. Passar para o domínio do back-end, por sua vez, envolve conhecimento ao nível da programação (quase sempre de ‘alto nível’), organização e arquitetura de soluções/projetos, segurança, protocolos web e gestão de sistemas — e a documentação, para onde vai? —. Alguns deste subdomínios são tão importantes que, por si só, justificariam especializações ou cargos profissionais! Sim, faz sentido, por exemplo, ter um front-end developer que não domina a área da experiência de utilizador mas percebe imenso de interações com a DOM, ou ter um back-end developer apenas especializado em fazer API.

Não me parece que o ramo extremamente genérico da ‘Informática’ seja pouco acessível ao ponto de termos gente que sabe um pouco de tudo mas não se especializa em nada. Em alguns casos específicos até pode fazer sentido, mas mesmo o mais ávido full-stack* acaba por se especializar em algo! E não é por acaso que na medicina existem tantos cargos — e sim, ‘Clínica Geral’ É uma especialização!

É preciso sim ter alguns conhecimentos gerais numa fase inicial da carreira, mas isso é porque ainda não sabemos como as coisas funcionam na prática e não definimos uma área de que realmente gostemos, ou nos sintamos à vontade. E aí sim, começamos a desenvolver traços individuais que nos caracterizam não só como profissionais mas como pessoas!