• Introducing the FreeBSD Test Suite

    I joined the FreeBSD committer ranks a couple of months ago with the intention to equip FreeBSD with an out-of-the-box test suite and with a testing infrastructure. The time until now has been quite fruitful and I have been rushing to get something ready for you before the year end. [Continue reading]

  • Header files: Poor compilation times in C++

    Have you ever wondered why building C++ code is so awfully slow and, apparently, compilation times haven't gotten any better over the course of many years? [Continue reading]

  • Header files: Qualify your identifiers

    Apologies for the long pause in the header files series and in blogging in general. With the holidays in between and, especially, with my refreshed energy to do stuff in the FreeBSD and Kyua camps, I haven't had any reasonable amount of time to write. And, sincerely, with my very limited free time I really cannot cover it all. So... these days, coding it is thus expect a reduced blogging pace! [Continue reading]

  • Header files: Poor man's replacement for modules

    I don't like header files and, especially, I don't like having to use them to implement modules. When you have used a language that sports real modules —pretty much anything other than C or sh—, header files feel primitive. Well, they actually are primitive. [Continue reading]

  • lutok-0.3, kyua-testers-0.2 and kyua-cli-0.8

    Yesterday was release day: I pushed out Lutok 0.3, Kyua Testers 0.2 and Kyua CLI 0.8. [Continue reading]

  • Header files: Avoid C++ 'using' directives

    Following up on the previous C++ post, here comes one more thing to consider when writing header files in this language. [Continue reading]

  • Header files: C++ ipp files

    Hoping you had a nice holiday break, it is now the time to resume our series on header files with a new topic covering the world of template definitions in C++. [Continue reading]

  • Three productive days on the Kyua front

    This being Thanksgiving week in the U.S. and Google giving us Thursday and Friday off, I decided to take Monday to Wednesday off as well to spend some time hacking on Kyua — yes, finally, after months of being inactive. And what a three productive days! [Continue reading]

  • Header files: Self-containment

    The rule [Continue reading]

  • Header files: Multiple-inclusion protection

    Let's start the series with something simple: the basic structure of header files and why and how to protect against multiple inclusion. [Continue reading]

  • Header files: Series introduction

    As I started typing a supposedly-simple post on header files, I realized that what I was explaining could easily be split into various posts and significantly extended with additional content, so here comes a new (short) series on these special little files in the need of careful attention. [Continue reading]

  • Patch management with Quilt

    Creating and managing patches on top of a source tree maintained in a non-distributed VCS needn't be hard. Some people handle this with Git, but I use a tool that seems to have fallen in disuse but was once very popular to create patchsets against the Linux kernel: Quilt. [Continue reading]

  • How to add the Mac OS X screensaver to the dock

    For various reasons, I have trained myself to lock my computer's screen as soon as I vacate my seat every single time. This may seem annoying to some, but once you get used to it it becomes second nature. The reason I do this is to prevent the chance of a malicious coworker (or "guest") to steal my credentials at work. [Continue reading]

  • Joining the FreeBSD committer ranks

    About 11 years ago, I had the honor of becoming part of the NetBSD developer team. A week ago, the same offer was extended to me for FreeBSD and I could not refuse it... so, as of two days ago, I am jmmv at FreeBSD and will be working in src! [Continue reading]

  • Production software: Series wrap-up

    We have reached the end of the Production software series. Before moving onto other topics, let's wrap it up as is customary by listing all the posts so far: [Continue reading]

  • Production software: Identifying your builds

    The scenario of the day: a binary you deployed to production two months ago has been running fine and dandy since then... until today, when the report of a strange and concerning crash arrived. Nothing really unusual: these things happen all the time and need to be dealt with. [Continue reading]

  • Production software: Logging

    Quoting the Wikipedia as is becoming customary: logging is the cutting, skidding, on-site processing, and loading of trees or logs onto trucks or skeleton cars. [Continue reading]

  • Production software: Hide new features behind flags

    Following on the topic of run-time changeability from the previous post, it's now the time to talk about new features and the process of deploying them. [Continue reading]

  • Production software: Constants will bite you

    Early on in your career as a developer, you are told to never put constant values in the code and instead define those separately using a self-descriptive name. For example, instead of doing this: [Continue reading]

  • Production software: Be wary of assertions

    As the Wikipedia puts it (emphasis mine): [Continue reading]

  • Production software: Series introduction

    Hello again! [Continue reading]

  • EuroBSDCon 2013 takeaways

    EuroBSDCon 2013 is done. If you have been following my daily posts over the last 4 days (day 1, day 2, day 3 and day 4) as well as #EuroBSDCon updates in Twitter, you may already have a pretty good idea of what went on here. However, with the conference over, it is now a good time to recap the whole event and present the takeaways of these four days which, overall, were quite interesting and productive. [Continue reading]

  • Live from EuroBSDCon 2013, day 4

    Live from Malta today attending the EuroBSDCon 2013 conference. The conference is over; today was the second and last day and it has just finished. [Continue reading]

  • Live from EuroBSDCon 2013, day 3

    Live from Malta today attending the EuroBSDCon 2013 conference. Today is the first day of the conference itself. Many more people have shown up as expected and there have been tons of very interesting talks all the time. It is both good and bad that there are several tracks: you can select the topic you are most interested in, but sometimes great talks overlap! [Continue reading]

  • Live from EuroBSDCon 2013, day 2

    Live from Malta today attending the EuroBSDCon 2013 conference. Today is the second day of tutorials, still overlapped by the second day of the FreeBSD devsummit and the only day of the NetBSD devsummit. [Continue reading]

  • Live from EuroBSDCon 2013, day 1

    Hello everyone! Live from Malta today attending the EuroBSDCon 2013 conference. [Continue reading]

  • Novel color scheme for xterm

    Almost two years ago, I stopped using white on black terminal windows. I found that such a setup strained my eyesight significantly and disturbed my focus. However, the complete opposite — black on white — is not much better after staring at the screen for hours: a yellowish tinted background works much better in my personal case. [Continue reading]

  • CLI design: Series wrap-up

    The time to conclude the CLI design series has come. I hope you have enjoyed the topic and that got some useful tips and tricks for your future developments! [Continue reading]

  • CLI design: Consider interactive prompts twice

    While it is a rare thing to find, CLI-based applications can be interactive just like any other kind of application can. If you choose to interactively query the user for details in your program or script, you should be aware of the two scenarios that can result from this choice (which, interestingly, are the same scenarios that we already saw regarding output verbosity). [Continue reading]

  • CLI design: Screen wrapping

    In a world of terminal emulators within graphical environments, there is no longer a "standard" window size. 80x24 is still the default, sure, but it's trivial for users to resize the terminal. Why does this matter? [Continue reading]

  • Adding The Julipedia to Technorati

    Dear readers: I have registered this blog in Technorati and I am now in the process of claiming ownership. For this reason, I need to create this post with the corresponding claim token in it: [Continue reading]

  • CLI design: Handling output messages

    Your CLI-based program has to communicate with the user. The most obvious case is to display error or warning messages, but in some cases it is also to report progress status. There are a few details to be considered in this area. [Continue reading]

  • CLI design: Single-command interfaces

    In the previous post, I provided common guidelines on how to implement a subcommand-based interface. It is now the time to look into the interface of those applications that implement a single command or function, which are actually quite abundant. Without going too far, you will encounter cp, ls and sudo, all of which are just a tiny sample of tools that fit this model. [Continue reading]

  • CLI design: Subcommand-based interfaces

    Subcommand-based interfaces are common: the majority of the CLI tools that provide more than one operation within them expose their features in this manner. Examples of such interfaces include svn, git, ifconfig, yum, apt-get and many, many more. [Continue reading]

  • CLI design: Do not reinvent option parsing

    In the previous post, we saw what good and bad use cases for flags in the interface of a command-line application are. We talked about the theory, so it is now the time to talk about the implementation details. [Continue reading]

  • CLI design: Putting flags to good use

    As the Wikipedia puts it in its Command-line interface page: [Continue reading]

  • CLI design: Requesting and offering help

    Any CLI application must offer help to describe its command line syntax: the flags it supports, the subcommands it implements, the meaning of the positional arguments, etc. Failure to do results in an application that is completely unusable: unlike GUI applications, the interface of CLI tools is not discoverable without instructions. [Continue reading]

  • CLI design: Error reporting

    Error reporting is a tricky business. Get it right and your users will be able to correct their actions quickly. Get it wrong and you will be the cause of your user's frustration — because, face it: A) users will make mistakes and B) your application will encounter erroneous conditions due to bugs or unpredicted scenarios. [Continue reading]

  • CLI design: The CLI is the presentation layer

    Treat the code that implements a CLI utility to the highest standards. [Continue reading]

  • CLI design: Series introduction

    Ready for a new series? [Continue reading]

  • Writing good release notes

    As the developer of a software package, you have just finished preparing a shiny new release. No matter how big the release is, you obviously want your users to upgrade so that they can experience all the new features and bug fixes — or, rather, witness the results of your hard work. But how do you convince them to do so? [Continue reading]

  • Top 5 tips to write great commit log messages

    Writing commit messages is something that every programmer has to face at some point. It may be as early as when starting to contribute to an open source project from home or it can be as late as when joining a job where the development team uses a Version Control System (VCS for short). (Off topic tip: if an open source project or a job you join do not use any VCS, consider twice thrice if you want to do so.) [Continue reading]

  • Readability: Series wrap-up

    That's it! After two months worth of posts, it is time to part with the the readability series. We have covered a lot of ground with these 14 posts: from mundane things such as blank lines and spelling to deeper topics involving dictionaries and global state. [Continue reading]

  • Readability: Narrow try/catch blocks

    Try/catch blocks (or try/except, or whatever they happen to be named in your favorite language) are the mechanism by which you capture exceptions raised by a chunk of code in a controlled manner. Within that chunk of code, it does not matter which line throws the exception: any exception specified in the catch statement will be captured, and it is "impossible" to know at that point where it originated. [Continue reading]

  • 'Hello GitHub!' say shtk, sysbuild and sysupgrade

    Over a year ago, I developed two command line utilities for NetBSD (sysbuild and sysupgrade) and a supporting library for the two tools (shtk). These were all introduced in their corresponding blog posts —Introducing sysbuild for NetBSD, Introducing sysupgrade for NetBSD and Introducing shtk— and since then I have heard good comments about them. [Continue reading]

  • Readability: Don't modify variables

    Single assignment says that a variable should only be assigned a value once; i.e. a variable should only be initialized and never modified later. This could be said to be a property of functional programming —never mind that it's used in compiler optimization a damn lot— so it may sound a bit out of scope in a readability post. Not really. [Continue reading]

  • Readability: Conditionals as functions

    Conceptually, there are two kinds of conditional statements: ones that compute —or affect the computation of— a value and others that guard the execution of optional code (e.g. functionality enabled by a command-line flag). In this article we will focus on the former kind. [Continue reading]

  • Readability: Explicitly state complementary conditions

    In the most basic form, a conditional has two branches and the conditional expression inspects a single variable on entry. For example: [Continue reading]

  • Putting a PowerMac G5 to good use

    A few months ago I bought an old PowerMac G5 off of Craigslist and since then I have been experimenting with various operating systems and configurations. Before I tell you more about these, let me briefly explain why I got such a machine. [Continue reading]

  • 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. [Continue reading]

  • 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. [Continue reading]

  • 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. [Continue reading]

  • 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. [Continue reading]

  • 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!" [Continue reading]

  • 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. [Continue reading]

  • Self-interview after leaving the NetBSD board

    The decision to not renew my NetBSD board membership was bittersweet. [Continue reading]

  • Readability: Mind your typos and grammar

    I can't claim to be an expert writer — not in English, and not even in my native languages — but I do put a lot of attention to whatever I write: emails, presentations, letters and, of course, code. As it turns out, code has prose in it most of the time in the form of comments and documentation. [Continue reading]

  • Lutok 0.3 released

    Lutok 0.3 was released yesterday evening. The packages in pkgsrc-current, Fedora 19 and Fedora rawhide have all been updated accordingly. [Continue reading]

  • Readability: No abbreviations

    When you are writing code, it is very tempting to shorten the names of functions and variables when the shortening seems blatantly obvious. All of us have, at some point, written calc_usage instead of calculate_usage; res instead of result; stmt instead of statement; ctx instead of context; etc. The thought goes "well, these abbreviations are obvious, and I'll be a much faster developer!" Wrong. You might think you are faster at typing, but you don't write code in one go and never ever get back to it again. As we have already mentioned, code is usually only written once and is later read many times, possibly by people other than the original developer. At the very least, I'd expect you going over your code once before checking it into your repository. Spending the extra minute it takes to write words in full will benefit you and your readers. [Continue reading]

  • Readability: Blank lines matter

    Vertical spacing is important for readability reasons: group together pieces of code that should not be split apart, and otherwise add blank lines among chunks of code that could be easily reordered and/or repurposed. That's a pretty loose suggestion though, so let's look at some specific situations in which you want to consider your vertical spacing practices (both adding and removing). [Continue reading]

  • Readability: Blocks and variable scoping

    In a dynamically-typed language, it is common for the scoping semantics of a variable to be wider than a single code block. For example: in at least Python and the shell, it is the case that a variable defined anywhere within a function —even inside conditionals or loops— is reachable anywhere in the function from there on. [Continue reading]

  • Readability: Series introduction

    Dear readers, [Continue reading]