My blog

Functional options is a paradigm in Go for clean and extensible APIs popularized by Dave Cheney and Rob Pike. This post is about the practices that appeared around the pattern since it was first introduced.

Go kit is often accused of being too complicated, at least compared to other libraries used for building applications. This post ought to explain the differences between them and demonstrate the thought process of building an application with Go kit.

Recently I migrated one of my libraries (Emperror) to a vanity import path. Although the migration itself was easy (took less than one day), making the decision, thinking it through from every angle to make sure existing applications don't break, wasn't. I did a lot of research to find the right migration path, URL, tooling and I decided to share my experience in this post.

In the last couple years RPC started to become popular again as a communication mechanism for web-based APIs. It's not a new concept at all, but it changed a lot over the years: the technology evolved, new IDLs and frameworks (like protobuf and gRPC) appeared. TwirPHP tries to bring this new tech to PHP by porting Twirp, Twitch's “simple RPC framework built on protobuf”.

Recently I was tasked with deploying and operating a Symfony application on Kubernetes. Since PHP is not my primary area of work anymore, I was hoping to find some up to date guide and/or best practices about the topic, but sadly that wasn't the case at all, so I decided to write about the process of containerizing the application, building up the infrastructure and deploying it on Kubernetes.

Every developer's nightmare is that his/her code crashes in production because of the (unexpectedly) high workload. When a new project starts, no one can predict precisely how many people will use it which makes designing the application and the infrastructure quite hard from a performance requirement point of view. Not to mention that there is not always … let me rephrase there is never enough money and time to create THE perfectly scalable and resource efficient software. But this can be a problem during the software's lifecycle as well, not just in the beginning: as the software evolves we need to be aware of it's limits. This is where performance testing helps.

It's been almost a year since we released the first stable version of HTTPlug so I felt like it's time to look back on what we've done so far and what's still ahead of us.