Vous reprendriez bien un peu de Front avant les fêtes ? 🎅
Chez SFEIR Lille, nous sommes nombreux à faire partie de la team #front et il nous tient à cœur de vous partager régulièrement nos dernières trouvailles en matière de veille technique.
Vous avez sans doute entendu parler de Vite si vous suivez Evan You, le créateur de Vue.js, sur Twitter. …
You either pick a i18n library or live long enough to write your own
I must confess something to you, and I hope that you will forgive me for it: I am French 🇫🇷🥖🧀🍷🐸🇫🇷.
I tend to write my applications in English in order to make them accessible to the greatest number of developers around the world. However, I sometime forget about the people closest to me.
I recently asked my family to beta test an adaptation of a board game that I am building and the first feedback that I got was my girlfriend asking me “pourquoi c’est en anglais ?” …
Make your domains shine!
I think that one could say I was already convinced by the benefits of the Domain Driven Design.
I learned the hard way that driving your software engineering by the technical end can lead to pretty catastrophic situations.
Technical debt, hard coupling with any data provider, having to translate every domain feature request to fit in the already infected code base… I found myself in this situation not long ago and it was really hard for me to find the root cause.
This is when I found out about DDD. It immediately connects to me as it was exactly the thing that I was not able to name! All of those smells could be avoided by working with the domain to create a software that really reflects it. …
Logging enhanced, plus a quick integration with the ELK stack
Logging is a key part of debugging. How can we understand what went wrong in our application if we are in the dark?
However, logging for the sake of logging is never enough. For the messages to be useful, they need to be contextualized. What is the level of the log? What data are attached to it?
This way, we are able to quickly understand the root cause, which actions led to the observed behavior.
Still need to be convinced ? Want a more in-depth presentation of the why and how ? Please take a look at Edouard Cattez’s awesome article on the subject. …
Code smell: In software development, any symptom of a greater sin within the product.
Ladies and gentlemen, members of the board and shareholders, I am glad to welcome you to this year’s leaders meeting.
For those of you who do not know me, the name is Thomas Doe, co-creator of Pentathlon and head of the IT department.
I hope that everyone made a fine trip and that you all enjoyed the petits fours. It is now time to kick-start this meeting with the less enjoyable news. Yes, I am talking about the migration to our new set of applications.
My take on the application of the Docker’s promises
As you may notice through the reading of my articles, I am no Docker expert.
On the other hand, the premises and the potential of containerization really speak to me. That is why I am willing to step out of my comfort zone to learn the principles and apply them as much as I can !
The thing that really bugs me about Docker is its usage that seems to be generally done.
I may be mistaking, but the really strength of Docker for me is in the ability to have the certainty to put in production the exact same environment that you developed on your machine. …
Applying TDD principles to the making of a helper in Go
I may be new to the Golang world, but here is something I am already familiar with: Building things in Go feels great !
What feels event better is to build those things with the absolute certainty that it works the way it was meant to be.
I am leaving the preaching and teaching parts to Kent Beck and consort. I can, however, tell you that the Test Driven Development (or TDD) principles are perfect to give you that certainty.
Following the TDD principles in Go does not require any particular setup. No dependency or IDE plugin to install and configure. You just grab your favorite text editor, a terminal plus a notebook and a pen if it suits you better ! …
A story about ego, pride and communication in the IT world.
A few months ago, somebody said that I was unprofessional and, I admit, I was pretty mad about it.
But do not worry, this is not an article about proving him wrong, even if it was my first thought back then.
First, in order to fully understand the story, a little bit of context is needed.
I am a software developer, currently working in a big retail company on behalf of my employer, a small IT services business.
The mission started out six months ago, with a team of four developers, a product owner, a devops and our customers support staff. …
Introducing the blogging application domains
In the previous post, I have introduced the back story of this project and his goals.
This second part will dive into the several domains involved.
This is not a definitive feature list, but more of a macro road map.
I really want this project to be available as soon as possible.
This way, I will be able to validate the technical environment and most importantly I will know if it feels good to use and develop.
In order to do that, I will restrain myself to a single domain with a bare minimum of features. …
… to bring together a group of remarkable technologies, see if they could become something more.
Behind this not very subtle reference lies the whole idea of this series of posts.
I think that a little of backstory is necessary to fully understand the shift of mind that leads to the making of this post.
We are, with a friend of mine, working at an IT services company and are currently in a mission within a little team of software engineers for a big retail company.
Even though we are passionate about our job and the Web Development in general, there is something in this specific mission that feels wrong for us. …