• Installing FreeBSD with a ZFS root on a PowerMac G5

    Suppose you have a nice PowerMac G5 big beast around and want to install a modern operating system on it. Suppose that you want FreeBSD to run on it. Suppose that you would like to use ZFS as much as possible, say to use the machine as a NAS. If all of the above apply to you, you have come to the right place! Read on for how I got FreeBSD 10.

  • Readability: Do not abuse classes as global state

    You know that passing state around different functions by using global variables is bad: it results in spaghetti code, it introduces side-effects to your functions and, well, is just bad practice. Then: don’t make the same mistake when using classes. The form this manifests in code is by having a particular class method (not necessarily the constructor!) initializing a member field and later having other unrelated methods querying the attribute “out of the blue”.

  • Readability: Dictionaries are not data types

    Yes: a dictionary is a data type. No: a dictionary is not a way to implement abstract data types; doing so is lazy programming and is asking for trouble later on. What do I mean by this? In Python and other similar dynamic languages, dictionaries are a mapping of keys to values that have no typing restrictions: the dictionary is heterogeneous, and a single dictionary can contain elements of different types both as its keys and its values.

  • Readability: Abuse assertions

    Assertions are statements to ensure that a particular condition or state holds true at a certain point in the execution of a program. These checks are usually only performed in debug builds, which means that you must ensure that the expressions in the assertions are side-effect free. Because assertions are only validated in debug builds, you can abuse them to make your code more readable without impacting performance and without having to write a comment.

  • Readability: Avoid comments

    One of the best things you can do to improve the readability of your code is to avoid comments. “Uh, what?“—I hear you say—”That goes against all good coding guidelines, which state to heavily comment your code!” Right. Except that the real goal is to have valuable comments only, and doing so is a (very) complex matter. The code should document itself at all times, and be crystal-clear at doing so.

  • Readability: Document your types

    Wow. The previous post titled Self-interview after leaving the NetBSD board has turned out to be, by far, the most popular article in this blog. The feedback so far has been positive and I owe all of you a follow-up post. However, writing such post will take a while and content must keep flowing. So let’s get back to the readability series for now. In dynamically-typed languages1, variable and function definitions do not state the type of their arguments.

  • Self-interview after leaving the NetBSD board

    *The decision to not renew my NetBSD board membership was bittersweet.* Let me put aside the Readability series posts for a moment while I recap how the two years serving the NetBSD Board of Directors have been. My term just finished a couple of weeks ago, so it is better to post this while it is still relevant. First, let me backtrack a little bit. A couple of years ago, I was nominated to serve the NetBSD Board of Directors.