Posts

Modern software does not exist in a vacuum, developers always rely on other developers or engineers to provide aspects of their systems. Even if you write hello world in your programming language of your choice you likely still depend on the standard library from your language. Even if you were to write hello world in the raw binary format of your assembly language, you still depend on the operating system. Even if you wrote your own uni-kernel to produce hello world on the console, you likely rely on vendor provided firmware to initialize the program or memory. And if you are one of the blessed few who can completely fabricate your own hardware and don’t need to rely on vendor provided firmware, you likely don’t have time or expertise to write efficient higher level systems and need others to provide software to run on your hardware. Therefore the question is not will you use dependencies, but how will you use them responsibly.

So you are developing software, and you need the software to build for multiple difference machines, with different version of a library, or with just different compile time options. You can probably manage this by hand, but it very quickly gets out of hand. Spack is a package manager designed for high performance computing, but I would argue is more broadly useful for five reasons:

Should a software design be strong or robust? This is a debate that seems to have been developing in recent years with the recent proponents so-called “strong-typing” advocating new API designs. In this post, I go a little into the debate and discuss its consequences.

There is a constant problem with programming language design: fast, generic, easy to write; pick two. The principle is that programming languages cannot be all three at once. Code that is Fast and Generic like C++ isn’t exactly easy to write. Code that is Generic and easy to write like Python isn’t always fast in the sense that C/C++ programmers mean it. Code that is Fast and Easy to Write isn’t always Generic in the sense that Python is. There is a new language on the block – Julia – which strives to challenge these assumptions. In the remainder of this post, I highlight what I like about it and describe my experience using it over the last semester.

So you know you need a configuration management system and you have an idea of which one will work for you. So what should I think about about before deploying one of this systems? In this third and final post in this series, I present some suggestions about using these systems in a way that is flexible and scalable to larger numbers of systems.

So, you need a Configuration Management System, so which one do you choose? This post is the second in a three part series on configuration management. In this post, I’ll highlight the strengths of these systems and their respective weaknesses.

Configuration Management Systems like Ansible, Chef, Puppet, and SaltStack are in my opinion are nearly essential if you find yourself managing more than 5 machines. But what exactly are they, which is better for my circumstances, do I still need them if I use a container based infrastructure, how do I get started? This post is the first in a series of posts that will attempt to answer these questions.

GPU programming has the potential to make embarrassingly parallel tasks very quick. But what if you want to perform the same task on a variety of different types? In this post, I walk through a generic testing code that preforms a vector add on GPU and CPU to verify the correctness.

Over the last two months, I spent a significant amount of time using Clang’s libtooling. Libtooling is a great way to quickly develop tools to analyze and modify large quantizes of C++. In this article, I share some lessons learned working with libtooling.

Ever notice that every matrix and graph library seems to have a different interface for constructing matrices? Also notice that each only only supports some subset of common matrix formats? With a little help from the Adapter and Builder design patterns we can actually solve this problem.