Dion Moult Seriously who ever reads this description.

Things I should’ve done earlier.

On Linux, there are things that you know are better but you don’t switch because you’re comfortable where you are. Here’s a list of the things I’ve changed the past year that I really should’ve done earlier.

… would be interested to know what else I could be missing out on! :)


hari says: (1 February 2015)

nginx is a great webserver. Easy to configure and much more lightweight than Apache. I would choose it over Apache if I ever hosted on a VPS.

Dion Moult says: (1 February 2015)

Absolutely right, hari!

Only one issue: nginx is not too happy when presented with not-so-common HTTP verbs such as OPTIONS, which is a must-have when I’m developing a discoverable API. So I must live with having nginx proxy over to Apache … just for the API :)

Also, in an attempt to see if I could write a module for nginx to support OPTIONS (disclaimer: I don’t know C), I did peek inside the codebase and failed miserably. I did come across http://blog.schmichael.com/2010/12/28/noobs-guide-to-hacking-nginx/ – which has a lovely quote describing nginx:

Nginx is not “an established C project”, it’s the insane product of Igor’s twisted mind. It’s a brilliant totally asynchronous giant state machine – which is how it’s so blindingly fast – because everything is non-blocking, and everything is super efficient.

That said, half the efficiency comes because everything is totally open-coded. Every piece of state machine is right there in hand-spun C. Amazingly long-winded code, which makes it hard to understand immediately what’s going on if you don’t already have the entire state machine in your head!

hari says: (1 February 2015)

I know. A lot of clever stuff in C is very abstruse for even experienced programmers, let alone newbies.

But I am surprised at your choice of ‘make’. I am sure there are more modern and better build systems out there than GNU make.

Dion Moult says: (2 February 2015)

The choice of `make` is only understood by looking at what I switched “from”. In this case `phing`. Phing is an Ant-based (hence XML) build tool built in PHP and marketed towards the PHP community. While people familiar with Ant will feel at home with Phing, it has two disadvantages:

1. Building PHP apps is much simpler than compiled languages. A simple set of bash commands written in Make suffices rather than the complex setup that Ant works well with. This means that my Makefile ends up being much smaller and simpler.

2. It introduces PHP is a build-time dependency! Not only that, Phing is an uncommon tool so most developers will need pull it in before being able to build the software. This is very irksome.

So the choice of `make` is only limited to the PHP projects, which benefit from very simple bash instructions, conveniently grouped into targets.

Ant, cmake, et alternatives are still being used outside the PHP projects, of course :)

What would you recommend, I know you are doing Python?

Dion Moult says: (2 February 2015)

Worth mentioning that my current approach for Python uses make, and inside make it calls pex.

hari says: (2 February 2015)

I haven’t been coding lately, but when I do, I haven’t used any build tools in python projects. When I need to build any resources or stuff, I usually do a manual compile.

For redistribution I usually use the built-in distutils to create the distributable package and git for the source repository. Of course, I could also use pysetuptools as well.

Dion Moult says: (3 February 2015)

Ah OK – the projects I work on use CI, and expect daily deploys of multiple versions with their own dependencies on a single host, so the ability to package properly wrt virtual environments is very important.

Leave a Comment