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.