I've been playing with Cruise Control and Ant, trying to get a reasonable Continuous Integration server up and running. For those that don't know, a Cruise Control is a server that takes your source code, and tries to build it until you hit the big red stop button, or the heat death of the universe. Ant is a piece of software that performs the actual building of other software.

And by the time the heat death of the universe arrives, I think I may have it all working, and in a semi intuitive way.

To set up Cruise Control, and Ant for that matter, you need to use XML. XML is an alright, if not exceedingly and outrageously verbose method for describing in excruciating detail data, as well as meta-data—which is to say—data about data. (Whew!) The thing with XML, is that it is a flaming shit sack of metric fail when it comes to describing processes. Processes like the building complex bases of source code, executing them on very finicky server software stacks, launching automated functional tests against them, with each process (build, execute, test) running in its own separate virtual machine are a royal pain in the ass to describe in XML. Again with the flaming sack of fail.

I find it very fitting that in the top 10 search results for fail, Ant documentation comes up.

Ant was built to fulfill a very specific need, which is, to help the process of compiling and bundling Java software together. It does an alright job at this, not stellar mind you, but alright. If you happen to be doing exactly what most other Java programmers are doing, deploying roughly what they are deploying, then you could do a lot worse then Ant. But the second you add any kind of complexity into the pile, it starts to show its warts. It's like playing with a plastic lightsaber; it looks great when you are just waving it around in the dark, but once you actually hit something, sparks don't fly, it just goes snap and it ceases to be any fun. Now you just have broken plastic.

The problem with Ant, Cruise Control and building software in general, is that the process is not linear. While it may be useful to have a descriptive language like XML to describe dependencies between Java files, it is absolutely horrific if you need to do things like conditions (if the build failed, then send a nasty gram to the developer and a 50K volt shock to his chair) or do complicated actions (munge this file to make it actually XML).

A lot of its complexity lies in its dependence on XML as a Domain Specific Language. To make a human languages analogy, it's like learning to speak Esperanto in order to practice Zen Buddhism—one perhaps feels that if they just took up Japanese instead, they might have gotten the job done a lot quicker, with less mucking about.

What strikes me as absolutely insane about Ant, is that when you have a reasonably hard job of working some behavior into your build script, solutions like "run XSL transformations on your Ant Script to give it behavior" are floated about, all with seemingly a straight face.

All in all these are good tools if you want to look like you are working, and enjoy tinkering around with XML, but if you are working towards the goal of building rock-solid, stable, testable software that in any way deviates from the norm, with the intent of releasing a maintainable, easily understood system in a reasonable amount of time, well, that tool isn't built yet (to my knowledge). Rake, being a ruby build tool written in ruby, might be close though.

A good Build Tool would be one that looks similar to, or is just an extension of the language you happen to work in, thus making the entire concept of a separate integration server redundant. Instead of having to bundle the build tool with the integration server, you end up allowing the user to write (in relatively few lines of easily abstracted code) the loop which is the crux of the Continuous Integration server inside of the build tool.

I bet it's built in Scheme.

New Selenemacs packages are here:

• selenemacs.js
• selenemacs.el

I fixed some of the more obvious and glaring bugs.

For now the Selenemacs main page will be Here. If/when there is more interest, I'll put up a proper SVN repository and a page on bunnywiki.

In my previous entry, I described how one could set up selenium to runs tests from emacs, via the Moz REPL. The most painful part of all of that is setting up the REPL to run. After every firefox startup, you have to manually go to tools menu, and manually select 'MozLab' and then 'Start REPL'. YUCK.

It would be nice if you could somehow automatically run javascript on Firefox startup.

Enter UserChrome.js. With a little more polish, some documentation, and something more then a MozillaZine forum posting for a website; this little extension is poised to become the new GreaseMonkey. It will be the GreaseMonkey for the hard core.

Once you have installed the extension, you can now run Javascript on the creation of every new Mozilla window (even sub windows like prefs, downloads, etc.) or just the main window. From this point, it is almost painless to start the REPL:

// Anonymous function application to 
(function(){
	var repl = Components.classes["@hyperstruct.net/mozlab/mozrepl;1"].getService(Components.interfaces.nsIMozRepl);
	if (repl && (!repl.isActive()))
	{
		repl.start(4242);
	}
})();

This gives you a good example of how to interact with other Firefox plugins/addons through Javascript.

One of the biggest hassles with web development is the lack of any real test harness. I have lamented about this before, especially when it comes to testing such ephemerals as an elements height, width, etc. So far the best tests I have run into are your two eyes, which is fine when you are working and testing on one discreet component... but web sites, especially the ones I work on, tend to be more then just 1 or two discreet components.

Enter Selenium IDE. The Selenium IDE provides you with a method to record and execute automated tests of your website. It is easy to use, and hella cool. It can test things like the existence of an element, the text contained inside of an element, its width, height, position, etc. Using selenium, you can build yourself unit tests. This is especially useful and powerful if you happen to be one of the unlucky bastards faced with writing code in JSTL, SMARTY, or some other templating-language-that-needs-to-die. Now you finally have unit tests.

Using Selenium, the testing process is a little more automated. More importantly, you can build a series of regression tests, to ensure the stability of your web application.

There is another piece of the web-development puzzle here, and that is the Moz Repl. An REPL is a Read Eval Print Loop, basically an interactive command interpreter that you can feed commands to, and experiment with. the Moz REPL is a javascript version, that lets you inspect and modify any Javascript object in the browser. This REPL is telnet enabled, in fact, there is even a way to make Emacs talk to this REPL, so you can poke around the browser from within your text editor. This is amazingly powerful in two regards:

1. you can script your browser from emacs
2. you can edit code inside emacs, and send it right to the javascript interpreter for testing, and evn install it on the current page

The existence of this REPL is what finally pushed me to stop using Jedit and move to using Emacs incedentally enough.

So the final piece of the puzzle is something I call Selenemacs. It is a global emacs minor mode, in conjunction with some simple javascript that will script selenium, and provide you with feedback on whether or not its tests pass or fail.

Update 2007-07-09: new versions (Version 0.2) added
Here are the two files:

• selenemacs.js
• selenemacs.el

Here is how you use them:
First, download the MozREPL and Selenium IDE extensions for firefox
Edit selenemacs.el to make sure that the variable selenemacs-js-file points to selenemacs.js
Enable the MozRepl (Tools->MozLab->StartREPL)
Load up selenemacs.el inside emacs (load-file "path/to/selenemacs.el") works
Enable the minor mode selenemacs-minor-mode
Record your test in SeleniumIDE
Use the emacs command selenemacs-execute-test to launch the test, its shortcut is C-c C-s C-e
Emacs tells you if the test passed or failed.

The idea here is that you write your test, and stop using your eyes to test the results of your coding to the browser, but instead use Selenium. This is especially good if you are doing multi-stage and repetitive like testing logins, searches, etc. You can code and test right inside emacs, and only have to switch to the browser to verify that your tests actually passed.

These files also show an interesting way to script mozilla through emacs. The next step of course is to get emacs to start interacting with Firebug.

Want to get UTF-8 (unicode) to work on Emacs but don't know where to start?

Snarf this, and toss it in your .emacs.

;;;;;;;;;;;;;;;;;;;;
;; set up unicode
(prefer-coding-system       'utf-8)
(set-default-coding-systems 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
;; This from a japanese individual.  I hope it works.
(setq default-buffer-file-coding-system 'utf-8)
;; From Emacs wiki
(setq x-select-request-type '(UTF8_STRING COMPOUND_TEXT TEXT STRING))
;; MS Windows clipboard is UTF-16LE 
(set-clipboard-coding-system 'utf-16le-dos)

The part about the clipboard-coding-system is essential for MS windows users who want to transfer content back and forth between windows apps and Emacs.

Yet another major milestone was hit recently. World Wide Guides, a Hyatt project that I have been working on for a long time has finally gone live. This project is essentially the full localization of all 200-and-something Hyatt Hotels into 10 different languages including Japanese and Russian; with simplified Chinese, traditional Chinese and Korean to follow soon. Not only did I do a large part of the web development work on this website, but I also ended up doing a some of the apps development work.

Really this project was the project that I "Grew up on.". This was really the project that turned me from a Junior Web Developer to a Senior. It feels good to have something this big, and this significant (at least, to me) out the door.

So, if you read French, German, Spanish, Portuguese, Russian or Japanese (or are just interested) check the site out.

Another version of the MySQL FFI is finished and ready for takeoff. Some big changes in this version. First of all, MySQL connection pooling has been implemented, and should be mostly thread-safe. I've also done up some higher-level functions for retrieving data from the database. Again, this release is not perfect, but it is getting much closer.

Click here to download the tar file
Here is the documentation

I am currently working on a set of macros as a sort of object-relational layer between the DB and scheme. Obviously this not a true object relational... anything, because there are no real (native) objects in scheme. More info forthcoming.