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.

Via Sam Ruby I found this awesome presentation about the static analysis of PHP. This kind of action is happening more and more. PHP has some really good things about it, but it is also really rough around the edges. So when smart people take a deep look into the language, and its implementation, it is pretty exciting.

now I have all but given up on PHP (at the moment—I am anything but static) occasionally taking pot-shots from the sideline at what I consider to be silly or misleading statements. That being said, I still do see the beauty of PHP, and I may return to it once again.

Or my mad science project will be successful, and I will have created a wind-mill-destroying monstor!

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.

I'm becoming a bit of a PHP gadfly these days. Seeing as how I am in the middle of building a web server with scheme, it is difficult not to snipe at what some other members in the PHP community are saying about PHP, simply by virtue of seeing things from a different perspective. Now I don't really have it in for PHP (okay, maybe just a little). It is an okay language, and you can really get things done with it. However (and you knew it was coming...)

PHP has one major thing going for it - it's simple nature lets developers keep things simple, and simple is good.

--PHP Developer

PHP is not simple.

PHP's Type System is complex. Sure, dynamic typing is easy, but weak typing is weird. 5 + "10 little piggies" -> 15?

PHP's Object System is complex. It is Javas OO system grafted on top of a really basic system. Ironically, this is where PHPs type System gets so strong to be a real pain in the ass. Ever had to cast an object?

PHP configuration is complex. 3 words: php dot ini.

PHP has complex syntax.

There is also a vast volume of built in functions for php, and an even larger body of extensions. This is not bad (its very good in fact) but it hardly makes the language simple.

There are plenty of reasons to like PHP, but simplicity isn't one of them.

Imagine a webserver that is completely dis-entangled from the filesystem. Where requests are handled as they should be: as requests for representations of resources. Imagine a webserver based on very simple rules that can be composed into more complex rules (url is foo, host is bar, accept-language is baz, method is blarg). Imagine a webserver where typical HTTP headers and methods are understood, but extensions can be easily dealt with. Thats right, a server that could respond to the new FROBNICATE method is possible.

This server, is called zen-garden. zen-garden is my pet project. It is my tilting at a windmill, and it is rapidly approaching a 0.1 release. The fundamental difference between zen-garden and most other webservers is that zen-garden is built, and based around simple rules. You want to log every request to a database table? Write a rule that acts on every request, and writes the request info to the table. You want to run all of your HTML files through Tidy and or gzip to compress them? Write a rule to act on every response that doesn't already have gzip encoding, and has a content-type of text/html. As you can see, the rule-based webserver is a very powerful concept indeed.

Now you might be asking "How do you handle a request for a single page, a single CSS file?" The answer is simple: a rule to output the page or CSS file when the request method is GET, and the URI is /path/to/your/file. But imagine this, instead of making the webserver find the file, load it, and send it across the network, what if you told the webserver it should compile the serving of that file into itself on deploy time? What if part of the deploy is taking a source file in XML and doing some transformations on it, and then compiling the transformations into itself before deploying? But what if all this was developer friendly so that when working in a development environment, you don't have to deal with the daily grind of compile-test-debug, you could make a change to your file, and test it on the spot? zen-gardens host language is Scheme on Gambit, so it is interpreted for a really fast development cycle, but Gambit can also be compiled to C (which of course can be compiled to native code) so when it is time to deploy, your server will be fast.

The crux to zen-garden is the request-chains and request-handlers. A request-handler is a data structure, with 2 important parts: a predicate stating whether or not the handler should execute, and the handler itself. Both of these are functions that return booleans. A request-chain is really just a series of request handlers that are executed in a particular order, split out into 4 convenient phases: initialization, handling, fallback and finalization. A request-handler can be bound to any one of these 4 phases. If a request is not handled during the 'handling' phase, the fallback phase is executed, otherwise it is skipped.

The real interesting thing about this structure is that a request-handler can spawn a new request-chain. So you can have a request-handler that executes when the 'Host' header is set to 'my.foo.domain.com' that spawns a new request-chain. On top of that, there is nothing stopping you from dealing with requests in other ways, in fact, any way you see fit. Don't like my method of predicates and request chains and what have you? Write your own method of doing things. zen-garden is modular in design. Pull out the routine that I use to handle requests, and install your own.

What is in the future of zen-garden? Well, ZSP's, or Zen-Server-Pages, which is a JSP/PHP method of page generation. Unlike these other technologies, I plan on getting the separation of business logic and display logic right. No top-heavy tag libraries with presentational logic getting confused with document structure, yes JSP and the entire J2EE stack, I am looking at you. No business logic tied up with your presentation, dirty, nasty PHP! What else is in the future? My(and other)SQL connection pooling, GD integration, regular expressions, optional continuation based web programming, RESTful resources, specialized preprocessing of CSS and Javascript files (only send the browser the CSS it needs, and you want it to have).

Oh, and it is all under a BSD License.

For now, everything is available in a subversion repository, svn://panda-ba.sanriowasteland.net/zengarden/trunk . You will need the Gambit-C compiler and interpreter as well.