State management is very important aspect when creating responsive, high quality single-page JavaScript applications. Just think about users with slow connections or high latency. What will happen if your AJAX requests will take 5 seconds, 10 seconds. Will user's action affect the state of your model in the meantime?

Let us take a classical example: TODO application. You can find a TODO application samples implemented using all possible JavaScript MVC framework. Your TODO application will store a new TODOs and updates of existing TODOs to the server. However every server/Ajax call can take time, and also can fail. So when request is inflight would be great to provide a visual feedback to the user about that, and possible disable/enable some of the UI actions. More over we would like to modularize such code and make it easy to test and modify in future.

For a solution we can take a state chart micro-framework: Stativus. This framework is originated from refactoring of the Sproutcore-based Ki framework. The only difference is that you can use it with any MVC application framework like Backbone.js, Ember.js, or any other.

Fo our sample we will use following state chart:

When application DOM is ready and all javascript files are parsed we are in Start state. Then we move to the Initalized state. In the initalized state we trigger loading of the data from the server. This is asynchronious operation and may have two outcomes: success (Model loaded) and failure (Failed to load Model). So from Initialized in case loading is successfull, we move to Editing state or to Load failed state.

In the Editing state we give a user full power to modify our model by creating new or updating existing TODOs, however we want to persist changes to server (every change, or all changes in batch after defined timeout). So from Editing we may move to Persisting state. There we initiate an AJAX asynchronious call to server, which could bring us back to Editing state if successfull, and if not we are moving into the Persist failed state.

That's how it will looks like in the code:

As you can we declared a Start state and it has one method enterState. This method will be called when statechart is entered the state (there are other methods your statechart may have, we will talk about them later). So Start state just move our statechart to the next state, namely to Initialized.

The Initialized step is more complicated, here we load JSON data from the server, and as success callback we move to the Editing state and in case of communication failure we move to the Load failed state.

Next state is Editing:

Usually there you should react on change events from your model, but for the sake of test Editing state will just trigger a move to the Persisting state in 1 second. 

Persisting state is simlar to the Loading except it pushes the model to the server. Description of the failed states I will skip for this blog. You can see the full souce code with the test in this gist. Now we can intialize the statechart by doing that:

Now if we fake some of the JQuery AJAX operations and start our statechart we will see following in the developer console:

After initial statechart is in place you could enrich it with additional actions.For example you can disable UI elements when leaving and enable them when entering the Editing state by implementing functions exitState and didEnterState like this:

Or you could show a progress window to the user when doing some long-running operations by introducing a sub-states and events, but that is a topic for another blog. Full list of supported callabck methods you could find in the Stativus documentation.

To summarize: using statechart we will not only understand and document our application structure and behavior better, we will also get a better modularization and testability of our application code. Statechart applications are simpler to develop, they are more deterministic and allow us, developers, to provider a better user exeprience without compomising the code quality and clarity.

The full source of the statechart sample from this blog you can find here.

It's quite interesting to see how Internet age coming to the end. With HTML5 stake major players like Apple, Microsoft, Google and Adobe are creating a complete new direction on the web. Web sites are no longer just a set of pages served from the server.

The modern browser, or as they often called single-page applications are now full blown 'fat' application clients. And they have a full-blown application runtime (just like JRE or CLI). Just a short look on W3C (and not W3C) standards (see presentation below) will give you a good overview of the APIs similar to JRE APIs or Win32 APIs.

But the question which is more intersing for me now what will happen with larger application architecture. And in my opinion we shall move from 'old' Service Oriented Architecture to next generation of it: Web Oriented Architecture.

WOA does not mean a web in terms of the web-site or a Web Service (let alone the term 'Web Service' is too overloaded). The WOA for me is a application architecture for next generation of applications. Applications that are running in new runtime environment (Desktop or Mobile browser).

Such application would need a similar set of infrastructure services, just like SOA applications right now. Think about security, location, versioning, etc. Just like in SOA there will be a need for service bus, that will take care about service orchestration and data/message transformation. Such service bus should enable 'new applications' to consume a set of services. It could solve problems specific to new generation of applications, such as Single-Origin-Policy or enable faster application distribution via CDN. There are many other possible application for such a new service bus, however it's topic for the separate post.

It is a common wisdom that statically typed languages (Java, Scala) are better suitable for large-scale development. Dynamically typed languages (Ruby, Groovy, Javascript) are faster to develop for small projects however large projects are simpler develop with static types checking.

Take for example Java - the great example of static typing in action. I think nobody would object that Java is suitable for large-scale development, and large code-based projects are a clear evidence for that (take Eclipse Platform + all eclipse sub-projects for example), however when moving into server-side, enterprise Java space the promise of type-safety disappearing rather quickly. Some examples:

• Spring framework uses XML composition (and programming) language for declaring dependency injection, composition and configuration rules. Needless to say bad idea. Obviously not type safe.
• Same goes for OSGi. The MANIFEST syntax along comes from Java 1.1. Blueprint does not make it better - no type safety.
• Apache CXF extensibility mechanisms are based on a number of java.util.Map<Object,Object> that are passed around the stack. No type-safety there too.

There are obviously a good samples that promote type-safety, like Google Guice (which is IMHO superior replacement for Spring) or Tapestry IOC, however these are not mainstream enterprise java technologies because of the complexity associated with type-safe programming and (partially) generics.

As a background of this post we had a recent discussion with my colleauges at Talend. We need to design an interface for OSGi service that have to be very stable and extensible. The only practical way to do that is to use java.util.Map<String,Object> and java.lang.Object almost everywhere which essentially mean breaking type safety and fooling the compiler so that no type information is available at compilation time.

Given examples examples above I could conclude that type safety is a promise that works well up to the level where flexibility and modularity requirements become a major concern. Practically speaking small parts of the code will benefit from type-safety and early compiler checks, however large code bases (which need to use Enterprise java frameworks) will not have any benefits.

It was many discussions and rumors recently about how much memory does the IPad2 has. Let along the end result for IPad2 but it's obvious that the IPad1 has 256 Megabyte of RAM. Just imagine, it's 16 times less than my current MacBook has and 32 times less than my future MacBook is going to have. With some limitations what I do with my laptop, I can also do with IPad. Things like browsing internet, editing documents and even programming I can do with IPad. That means that generally speaking IPad is (almost) 16 times more efficient than my current laptop. Obviously it's a simplified representation of reality but it can give you an idea that even for simple things there is a space to improve on efficiency.

Now to the topic. Recently I've been reading more and more about node.js. It's absolutely great platform for server-side development. Creators of this project not only were successful to reach the sweet point between abstraction and control (IMO) but what is really interesting is to compare it to the Java world which I know very good.

Java is write-once run everywhere, when you are programming in java things can became very complex (think about volatile and synchronized and concurrency infrastructure) but at the same time JVM gives you a common ground to make it work on all platforms. It's pretty cool since it will run everywhere, however with JVM you are getting a common denominator between all platforms, meaning a potentially weakest solution possible on all platforms.

In contrast node.js is very linux oriented, and there you can for example use file descriptors to pass data between two processes running on the same PC, which is absolutely exciting way to load balancing, which was very infrequently used in Java world. Apart from that it's not only fully asynchronous but when programming node.js you can see exactly how things works on the OS level (if you want). With Java most of the time you would need to guess what's happening behind the JRE APIs.

When I was exploring node.js and huge ammount of frameworks already created for node I was most of the time thinking 'In Java I would need a huge abstraction and communication layer for that' and node answer for that 'Just use the OS for that, stupid - OS is the best middleware'. That's pretty mind blowing to see simple solution for simple problems, especially when you know how complex are solutions to the same problems offered in different languages/platforms (example OSGi hell vs. RequireJS).

But major point what is so attractive for me is node.js is computational efficiency.Think about Direct Memory Access (DMA). From Wikipedia: "DMA is an essential feature of all modern computers, as it allows devices to transfer data without subjecting the CPU to a heavy overhead". If we just need to take these 10 MB in memory and put it to the network CPU shouldn't be busy with it. You application should tell network card: 'Take these bytes and send them, after that just inform me when you are ready'. After that application should just continue with business logic. One CPU core executing one single thread is much more efficient than one single core running 100 application threads with constant context switching. And that's the main advantages of node.js for me:

• with node you can increase your computational efficiency to the level that is hard to mach with other frameworks (one CPU core - one thread).
• a sweet spot between complexity and control will make you much more productive in developing efficient applications (simple solutions for simple problem).

And concerning platform independence (write once run everywhere) with virtualization I don't care anymore.

Was hacking a bit with Sproutcore this weekend. Sproutcore is absolutely awesome MVC based Javascript application framework, it's not only beautifully designed (right interpretation of MVC) but also comes with full blown set of practices and utilities for large-scale Javascript development. This is a major Sproutcore feature (IMO) which also made it so attractive to me.

So, Sproutcore has absolutely awesome backend/data store functionality that can be seamlessly integrated with different kind of storage backends. I used forked and did a minor corrections to the CouchDB Sproutcore backend developed by Evin Grano. However I had one issue. To this one I'll tell more later.

Here I would like to give you a tip on how you can implement a 'Loading...' indicator like in Gmail:

Basically this indicator should appear on the screen as soon as first AJAX request is sent and disappear as soon as the last AJAX response is received or request(s) is (are) canceled. Fortunately Sproutcore already have a nice centralized service that is informed about all AJAX requests which are done though SC.Request - SC.Request.manager.

From the JSDoc: "The request manager coordinates all of the active XHR requests.  It will only allow a certain number of requests to be active at a time; queuing any others.  This allows you more precise control over which requests load in which order."

So to implement our loading indicator we just need to add this:

Where App.mainPage.mainPane.loading is your loading indicator view positioned the way your like. 

Now back to why I needed this one. Model updates and synchronization with the server is happening (obviously) asynchronously, so at the time when requests for update are sent but responses are not yet received model objects are kind of blocked (in BUSY state) therefore are not modifiable by users (prevented by evil exceptions), so I'm using such trick as a dirty workaround to block users activities because my 'Loading...' indicator is very big and span all across the screen ;).

This is obviously not the best solution but works for now. For future I have in mind something more 'Wave'-like with integrated undo/redo support, etc.... but that's a topic for the new post.

Updated: As properly corrected by Luc visibility modification should be done within the SC Runloop.

Updated: As properly corrected by Erich Ocean loading view should be accessed via getPath.

It's done. My pull request accepted and merged into the Smooks github repository. Inside this monster commit (it was actually 10 commits squashed into 1 - p.s. git is awesome) we have now a support for the namespace declaration inside the SAX events generated by UN/EDIFACT parser. In this blog post I will explain how can you use it.

Firs change we have is that we created a new version of the EDI Mapping schema http://www.milyn.org/schema/edi-message-mapping-1.5.xsd so we don't break a compatibility to previous versions. Main changes so far are addition of the namespace attribute to the top element of mapping, so if before you were using 

<?xml version="1.0" encoding="UTF-8"?>

<medi:edimap xmlns:medi="http://www.milyn.org/schema/edi-message-mapping-1.5.xsd">

<medi:description name="Test Message" version="1.0" />

Now you can declare a namespace of the elements that will be generated by UN/EDIFACT parser using namespace attribute:

<?xml version="1.0" encoding="UTF-8"?>

<medi:edimap xmlns:medi="http://www.milyn.org/schema/edi-message-mapping-1.5.xsd" namespace="urn:my:namespace">

<medi:description name="Test Message" version="1.0" />

Please note this attribute is optional, if you omit it EDIFACT parser will not set any namespace into SAX events.

Second change is now ECT (tool that generate Smooks UN/EDIFACT mapping files based on the UN/EDIFACT directories) will automatically generate namespace attributes on the mapping files. It will use following rules:

• Directory namespaces will have following format http://www.milyn.org/schema/edi/un/[RELEASE]/[STANDARD].xsd for example for CUSCAR version d99a it will generate namespace  http://www.milyn.org/schema/edi/un/d99a/cuscar.xsd
• Common definitions files (reused by all definition files within one release) will have following namespace http://www.milyn.org/schema/edi/un/[RELEASE]/common.xsd for example for d99a it will be http://www.milyn.org/schema/edi/un/d99a/common.xsd
• We also have a namespace for the EDI envelope (UNH, UNZ,... segments) namespace is fixed (for the envelope version), right now it's http://www.milyn.org/schema/edi/unedifact-header-41.xsd

And off course with all these changes UN/EDIFACT parser will now produce a namesapce aware SAX events (including calls to startPrefixMapping/endPrefixMapping and xmlns attributes), so XML produced by the EDI Parser will looks like following:

<?xml version="1.0" encoding="UTF-8"?>

<h:unEdifact xmlns:h="http://www.milyn.org/schema/edi/un/header-4.1.xsd">

<h:UNB>

<h:syntaxIdentifier>

<h:id>UNOA</h:id>

<h:versionNum>2</h:versionNum>

</h:syntaxIdentifier>

<h:sender>

<h:id>SENDER</h:id>

You can find a full XML file here.

Please note that header elements (UNB, UNH, etc) are declared in envelope namespace, CUSCAR elements (CUSCAR, Beginning_of_message, etc) are declared in CUSCAR specific namespace and common elements (DOCUMENT_MESSAGE_NAME, DOCUMENT_MESSAGE_IDENTIFICATION) are declared in common namespace.

So, to summarize the changes, on the first sight XML produced with namespace support could be seen as less readable. It is so, indeed, however namespace support is a first major step towards XML Schema support for generated UN/EDIFACT XML and in future a must-have for X12 or HL7 support we are going to implement in Smooks. Next step would be to simplify generated XML by using shorter element names as well automatic generation of XML Schema documents based on the namespace aware EDI mapping files. Stay tuned or follow me at @zubairov or @smooksframework.

Hello posterous

Hello new blog. It's time to move on to the new blogging platform. So here I'm on Posterous.