This has got to be one of the cutest tricks I’ve seen. A few years ago I wrote a simple Flash script that solved any similar (two openings on the outer wall) maze using an A* algorithm, probably got it laying around somewhere. Doing it in Gimp beats it tough.
As messaging and therefore queues is close to my heart, I’ve been following the discussions on rest-discuss on how to construct a RESTful queue with great interest. The discussion started (as did my thinking on the topic a year or so back) around how ActiveMQ has choosen to implement their REST support, a somewhat broken model as pointed out by Paul Winkler (e.g. non-safe GET, DELETE on queue deletes message rather than the queue).
My favorite model so far is the one suggested by Steve Bjorg, also quite similar to the one described in HTTPLR. In that case you would push messages onto a queue with POST and pop then with a combination of POST and DELETE. To quote from Steve’s email.
To add an item:
POST /queue
Content-Type: application/xml (or whatever a queue item is)
–>
201 Created
Location: http://server.com/queue/itemXYZTo request to pop an item:
POST /queue
Content-Type: application/w-www-form-urlencoded
AckTTL=60 (where AckTTL is the time to acknowledge the queue item or
it becomes available again)
–>
200 Ok
http://server.com/queue/itemABCTo delete a popped item:
DELETE /queue/itemABC
…
Go read the discussion thread as it contains many interesting aspects on this pretty hard problem. Ideas on how to improve the current suggestions is very welcome.
I’m a big fan of Wikidpad and use it for most (if not all) of my digital notes (a trusty Moleskin does the trick for those analog ones). Today I was in a meeting discussing a set of integrations between a few applications. Pictures was drawn on the whiteboard and I was somewhat desperately trying to convey these into wiki text. The results wasn’t all that good. This scenario has been played over and over again and I have tried a large number of different replacements for Wikidpad that would be somewhat more “rich” in their content, for example OneNote. Still, every time I have returned to old, trusted Wikidpad.
Now, while in the meeting today I thought that the pictures drawn would be perfect to draw using dot from GraphViz, another favorite of mine. I went into my text editor and hacked up a simple dot file that described that integration scenarios being discussed. When I was about to save the file, it struck me that since it just text it would be better suited to store it right there in the wiki. I thought that some Python (that’s what Wikidpad is written in) hacker should fairly easily write up some code to render it for me. When I was about to start writing an email begging at people over at the dev list, it actually struck me to look at the extensions already shipped with Wikidpad. Lo and behold, right there is was, GraphvizClBridge.py. And nicely documented as well. So now I got perfectly beautiful dot images just where I want them. Couldn’t be happier.
There’s tons of interesting discussions going on the the JSR-310 dev list right now. It’s the JSR for developing the new(er) date and time API for Java, based of Joda Time. The discussions are currently covering two important aspects, the basic design principles for the API and how to handle non-Gregorian calendars. The latter being something that the Calendar API failed at miserably. Not that it didn’t support it correctly, just that it did it in such an intrusive way that you quickly get annoyed with it.
The design principles this far looks well thought out:
I think that setting basic principles like this for your API is a really good idea. As we learn more and more on what the winning principles are, it would be a topic for a book to collect them much like the GoF book. Personally, I think the XOM principles (also covered here) are the best general guideline currently available.
Starting today, Apache Incubator FtpServer JARs are available from the Apache snapshot repository. This should make it easy to use FtpServer in your Maven 2 build. Just declare the following dependency and you’re done.
<dependency>
<groupId>org.apache.ftpserver</groupId>
<artifactId>ftpserver-core</artifactId>
<version>1.0-incubator-SNAPSHOT</version>
</dependency>
Currently, the snapshots will be deployed manually, but I’m working on getting a CI build up and running that would also deploy snapshots automagically.
Bill de hóra seems to be nailing them these days.
"SOA seems to encourage business to meddle in IT at the wrong levels and might actually prevent commoditization by making all this stuff specific to a business at-a-point-in-time; like encouraging Service Oriented Electricity instead of electrical Grids and uniform access to outlets.”
On the service-oriented-architecture list.
The fact that quotes like this makes me giggle probably says a lot about me having spent to much time thinking and talking on these topics lately.


