Uma reflexão de ano novo

Vamos começar analisando a diferença entre solidão e solitude. A solidão acontece quando você está só, mas não gostaria de estar. Ela é geralmente relacionada ao sofrimento. Você sofre por estar só ou por se sentir só. Já a solitude acontece quando você também está só, mas consigo mesmo. Um isolamento voluntário.

Esses estados podem confundir algumas vezes. Eu, por exemplo, gosto de almoçar e ir ao cinema sozinho, uma vez ou outra. E não é por falta de companhia. No cinema, com inúmeras pessoas ao redor, estou só, mas porque eu escolhi e não fico triste por causa disso. Já a solidão não é voluntária, gera ansiedade, sofrimento e depressão.

Continuar lendo

Anúncios

Git merge e rebase?

Quando se está trabalhando em uma branch e outro membro do time faz um git push, você terá que fazer um git pull antes de enviar seus commits para o repositório bare. Quando isso acontece, o git gera um commit de merge. Muitos commits de merge não são informações úteis para outros desenvolvedores e podem complicar a leitura do histórico de commits.

É uma boa prática usar pull com rebase usando o comando:

git pull --rebase

Desta forma o histórico fica mais legível.

Para deixar esse processo automatizado, podemos usar a seguinte configuração:

git config --global --bool pull.rebase true

Quando estiver trabalhando em um feature branch e precisar fazer um merge para o trunk, que geralmente é o branch master, é uma boa prática usar o parâmetro –no-ff.

git merge --no-ff my-feature

Isso faz com que o git gere um commit de merge mesmo quando faz fast-forward, criando rastreabilidade, facilitando saber de onde vieram as alterações e quando o merge foi feito. Também facilita reverter funcionalidades adicionadas ao master.

A configuração abaixo deixa esse processo automatizado. Com ela, todas as vezes que você fizer merge, o git irá criar um commit de merge automaticamente.

git config --global merge.ff false

Ainda falando de features branches, quando se está trabalhando em um feature branch e precisa-se levar commits do master para ele, muitos devs usam rebase. No entanto o rebase reescreve o histórico e complica o fluxo além de ser muito mais custoso resolver conflitos quando se usa rebase. Então é melhor usar merge nesses casos.

Até a próxima minha gente.

Diga, não pergunte

Diga, não pergunte – mais popularmente conhecido como tell, don’t ask – é um princípio da orientação a objetos que nos lembra de que, ao invés de pedir dados a um objeto, devemos dizer a ele o que fazer.

Dados e operações devem pertencer ao objeto, logo, você não precisa consultá-lo para depois agir em seu nome. Ou seja, você deve dizer ao objeto o que você quer que ele faça, e não perguntar sobre seu estado para depois tomar uma decisão. Por exemplo:

def street_name(user)
  if user.address
    user.address.street_name
  else
    'No street name on file'
  end
end

O método street_name está perguntando o estado de user para tomar uma decisão e retornar algo. De acordo com o tell, don’t ask, a implementação dessa lógica deveria ser responsabilidade de user e não do chamador, pois o tipo de implementação visto acima, viola o encapsulamento de user.

Uma solução bem melhor seria:

 def street_name(user)
   user.address.street_name
 end

 class User
   def address
     @address || NullAddress.new
   end
 end

 class NullAddress
   def street_name
     'No street name on file'
   end
 end

Agora, stree_name apenas diz o que quer e o objeto user se encarrega da lógica. Também fazemos uso do pattern NullObject, para deixarmos a solução orientada a objetos de fato.

Deste modo, passamos a pensar declarativamente ao invés de proceduralmente.

Referências
http://martinfowler.com/bliki/TellDontAsk.html
https://pragprog.com/articles/tell-dont-ask

Extended Belém e as novidades do Google I/O 2015

Aconteceu ontem (dia 28), direto da sede em Moutain View o Google I/O 2015, o evento anual da empresa focado no desenvolvimento de aplicações para os seus sistemas operacionais, especialmente o Android, além da apresentação de novos produtos, como smartphones e tablets. E não faltaram momentos em que a plateia fez o seu “uuuuuhhhh” a cada novidade apresentada.

Foto da plateia presente ao evento

Plateia do #io15bel

E como não poderíamos ficar de fora de um evento como esse, aconteceu o 1º I/O Extendend realizado em Belém City. O Google Developers Group de Belém, ou apenas GDG Belém, organizou, em parceria com algumas empresas e entidades, o 1º Extended dessas bandas, transmitindo a Keynote oficial para um público aficionado por Google, tecnologia, desenvolvimento, Android e por aí vai…

Juntando developers de longa data com iniciantes e curiosos que nunca escreveram uma linha de código, o evento cumpriu seu papel deixando todos ligados e ansiosos com as novidades. E por falar nelas… Veja a seguir o que tem de bom chegando. Continuar lendo