## Priority #1 kills priorities

In my journey looking for the best way to manage my to-do list, I recently tried to create a Trello board where to put all the new tasks added to my personal backlog. My choice of using Trello was based on several needs:

• Being able to order tasks by priorities

Since Trello is very flexible, I thought that I could create one card by item and three columns: to-do, work in progress, and done. But then, I started to have lots of cards in my to-do column and thought I needed to re-order all the cards to be able to quickly see which have a high priority and which can wait.

I first tried to create an intermediate to-do column called “today” where to put the item I needed to be done by the end of the day. I quickly found out I still had to deal with all the other cards in the “to-do” column which needed review each morning. Thus, I moved once again and created three to-do column :

• Backlog
• Priority #3
• Priority #2
• Priority #1

For a while, this system seems perfect. Each time I had completed a task, I was able to see which one will be the next to focus on by looking at the priority #1 column. I had a clear view of what I really needed to do at any time. Every week or so, I reviewed my to-do lists in order to move cards from lower priority to higher. Or, at the contrary, I lowered the priority of some tasks considering they were supposed to be priority #1 but I hadn’t time to work on it and the world didn’t stop.

## The Engineering Manager is part of team

The more I talk with engineering managers around me - in my own company, during interviews or around a beer - the more I see tow patterns, two different ways to talk about their team: those who say “they” about people they manage and those who included themselves in a global “we”. I first thought that the difference was the result of different skills. I thought that engineering managers that used to be engineers tends to include their selves in the team. [Read More]

## Integrating logrus with cobra

You can find a working example on my GitHub: https://github.com/seblegall/blog-scripts/tree/master/logrus-cobra

I recently had to refactor the way one of my app print logs. My idea was to use logrus as it is a very well known lib to produce logs with Go.

Logrus let you print nicely color-coded and structured logs and is completely API compatible with the standard library logger.

My first question was about log level and how to setup it once across all sub-directory/package of my project.

Under the hood, logrus instantiate a new variable log. Once done, calling the logrus.SetLevel() function will store the level directly in this newly instantiated struct.

Thus, we have a global struct, available across all sub-package making the level automatically shared without having to use dependency injection.

If you need to set a different level in a sub-package (for example), you just need to instantiate a new logger :

 1 2 3 4 5  var log = logrus.New() //... log.Debug("debug log")

## The bottom-up performance review

The performance review is a common way to regularly give or get feedback about the work that has been done. Some company performs those once a year, other twice a year. Agile teams may do it more frequently. In my previous experiences, the retrospective we were doing after each sprint was a way to give personal feedback and once a year we were doing a yearly retrospective to summarize the whole past year, as a team.

## A Makefile based CI/CD chain for Go

Whatever the project you are working on, whatever the programming language, using a Makefile to handle common tasks is a great idea.

Makefiles are great at :

• Manage configuration using env var;
• Define a common interface / standard between projects;
• Abstract the underlying technology.

For all those reasons, make is a perfect fit with any CI/CD chain. Using a Makefile helps you define a simple and common interface usable whatever the CI/CD chain you plan to use. The only thing you will have to worry about is that your CI/CD chain tool will call the right target.

 1  make something

And the job is done. It could be done with Travis. It could be done with Jenkins. The only thing that matters is the interface defined by your targets.

## Handling validation errors from API-Gateway with AWS Amplify using ReactJs

Recently, I’ve been working with AWS in order to experience how it is to build a MVP really quickly. The goal I’ve been trying to achieve is to use as much AWS tools as possible to get a working product in production the fastest.

To do that, I choose to rely on :

• Lambda for back-end code
• API-Gateway for REST API
• DynamoDB as a database
• Cognito to manage Singnin / Singup and authenticated calls to the API.

## Building a really smart Jabber chatbot with Dialogflow

Have you heard of Dialogflow?

Dialogflow (previously known as api.ai) is a conversational agent manager. Basically, you can see Dialogflow as a back-office were to manage an NLP engine.

As an admin, you can create intents that represent a suite of similar “user says”. Under the hood, Dialogflow provide an AI (Natural Language Processing) that learns to match user inputs (called “user says”) with intents depending on the context, in order to provide the more logical/appropriate response. It could be an actual answer, called a “speech”, as it can be an action. For example : starting a job, running a command, etc.