Felix Crux

Many years ago I laboriously ripped a collection of CDs (and a few cassettes) into digital files. It was already clear at the time that I wouldn’t want to lug discs around and that these newfangled “MP3 players” were on to something good.

Unfortunately, the hard drive space required to store my collection in a lossless format was far out of reach for me at the time, so I resigned myself to keeping everything as lossy low-bitrate MP3s. Later, a new free/open-source and patent-unencumbered format called Ogg Vorbis turned up on the scene, and my enthusiasm for it overpowered my horror at re-encoding from one lossy format to another, so I gritted my teeth at the quality degradation and converted everything.

Now in the present, Vorbis has been surpassed by Opus, FLAC exists, hard drives are cheap, and it’s time to start over.

Continue reading…

How do you follow your favourite online creators and their blogs, articles, videos, podcasts, comics, or what have you? How do you choose what to read when you have a few minutes to kill on the bus, or when you want to get caught up in the morning with a cup of coffee?

Most people hand this choice over to social media, inviting along the whole associated host of problems like clickbait; outrage amplification; snooping targeted advertising; radicalising rabbit-holes; echo-chambers and filter bubbles; algorithms choosing what to show you based on “engagement” rather than what you’d want for yourself; and on and on.

There’s a better way — and there has been for decades! Amazingly, it seems underused even within tech circles, and almost completely unknown to the general public. It’s super easy to use, actually more convenient than social media apps, and leaves you in complete control of what you see.

I’m talking, of course, about RSS/Atom web feeds, and I contend that they are not only a better alternative, but in fact I’d go so far as to say that a feed reader is the only tolerable and civilised way to read online! The system works really well and more in line with what (I think) most people actually want; it minimizes the use of harmful social media platforms; and it helps foster a more vibrant, independent, creative, and non-commerical Web. So drop your non-chronological algorithmically-obscured sponsored timeline, and let’s have a whirlwind overview of what feeds are and how to use them!

Continue reading…

One of my favourite features of the Firefox web browser is surprisingly unknown and sadly underused. Keyword search bookmarks let you kick off a custom search of any site straight from the address bar (a.k.a. the “awesome bar”). For example, if you typed “w hedgehog”, you could go to the Wikipedia page for the little critters, or “img hedgehog” could show you a cute image search.

Continue reading…

…or at least the best one I’ve managed to come up with.

The venerable cron utility has some well-known shortcomings, chief among which is how difficult it is to monitor the health and output of scheduled tasks. The default setup tries to email output, but on a typical laptop, desktop workstation, or even on many servers, it’s common to not have a working system-wide mailer configuration. Many users therefore set up “wrapper” scripts that handle logging, time­stamping, and so forth. This is the best one I’ve managed to come up with.

Continue reading…

The Ledger accounting system is a powerful (but not very easy to adopt) software tool for double-entry bookkeeping. It can be used for far more than just basic finances: tracking billable hours, calculating taxes and tithes, reporting on the asset class balance of your investment portfolio… almost anything you can think of — if you can figure out how to do it.

Most of the information I could find just presented a basic overview of the simplest possible use of the tool. The official documentation, on the other hand, is very comprehensive, but it's like being given a pile of logs and some nails when you're trying to find out how to build a house.

I therefore will be writing up a series of posts on “Ledger Practices”, describing how I actually use the system for intermediate-complexity personal accounting. These should be “recipes” for solving real problems or answering real questions using ledger.

Continue reading…

Last year at PyCon I organized a small Open Space event for OpenPGP key signing. Based on the success of that event I'm doing it again this year at PyCon 2015 in Montréal. We'll be in room 512cg at 18:00 on Saturday the 11th.

I wrote up a very short superficial guide that covers what this is all about, how to get started, how key signing happens, and where to go from there; you can read it here.

All are welcome, regardless of level of experience. Even if you don't intend to actively participate, feel free to come out to meet others and learn.

Corrections, additions, and comments on the document would be very welcome; it's just something that I wrote up quickly on the train, and so is bound to be incomplete.

When I was first introduced to Django, I found it so pleasant to work with, and so productive, that I ended up accidentally creating this site. I still stand by this first impression, and I still recommend and promote Django whenever I get the chance.

But sometimes it just isn't the right tool for the job. For a site like mine, which has essentially no dynamic content whatsoever, and is infrequently updated, it doesn't really make sense to keep up with the treadmill of updates, both to Django itself, and to the supporting infrastructure like the PostgreSQL database that sits behind it. Static HTML pages would be simpler to maintain, and, as an added benefit, load faster.

However, I didn't want to give up on some of the key parts of Django that really made my life easier. The templating system, for example, meant that I could tweak the look of the site and have changes consistently propagated across all pages, without manually updating each one. The automatic generation of RSS feeds was another nicety I didn't want to lose.

I therefore put together a system that allows me to retain the key benefits of Django, while producing an end result that is in fact a whole bunch of static HTML pages. It's called Transcribe, and it currently powers this site and a couple of others that I maintain.

Continue reading…

Makefiles are the granddaddy of build systems. Though falling out of favour relative to more modern systems like SCons and ant, make is still the lingua franca of software builds, particularly in the C and C++ parts of the open source world. Because of this, it is imperative to have at least a basic understanding of makefiles and their use.

There are plenty of tutorials introducing the fundamentals of makefile syntax, and a handful that show off some advanced features. There are very few, however, that actually show how to write a useful makefile, or that introduce makefile conventions and patterns. For me, this meant that writing makefiles became an arduous process of stringing together snippets from various places, and hoping they interoperated harmoniously. Frustratingly, I'd often learn of a new feature months later and rip out half of the file and replace it with a single line. Worst of all, I had no idea if what I was doing was “conventional” or even passable as a serious makefile.

Continue reading…

I am afraid that I have to admit that the development of this site has until now proceeded in what any programmer must consider a state of sin: it was not under version control. Sure, I had periodic snapshot backups, but forget about versions, branches, and reverts.

The reason for this is that I was under the mistaken impression that my VCS of choice, git, made it difficult to set up remote branches. I think my confusion stemmed from the fact that it is somewhat tricky to set up public-facing ones with good commit-access control etc (which is why GitHub is so great).

Now that I looked into it more, I find it's actually tremendously easy, and I've got a really great work-flow set up: I have a master repo on the server, a development repo on my laptop, and another one in the directory from which the site is served. I can make changes on my laptop (and thanks to the magic of makefiles and m4 macros, keep a separate dev config file), and then push those to the master repository. When I'm ready to launch, I just pull them to the serving repo and run a make prod.

Continue reading…