One of the things that in a complex system can complicate testing, is the fact that you may rely on the database a lot. You can always mock the database, but this slows down writing the tests.

Ruby on Rails has a feature called 'fixtures', which makes setting up test databases pretty easy.

Inspired by this, a few of my fellow ATK developers have written a system to make using test databases very easy. Not only with fixtures, but also with automatic cloning of an actual database to be able to use actual data in tests (where this is relevant).

Peter has written a blogpost about this on our company website. If you're using ATK and want to increase your unit/webtesting productivity, check out his entry.

This week I visited the Holland Open Software Conference. It was a nice conference, I will write a review later.

What I want to talk about now though, is what happened to me during this trip.

Before I begin, you should know that I am a die hard PHP fan, and I have been using PHP for 6.5 years now. If there is one thing that I've learned during this time, it's that PHP rules.

For a few months now however, friend and colleague Peter has been nagging me to check out Ruby. While I have been working mostly in PHP, he has used Ruby for the backend of epointment.com. I had looked at his code before, but it didn't catch on. It eyed weird, had funny-looking constructs (Ruby's lack of braces reminded me of Visual Basic even) and it was surrounded by a lot of hype, which often is a bad sign. It didn't even have a '++' operator. Get real.

Then he gave me this book they call the 'Pickaxe'. I tossed it on my desk, near the rest of the things-to-do-which-never-get-done.

But now I was going to this conference, which was a 2.5 hour train trip on both conference days, so I decided to check out the book to kill time while on the train.

The first day I read about 30 pages into the book, and I was intrigued. I read about how everything is an object, how even primitive types are objects. I read about code blocks (which turned out to be the funny constructs I didn't understand when reading Peter's code earlier), about the ability to redefine operators (which I remember from C++), about its regular expression support and about how Ruby encourages application of OO principles like encapsulation and loose coupling.

I had my laptop with me but no Ruby installed, so I wasn't able to try any of the code, but I was intrigued nevertheless.

At night, I decided to install Ruby so the next day I was able to actually hack away a bit. I read more in the book. I delved into collections, found out how they handle looping and how iterators are an intrinsic feature of the language. Around 100 pages into the book, I was hooked. I was writing classes, trying out all these language features, and it was great fun. I hadn't read nearly all of it yet, but at one point, I needed to get something done in my code, and without looking it up in the book, I just typed what I thought was the right way. I thought 'oh well, let's see what this does' and ran the script; and it simply worked. It didn't even generate a parse error. It was handled exactly the way I had expected it. This happened on 2 more occasions. So Ruby seems to be quite intuitive; if you have an idea of how the language is set up, what its approach to object orientation is, you can almost guess how you should accomplish things. So there I was, enjoying a new language. It felt like the first time I used PHP, back in 1999. Ik was astounded with the ease with which you could write programs (something which I never felt with C, C++ or Java).

I nearly missed my stop, and when I bagged my stuff and stepped out of the train onto a sun-engulfed platform, one thought crossed my mind.

"Whoa, I know Kung Fu".

It really felt like that. It was as if in a few hours, a whole new approach to programming was uploaded into my brain. In essence it was just a new scripting language I had just learned, but it merged perfectly with everything I ever learned about object oriented programming. I realised why they call it 'Ruby'. It is this clean language that has a pragmatic approach to object orientation that I haven't encountered before in any language.

And then, during the short walk from the station to the conference premises, I was reflecting on what had just happened. In my mind I was already looking at how I could do certain features of ATK more cleanly in Ruby. I was comparing how things are done in PHP and how the same things are done in Ruby. I marvelled at how Ruby fits ATK's "less code" philosophy.

And then I got scared.

What if I can't find any aspect of PHP that is better than Ruby? What if the only reason to still use PHP is 'that it is more widely used'? Surely that will not be the case, right? I have been using PHP for 6.5 years and it has never let me down. I am not crazy, am I? Ruby seems to be this shiny apple, but will eternal damnation come my way if I eat it? is Ruby the Red Pill? Will this be the beginning of the end? Will I switch from PHP to Ruby? This question has been bothering me since I got back from the conference.

After a good night of sleep, I've concluded that I will use both. PHP feels like this jeans that I have been wearing for years. It's worn out, but it's still my favorite jeans. It just has the right fit. I have other newer jeans that are less worn, but they still are not as comfortable as my old one. Although this Ruby jeans feels damn comfy, too.

But my jeans are not mutually exclusive. Neither are Ruby and PHP. So I'm going to use both. I'll use PHP here, and Ruby there. Let's just see what the future will bring. I will consider making a Ruby version of ATK (on top of the Rails framework), so I have two options when developing web applications. I hope to continue to be part of the PHP community for a long time, and I hope I will become part of the Ruby community too. Surely they'll accept me even if I still use PHP a lot.

In any case, one thing this tale has left me with is a deeper resolve for object orientation. I hope that for PHP 6 and 7, they will look more to their sister Ruby than to their predecessors Java and C++. Because Ruby knows how object oriented programming should, and can, be done.

When in october 2004 Peter and I took on the idea of developing epointment.com, we thought we had all the time in the world, given the fact that at that time most online calendering applications were rather rubish.

Over the past few years, several new sites have been created for this same purpose, and when a few months back the rumours about Google Calendar started, I was initially horrified. I felt what I think employees of Netscape must have felt when Microsoft released Internet Explorer.

Funny thing is, it's hardly ever about money. Netscape was already freely downloadable when Internet Explorer was released. Similarly epointment is as much free as Google Calendar is (our investments are to be won back by providing professional services). This is more about how given enough weight, any market can be taken. Internet Explorer didn't crush Netscape because it was a better browser. Microsoft just was a bigger player with better cards.

Now we don't claim to be better than Google Calendar, that would be quite presumptuous, given that probably they employ some of the smartest minds in the industry and have a lot bigger team than the two of us working on epointment. But my point is that neither price, nor quality, matter, when the elephants walk by. The fact that it is 'Google' Calendar and not 'Just Any Calendar', makes it Good. (I sometimes have the same feeling about art. Some art is art only because of the signature on it). And don't get me wrong, Google Calendar actually *is* good. And competition is a good thing anyway, it gives people choice.

And, instead of sobbing, which never really helps anyway :-), mice like us should do the only sensible thing: distinguish ourselves. We have many ideas that we will roll out in the foreseeable future, but we already do it very subtly. While Ajax is hype and everybody makes sure Ajax is part of their product description, we stay away from the term. We actually use the technology (using prototype and script.aculo.us if you're interested), but you will have a hard time finding it.

Another choice we made is to make the agenda not look like the digital version of the schedule of a trained secretary, but make it something that is more like the type of calendar that hangs on your mother's wall. Keep it simple, so to say. Most people don't really need a digital secretary, they just need a way of keeping track of (and remembering) their appointments.

So no, you cannot sync your appointments in epointment yet, we'll focus on ease of use first (and how much do the non-techies sync their agenda's in real life anyway? ;-))

One thing we did realize in the past months do is that looks do matter. The initial layout (well, let's rather call it a complete lack of layout) was, in hindsight, terrible. So yesterday we finally released a new version of the site that we feel looks a bit better. Now all we have to do is stay away from the elephant's feet and run right under them and finish first.

Oh and, because we are geeks after all, we just had to implement easter eggs. Not that anyone would ever find them, but writing them was fun in itself.

Together with comunication firm Effectiv we developed a marketing tool for Cirque du Soleil in ATK. For this application, we needed a better way to search through the myriad of data in their database. Peter solved this by adding a new nifty Ajax powered search functionality to ATK, that can be used to traverse all data, following relationships and exposing the entire database through a single interface.

An example of the type of searches that a user can do: 'show all employees that work in a department whose manager lives in a city that has at least 10.000 inhabitants'.

This functionality is available in the current nightly build. (This contains only the atk subdir, if you don't have an ATK app already, download the sample application first.)

Here is a screenshot:

In this screenshot, I am looking for all employees whose manager is 'ivo', and that work in a department which is currently hiring. (this is taken from lesson 3 of the demo application)

In ATK tradition, to enable the functionality you need only one line of code. Just add the following code to any node (constructor or action_admin override):

$this->setExtendedSearchAction('smartsearch');

(Note1: if you do not have AF_SEARCHABLE attribs, make sure you set NF_EXTENDED_SEARCH to force display of the search bar. Note 2: in a future nightly this will be even easier through the use of a new NF_SMART_SEARCH flag)

Now, click the 'extended' link in your application's search bar to get the new search.

Another neat feature is the possibility to save and load sets of search criteria. To enable this, you need to have the atk_smartsearchcriteria table:

 
CREATE TABLE atk_smartsearchcriteria
(
  nodetype VARCHAR(100) NOT NULL,
  name VARCHAR(100) NOT NULL,
  criteria TEXT NOT NULL,
  PRIMARY KEY (nodetype, name)
);
 

Peter did a great job with this feature. I think this opens the road for advanced reporting functionality in ATK.