Peter Bex

Dokeos will probably end up in the history books as the project that spawned Chamilo.

The lead developers all abandoned Dokeos because of unhappiness with the way the company managed the project; more and more code was closed up and new features were no longer provided as part of the free "community edition". As a response, they set up Chamilo as a truly open source project, embracing the ideals of the free and open source software community and making the legal owner of the code a nonprofit organisation.

The proof is visible right here on Ohloh in the "5 year commit count" graph: there's a big bar of commit activity up until January of 2010 and then a sharp drop. The 5 year commit count of Chamilo is the inverse of this graph. It's clear where all the manpower went.

This whole episode has an uncanny resemblance to the events that led to the fork of Joomla! from the Mambo project back in late 2005, and I am confident that Dokeos will end up having the same fate as Mambo: as a footnote in history and an example of how NOT to manage a free software project.

With regular HTML (or ERB), closing tags all the time and indenting gets annoying and it's too easy to get the nesting wrong, especially when you have some nested conditionally shown HTML fragments or after moving stuff around in a HTML file.

Haml fixes these problems once and for all: it replaces opening/closing tags to nest tags by using indentation to indicate the structure.

The Haml syntax makes the tree structure of HTML much clearer and with the Emacs mode that's shipped with it, editing is really a breeze.

There are also some disadvantages: Haml's syntax does not allow hashes on both the attributes side and the content side of a tag. It also makes it hard to nest things in such a way that only the outer part of markup differ, with common inner content. You're forced to use a partial then, or repeat the inner content for each variation of outer markup.

Last but not least, inline javascript (or other types of non-html content) is painful when you need to use Ruby code in it, because the Ruby is evaluated in another environment than the surrounding template.

On the whole, Haml gets a well-deserved 4 stars, for making my Rails templating life much easier.

As a Schemer who codes PHP at work, I know the pain of having to code in a crippled language (one bright spot: at least PHP 5.3 will have real anonymous functions!). It's great that someone's working on a set of tools to make proper functional programming easier in PHP.

I've browsed the source for a bit, and already found a couple of things I recognise from the all the Greenspunning we had to do to make PHP bearable for CASCO (http://www.ohloh.net/projects/casco); most interesting is the dynamic scoping functionality; we had just come up with this ourselves a few weeks ago :)

We're probably not going to use this framework in CASCO because we've already decided upon a fully object-oriented programming style (without good namespacing, classes are the next best way to keep functions grouped and out of the way) and already have selected SimpleTest for our testsuite, but I still would like to wish this project all best of luck! PHP really needs better programming tools.

Love the project name, by the way ;)

Finally, a purely client-side Javascript (no Flash, no images) font replacement library!

This library is small but functional, and has zero dependencies.

It's pretty fast, and has decent support for all browsers except Opera (but that's a bug in Opera, which is fixed in the upcoming version).

It has a server-side companion script to convert truetype fonts to Javascript files, which is unfortunately not freely available at this point; you'll have to upload your fonts to the webpage, for now.

Because it draws the fonts using the Canvas element (or VML in IE), it cannot support the full CSS transformation and effects you can apply to type, which is a shortcoming you have to be aware of.

You will also have to keep in mind that CSS font "properties" like font-weight and italics (but *not* underlining) are actually different fonts in the same font family so you'll have to upload the bold version of the font to generate a Javascript font file in order to be able to use it to replace text in elements that are styled with the font-weight property (remember, headings are boldfaced by default).

All in all, I'm very happy with this library because it makes maintenance of website headings in a CMS less of a chore -- in fact, it allows our customers to manage the headings as content without worrying about generating a new background image to replace the text with, every time.

Having suffered from bad performance of a TDP4R-based parser, I turned to racc to see if performance could be improved. Since racc generates LALR(1) parsers, I expected much better performance than I got with the backtracking recursive descent parsers you can write with TDP4R.

This expectation was correct - the parser was a lot faster. I had used yacc in C projects before, and I really liked how familiar racc feels! I got started quickly and managed to convert the parser easily. The parser's code size is comparable to the one I wrote with TDP4R, which kind of surprised me since you can do neat things with higher-order functions, while the racc parser has to be very straightforward, BNF-style.

The main disadvantage of using racc was that racc requires an edit-compile-test cycle, something that can really slow down your development process. TDP4R is pure ruby and does not require any preprocessing. Another disadvantage is that because it looks and feels so much like yacc, you're programming in an entirely different language that is not Ruby.

I really liked the way racc provides feedback about rule conflicts; it helped me detect and get rid of a superfluous rule (reduce/reduce conflict) which might also have been the cause of *some* slowdown in my original parser. Another neat feature is the debugging output log it can produce, which contains all the rules and states the parser knows about. It takes some getting used to and it's hard to grok the output, but it's very helpful even if you don't fully understand everything. And there's even a way to automatically get debugging output from a working parser while it is analysing its input.

I also briefly tried out Treetop, but didn't like it. It also requires compilation, is an extra dependency (the racc runtime ships with plain Ruby) and its syntax tree objects are not very convenient - it's much nicer to just return the final data structure straight from the parser.

I still like TDP4R for its ability to quickly hammer out a parser, but I'd certainly consider using racc from the start in a project where I knew parsing could be a major bottleneck. If I wasn't sure, I might use either; it's easy to do some prototyping in TDP4R and then convert the parser to racc. Just be careful not to rely on higher-order functions or dynamic combinators :)

Scheme regular expressions were introduced by Olin Shivers more than 10 years ago as a "100% solution" for doing regular expressions in a clean non-string-based way.

By storing regexes as structured trees instead of opaque strings, they become much more composable and hackable. This means it is much easier to write *readable* expressions, which means regexes are able to scale to arbitrary sizes without becoming unmaintainable.

IrRegex is a great reimplementation of this age-old idea. Instead of being written for one particular Scheme, this is a truly portable implementation which (hopefully) means that other Schemes will now finally adopt this brilliant and eminently practical idea. At least my favorite Scheme, Chicken, has already embraced this library fully, to replace the bug- and vulnerability-laden PCRE library which was a pain to maintain.

IrRegex even improves upon the original SRE notation by getting rid of the awkward macro (making them truly composable), adding back references and adding "named submatches" in a clean way that would even surprise Olin :)

The one disadvantage one could name would be that it's slow. Well, yes, but at least improving that's on the TODO-list. Good code is written by not worrying about performance prematurely.

Simpletest used to be a pretty decent test framework, but unfortunately its maintainer has very little time to spend on it. Even though there is still work being done on the subversion tree and he actively helps people on the mailinglist, the last official and stable release is from 2008. This release still has some PHP4-isms in it (especially regarding the way it uses objects and pass-by-reference), and if you enable strict warnings, PHP bombards you with warnings.

The documentation isn't great with several completely different-looking static html websites providing information about it, but you can get the information you need from it. I think newer documentation is concentrated in the PHPDocumenter-generated API docs (which is a mess all in itself), which PHPUnit also uses for their main documentation.

The API is very similar to PHPUnit too, as both were inspired by the xUnit type of test frameworks. However, PHPUnit has a much more active development team, has a much more thorough documentation and, as far as I've been able to determine, is used by more projects. Drupal is a notable exception as it has embraced Simpletest in their previous release, but they ripped out all that code in favor of their own implementation (which they confusingly also call SimpleTest...)

Both SimpleTest and PHPUnit consist of a tangled web of classes which are quite hard to understand unless you are willing to dive deep into the bowels of the system, but I guess that's just typical for xUnit type frameworks. It came from the Java world, after all... ;)