Home » 2013 » July

Twitter Bootstrap 3

It looks like Twitter Bootstrap 3 is just around the corner! I’ve been using Twitter Bootstrap 2 for an internal project and have used it for other quick prototypes as well (including the first Twitter Bootstrap). It’s an awesome framework for quickly putting a nice looking user interface together.

Version 3 promotes itself as mobile-first. Which I guess is getting more and more important these days.

At a first glimpse it looks like for Twitter Bootstrap 2 users the grid system has changed the most. The default style has changed a bit as well. No more gradients and box-shadows as well (but it seems they will come back). Though you can always add them back I liked the default style of version 2. A full list of changes can be found at Github.

A post with the best new features in Bootstrap 3.0 gives more in depth information on what changed. Good stuff!

Server provisioning: my experience with Puppet and Chef

Server provisioning tools such as Chef and Puppet make it easy to automate installation and configuration of your servers. I’ve used both now in two projects where they provisioned my virtual servers built with Vagrant.

I’ve first heard of Chef and Puppet when I started using Vagrant. With Vagrant you can quickly get a virtual server up and running for your project. In its most basic form Vagrant can execute a shell script in which you setup your server. Because this is a bit limiting it’s interesting to look into a more automated provisioning process.

Just over a year ago I started using Vagrant for Maximus and after giving both Chef and Puppet a quick review I decided to go with Puppet. At the time I thought it looked easier to use and it had lots of modules available for installing software.

Earlier this week I decided to add Vagrant to a new project of mine: a small and simple CRM system which is adapted to my workflow, and decided to give Chef (Solo) a try. At first Chef looked like a lot more hassle than Puppet, but that’s mainly because you start off with a big chef directory just to get started and cookbooks have a folder hierarchy of their own as well. In contrast, with Puppet modules basically have a files, manifests and templates directory.

If I compare my experience between Puppet and Chef I had more trouble setting up my Puppet manifests than I did setting up my Chef cookbooks and recipes. I’ve found Chef cookbooks easier to use than Puppet modules. Mainly because configuring software with Chef seemed a lot easier. Maybe that’s because the available Chef cookbooks actually provide this functionality as it seemed totally absent in most Puppet modules I’ve come across. Maybe it was there but I couldn’t find it. That’s another thing, the Chef cookbooks seem to be better documented than the Puppet modules I’ve seen. One thing I do like about Puppet is that you can define dependencies between every step or command you want to run. I’m not sure if Chef supports this as well.

Just to make clear, my experience with Puppet and Chef is limited and I currently don’t use it to provision servers used in production (at least not yet, but I’m sure that’ll change in the future). This is just based on my experience. If you’re interested in these tools I suggest you try them both to see what it’s all about. They both have a solo/standalone version which doesn’t require a main server where your cookbooks or modules are stored.

One great resource of getting started with Chef can be found at Christopher H. Laco’s website.

Pulling the plug on Maximus, the BlitzMax Module Manager

A couple of weeks ago I talked about the future of Maximus and said that I would inform you about my decision once it was made. I’ve come to a decision about Maximus and have decided that I will pull the plug on it. I just don’t know when yet.

For the time being the website will stay online but I’m no longer making an effort in keeping it up and running. As soon as I need the server resources that Maximus is currently taking I’ll be shutting it down.

There’s a slight chance I’ll move Maximus to my local homeserver which isn’t always available. The only reason I would do this is so I’ll still have a hosted module repository in case I want to use BlitzMax again. But considering I haven’t touched the language in a while I’m not sure yet.