To my surprise I hadn’t even announced here that I have recently started freelancing! As of August the 1st I now operate under the name Kras IT and am available as a freelance developer. Since it’s now the 1st of September this means I’m already in business for a month now which has been exciting. I’ve been with my previous employer for almost 7 years and after a lot of thinking and planning I decided to take the leap!
As a freelance developer you can hire me for all your PHP and Perl work. I mainly do webdevelopment but I do a lot of backend as well. Aside from that I also enjoy configuring Linux servers. I personally think being able to configure and optimize both your app and the server(s) the app is running on can be a great asset, as it gives a lot more insight in the overall workings of your software.
Aside from doing freelance work I also plan on doing product development. I’ve got a few ideas in the pipeline of which one I expect to launch within 5 months. I’m likely to blog about this in the near future as well as about freelancing and running your own business.
For a full list of skills you can take a look at my website at Kras IT. Currently the website is still Dutch only but my LinkedIn and résumé are in English. Do you’ve got any questions or are in need of a freelance developer? Feel free to contact me!
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.
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.
In the last 8 weeks or so I was working together with 3 other students researching some of the possibilities of the Raspberry Pi and what it could offer the school for future education and research purposes. The results of the many small research subjects came together in a remote controlled boat.
Sadly due to me getting sick this week I haven’t been able to properly finish the project myself, but the other team members were able to though.
The boat’s (server) software is a Python app running on the Raspberry Pi (model A). This app is responsible for communicating with the Arduino through I²C and basically tells the Arduino which channels to modify. The Arduino runs a simple C program for this. There are 2 separate motor controllers which are connected to the Arduino. The rudder is a single servo which is also connected to the Arduino. Initially we had planned on mounting a camera on the pan-tilt mechanism which is located up front, but the ideas we had for implementing computer vision didn’t quite work out. The pan-tilt mechanism has two servo’s, both connected to the Arduino. So in short the Arduino drives all the hardware and the Raspberry Pi tells the Arduino what to do.
The Arduino itself is ‘mounted’ to the Raspberry Pi with the use of a custom made connector board. The Arduino is placed on top of that. On top of the Arduino is a custom made shield which has pins for connecting the motor controllers and servo’s and powers both the Arduino and Raspberry Pi.
We decided to call it the Stackberry Pi.
Here’s our workroom where the boat was being worked on.
And finally its first test run!
But motionless pictures are no fun. Here’s a video of the boat’s first test run.
In case you’d like to hear more details about the boat please do ask.
Whilst I was busy trying to optimize a MySQL query I got annoyed by the fact that when you make use of MySQL’s query cache that a query gets cached. When that happens a second time you execute the query it’s being looked up and the cached results are being returned. If you want to optimize a query and test its performance this can be quite annoying.
Luckily I found out there’s an easy solution to this problem. Just make use of
SQL_NO_CACHE like this:
Now when you run this query it makes sure MySQL doesn’t store it in its query cache.