MacKuba

Yeah, I know that there’s already about 5.4 gazillions of such posts on the web. So what :) I believe that cool apps – especially cool free apps – deserve promotion like this; and although some of the apps listed here are rather well known and popular, some are not.

Most of these apps are free; it’s not like I can’t afford 0.79 €, but I’ve been a Linux user for a few years and I got used to the “free / open source = good, paid = evil” way of thinking. It’s slowly changing, but I still prefer a good free app to a great paid app – unless there aren’t any good free apps available.

I haven’t included any games here – the reason is that I don’t play them a lot on my iPhone; I just don’t have time for that. The only times when I want to play games on it are when I have a bit of time and completely nothing else to do – but in such cases simple logic or board games are enough for me.

So here’s the list (in a rather random order):

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()':
...

For the last 3 months I’ve been working on a new web application at work. It’s quite unique in some regards, from the architecture perspective; the biggest difference from other projects that I’ve worked on is that almost entire page is one huge embeddable “widget”. This requires a completely different approach than I usually use:

• a lot of the code above the model layer is moved to the client side (i.e. JavaScript); this means that controllers and helpers are rather simple, controllers mainly return JSON, and there’s quite a lot of JavaScript to write
• since a significant part of the system is written in JavaScript, it needs to be unit-tested too
• I have to be very careful not to cause any JS, CSS or DOM id conflicts between the embedding site and the “widget“ (which includes such things as keeping all JS code in a single global namespace, and using jQuery in the “noConflict extreme“ mode through an alias)

Another thing, which I’d like to write about today, is the way the views were implemented in this project. Since entire GUI is created dynamically by JavaScript, I had basically two options:

• render the views in Rails with ERB and send big chunks of HTML via AJAX to JavaScript;
• or make Rails send only data as JSON, and render the views on the JavaScript side.

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.

As I’ve promised in the previous post, I’ve started working on my first iPhone application, the Blip.pl client, which I’ve given an extremely creative name, xBlip :) (why “x”? that’s simple, because “i”, “m” and “a” were taken, “i” even twice :).

A few screenshots from the current version:

For the last few months, I’ve been spending a lot of time learning how to create apps for the Mac. Since I’m slowly starting to run out of new tutorials to read, I’ve decided to find myself something new to learn ;) Well, not completely new, actually, as a lot of that knowledge about Cocoa is going to be very useful.

I’m talking about iPhone development, of course. I bought an ebook about iPhone SDK from Pragmatic Programmers some time ago, which looks very promising, but I didn’t really start learning, because I wanted to get the iPhone development certificate first, and that took some time. You see, Apple’s platform is so damn open that to install even a “Hello world” on your own phone, you have to have a set of certificates from Apple, which they give you only after you register for an “iPhone developer program” which costs 100$. Really, guys, this is not how you attract developers to a platform… :\

Anyway, I got the certificates now, so I was finally able to run the “Hello world” on my phone :) Here’s a proof:

Photo by Alexander Staubo (CC)

Some time ago I wrote about all the things that I loved in the Cocoa framework. This time, I’d like to write a bit about the worse side of Cocoa – the things that annoy me, confuse me, and make me wonder who the hell came up with such an idea…

So, the things that dislike in Cocoa are:

• Long names. I know, some people say that explicit is better than implicit, also, there are no namespaces in ObjC, which may explain some of that. But I’ve seen names which really belong on The Daily WTF. The longest I’ve found so far is “NSManagedObjectContextObjectsDidChangeNotification” (51 characters), and I’m worried that this might not be the longest one yet… Are you telling me a name that takes half a line in my editor is more readable than a short one? Seriously?

I read Apple’s tutorial about Interface Builder this week. Most parts of it told about rather basic things and were quite boring, but I’ve learned several useful tricks from it. IB, like most of Apple’s applications, has lots of hidden features which aren’t obvious at first, and can only be found by experimenting, by accident or by reading about them somewhere. Here’s a few things that I’ve learned from the tutorial – some of them are such hidden features, some are just things that weren’t mentioned in any source I’d read before.