New Version of my Simple Kanban Board Application

Over the weekend I've worked on my Simple-Kanban application. Simple Kanban is a small Kanban board application in one Html file. New features are a data mode that displays the data in raw format for easier cut & paste and drag & drop support for moving stories around.

Simple Kanban Screenshot

There is a website now! I've added a small website at http://www.simple-kanban.com, where you can find new versions. I've also created a GitHub repository for Simple Kanban, where I'm planning to post the code (funny, the code is already open source as part of the Html file 🙂

Much fun with using Simple-Kanban in your company, think lean!

ActiveMQ vs. Jabber

If you have or plan an application with synchronous communications over an external API, it will sooner or later break. Why do we need asynchronous communications? Matt Tucker is clear about that:

Take, for example, Twitter. High Scalability recently covered the load stats on Twitter reporting that they average 200-300 connections per second with spikes that climb to 800 connections per second. Their MySQL server handles 2,400 requests per second! Recently, the [2008] Macworld keynote became the most recent culprit for causing Twitter to cut off its API, which has 10x the load of their website.

When one of my web pet projects needed a messaging backbone which extends to the browser. Whenever a resource did change on the server, all users watching the resource should get a notification without need to reload their browser. Two candidates are Javascript for ActiveMQ, which uses Comet

ActiveMQ supports Ajax which is an Asychronous Javascript And Xml mechanism for real time web applications. This means you can create highly real time web applications taking full advantage of the publish/subscribe nature of ActiveMQ.

ActiveMQ is a messaging bus, often used as an Enterprise Service bus as mentioned in my recent concurrency rant. Components can send messages to the bus and subscribe to topics.


smokin
Creative Commons License photo credit: mudpig

The other unsuspected contender is Javascript for Jabber. Jabber with the XMPP protocol is usally used for sending chat messages. Comparing these two and my thoughts:

ActiveMQ

  • Standard solution, JMS based
  • Routing solutions like Camel available
  • Easy access for different languages via Stomp
  • Attach Jabber as a service
  • Notification easily over topics

Jabber

  • Free OpenFire server
  • Messaging with only one user with UUID for resource which did change
  • Messaging with many users, who join one chat room
  • Chat rooms as topics
  • Server side filtering? How to make it secure, that people only get their own messages?

In the end I decided to go with Jabber/XMPP. The main points for me have been:

  • Server does scale to connections
  • Chat client can be used for debugging
  • Very easy to use with different programming languages
  • Presence protocol to detect services
  • Easy to implement additional chat solution

This worked quite well as a spike. I followed a similar mode as Adrian Sutton, who had good experiences with Jabber/XMPP too when spiking a cache solution:

We grabbed the Smack API and started playing with it and quickly discovered that sending and receiving messages was ridiculously easy. It turns out that the absolute simplest way you can minimize stale data in your caches is to simply have all the servers join a preconfigured chat room. Whenever they save a change to a resource they send a message to the room with the unique ID of that resource and whenever they receive a message from the room they assume it's a unique ID and remove any cached versions of that resource.

Though I had some major problems accessing Jabber consistently from Javascript. With more on messaging in the backend, I would have went with ActiveMQ as a message bus. And perhaps I might move to ActiveMQ in the backend and then I'm still free to attach Jabber on top of that and keep the frontend code. Best from two worlds.

Think innovative, use technologies in a way to help you. Jabber/XMPP is more than a chat protocol.

David Pollak (from Lift): “There’s no way to convert from XML to JSON because XML contains sequences not expressible in JSON”

Hmm[*]. Not sure if this is true (with CDATA, #Text and @attributes handled in some converters). For me the problem is more that there are too many ways to convert XML to JSON. For exampe the Badgerfish convention. Or the the Google and Yahoo versions. Or the XML.com way. And the Parker convention.

But the ways in Javascript to convert XML to JSON are either slow, very basic, use XSLT, use nasty Regex or cannot create simple JSON which feels JSON like.

* Note to self: Should start using Twitter for this [**].
** Did start Twitter

Update: Any ideas for a good XML to JSON conversion which feels JSON like (no need to be bidirectional)?

Update 2: I currently use XSLT with nice results, Safari doesn't work yet and neither does Chrome. More to come.

REST: Lean JSON and XML from the same code

Generating JSON and XML with the same code is difficult. One can create the semantically richer XML and convert it to JSON, but JSON notations for XML like Badgerfish look quite ugly to JSON advocates.

The problem at the core is that XML is typed whereas JSON is not. Every node in XML needs a type - it's name - for example <item><id>123</id><item>. JSON doesn't need such a type, { id: 123 } is fine for an item. { item: {id: 123}} looks too verbose. Especially getting to the data in Javascript: var id = item.item.id. The same goes for accessing arrays with var id = items[0].item.id; instead of var id = items[0].id;. The problem exists with other dynamic languages and data structures too, see Cobra vs. Mongoose for Ruby.

As I currently develop a REST based Jersey application in Java I needed a way to generate lean JSON and XML. Wouldn't it be best to have one code for both? DRY. My previous solution for generation JSON worked fine. The $(...) method calls create a node tree with nodes and lists. With a JsonRenderer and the Visitor pattern I generate JSON from the node tree. The problem was that this Java code

$( 
  $("id", listId),
  $("items", 
    ...
   )
);

creates nice JSON like { id: 123, items: [ ... ] }, but was unable to generate XML. As written above, the outer list has no type and a XmlRender therefor cannot render <shoppinglist><id>123</id>...</shoppinglist>.

The solution I thought about is to add type information to nodes which have no names.

$( type("shoppinglist"),
  $("id", listId),
  $("items",
    ...
  )
);

The implementation uses a simple static method and a Type class.

public static Type type(String name) {
    return new Type(name);
}

The type is attached to the node and if the node has no name but a type, the XmlRender uses the type instead of the name. The JsonRender doesn't use the type information and renders the same JSON as before. The piece of Java code now generates XML

<shoppinglist>
  <id>123</id>
  <items>
    <item><id>234</id><price></price><shop></shop>
      <description>Apple</description></item>
    <item><id>233</id><price></price><shop></shop>
      <description>Banana</description></item>
    </items>
</shoppinglist>

and lean JSON where neither shoppinglist nor item has a type

{ id: "123", items: [ { id: 234, price: "", shop: "", description: "Apple"}, { id: 233, price: "", shop: "", description: "Banana"} ]}

Next thing is to automatically apply the right renderer, toXml and toJson from within Jersey. The content negotiation then choses the accepted format for the client. Attributes (Meta-Information?) are not solved yet and I'm not sure if they are needed, or how to nicely add meta information to the $(...) tree. There is some discussion in the context of markup builders and attributes on James blog.

Probably the code will be released as an open source RESTkit if someone is interested.

Thanks for listening.