New Tasks feature in gMail

The new Tasks feature is gMail is awesome!!! I have waited for it so long. Now I can abandon all substitutes I had tried to use (without any success by the way).

I use gmail as my single access point to work items. Separate tasks management systems was really unnatural for me. And now I can use gmail to do all stuff I need day by day.

It is not very rich from feature set point of view, but usability is great as usual. Hopefully, additional features will appear soon. I'll be happy to have an external access to the task list and tabs for task list switching (google, do you hear me?). :)

No posts for a long time

Lately, I did not write much. This is due my long summer holidays (I've visited Norway and Altai Mountains btw).

Now I want to inform you about some news. I leave Enterra Inc and Barnaul tomorrow and move to Saratov to work for Grid Dynamics. Hopefully, I'll be able to get a stable internet connection soon. If so, I shall update my blog more frequently.

I plan to share details of my life in Saratov and experience in grid systems building.

GWT: Pros & Cons

Pros:

• Very good perceived UI responsiveness. In a perfect case response times will be even better than on desktop (local Google Gears caching is great).
• GWT uses component model for UI, so code reuse is easy. And there are many open-source libraries of GWT components too.
• GWT server-side is stateless. So it is highly scalable "by design". In our case we achieved very good performance per single front-end server instance.
• You can make your UI similar to desktop GUI with associated sweeties (DND, visual effects & etc)
  

Cons:

• GWT is built around Java -> JavaScript compilation. So if you get a big Java codebase, the result js files will be big. So some old browsers will not be able to load and run them
• GWT app loading time may be quite significant for big codebase. Of course, browser caching helps here
• GWT renders page content with JavaScript, so indexing of data represented by the app is problematic
• While there is browser history control inside the library, there are restrictions introduced by HTTP/HTML stack. In general case, you will not be able to reference pages inside GWT app if you use HTTP redirect (for example during authentication)
• HTML Browsers are not too good in visualization of dynamic HTML (IE is the worst, Safari 3 is the best). So you may need some tricks to show big number of items)
• GWT components are not easy to debug/implement. They should be cross-browser. And HTML browsers have their own bugs too. So you may need a JS/DHTML guru in your Java team.

SpringSource Application platform

Lately, several Spring based platforms for application development has arisen. I guess this is a good thing. JEE is a quite rigid and restrictive for modern application development. There are areas were this is good. For example in conservative industries code may live for 10-15 years. So well described standardized platform is a must.

But as I said it has drawback. This is why Spring is the leading framework for application development. It is like LEGO. The framework ties together many different components into a single system and provides unprecedented flexibility in architecture design. In the last two java projects of mine JEE container was just for checkbox. Mostly all functionality is controlled and managed by Spring.

So introduction of the Application Platform by SpringSource is a GREAT EVENT for me! While the platform is on early stages of development yet, it tends to be a great tool!

• All components are physically modularized through OSGI. So version control and dependency resolution is inside container already. These things I was doing manually for ages.
• Logging is fantastic! The platform separates event streams by originating application and allows to configure details level very precisely. The configuration language is much simpler and comfortable than Log4j XML. Moreover, serious app errors are detected and logged (deadlock & etc).
• The platform provides native support for Spring contexts, modules linking through Spring DM. I am happy. :-))))

However, the platform is young still. I did a quick review and got following wishes:

• The platform need a bundle distribution infrastructure. I want not put new bundles into all instances manually. Of course, I can automate this. But it would be better to have the feature inside the AP.
  
• I'd like to have Tanuki software wrapper as native runner instead of custom made shell scripts. The wrapper is broadly used by community and it provides very good capabilities for OS integration (services, remote restart, watchdog & etc)

Anyway, this is a big step forward for server application development. You are on good course Spring!

Monitoring that matters

I am using Hyperic HQ monitoring for more than a year now. And it becomes more and more obvious for me that an important aspect of monitoring is missed by popular solutions. Yes, it is important to know throughput of the system.

But the metric that is really matters is CUSTOMERS EXPERIENCE. And it usually derives for two things:

• Service responsiveness
  
• Error ratio

The problem is that these metrics are application level parameter. I mean there is no OS counter that can be easily obtained by software system. And both application and monitoring system developers should pay effort on integration. This is where HQ is good. It is really easy to create JMX bean and an XML plugin to gather application specific metrics.

But there are area for improvement. I'd like to have:

• Network level error statistics like number of missed IP packets
• Exceptions in the log by type

Usually, errors rate gives more information about system health. But this type of metrics are successfully ignored at the moment.

Gigaspaces monitoring with Hyperic

A half-hour ago I've released the first public beta of the Gigaspaces monitoring plugin for Hyperic HQ. The plugin provides automatically discovers and monitors of GigaSpaces XAP 6.0 on physical and logical levels. More information from the project homepage.

Farewell, Vista

Lately, I have purchased a laptop with pre-installed Vista Home Premium. My first impression was quite good. Wow, it is so nice and quick enough.

But problems started to appear soon. I started to get "Not enough memory" errors from Eclipse. But wait, my development environment works fine on my desktop with 1.5GB RAM. Why does it fail on 2Gb with Vista?

The answer is simple. Just after install my Vista allocated 860Mb of physical memory for background processes. So I took my tambourine and file those I had used for Linux a long time ago and fixed it. It had worked for me for sometime.

As I've written already, I am working on a plugin for Hyperic which will allow monitor activity of GigaSpaces clusters. As I was waiting for availability of Ubuntu Hardy beta, I have written the code on my Vista laptop. It was a BIG ERROR.

Hyperic auto-inventory just don't work on Vista. I spent several days of work tring to resolve a error which appears on Vista only. Yes, I am not sure this is Vista's fault. But I have seen several very weird bugs like that. So I will not use it for important things anymore.

Farewell, Vista

GigaSpaces plugin for Hyperic

I've just started an open-source project aimed to developer Hyperic plugin for GigaSpaces XAP monitoring and management.

See details here.

Ya.ru service validation record!

Hello!

I have added the blog to ya.ru service. It requires ownership checking. So this post is just for the registration authorization.

22267502.024530d1d30810ca053b429754354a41.1203668219.d3e85a9367d5a2e2633c951543c6ed76

GWT: Improving performance

I have moved the article from blog of Enterra Inc in order to ensure it won't be lost. A copy of the article can be found on their site.

Authors: Renat Akhmerov, Alexey Kharlamov

Published: 13th Feb, 2008

Since the public introduction in August of 2006 the Google Web Toolkit (GWT) has gained significant momentum among web developer. The technology allows to build very interactive and responsive applications using convenient and very sophisticated tools as Eclipse, Maven and SVN. Moreover the GWT aims to build cross-browser applications by isolating platform specific quirks.

Our team has used Google Web Toolkit since the 1.1 release. While we are very happy with overall development experience we have found several performance limitations of the library. Actually, the limitations originate from restrictions inherited from the HTML layout algorithms and browsers implementations. In this article we will try to offer ways to workaround these limits by using more effective ways of HTML manipulations.

First of all, let me describe our application. The system is aimed to provide time management and collaboration features to the system members. So the most time a user sees a tree of tasks like Work Breakdown Structure. GWT components worked rocket-fast while the number of visible items did not start to grow. Some of active users had several thousands of items in their space. So the rendering took tens of seconds.

Another problem was in updating browser’s working area. The most popular web-browsers do not update HTML canvas during execution of JavaScript. So browser freezes while the application builds GWT components. User actions are not handled at all during this period. So the slow components rendering becomes a real disaster. Fortunately, the solution is quite simple and well known among the GWT community.

Any long running work should be divided into small-to-medium sized chunks and executed through theDeferredCommand. So a parallel execution is emulated.

Fig. 1 Deferred rendering

While we are keeping execution time of a single DeferredCommand less than 100-200ms delays between user actions and system reaction do not hurt user experience. But the solution is not exhaustive. It softens the problem, but rendering of complex data still may be too long. The problem is hidden inside component model provided by the framework.

GWT has many special widgets that serve as containers. Frequently the containers are used to format other components with data attributes. It turned out that containers used DOM.appendChild() method to attach their children to a document. For example, FlexTable and VerticalPanel manage descendants this way. Also, the standard components actively use DOM.createElement() calls. These operations are fast enough for a small number of components. However, they are really slow in a mass.

Our tests had shown that DOM.setInnerHtml() worked much faster than theDOM.createElement()/DOM.appendChild() pair. This is quite expected as innerHtml property uses optimized native DOM building code inside the browsers. So we decided to rework our Tree component to use innerHtml. The updated tree was hundreds times faster! It seems dynamic operations on DOM inside browsers are far from optimal in the most wide-spread browsers. To resolve the issue we abstracted a common way to implement UI components those should be rendered quickly and called it FastContainer.

The FastContainer pattern

The idea of the pattern is simple. Using setInnerHhtml to create DOM fragments and attach GWT components to the appropriate elements. But it’s not very convenient way to work with DOM-objects representing them as strings. Moreover, setInnerHtml is more effective for bigger chunks of HTML code. So it is sensible to insert a group of elements/components at once.

Fig. 2 Work item

If you take a look at the picture above you will see an example of such group. This component can be virtually divided into layout HTML and a set of controls (one checkbox and the text labels in this case).

Under layout we understand the frame with gray background and rounded corners. It contains other small controls inside. The layout is also responsible for alignment of these controls in its scope. So if we want to implement this layout using most common way we’ll have to do a lot of things. First, we’ll need to create an instance that will be a layout. For example, it is possible to use FlexTable or some other panels. Then we’ll have to do complete configuration of this object adding all the rows and cells (including cells that will contain pictures of rounded corners), setting styles up for these cells, inserting pictures of rounded corners and then inserting target controls. All of these actions would be performed dynamically step by step! And each will call one or several createElement()/appendChild() methods. But this can also be accomplished using text representation and a single call to the DOM.setInnerHtml() method. And the layout HTML can be developed in a favorite editor rocket-fast.

Following this logic FastContainer pattern was invited to provide a convenient way to work with components considering them as HTML fragments. In other words, this pattern allows building a Widget instance from html text fragment and provides an interface to interact with the contained widgets. The original idea belongs to Sergey Dryganets who suggested the abstraction and provided the first implementation called LightWidget. Later we improved it and formulated the FastContainer pattern.

The basic idea is isolation of HTML source inside a Pattern entity. The entity encapsulates all HTML source building logic. The class FastContainer represents a desired component that builds itself using pattern and context. Also it provides an interface required to manipulate with its descendants.

On rendering stage each FastContainer uses the Pattern to generate an HTML fragment which is passed to browser. During the generation process the ConcretePattern instance fills the Context with data about element bindings. So the container will be able to quickly find required elements.

Fig. 3 FastContainer structure

It is very important to understand that the Context is a bridge between the container and its representation inside the browser’s DOM. It allows perform dynamic updates of internal structure and quickly find placeholders for child components insertions.

As there can be several instances of the same pattern inside the document an IdManager should be used to generate unique IDs for HTML placeholders. But this process is completely hidden in the pattern implementation. So client is only aware of names (string values or any other keys) of the placeholders. Using these names a client can:

· put a plain text/HTML code into the specified placeholder

· put a Widget into the predefined position in the pattern

· create a Widget descendant using an element inside the pattern

Pros and cons

Using this pattern we have two advantages. First, we have the possibility to implement layout of some component as an html code. That is more straightforward way than using GWT object model. The second advantage is in improving rendering speed of the component due to using DOM.setInnerHtml() and the fact that we attach the component’s layout in one step instead of building it iteratively in a few steps.

However, GWT encapsulates the most serious cross-browser issues. As we use pure HTML we are in charge of solving cross-browser problems by hand now.

Also it is inconvenient to manage generation of the HTML code inside Java sources. While there are some methods to relax the problem by using external HTML templates (See GWT HtmlTemplate widget), they may slow down application loading and rendering speed.

At the moment we see only one satisfactory solution. A support of HTML pattern generation inside the GWT compiler in a manner of resource bundles implemented now. This will allow:

· develop HTML templates in separate files but keeps them inside the main JavaScript application code

· avoid manual generation of patterns together with all id related work

· improve performance

We would be happy to discuss ways of the GWT compiler improving with the community.

Maven: Do you use it? Still?

Sometime ago Howard Lewis Ship has posted a critique article about Maven builds. I am fully agree with him. I use Maven based build on one of my projects for 1.5 years now. It is a REAL PAIN. A year ago a was so disappointed by it that I had wanted to write a slashing article. But I've abstained. Now I see that my problems are not unique. So I want to add my 2 grams of lead mostly due the comments on the Howard's article.

There are three things those make Maven an bad choice for build tool:

1. Lack of discipline in developers team
Yes, I said it. All other problems are just consequences of this. There is no any release plans, configuration management and communication with customers.

As result, you shall find yorself using SNAPSHOT versions of plugins so explicit version numbers will not work. You need to establish an own controlled repository.

2. Convention over configuration principle
Yes, I am a heretic. I think conventions do not work good enough for large projects. Just because you need account too many of them.

Maven works good for simple projects, where artifact structure is planar. But it become a real mess to manage 3-4 level hierarchy of projects inside one build.

Another bad thing with conventions is easy modification. The Maven dev team can do a small change, and your build will be broken. Actually, the change may even be a bugfix. But you are in trouble anyway. It may pass sometime before one of your team members install Maven with a difference in patch level and the build will stop working for him.

3. Buggy implementation
There is no any software without errors. This is like an axiom in our days. But in the Maven's case bugs are a real problem. Mostly because of lack of appropriate release policy. Some issues stay unresolved for years.

Now, it is unrecommended practice to use Maven for builds inside my company. All new projects use Ivy together with internal Maven repository now. As I can see developers are much happier with it.