Usually I just talk about tech, projects or some funny (not that funny) jokes or anecdotes.

But today I saw the Goodreads 2022 Year in Books and I'd like to share this personal accomplishment that, for me, was really meaningful.

I've never been the kind of person that reads a lot, never had this routine of reading a book before bed or when going to the beach or ... well, I actually never had this interest, it was something that, for me, was boring, like studying for an exam. I just used to read development books, but it used to be one per year or even less.

2021 came and, with some inspiration from my wife, I started reading a book that was a collection of crime stories (kinda like Arthur Conan Doyle), that was a nice ride, and then, I just read another book, so 2 in total.

Now, 2022. I started with a goal of reading at least 2 pages before bed.

That was a fairly easy goal, but even though it was easy something bugged me a lot, that was, if I read 10 pages yesterday, I should read at least 10 today. But with this "excuse" I started procrastinating a lot on my readings because if I wasn't in the mood of reading at least 10 pages or, too tired and knew that I would read a maximum of 5, I would just skip that day.

Something that changed was, my mindset, I forgot about the "at least 2 pages rule" and started reading as much as I was comfortable with.

It might sound so easy, like "oh, but this is obvious Airton", well, for me that was a mindblowing move.

With this new mindset, I started reading more often and turns out that I started to read more as well. Fiction started to be adventurous, biografies started to be interesting, tech related books started to be less in my pipeline, and I started to read more books regarding management and behaviour.

In the end of the year I could see that I read 12 books. That, for me, was incredible.

Here's the list of books that I've read in 2022, not in any particular order:

1. The Storyteller: Tales of Life and Music by Dave Grohl
2. The Unbearable Lightness of Being by Milan Kundera
3. Mask Off: Masculinity Redefined by J.J. Bola
4. The Courage to Be Disliked: How to Free Yourself, Change your Life and Achieve Real Happiness by Ichiro Kishimi, Fumitake Koga
5. The Culture Map: Decoding How People Think, Lead, and Get Things Done Across Cultures by Erin Meyer
6. A Study in Scarlet by Arthur Conan Doyle
7. Tell Me How I'm Doing: A Fable about the Importance of Giving Feedback by Richard L. Williams
8. Non Violent Communication A Language of Life by Marshall B. Rosenberg
9. Resilient Management by Lara Hogan
10. The Coffee Saga by Robin de Graaf
11. In Defence of Open Society by George Soros
12. Psychedelic Cannabis: Therapeutic Methods and Unique Blends to Treat Trauma and Transform Consciousness by Daniel McQueen

I don't think that reading makes people smarter than others, but it's an active way of consuming content, it's a quiet moment, it's you and your mind, and nowadays, in this world that has too much of a noise, one can benefit from the quieteness.

I also should mention and thank my wife on helping me keeping this habit, it was really nice to have her support on this.

This is more a note for my future self than a post that helps others, consistancy is better than quantity in a time frame. Well, this can go for anything in life, so I shall try to apply this to other parts of my life as well.

Há algum tempo criei um bot que conversa com a API do Wakatime e publica em um Gist (que você pode pinnar na sua página de perfil do Github) o tempo que gastei desenvolvendo em certas linguagens. Para se aventurar nessa jornada e criar um bot para você, o código está aqui: https://github.com/airtonzanon/wakatime-gist

Conteúdo

Conheci o Wakatime há um bom tempo (quase 5 anos atrás), quando trabalhei com o Ivan Rosolen. Nessa época eu só utilizava para brincar com as métricas e não sabia muito o que fazer com aqueles dados.

Não acredito que o Wakatime é uma métrica para produtividade, mas sim uma ferramenta legal para ver quanto tempo você passou utilizando linguagem x/y ou quanto tempo você passou em algum projeto, mas para deixar claro, não utilizo-o como ferramenta para cobrar freelas ou para medir produtividade.

Dito isso, o Wakatime é uma ferramenta muito simples para começar a se utilizar, e o melhor, é de graça (pelo menos para o que vamos utilizar aqui).

Esta ferramenta se integra com vários editores (i.e. PHPStorm, Vim, VSC, Sublime, e outros), para saber se o editor que você utiliza, está disponível em uma integração com esta ferramenta, dê uma olhada nesta página https://wakatime.com/plugins

Quando conhecei a trabalhar com o Malukenho vi ele utilizando o Github actions para capturar uns dados do Wakatime e joga-los em um Gist, com isso é possivel pina-lo e colocar na sua página inicial do Github.

Hoje em dia você já pode brincar com o próprio Github para exibir uma mensagem engraçada ou seu portfolio na página do perfil, porém ainda continuo usando meu bom e velho Gist ♥.

Como na época eu estava muito afim de fazer coisas em Python, criei um worker que conversa com a API do Wakatime e joga os dados para o Gist, porém eu gostaria de fazer isso periodicamente, então decidi coloca-lo em um servidor do Heroku com um cron job que roda todo dia.

Para utilizar o mesmo código que menciono acima no TL;DR; você vai precisar de uma conta no Wakatime! Assim que criada, você já consegue conectar com o seu editor de texto preferido (existem tutoriais no próprio site da ferramenta)

Depois disso, você pode acessar https://wakatime.com/settings/api-key para pegar sua api key, é com ela que o script vai conseguir se comunicar com o Wakatime. Essa key é a variavel WAKATIME_API_KEY.

Além disso, você vai precisar acessar https://wakatime.com/me, você será redirecionado para seu perfil do Wakatime, na URL, você consegue achar seu user id (i.e. @d831e48d-dff2-4cf2-5d4e-1d6h5f4328c9), que vai ser utilizado para popular a variavel WAKATIME_USER_ID.

Agora a parte do Wakatime já está completa, no Github, acesse https://github.com/settings/tokens para gerar um token de acesso, este token será utilizado na variavel GITHUB_TOKEN.

O último passo é criar um gist vazio com o nome de weekly_development_breakdown.txt, infelizmente não deixei o nome do arquivo dinâmico, porém o repositório está no Github e ficaria muito feliz de receber pull requests.

Assim que você criar o gist, na URL você terá um hash mais ou menos assim: 0000f8e67061874431540223bp3wb611, copie ele, pois será a variavel GIST_ID.

Com as quatro variaveis de ambiente já em mãos, é só usar o botão abaixo para fazer um deploy para o Heroku (caso queira usar algum outro host, sinta-se a vontade, só lembre de setar as variaveis mencionadas acima).

Quando você clicar no botão acima, será requisitado as variáveis que falamos acima.

Assim que você apertar no botão deploy, o processo inteiro vai ser feito e você estará no dashboard do Heroku. Procure pelo addon scheduler que já estará instalado, clicando nele você irá para outra página, onde iremos fazer o setup do cronjob.

Aperte em Create Job e um modal do lado esquerdo aparecerá para você dizer a frequencia que este script irá rodar, pessoalmente acho que 1 vez por dia durante a noite é suficiente.

Na sessão de Run Command coloque python3 wakatime.py no field com o cifrão ($) e mantenha 1X o tamanho do dyno.

Com isso, é só apertar em Save Job e esperar rodar!

Caso não esteja paciente para esperar rodar, você pode instalar o heroku cli (clique aqui para ver como instalar).

No seu terminal, depois de logar na sua conta escrevendo heroku login, procure o app que está rodando o script.

O comando heroku apps lista todos os seus apps rodando no Heroku.

Com isso, você pode rodar o comando abaixo e ver se um JSON gigantesco aparecerá no terminal.

heroku run -a name-your-app87753 python3 wakatime.py

Caso algum erro aconteça, pode ser problema de permissão no Github ou alguma variável de ambiente está errada. Me procure no twitter que posso te ajudar!

TL;DR for logs - Depending on the resource that you want to see the logs just do a kubectl logs -f <resource> --namespace <namespace-name>

Well, first of all we gonna need install a tool that you gonna use to interact with the kubernetes cluster: kubectl

For Mac is really simple:

brew install kubectl
kubectl version --client

Now, if you're using other kind of OS, take a look here: https://kubernetes.io/docs/tasks/tools/

Listing the contexts that you have:

kubectl config get-contexts

If you don't have any context, perhaps this can help https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/

There you gonna be able to see the contexts that you have access to, so, if you're using Minikube for example, you gonna see it there.

Contexts are the way of saying which cluster you gonna interact with. You can also use one of those commands below to interact with k8s.

kubectl config current-context               # display the current-context
kubectl config use-context my-cluster-name   # set the default context to my-cluster-name

Inside a cluster you can split some applications in namespaces (I might be wrong about this concept).

To list the namespaces, if you don't it already, and see what namespaces you have inside a context you can do kubectl get namespaces, with it you can start exploring your application, something like take a look on pods, deployments, cronjobs and so on.

When you already know the namespace you can do a quick look on everything that you have inside that namespace by doing kubectl get all -n chosen-namespace.

This will list everything that you have inside this namespace, so you gonna be able to get a pod, for example, and take a look on the logs of it like this: kubectl logs -f my-pod --namespace my-namespace

Take a look on this cheatsheet for more commands that you might want to use.

So I started setting up my environment for it, first I needed to setup my GOPATH into my PATH environment variable, so:

export PATH=$PATH:$GOPATH/bin

# If your $GOPATH variable is empty, just do it:  
export GOPATH=$HOME/go

Here, for the auto-complete stuff, we gonna use gopls (pronunciation: "go please"), it's the official language server for the Go language.

For installation you need to run the line below:

GO111MODULE=on go get golang.org/x/tools/gopls@latest

To see if it's working properly just try run gopls --help. It should be working because we already added the $GOPATH to $PATH environment variable, if it's not working, take a look on your $HOME/go/bin directory, if the gopls file is there, then it might be a problem pointing the go path to the path variable, if it's not there, might be a problem on the installation above.

Now it's time to setup coc, inside vim, just run :CocConfig. If you don't have any language server configured yet, just paste it there:

{
  "languageserver": {
   "golang": {
      "command": "gopls",
      "rootPatterns": ["go.mod", ".vim/", ".git/", ".hg/"],
      "filetypes": ["go"],
      "initializationOptions": {
        "usePlaceholders": true
      }
    }
  }
}

If you already have a language server there, just add the "golang" node inside "languageserver".

The result in a Go file will be something like the one below:

Nigel Kersten - Enterprise DevOps 10 years on: What went wrong? and what went right?

• Missing parts of DevOps in most organizations these days: Culture and Sharing.
• DevOps includes: Culture, Automation, Lean, Measurement, Sharing

Joshua Zimmerman - Why We're Bad at Sharing Devops

Teaching concepts are hard, sometimes we focus on the word it self, but we should focus on the concept. It can change from person to person, even if everyone have the same explanation about a version of a concept, a lot of different versions will come from there. Probably I got something totally different from this talk than other person on the audience.

But what DevOps really means? That's the thing. Some people even say that DevOps is dead.

How can we improve the way to teach concepts?

• don't focus on language, focus on concepts
• pose more problems offer fewer solutions!
• create more spaces for collaborative learning

Ken Mugrage - Everything I need to know about DevOps I learned in The Marines

• Words matter, having a obiquos language, that everyone knows what you're talking about, knows what that means.
• Empowered teams: diverse and inclusive team, know what to do with your skills, and support each other

Ramon van Alteren - Applying (Supporting) devops practices to technology procurement

• When you have stuff in house, you know about costs. It's fix. But when we go to cloud, any team can run whatever they want in cloud, and the costs can go really high.

• Costs is a factor in how you design & run systems for every teams

Lessons:

• 1 - Create a safety net - to be free to test stuff on cloud
• 2 - Global cost optimisation before local -
• 3 - Explicit frame of reference -
• 4 - cost reduction =! goal - goal is bring value for users

Julie Gunderson - You Can't Buy DevOps

• You can't change culture with a credit card

What devops isn't:

• moving to the cloud
• forming a DEVOPS TEAM
• getting rid of the ops team
• something that you can download
• not a prescript checklist

What devops is:

• culture
• people over processes

westrum three cultures model five keys to a successful google team (image)

Psychological safety:

• allow to take risks, without pointing fingers to blame
• Incorage people to take risks
• people are not afraid to speak up
• allows to ask questions

Practices:

• discipline doesn't cost money
• automation
• right tools (choosed by the team, and try to get the right ones)
• continous deploys, small changes
• test - continous integrations

Daniel Maher - What MMA taught me about working in tech

• Mixing techniques toguether

Fundamentals win fights:

• some basics that we need to learn
• don't be dogmatic about fundamentals
• we need to explore more than know how to use a loop or something like that, there are a tons of ways to do the same thing

Diversity makes you better by default:

• Fresh eyes and fresh ideas - Getting stuff for people from different backgrounds, using different tools, this kinda stuff.

Knowing that we can do stuff, getting everything together, diversity, data, everything, but sometimes we get frustrated, sometimes we get the "WTF's happenning here?"

Sasha Rosenbaum - Admitting that hard problems are hard

Do we need all the complexity that we put in our architecture?

It's a really huge cost admiting ignorance.

I'm a bear of very little brain, and big words really bother me. Winnie the pooh

We should stop pretending that:

• Distributed systems are easy
• people are available 24/7 and if they work more than other people they are better than others
• Unicorn companies don't have technical debt
• that new product will solve all of your problems

Stereotypes are self-perpetuating - assumptions, if you have a assumption about someone, you'll not hire this person

Costs of complexity:

• time to learn, to build, to maintain
• increases the changes of failure
• money (what business care in the end of the day)

Psychological safety

• make space for some other people ideas
• to admit mistakes
• you don't know everything

"You're here to improve not to prove your self"

book: mind set - the new psychological of success

Second Day

Patrick Debois - Devops beyond dev and ops

• Report bugs for services that we use, give good feedbacks, they'll appreciate if it's for a trully porpouse
• Companies should get employees that are willing to learn, to work with their product, even if they don't have 100% of the skills needed.
• Technology needs to be aligned to the legal contracts and stuff. It's cool the revisit it once a while that something changes
• DevOps is a tiny part of the company, not overestimate your power as a tech person

Jody Wolfborn, Kimball Johnson - Pipelines to Production: Detangling the DevOps Web (of Lies)

• Automate practices.
• Right tools for each problem.
• Delivery small changes and tested
• Monitor proactively
• Trustness, create safe environment

Culture = DevOps == Empathy

Michael Ducy - Different Paths, Same Place - A Human Case Study

• Different paths = Same goal
• Diversity of all things.
• Never criticize a person until you've waled a mile in their shoes

George Miranda - The Perfect Storm - How We Talk About Disasters

• Have a plan for incidents
• Share what we learned from the incidents
• What is the next step? How the future looks like
• Retro on teams out of tech teams

Bryan Liles - Sysadmins to DevOps: Where we came from and where we are going

• write softwares to solve biz problems
• most likely runs on servers somewhere
• Team understand the full stack
• We had dev vs ops

Good parts:

• automate - code as infra
• empathy
• collaboration -> with peeps that know more than you.
• use a little of agile

Bad parts:

• DevOps - a made up word, WTF?!
• DevOps Eng - WTF?!!?
• SRE

Bridget Kromhout - Devops, distributed

Focus:

• Grow with more people we're one single point of failure
• Time: people may not know stuff as you know because xp. Try to share it.
• Communications & Structure
• share cross orgs

Clarify:

• Write docs, make it explicity
• Complexity can come with chaos
• Detail & scaling

Imagine:

• complex & distribuited

We can make different stuff, to not be hard and make something nice for everyone

• When you enable developer mode all of your files, directories and accounts will be deleted.
• Google doesn't support your Chromebook in developer mode.

Enabling

• Turn on your Chromebook.
• Restart it with recovery mode (Pressing esc, refresh and power button).
• The recovery mode screen says "Chrome OS is missing or damaged.". Press CTRL + D to go to another screen.
• Now you can press Enter and enable the Developer Mode.
• Wait a few minutes and your Chromebook will restart with Developer Mode Enabled.

To Go Ahead

• When your Chromebook turn on, a message will appear "OS verification is OFF", so press CTRL + D again. (This message will show up every time that you start it)
• You need set on the Debugging Features.
• So, click in Enable debugging features, then press Proceed.
• After it, your Chromebook will restart.
• So when it turns on, you can put your root password.
• Now you just need to set the normal options to your Chromebook work.

Set user password

• After these steps, you can set a user password to use sudo.
• Press CTRL+ALT+F2 login with root (use the password that you informed when you enable the Debugging Feature).
• Now write passwd chronos.
• Now you can write the password.
• After that, press CTRL+ALT+F1 to back to graphic mode.

So, as I already had this "bad experience" before, I raised the question: should we review PR's that are flagged as WIP? I wasn't sure, because we can create a PR for some other reasons than a review, sometimes just to run the pipeline and see if everything is working fine, also it can be a team/company agreement - every time you start a task, create a PR on WIP.

With this question in mind, I created a poll on twitter, I wanted to know other points of view about this.

Do you think it's relevant to review pull requests in WIP or we should wait for the author to finalize it?

— Airton Zanon (@airtonzanon) January 21, 2020

We got 53.6% for waiting for the pull request to become ready to review (not WIP) and 46.4% for reviewing it right away.

I got three answers that made me think about giving feedback as soon as possible:

Depends on if the author requested it or not.

— Timothy Vernon (@tvernon_tech) January 21, 2020

IMHO: Review as soon as you have a PR open, WIP or not. Feedback is good at any time of the process.

— Marabesi 💻🇧🇷 (@MatheusMarabesi) January 21, 2020

Early feedback is always good.
If you don't want a feedback, don't open a PR.
WIP PRs should have context described in the description (goal, what was done, what is yet to be done).
WIP should mean 'don't merge' and 'review as not yet finished'
;)

— Diego Rabatone (@diraol) January 22, 2020

Giving feedback right away may give the author a good north to follow. Sometimes we start a PR knowing what is our goal, achieve the acceptance criteria for a new feature or correct some bug that we had in production, but sometimes an early feedback can help out the author to finish the task faster or give some tips about some other part of the system that might already do what the author is creating.

Also, Gabriel Caruso made a really good point about doing that:

Review it if you have enough context to say: "this is going on the wrong direction from what we discussed" for example

— Caruso (@carusogabriel) January 21, 2020

Something I had already seen happening was a developer that as creating an event named "user changed status", to see how many times a user uses the new feature that changes the status on the system. The author didn't know that an event named "user interacted with system" existed on the project which accepted the values "action" and "category". The purpose that the developer needed the "user changed status" could be fulfilled with the "user interacted with system" passing the values "changed" and "status".

In this case, early feedback saved a lot of time for the author and if the reviewer didn't have this kind of context about events, they might have done a wrong review.

As I was thinking that making review on WIP PR's wouldn't be good, these points above really made me think that I was wrong. I had the opinion that I made on the start of this text, about getting changes when you're reviewing the PR could turn the review useless, but Bojan changed my mind with this tweet:

My stance is that reviews are rarely useless 😁 I’ve learned so much from discussions sparked by PR’s, even those which seemed totally irrelevant! I’m a big fan of code review, btw 🤗

— Bojan Gvozderac (@GvozderacBojan) January 21, 2020

Taking this point of view, we can see that even when you do a review for a past patch, you might give some good information to the author to advance on their task or also to take this chance to learn some new stuff.

Rarely discussions (when engaged) on pull requests are a waste, they can help future developers that need to dig a little deeper on some part of the project. When a good conversation is made on a pull request, we can use that to understand why some decisions were made. I already found myself looking on an old PR because I wanted to understand why the author did something in the code. Of course the commit message should have given this information to me, but it's not always the case, but I'm leaving the focus of this text on WIP PRs.

One good point to consider if we should or shouldn't review a WIP PR is if the author asked for it, as Timothy says here:

Yep. For me, unsolicited advice always takes more emotional energy to receive well. So for a PR, I generally wait until the author asks or removes the WIP unless I see something that is a big red flag or potential waste of time where raising the issue could help them.

— Timothy Vernon (@tvernon_tech) January 21, 2020

That's a good point because sometimes when we give unsolicited feedback to someone's code it can not be received as good as we thought it would be. Sometimes the author creates a PR, do their own review and found that they needed to change some stuff, and if we point out these same changes on their code, it can not be received "well".

The conclusion that I got from this poll is that we could start reviewing a WIP PR if it is solicited. Then the author will wait until getting the feedback and will not send any new patches, the reviewer won't get "pissed", and the author can get some earlier thoughts on their PR to get forward on their task.

I've stopped reviewing WIP PR's that I don't get asked to give feedback, and I just wait for the PR to get the WIP solved. I usually like to read some WIP PR's, and if I get something that I find I could help with, I can send a message to the author and talk about it. It's more a request whether they need feedback or not and, when I do that, I don't do a deep review, commenting, etc... but getting an overview of the changes.

I hope that this text helps someone or just points out that we can make some agreements on how to review pull requests that are still on work in progress status.

> for network

7. Find all the WiFi Networks around you: sudo iwlist wlan0 scan | grep ESSID.
7.1 Generate the wpa access password: wpa_passphrase NETWORK_ESSID NETWORK_PASSWORD.
8. It will generate something like this:

network={                                                                   
        ssid="NETWORK_ESSID"                                                 
        #psk="NETWORK_PASSWORD"                                                  
        psk=e0fa796c9d43d1c5e75e0c4fd77695e97cbccdb180ec2e5c10ab523hh6956666
}                                                                           

9. Copy it and then edit this file sudo nano /etc/wpa_supplicant/wpa_supplicant.conf
10. Paste it below everything that we have there.

> for locale

https://daker.me/2014/10/how-to-fix-perl-warning-setting-locale-failed-in-raspbian.html

You just created a Process Builder to run 10 days in advance and you would like to create an Apex test for it.

I had this problem because in my current company we're trying to create tests for all new process builders.

Problem

If you change the date of when the object was created it won't work, because the scheduler needs to wait an amount of time to run.

Solution

Every time we expect that a process builder runs, if it has no immediate actions, the process builder will create a record on FlowInterview table, which is a kind of queue.

So, if after we run a test we have a record in that table, it means that the scheduler worked.

The process builder setup was: Run every time that a task is created and will close it in 10 days if it still Not Started.

Then the test:

@isTest
public class VerifyProcessBuilderTest {
    @isTest
    public static void verifySchedulerCreated() {
        Task task = new Task(
            Subject = 'Call Airton',
            RecordTypeId = '000a00000000AAA',
            Status = 'Not Started',
            Priority = 'High',
            Type = 'Call'
        );

        Test.startTest();

        insert task;

        List<FlowInterview> flowInterviews = [SELECT Id FROM FlowInterview];
        System.assertEquals(1, flowInterviews.size());
        Test.stopTest();
    }
}

This will create a task, but notice that it's between Test.startTest() and Test.closeTest() calls, so when we insert the task, it will trigger the process builder, and below we'll assert if the scheduler worked or not.

Conclusion

This test won't test what the process builder will do (which normally is what we do in this kind of tests), but it will test if the action of this process builder is scheduled, so if something changes, the process builder is inactive for some reason, or if it's not being scheduled anymore, the test will tell in the next deployment.

Conslusion 1.1

Remember that every time we deploy a process builder, it'll be inactive, so for the test to run well, we need to deploy the process builder first, activate it and then deploy the tests. (It's not the best scenario of all, but, at least we'll have something testing the process builder).

If you don't want to have this problem, please read this release note from Salesforce.

Update 12-08-2019

Some days ago a peer was talking to me about a test that wasn't passing because it found some rows on FlowInterview table, that was trick, because it was supposed to have no rows there, after an investigation on our Process Builders we found the problem, we forgot to disable a process builder that we wouldn't use anymore. So that's the beauty of this test, we can find if something is triggering something else that shouldn't.

Also, I would like to mention that every time that a new test runs, it will clear all the database, in other words, the table FlowInterview will be empty when you run a new test, and it will just have content if some process builder has a scheduler.