Wonderful analogy between programming & sleeping

Just found a great article about Analogy between sleeping & programming (russian only). When stated, similarity becomes mostly obvious.

Full-text & faceted search over In-Memory-Data-Grid

Modern in memory data-grid solutions provide different facilities for execution of queries over whole stored data set with different levels of sophistication . Coherence provides Query facilities (one time full scan & continuous quering with Cost-Based-Optimized). Gigaspaces has JDBC Query interface with ability to use hash & B-Tree indexes. The solutions work quite well for big part of problem areas. However for heavy loads & complex multi-createrias queries the facilities may become a bottleneck quickly.

But there is a class of workloads producing high query loads onto IMDGs. Item catalogs (in retailing companies for example) are hit by diverse stream of multi-createria queries.Typically query you see likes :

give me cell phones with MP3 support, Java and in red color.

Fortunately, Compass framework allows to do such queries effectively. It allows to builds inverse indexes with Apache Lucene and store them in a grid. The capability originates in very modular design of Lucene framework. All index IO operations hidden by abstraction of FileDirectory.

For now Compass provides implementations for Coherence, GigaSpaces and Terracota introducing unprecedented ability to build a vertical search solution on top of In-Memory DataGrid.



Moreover, Compass has sophisticated object-to-document mapping system which allows to make stored objects searchable just by addition of Java annotations or XML mapping files. Also mapping can be built in runtime.

However, inspite the great code, Composs has scarce documentation. It may take significant time to dive into the code and docs to get what you want. But results will overcome all your expectations. Search engines on top of data grids easily overcome any old-generation search technologies.

Ship It Review

Content of the book can be naturally divided into 3 parts:
- Code of Software Developer
- Advices about development tools and considerations
- Trace Bullet Development
I'll review each part independently.

Part dedicated to relations in developers team and management is absolutely brilliant. It gives wonderful inside to team dynamics, main factors influencing changes and intrateam relations. And most importantly it provides solutions for common problems of day-to-day developer’s life. No doubt, the chapter will be interesting for both newbies and seasoned team leaders.

Another part of the book is dedicated to development tools and processes. There is nothing novel here. In our days every developer knows Version Control System should present. And it would be better to have a continuous integration server if your team has more than 1 guy. So the part can be skipped if you have knowledge about modern development processes.

And the last part is dedicated to so-called Trace Bullet Development (TBD) process. While the wording sounds cool, usefulness of the process is rather arguable. Don't get me wrong; described design process (yes, this is not a Development process, this is a Software Design Process) will work. Creation of vertical of functioning system components is a good starting point for any project. But TBD pushes it forward too much. Interfaces created early tend to be error-prone. And after the interfaces were designed, they tend to become unchangeable. So line by line they become monsters which have no connection with the original elegant idea.

Concept of implementation of architecturally important user-stories or use-cases looks much better for me. Needless to say, as in any book there are several out-dated or even harmful advices. For example, "design all interfaces to be remote" . Such methodology used without appropriate care will make system too complex without real need.

Anyway, the book worth reading. This is the best masterpiece I’ve read since "The One Minute Manager".

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!