🇬🇧 Read in english here 🇬🇧 C’était quand le président Macron a tweeté à propos de l'événement, voilà pourquoi. Tout d’abord, je cite Wikipedia pour ceux qui ne connaîtraient pas le Z Event. Le Z Event est un projet caritatif créé par Adrien Nougaret et Alexandre Dachary - respectivement connus sous les pseudonymes ZeratoR et Dach - réunissant des streameurs francophones afin de récolter des dons qui permettront de soutenir une ou plusieurs associations caritatives.
It was when president Macron tweeted about it, and here is why. First and foremost, quoting Wikipedia for those who might not have heard about it. The Z Event is a francophone charity project created by Adrien Nougaret and Alexandre Dachary (respectively known under the pseudonyms ZeratoR and Dach) whose goal is to bring together French streamers to collect donations that will support a charity. Organized on the Twitch streaming site, it has raised more money than any other french video gaming event.
TLDR; see title. Long time no see, and it’s been a while since we haven’t talked about Go. I still love the language, I still use it on a daily basis, and today I feel like talking a bit about dependency injection. So hold on to your seats because it’s going to get boring very soon, or not we’ll see. What’s the problem? Take the following file. It has a Fetch function that takes base currency and a target currency, and it fetches the exchange rate between the two currencies by contacting an API that has that information in JSON format.
It’s been a while since I haven’t had a long debate about which communication tools we should use and how we should use them as a team. Since the global health situation won’t let us have this debate where it normally belongs - the bar - I’ll just put some thoughts here and maybe share a few unpopular opinions. The other day I was using Slack to chat with my project manager Johana and just about when we finished our conversation, my doorbell suddenly rang.
I’ve been using Go for a few years now and today I want to share some experience. This post is about a few funny and somewhat not obvious bad Go patterns. This is 3 ways of shooting yourself in the foot when writing applications in Go. Channels overflow Among many other things, Go is great for its concurrent programming model. Goroutines, channels and packages from the standard library like sync offer a great experience when it comes to solving problems with concurrency.
Kubernetes offers various ways to add custom functionalities and to modify the way built-in features work. Today I want to talk about extending Kubernetes by using custom resources and controllers. Let’s take a close look at how to do that, but first a quick story! Why extending Kubernetes As I mentioned in my previous post, my journey on the cloud began with Google App Engine. As a developer, I was pretty happy with the path to production of the service.
After a few years of daily work with Kubernetes, I decided to become a Certified Kubernetes Application Developer (CKAD) as well as a Certified Kubernetes Administrator (CKA). As I’ve just taken and successfully passed the exams, I figured this was a good opportunity for a story. My background experience My first steps with Kubernetes go back a few years ago, when I began experiencing on Google Cloud Platform and was amazed by how easy and fun it was to deploy applications on Google App Engine.
I recently left a team where I was the lead developer for about three years. I was regularly asked about why I wanted to keep the history of the git repository linear. Most of the time (but not always), the question came from fellow developers having a hard time rebasing a work branch. As a matter of fact, the question was also asked multiple times on StackOverflow, especially as What are advantages of keeping linear history in git or Git workflow and rebase vs merge questions.
Being the best, meaning having the best technical skills. It is not a rare thing for me to meet with someone, typically a fellow developer, who will give me the impression that having figured it all out about a technology is what makes you the best match for working on a particular project. I believe this statement is wrong and it may sound straightforward to say. But identifying what we are missing when we think like that is a bit less obvious.
Ever found yourself in a situation where you had to promote an idea that you thought it was brilliant, but your co-workers did not? We don’t always have good ideas, sometimes we poorly elaborate our instincts, and whatever we come up with doesn’t pass the test of the evaluation by our pairs. If your colleagues have presented robust and logical arguments, then it’s hard to defend your idea further. The thing is, if you really care about these ideas, then it is really a shame that it would only take a solid and well established argumentation for them to be rejected.