My X10 integration patch made it through Open Remote B.O.S.S. 1.0, so I think I owe a blog post :)

Fun things first, here's a video demo of the whole thing :

X10 is an ancestor amongst domotics protocols. It is flawed by many ways and I guess pretty outdated if you are into modern domotics ; but it has two main advantages : it's cheap, and you don't have to re-wire your home. So that make it a good candidate for prototyping and experiments of all kinds. Which is exactly what I am using it for :)

Making OpenRemote talk to the X10 controller has been pretty smooth, thanks to Jesse Peterson's library. I guess next steps will be to support dimming commands, as well as status inquiring.

If you are interested in controlling X10 devices with OpenRemote, I've written a short HOWTO, you can read it here.

More OpenRemote fun on this blog coming in 2010 !

XWiki now (starting with the 2.0 serie) supports rendering macros definition in wiki pages. And really, that opens a door to a lot of fun. It basically means for developers the ability to write macros as we write wiki content, with all the other macros available, including scripting macros. That's where groovy comes in :)

I won't go in the technical details of how to write wiki macros here - there is a tutorial on XWiki.org dev guide covering this topic. I just want to show my love for the groovy programming language (and of course for XWiki) through a 10 lines of code RSS aggregator macro.

Here it goes :

{{groovy}}
import java.util.TreeMap;
import com.sun.syndication.feed.synd.SyndEntry;
import com.sun.syndication.feed.synd.SyndFeed;
import com.sun.syndication.io.SyndFeedInput;
import com.sun.syndication.io.XmlReader;

def urls = [];
def entries = new TreeMap();

xcontext.macro.content.eachLine() {	urls.add(it.trim()); }

urls.each() { rssUrl ->
  def feed = new SyndFeedInput().build(new XmlReader(new URL(rssUrl)));
  feed.entries.each() {  entries.put(it.publishedDate, ["entry":it, "feed": feed]); }
}
println """|=Title|=Date|=Author|=Feed"""
(entries.keySet() as List).reverse()[0..10].each() { 
   def e = entries.get(it).entry, f = entries.get(it).feed;
   println """|[[{{{${e.title}}}}>>${e.link}]]|{{{${xwiki.formatDate(e.publishedDate)}}}}|"""
   print """{{{${e.author}}}}|{{{[[${f.title}}}}>>${f.link}]]"""
}

{{/groovy}}

That's enough. I can now call my macro from any page with :

{{rssaggregator}}
http://feeds.feedburner.com/xwikicomblogen
http://feeds.feedburner.com/massol
http://feeds.feedburner.com/ludoblog
{{/rssaggregator}}

Which will result in :

The "rssaggregator" macro is not in the list of registered macros. Verify the spelling or contact your administrator.

http://feeds.feedburner.com/ludoblog

Of course, the macro could be a lot improved - this is just a proof of concept. We could add parameters to chose the displayed columns, the maximum number of entries, etc.

Anyway, groovy is sweet, and so macros as wiki pages are :)

We added in XWiki Enterprise 1.9 Milestone 2 a compatibility.js file to host all deprecated functions and variables, as well as the old aliases of functions that changed signature (renamed, or namespaced for example).

As for the server code, we warn in the (client) console all usages of such deprecated APIs, to help applications developers (and ourselves developers of XWiki Enterprise) move to "the new way". The rule for us is that every release of XWiki Enterprise (including milestones and RCs) should make no use deprecated code (and thus should work fine without the compatibility file).

The very nature of JavaScript makes it easy to implement such a strategy, and in our case no new framework is needed to help achieve that (although some exists, like jquery-aop). Prototype's Function#wrap comes to the rescue! As the doc says, it

distills the essence of aspect-oriented programming into a single method, letting you easily build on existing functions by specifying before and after behavior, transforming the return value, or even preventing the original function from being called.

For example, handling the compatibility of a method that has been moved from the global object to the XWiki namespace only takes the following:

/** Deprecated since 1.9M2 */
window.displayDocExtra = XWiki.displayDocExtra.wrap(
  function(){
    warn("window.displayDocExtra is deprecated since XWiki 1.9M2. Use XWiki.displayDocExtra instead.");
    var args = $A(arguments), proceed = args.shift();
    return proceed.apply(window, args);
  }
);

We can also inject more complex things before the actual call, like DOM manipulation to make the HTML match the new function's expectations. See the live table example in the complete file on fisheye.

I've added a couple of bindings to allow full access to the XWiki API, and the notion of saved script for recurring admin tasks one would want to execute (and of course, restricted all this to users with programming access level!). Here is a screenshot of the console in action on our incubator wiki, executing a script that empties the trash bin of deleted documents.

The cool thing is that I know I will be using it for real by monday, on a project where I have large imports of data and images to run on a wiki.

The application is available for download on code.xwiki.org.

I will give a talk focused on enterprise usages of Application Wikis (Also known as "Second Generation Wikis"). My objective will be to attempt answering the following question :

Why, in 2009, you want to use an application wiki as foundation stone of your company's Intranet.

Of course, this taking XWiki as an example (eLiberatica is all about Free and Open Source technologies), but the topic itself is generic.

There are couple of good reasons I had in mind right from the beginning (the Open Source argument was a very strong incentive for me to take the job, I was not addicted to Web technologies at that time, as I probably am now). I still think they are good, valid reasons. Though I think they are arguable and in the end do not make the big difference:

• "You get to work with the best developers out there". My take on this is that you'll find the same talented, maven, developers in the open and in the proprietary world, but it's probably easier and faster to get to work with them in the open. And never forget Peter Norvig's advice:

  "be the best programmer on some projects; be the worst on some others"

• "You are one of the happy few that work on sexy, cutting-edge, software". Well, same argument, I don't think proprietary software programming sucks by essence, there are a lot of sexy software there too ; but might be easier to find this in the open.
• "You get more exposure and recognition for your work". This one is harder to argue with, since working for an Open Source project really means _working in the open_, it's part of the deal. But… it's a double-edged sword ; and there are jobs in the non-open that gives the good exposure as well.

Makes me like my job even more!

The editor itself really is a huge thing. It feels so good to write with I knew I could not resist the terrible temptation to plug and make it available to edit XWiki's JavaScript and StyleSheets eXtensions. So I did. Let's be clear, it is a saturday afternoon Q&D hack, not a clean integration, but it does the job. I basically just removed or rewrote some bits in the Bespin.Server class to skip the communication with Bespin server and load and save XWiki's extensions instead, fired automatically a couple of events, et voila! Right now it supports only JavaScript eXtensions, but making it work with StyleSheet ones would be really easy. I only tested it on a recent snapshot of XWiki, but it should work fine with all recent versions. Of course, we can only experience it in browsers that support the canvas element.

Here's how it will look in your wiki :

The XWiki extension is available here. It contains unmodified code from Bespin attached to a XWiki Document. The modified bits (Bespin.Server and Bespin.FileSystem classes) are in a JavaScript extension, human-readable directly from the archive. This extension is licensed under the Mozilla Public Licence, and all Bespin original code (that is, 99.99% of this extension) is the work of the Mozilla Labs Bespin Team.

To use it, just add the following line in the wiki content of a XWiki document that contains a JavaScript eXtension :

#includeForm("XWiki.BespinEditorExtension")

Really, the future is in a <canvas>!

AddSizes.js is a small but powerful Javascript snippet that inspect all the links of certain types that are present in a HTML document (for example office documents, PDFs, media files, etc.) and query their size against Simon Willison's json-head service on Google App Engine. Once it got a response, it inject the information just next to each matched link, so that users know before clicking what type of document to expect, and more, what file size to expect. Here is for example how it can look in a wiki page [...>>Blog.AddSizesForPrototype]