Caddy – The Ultimate Server with Automatic HTTPS

Great things are easy to get used to.  When something works the way you want it, and does so for a long a time, it is inevitable that one day you’ll stop thinking about it altogether and accept it as a given.

Apache was a great web server, until Nginx came along.  All of a sudden, it became obvious how much faster things could be, and how much simpler the configuration file is possible.

For the last few years, Nginx was working great for me.  And now that I came across Caddy, I realized that life can be a lot simpler.

Caddy web server

Here’s a bit to get you started:

Caddy simplifies your infrastructure. It takes care of TLS certificate renewals, OCSP stapling, static file serving, reverse proxying, Kubernetes ingress, and more.

Its modular architecture means you can do more with a single, static binary that compiles for any platform.

Caddy runs great in containers because it has no dependencies—not even libc. Run Caddy practically anywhere.

Seriously? We now have a web server which handles HTTPS with automatically renewed certificates (yes, Let’s Encrypt) out of the box… Mind-blowing.  I guess, 21st century is indeed here now.

What else is there?  Well, let’s see:

  • Configurable via RESTful JSON API. OMG!  No more trickery with include files, syntax checking and restarts.  In fact, configuration files are completely optional, and even if you choose to use them, they just use the same API under the hood.  Bonus point: you can export full configuration of a running server into a file via a simple API call.
  • Extensible.  Yes, that’s right!  “Caddy can embed any Go application as a plugin, and has first-class support for plugins of plugins.”  Check out their forum for plugin-related discussions, or simply search GitHub for Caddy.
  • Supports HTTP/1.1, HTTP/2, and even HTTP/3 (ETF-standard-draft version of QUIC), WebSocket, and FastCGI.
  • … and a lot more.

Wow!  It’s definitely worth checking out.  While Nginx is not going to disappear (much like Apache being still around), Caddy might be a better option for your next project.

A practical guide to writing technical specs

Writing technical specifications is difficult.  Writing good technical specifications is even more so.  Here’s an excellent practical guide from StackOverflow on how to write technical specifications, which have everything needed, yet not being too excessive or vague.

In the comments, there are a few additional suggestions and links to other similar guides.

The only way this could have been better, if they included a ready-made template with all the described sections, so that one could just fill it in and be done with it.

MySQL, JSON, indexing and generated columns

For quite some time now I wanted to play around with the recently added JSON type in MySQL.  Finally, I have a project where MySQL version is high enough to support it, and the requirements are such that this choice makes sense.

The first impression was great – JSON type is basically LONGTEXT type with a bunch of added functionality to manipulate JSON data.  It took no time to setup tables and necessary queries to work with it.

The second iteration though raised a few questions.  Large tables, with complex JSON structures were rather slow in some of the more complex queries.  The first solution to look at was obviously indexes.  Turns out, MySQL does not support indexing of the JSON fields. Bummer.

But there is a rather elegant work around.  It involves another recently added feature, of which I haven’t heard about until today – GENERATED columns.  Think of table views, but on the column level, not table level.  And generated columns can be indexed.

In fact, there’s a whole lot that you can do with GENERATED columns in general, and JSON data in particular.  This blog post – “MySQL for JSON: Generated Columns and Indexing” – provides a great starting point with examples and explanations, including a scenario with the primary key of the table being a generated column, with the data from the JSON-typed column.

Awesomeness!

Tips for Implementing a Software Release Process

I came across this nice article outlining some of the tips for implementing the software release process.

Software Development process is not complete and mature without a well-defined release process for the software applications. Every software application needs to be delivered or deployed at some point in time and for agile projects, this is happening more often. Therefore, there is a need to maintain software quality across the application releases to avoid deploying untested or malicious code to production environments.

Defining a release process for software applications helps in ensuring that software releases maintain a constant release quality. In addition, software changes and new features are traceable or can be correlated to specific releases easily. As a result, changelogs and release notes are easier for a generation.

I do agree with most of what is being suggested. And if there’s one thing to add to these suggestions, it’d be a clear versioning convention. Personally, I’m a big fan of the Semantic Versioning.

Google Chrome Tab Groups

Thanks to this great tip I’ve discovered the recently added Tab Groups functionality in Google Chrome browser. All you need to do is navigate to chrome://flags/ , search for “Tab Groups” feature, enable it, and restart your browser. Once that is done, right-click on any tab and you’ll see the option to “Add to new group”. Any tab that is already a part of the group, can be removed from there and added to any other existing group.

It is possible to rename groups and assign each one a color. In the screenshot above you can see how my groups look right now. Yellow ALT, red LM, blue PP, purple TTM, and green BLOG are tab groups. A color running under tabs to the right of each group indicates which tabs are part of the group to the left.

Grouped tabs are also a lot easier to move around and separate into a new browser window.