Posted on 3rd January 2010. Tagged as tips, osx, mac, desktop, virtualbox
When I'm developing, I try to continuously deploy to a realistic environment as often as possible. This means a Debian server running a stack as close to production as I can get. Of course, I don't deploy to the actual production servers (a lesson I've learnt many times over), so I virtualise a Debian box and clone package set from the production server. Combined with bridged networking and a quick hosts file change, and I've got a production-equivalent server always available at server.local.
Hence, I use VirtualBox all the time on my Mac, and I've got at least one server instance running all the time. But the Virtualbox.app clutters up the dock, and I really just want the instance available via SSH, I don't care about actually seeing its framebuffer.
Fortunately, you can run headless Virtualbox instances on OSX. It just takes a little extra work. Assuming you installed Virtualbox in the default location, headless Virtualbox binaries live in:
$ ls /Applications/VirtualBox.app/Contents/MacOS | grep "VBoxHeadless"
VBoxHeadless
VBoxHeadless-amd64
VBoxHeadless-x86
VBoxHeadless.dylib
You can easily run an instance in headless mode by specifying the unique name of the VM on the command line (replace "Debian Server" with the name of your VM):
/Applications/Virtualbox.app/Contents/MacOS/VBoxHeadless --startvm "Debian Server"
Of course, it's a pain to have to start these instances each time you boot the host system, but you can have the VM start on login by adding a LoginHook. Here's how:
sudo defaults write com.apple.loginwindow LoginHook /Applications/Virtualbox.app/Contents/MacOS/VBoxHeadless --startvm "Debian Server"
If you want to stop the VM, just use whatever ACPI shutdown method the guest instance provides (for a Debian server, sudo /sbin/init 0 will suffice), and the VBoxHeadless process will silently quit. If you're virtualising a graphical OS, like Windows, you should probably check the documentation to use with VBoxHeadless; you can easily specify a VRDP address so you can connect to the instance via any RDP client.
Posted on 1st January 2010. Tagged as django, python, debian, osx, emacs, personal
Like nearly everyone else on the planet, I've spent some of today thinking about how I can do better next year. My resolutions are roughly split into two categories; tech stuff, and everything else, which makes sense considering I spend at least half of my waking hours in front of a computer.
Since I can remember, I've compulsively tinkered with the computer in front of me; changing hardware, changing operating system, experimenting with different editors, different languages and different organisational systems. I'm a classic computing dilettante, I have a very broad knowledge and very shallow of many areas of programming and administration, but no real expertise anywhere. This bleeds into my choice of environment; I'm forever switching tools and languages trying to find the perfect tool. After years of searching, I've not come any appreciable distance nearer to that goal, so it's time to stop trying.
From what I can tell, this is a fairly common disease among programmer types. Some may tinker with software, some with their time management system, but the problem remains the same; we are wasting time trying to perfect a system which will never be perfect.
So, the main tech resolution I've made is to stop trying new things. This has been happening naturally over the last few years anyway, it's probably a combination of age and habit, but I'm going to endeavour to ignore new software, new methodologies and new trends in the coming 12 months. For the next year, I'm going to use the following tools, without deviation:
- OSX Snow Leopard on my laptop, Debian Lenny on the servers. I already know these platforms, they're both stable, and I have no reason to try anything else. I'm often tempted to try the latest releases of operating systems, which inevitably results in a week of lost productivity. As far as I know, there is no scheduled OSX release in 2010, and no release date has yet been set for Squeeze.
- TextMate. I've spent about half of 2009 using Emacs, but the power of Emacs comes at the expense of distraction; the hours I've spent writing elisp to try to save myself 10 seconds here and there far outweigh the actual time saved. TextMate is stable, the next release is a long way off (in fact, the TextMate 2 FAQ says it's coming when we get Duke Nukem Forever, so I guess that means never), and the lack of customisability compared to Emacs means there's just less to tinker with.
- IPython. I've spent far too long investigating other Python Repls, and while bpython is nice, IPython and ipdb.set_trace() have become so ingrained in my muscle memory that changing to anything else isn't worthwhile.
- Django. I'm not sure exactly how the roadmap for Django is laid out, but I suspect the 1.2 release will be with us for most of 2010, and Django is adequate for all the work I'll be doing with 84labs in the next year. I've toyed with Kohana, Rails and Seashore in the last year, and none of those brought any significant benefits over Django that would be worth holding on to.
- Safari. Safari is the most pleasant browsing experience to use on OSX. 2009's development of the Web Inspector removed any real dependency I had on Firebug, and combined with ClickToFlash and /etc/hosts level ad blocking, I've no need to use any other browser. Thankfully, I very rarely need to test my work in other browsers, so while I'll probably keep around a Firefox installation, it's very unlikely that it'll become my browser of choice again.
So, that's it. We'll see in 2011 if I'm still using this software (that's where the 'resolve' comes in), but I'm looking forward to gaining at least a week or two of productive work simply by keeping a static environment.
Will anyone else commit to joining me?
Posted on 25th October 2009. Tagged as event, barcamp, testled
I've just finished at Barcamp London. It was worth going, but very busy, probably a little too busy. There were so many rooms that I had to choose between two good talks in each session, which was great for the event, but not so easy for me.
The standout sessions were the elevator pitching practise, which was a lot of fun once the room warmed up a little, and it's definately an idea which I'm going to steal for Barcamp Manchester. Less fun, but nevertheless interesting was the session on the new Paypal APIs. We've been considering moving Testled's payment provider to Amazon's Flexible Payments Service, but it looks like in a few weeks we'll be able fulfil all of our requirements (mainly on-site micropayments) without changing provider.
Also, a quick note to those attending Barcamp Manchester, Testled are again sponsoring a small part of the event, so we'll be bringing yet more of our popular blue lollipops. I bet you all can't wait.
