In the recent past, I've been bitten by the Chef virus and I've used it to install and configure my Mac. The parts of that setup are described in detail in this blogpost: Automating the Setup of My Perfect Developer Environment on OSX 10.8 Mountain Lion.

Central in this story was the pivotal_workstation project, this project by Pivotal Labs is used to setup the developer workstations at Pivotal Labs, and as such any and especially my involvement with the project was limited to writing new recipes within the structure and behaviour that was predefined.

While learing more about Chef and Ruby in general, I learned that their default framework had some issues, or at least so it seems to me. The most important were that there was almost no use of community cookbooks and, since it is used in “production” at Pivotal Labs, the potential for large scale changes is limited. For example there is no room for a full Linux support, big changes that need integration in the Pivotal workflow are slow to get merged, etc. This is obviously understandable, but limiting what I wanted to do.

A while back GitHub released Boxen. Boxen has the same goals as pivotal_workstation, but uses Puppet. Where Boxen excells was in the delivery method (one line installers, dependency management) and the cleanliness of the manifest files. But unfortunately, it also has some issues I cannot look past. First off, I want to use tools like rbenv/rvm and Homebrew like they are meant to be used, and not some weird custom setup. It also uses Puppet, and by no means faulting GitHub, Puppet or Boxen, but I just cannot get Puppet to do what I want, my bad, but it's the truth.

So I started to write Kitchenplan, and by write I also mean lots of copy/paste from other projects. Kitchenplan is based around a few basic principles. I want it's installation to be as flawless, smooth and easy as Boxen. I want it to be based on Chef, librarian-chef and soloist. I want to use as much community work as possible and make very clean and easy to maintain recipes. These recipes will also be as “default” as possible (so no special Homebrew installs), it should be able to support Linux and it shouldn't destroy your prompt and ruby setup if you sudo to another user.

It will inherit one flaw from both Boxen and Pivotal workstation, I will be using it to manage the workstations at Kunstmaan but I will try to keep everything as default as possible so it will port to another company easily. This is why I used a different org on Github to make it more generic.

At work I was looking for a way to write project documentation for several non-public projects. It was important for me to have a system that was versioncontrolled in GIT, written in easy to understand formatting for both technical and non-technical personel (markdown) and makes publishing effortless. The resulting documentation should also be easy to access for our clients, without resorting to getting them all an account.

In a presentation by Stephen Hay at the Mobilism 2012 conference I was pointed to dexy, an advanced tool for writing documentation in a lot of different languages, markdown being one of them. In this post I will describe how to setup dexy, and combine it with GitLab's webhook system to create a selfbuilding documentation system.

Ever since getting serious in documenting my install process for my developer machine, I've found that while executing the steps themselves is fairly quick, it still takes me hours to get all the other applications I use on a daily basis downloaded and installed. While browsing my Twitter stream, I came across the pivotal_workstation project on GitHub. While I had some experience with automated provisioning systems like Chef and Puppet, it never occured to me that it might be the solution to this exact problem. In this blogpost I will outline all the different components involved, how to setup your computer with these tools and how to contribute to make this project even better.

As a fan of the GTD and Inbox Zero methologies, one of my most used features is an easy way to convert emails to todo's. For a long time I used an Applescript I found on the Things forum. This script showed a nice Growl notification that a todo was indeed created. With the release of Mountain Lion the Growl notifications, and after the recent Growl release, the Growl to Notification Center, notifications just weren't as pretty as they used to be. So I created a new script today, to remedy this situation.

It has been a few months since my previous post about my perfect developer environment on OSX Mountain Lion, and a lot of the issues and problems mentioned in the previous post are no longer valid. So I decided to redo the guide to contain the latest and the greatest.

I'm a follower of the GTD and Inbox Zero philosophies. One of the mail features for me is that my to do's are synced across all my devices without manual intervention from me. There are two main competitors in the market Things and OmniFocus. I've got both suites across all my devices, but OmniFocus is ugly (yes, it matters to me) and since the ML release I keep losing the Things beta icon in my dock for some reason. So I set out to try the build in Reminders app.

Travis-CI is a hosted continuous integration service for the open source community. It is used a lot for testing Symfony 2 applications and bundles and is a lot more developer friendly than the good old Jenkins. During the weekend I wanted to run my Symfony 2 project through a real Apache with the different PHP versions Travis-CI provides. For future reference and because trying such a configuration is a lot of trail and error work, I've documented the result.

While I spent most of my time managing developers, I'm a programmer at heart and that means that if I can replace manual work with an application, I will. Call it lazy, or smart, you choose :). We are managing several shared and dedicated servers for our clients. To track the costs for each of those clients we need to split up the monthly hosting bill over these clients. For the dedicated servers to one client, the shared servers and shared costs over several or all clients. At the same time these clients need to be coupled to our billing application's project id. A hell of a job, that is in serious need of automating. In this post I will document the entire process of developing this tool so you can follow the process as much as the result.

In my previous post I already touched upon the subject of tuning Sublime Text 2 so it becomes an even greater editor.

While browsing GitHub I came along this great repository where Zander Martineau lays out an enormous list of cool plugins for ST2. If you want the full story and walkthrough, read the readme of that repository, I will just summarise the install steps for my own convenience after a reinstall. I also added a few that were missing and left out some I don't use.

I'm a frequent reinstaller. There I said it. I can get a lot of entertainment by setting up my computer just the way I want it to be. This means that after a few tries i've got this thing covered and it is time to share it with the world. For the record, I'm not going into the process of obtaining and installing OSX, you need an Apple Developer account for that, and if you do have one, you know how to install it.