MacKuba

A few days ago I spent a couple of hours trying to install the full text search engine Sphinx on my work computer in order to use it in my current project. I’m posting the details here, maybe this will save someone some time…

Firstly, if you’re like me and you look for some kind of binary package (like .dmg) first – sorry, there isn’t one. This leaves us two options: compiling Sphinx manually from the source, or using a package manager like MacPorts. I always avoid the first method if I have any other option, so I tried the ports.

Here’s the first problem: Sphinx requires MySQL, and while I have it on the disk of course, I’ve installed it from a dmg package, not from ports – which means it’s in a different path than ports expect and they have no idea where that is. I got scary errors like:

$ sudo port install sphinx
---> Building sphinx with target all
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.​macports.​org_release_ports_textproc_sphinx/​work/​sphinx-0.9.7" && make all " returned error 2
Command output: sphinx.cpp: In member function 'virtual const char* CSphSource_MySQL::SqlError()':
sphinx.cpp:9397: error: 'm_tMysqlDriver' was not declared in this scope
sphinx.cpp:9397: error: 'mysql_error' was not declared in this scope
sphinx.cpp: In member function 'virtual bool CSphSource_MySQL::SqlConnect()':
...

I’ve read a lot about good programming practices recently. I’ve read the “Pragmatic programmer” book (which is awesome, one of the most useful books I have read, seriously); I’ve watched a great presentation “Craftsmanship and ethics” by Robert C. Cooper. And it seems that everyone seems to emphasize that one thing that is extremely important to write good software is writing unit tests (and writing them “all the fucking time”, as that black dude said in that presentation ;). I must admit I still haven’t had the courage to switch to TDD (although I try it for single tasks from time to time), and my test coverage is nowhere near what it should be ― it ranges from 20% to 80% depending on the project and its layer. But I know it’s important and I’m working on it…

Anyway, one day I had a thought: even if I test all models and controllers thoroughly, am I not leaving something out? Didn’t I forget about something that is a quite important part of the application ― about my JavaScript code? After all, it’s code too, right? And sometimes it’s very important code; and not having any tests for it means the code is very fragile, it’s easy to break things, already fixed bugs may reappear again, and so on. Of course, JavaScript may be harder to test, because it’s sometimes very closely coupled to HTML, but at least some part of it could surely be tested.

But how do you unit test JavaScript?… I had no idea how to do this.

So I started googling, and I found that there are plenty of different unit test frameworks for JavaScript. Of course I couldn’t resist and I had to take a look at every single one and compare them to choose the best one :) (I heard that it’s called “maximiser” and that it’s bad…). The result of this looking is the list below.

For the last 2 months, I’ve been using a new Ruby framework at work. A very… interesting framework :) It looked very promising in the beginning, only to become a complete disaster a few weeks later. I thought I could share some of my experiences with it here, although not to recommend it, but rather to warn you not to use it…

Its name is Hobo, which makes most people think of homeless people, and makes it a constant object of jokes in my company (see below :)…

A sign hanging in my room – copyright by Wombat

It seems that starting a blog was not the only stupid idea I had recently. I’m having more of those… For example, now I’m thinking about learning some Cocoa and writing some applications for the Mac :) I’ve been planning for some time to write something in Qt when I used Linux, but now it seems that although Qt has the advantage of being multi-platform, so I could write something that could be used on Windows, Linux and Mac, the disadvantage is that only a subset of Cocoa widgets are available in Qt; I couldn’t use some of the things I saw in native Mac applications, and because of that, my applications would be less “macish”…