The Python community is abuzz with excitement about better async support. If you have an existing service, you might wonder if you’re missing out. Benchmarks show higher throughput and promise the ability to handle more requests with less hardware. Will a switch to async be a free lunch for your existing service?

As often happens, the reality differs from expectations. Unless you run in a highly distributed environment and your service is the bottleneck, needing 10 instances just to keep up with all the traffic, you probably won’t see the benefits that most benchmarks promise. In fact, you might see worse performance by switching.

In the last part we covered all the fundamental techniques in writing macros. This enables us to write just about any macro we could think of, but knowing a few tricks can make the process much easier.

In this part, we will build on our where clause from the previous article. In the process we will allow the where clause to support multiple comparison operator (instead of just =) as well as multiple ways to join those operators (instead of just and).

In the last part we covered the very basics of macros and implemented a single argument query select. This was a good start, but only scratched the surface of what macros can do.

In this part we will implement multi-field select and a basic where clause. That will make our query macro far more useful.

Multi-field select

After being able to select one field, the immediate next thing that comes to mind is selecting multiple fields. Just like before, lets start with the invocation syntax:

Macros are required to do some very helpful things in Rust, but this isn’t an article about any of those things.

I became enamored with macros many years ago when I read Practical Common Lisp and saw the implementation of a SQL DSL that works with built in data structures. The whole implementation took less than a screen of code and absolutely blew away my expectations of what it took to create DSLs.

One of the most misused data structures is the humble map; hashmap, dictionary, hash table, etc.

It's a great data structure for quick storage and access of key value pairs. Unfortunately, because of its ease and availability, it becomes pervasive at jobs it has no business doing. The problem grows most visible in dynamically typed languages that make the map a first class citizen (Python, Ruby, Clojure, etc.), but it can creep up in any language.

I recently took over the maintenance of an open source Clojure project. One of the first things I noticed was the lack CI or CD. These are things that aren’t required but can save a lot of work, especially for a public project.

The CI portion helps make sure that all pull requests pass tests and conform to the project's coding style. The CD portion helps with deploying the project. And these parts become especially important if the project is in maintenance mode.

Distrobox is the single piece of software that completely changed the way I work. If you’ve hear of or used Vagrant and thought it was a great idea but implemented in a really heavy handed manner, then Distrobox is exactly what you’ve been looking for.

Within a month Distrobox became my primary dev environment and that hasn’t changed for over a year. In this post I hope to share how I use Distrobox and give you some tips for making the experience even better.

DRY has become a mantra throughout the industry. Any time repetitive code shows up, DRY gets applied as a cure all. If you even start to question DRYing up a piece of code, you are viewed as a heretic to the entire industry.

Ok, maybe it’s not that bad, but many times DRY gets applied without much thought. This careless application of DRY leads to brittle code, making even simple changes scary because they could have a huge ripple effect.

I recently started a new job that gave me the chance to run whatever Linux distribution would make me the most productive. In the face of complete freedom, I decided to re-evaluate my daily driver and see if there was a distribution that would give me the most up-to-date software while maintaining a stable system. The results of my search surprised even me.

Background

I have ran Ubuntu on my home lab server for over a decade, and used it a daily driver from 2009 to 2014. I switched from Ubuntu because their package release cycle, even on the latest version, is too slow for my liking. At around the same time, rolling release distros were gaining popularity. So I jumped on the Arch train.

When I started using lisp, I came from the world of modern dependency managers (npm, pip, maven, and the like). So I started searching for an equivalent in lisp. I quickly came across quicklisp. To my surprise, however, quicklisp worked differently than these packages. It works more like a dependency cache than true dependency manager, but that is a topic for another article.

The biggest struggle that quicklisp brought was managing local packages. quicklisp had no way to reference a dependency at a certain path, and couldn’t automatically import the project I was in. This is all for good reason since ASDF (the common lisp build system) allows a lot of freedom.