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 follow up all the in progress tasks
- 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 :
- 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 the team
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 :
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.[Read More]
Building an end-to-end testing strategy on top of Kubernetes (long version)
Building an end-to-end testing strategy on top of Kubernetes
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 :
- Mask the complexity of a task;
- Handle multiple tasks;
- Help contributors to start with your project;
- 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.
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.[Read More]