Technical interviews are a contentious topic, to say the least. It applies both as a candidate and as an interviewer. It feels that you end up sinking a lot of time into it, often with little to show for it.
More concretely, it seems that take-home coding assignments are becoming more and more the norm in the tech industry. Do you have opinions about them? I surely do! In this post, I want to talk about some practices I’ve observed lately that make companies look bad and poison the goodwill essential for a successful interaction between candidates and companies.
I’ve been working with OAuth a lot lately. Just recently, I wrote about setting it up for grafana. Today, I want to talk about the recommended flow for Single Page Applications, Authorization Code Flow with PKCE. I’m going to add authorization to a React application leveraging Auth0 as an Identity Provider.
I mention Auth0 so often around here, you’d think I’m getting a referral bonus. I promise you I’m not! It’s deserved praise. The UI is easy to navigate, is conveniently provisioned with Terraform, and has powerful libraries for most programming languages. I wrote about verifying JWTs from a SpringBoot…
I’ve gotten into the habit at work of signing my commits in
git with my GPG key. It adds an extra layer of integrity to the source code, as it enables us to know who produced each commit (if the practice is followed widely).
It requires some initial configuration, but after that, it adds very little overhead.
Even if your organization doesn’t have a policy requiring it, I think it’s still worth setting up. Let’s see how to do it.
Even if it’s not required by your organization’s policies, I think it’s still worth setting up. …
This seminal book aims to answer one simple yet fundamental question: What makes an organization that develops software successful? This is a topic that has been explored in depth by many, many authors. The key difference is the comprehensive body of research that the authors have compiled. Like, they’re using actual science for this, man.
As could be expected, it is a mixture of product development, practices, organizational alignment, and technical practices. The book is not exploring the topics comprehensively, but it’s definitely a good start.
It comes down to Continuous delivery, in the end. Who would’ve thought? Rapid iteration…
The appeal behind using Kubernetes is that you abstract the details of where your applications run and leave it in k8s’s hands. It’ll schedule containers following some given constraints, and restart them if they crash.
However, a Kubernetes cluster is not a perfect abstraction. That is especially visible as an operator. Even if you use a managed solution like AWS EKS, you still have to perform some maintenance yourself.
As an operator, I want this maintenance to happen regularly, to avoid stagnation and prevent failure. As a developer, I avoid unwanted interruptions for my applications. A Pod Disruption Budget (PDB)…
Team topologies is a book about software delivery that doesn’t mention technology. Rather, it’s about how to organize teams.
It’s almost impossible to work in the software industry and not hear regularly about Conway’s law (It’s not actually a law). It turns out that the way an organization is set up will influence the software architecture that it produces. Everybody is mindlessly using microservices regardless of fit. But if I’m allowed to quote myself:
All the fancy technology in the world won’t fix an organizational problem.
It seems hard to believe, but I had never written about Kubernetes before. It feels impossible to hold a conversation about technology for more than five minutes without coming to the topic of k8s. Let’s fix that. I have to publish a couple of articles centered around Kubernetes to catch up.
If you operate a Kubernetes cluster with any significant usage, chances are you’re using an Ingress Controller. It just seems the thing to do. I’ve had a thing for Traefik for a while. However, the path of least resistance is to use the NGINX Ingress Controller. …
If I say monitoring, the first thing that comes to mind is Prometheus. And its trusty sidekick, Grafana. Is it software engineering if you’re not continuously checking some dashboards? However, we don’t want to expose those dashboards on the public internet. That would be bad! In this post, I’m showing how to set up authentication for Grafana. I’m using Auth0 as an identity provider.
I wrote some time ago about setting up Auth0 with Terraform. Auth0 is an excellent product and a convenient way to set up authentication and authorization without handling the gory details. …
Prometheus is a complex beast. I’ve been using it at work for the past year, and I always felt that I could barely understand what was going on. Picking up this book is a great way to start filling those gaps. Roughly, there are the following sections:
Whether you are monitoring applications or infrastructure, the core components are the same. Instrumenting the code or using exporters, and then publishing metrics that Prometheus will scrape, with a few labels to sprinkle on top.
I wrote about Network Load Balancers recently. You get a lot of mileage out of NLB’s, but sometimes you do need Layer 7 features.
One alternative is keeping the NLB and putting a reverse proxy like Traefik behind it. However, a simpler approach can be replacing both with another offering from AWS, the Application Load Balancer (ALB). In this post, I’ll show how to provision ALBs with help of the old trusty Terraform.
There are three main components to consider: The load balancer, the listeners, and the target groups. I wrote in detail about this in my previous article, so…
I develop software for a living. Then I go home and I continue reading about software, because I just cannot get enough. Nowadays I work for ThoughtWorks.