Random Stuff Stefan Tilkov’s Weblog

A Nanite installation is based around a "mapper exchange" with which Ruby daemons (called Nanite "agents") register. Nanite mappers (running in, say, Rails or Merb applications, or even command line apps) can then call the exchange and gain access to the functionality of the agents. The mapper exchange makes it possible for daemons / agents to start, stop and die while allowing the whole cluster to be self-healing.

[via RubyInside]

From someone without a name at Apple:

We have decided to drop the non-disclosure agreement (NDA) for released iPhone software.

We put the NDA in place because the iPhone OS includes many Apple inventions and innovations that we would like to protect, so that others don’t steal our work. It has happened before. While we have filed for hundreds of patents on iPhone technology, the NDA added yet another level of protection. We put it in place as one more way to help protect the iPhone from being ripped off by others.

However, the NDA has created too much of a burden on developers, authors and others interested in helping further the iPhone’s success, so we are dropping it for released software. Developers will receive a new agreement without an NDA covering released software within a week or so. Please note that unreleased software and features will remain under NDA until they are released.

Thanks to everyone who provided us constructive feedback on this matter.

Very cool.

Ola Bini:

So it seems only fitting that I’ve decided to go public with Ioke, the source code, what it is and where it’s going.

Ioke is a strongly typed, extremely dynamic, prototype based object oriented language. It’s homoiconic and got built in support for several kinds of macros. The languages that most closely influence Ioke is Io, Smalltalk, Self, Ruby and Lisp (Specifically Common Lisp).

This sounds a lot like a language I'd like.

In a new article, Jim Webber, Savas Parastatidis and Ian Robinson show how to drive an application's flow through the use of hypermedia in a RESTful application, using the well-known example from Gregor Hohpe's Starbucks does not use Two-Phase-Commit" to illustrate how the Web's concepts can be used for integration purposes.

While many people have grasped the utility of REST for simple cases, the authors show how to get more value out of the REST core concepts, specifically the "hypermedia as the engine of application state" principle. They show how links, included within resource representations retrieved from the server, can enable the client to find out which possible transitions are available from a particular point in the overall application flow.

A really, really excellent article at InfoQ.

JAOO 2008, as was to be expected, was pretty great. It's hard to describe why, but it has a very unique feeling to it – it's different from any other conference I've been to. I met a lot of people I knew, or was happy to get to know, including Arjen Poutsma and Ian Robinson, Erik Meijer, Dan North, Michael Nygard Ola Bini, Erik Doernenburg, Michael Koziarski, Gregor Hohpe, Kevlin Henney, Rickard Öberg, of course the organizers, Kresten Krab Thorup, Aino Vonge Corry, and all of the other very nice Trifork folks.

Some of the most interesting things from my point of view: I attended Michael Nygard's absolutely great talks and had a chance to chat with him over dinner; I spent a while hacking together the very early stages of a REST DSL for Ramaze with Dan North; I exchanged ideas with Michael Koziarski about REST support in Rails 2.2, and I extracted a free copy of the ThoughtWorks Anthology from Erik Doernenburg. Talk about meeting interesting people :-)

All in all, probably Europe's coolest conference; highly recommended.

I've uploaded the slides from my own talk at JAOO 2008 (warning: this is a 12MB PDF). As usual, not sure how much value they have on their own; YMMV.

These are my unedited notes from Arjen Poutsma's very good talk at JAOO.

• REST intro (using very nice Airport pictures)
• pointer to http://livehttpheaders.mozdev.org/
• The fact that PUT can be used to create resources in addition to updating them is one of the major differences between HTTP and CRUD
• "Representations as reflection of resources on the cave wall" ... where have I heard this before? ;-)
• Example for usefulness of stateless communication: Google results in the form of pages, state not kept on the server, but in the representations sent to the client [Note to self: Paging is an excellent example.]
• OrderManagement and CustomerManagement example [pictures by me ;-)]
• Next up: REST in Java
• servlets handle OPTIONS correctly (?)
• spring mvc - classic mvc has limited multi-method handling, Spring @MVC (2.5) improves this
• servlets can be wired up within Spring just like a controller
• Struts 2 has a REST plugin
• Restlet is pretty good in his opinion
• Restlet creates abstraction over HTTP, has Spring support
• JAX-RS - annotation-based REST framework, considered pretty cool
• JAX-RS example
• client side: java.net has proxy issues and surprises
• commons HTTP client - powerful, but very verbose
• REST + Spring
• @Controller annotation for classes, get picked up automagically
• URI template support for @RequestMapping method annotation
• automatic conversion of content of specific types to Java objects and back
• view resolution based on accept header
• Formats: XML based on Spring-WS OXM (abstraction over mapping layers), JSON, Atom, RSS, Flex
• Shallow ETag support w/ a very simple ServletFilter
• RestTemplate as core client-side component, similar to other templates (Jdbc, Jms, WS)
• getForObject - performs GET and converts
• postForLocation - performs POST and retrieves location header
• put, delete
• uri = "http://example.com/hotels/{id}"; HotelList result = template.getForObject(uri, HotelList.class, "1")
• will be part of Spring 3.0, PathParam in M1 (Oct), REST follows later
• 3.0 final planned for early 2009
• Spring security nicely integrated with HTTP authentication

These are my unedited notes from Ian Robinson's very interesting talk at JAOO.

• Context: Engagement w/ a large entertainment and communications company.
• replace 20+ year old VAX BASIC billing application
• order capture, fulfilment, product catalogue, field force management, …
• new design for the next 10-15 years
• general SOA-like structure - product mgmgt, customer mgmt, order mgmt, provisioning, …
• 12-14 business meaningful services, relatively self-contained
• overall view of service estate doesn't change when new products are introduced or processes changed
• self-sufficient business services - no chatty service architecture
• each service can do its job from beginning to end
• services contain the data they need
• [very nice - actually matches my understanding of services perfectly]
• redundant information in services - therefore no hard runtime dependencies
• is it really redundant? no - order management and product management both need product info, but don't care about the others
• within the service boundary, there may be other distributed development to support e.g. wrapping a COTS app
• how are these data items replicated between systems?
• first question: who needs what
• events are used to distribute information
• some events related to entity state, some related to application state (e.g. service ordered, service provided)
• Implementation options for events: point to point (publisher maintains subscriber list), bus/middleware, consumer pull events (consumers poll publishers, guaranteed delivery delegated to consumers, no list of subscribers to maintain)
• bridge within the service that wraps a 3rd party app: atom client retrieves feed and applies them via the vendor app's WS
• Atom - what does published information look like
• AtomPub - how is information published
• atom feeds for specific time ranges - request to generic URI, specific URI returned in Content-Location header
• link rel=next to get to the previous archive (decided to stick with Atom terminology instead of inventing a "previous" rel)
• entries have a self link - each entry can be returned individually
• multiple category elements to classify (e.g. "product" and "created")
• links to objects within the entries as XML "Href" elements [I would have preferred an attribute called href]
• clients can follow links to retrieve the full archive
• interesting link to Pat Helland's data on the inside, data on the outside - set cache max age to 30 days for stuff that's no longer mutable (events of the past)
• cache responses locally when following links
• used WinInet local cache (same one as used by IE) for implementation
• navigate backwards first, then forward again; second request served from local cache
• archive size/granularity could change - as long as clients just follow links, they don't care
• support for conditional GETs and ETags
• "conservative" in using application/xml for the content types instead of some custom media type
• etag attribute in links to underlying resources http://...
• client can extract ETag, do a conditional GET [nice idea]
• high degree of connectedness
• [unfortunately, time was up - a pity. I'd have loved to here more.]

I've prepared a presentation that I intend to submit to the O'Reilly iPhoneLive Conference, let me know what you think.

Via James Robertson, wonderful quote from Boing Boing on Walmart shutting down its DRM servers:

But don't worry, this will never ever happen to all those other DRM companies -- unlike little fly-by-night mom-and-pop operations like Wal*Mart, the DRM companies are rock-ribbed veterans of commerce and industry, sure to be here for a thousand years. So go on buying your Audible books, your iTunes DRM songs, your Zune media, your EA games... None of these companies will ever disappear, nor will the third-party DRM suppliers they use. They are as solid and permanent as Commodore, Atari, the Soviet Union, the American credit system and the Roman Empire.