The simple beauty of NoJax

Recently I've needed to figure a simple way of updating a web page at each 4 seconds.

The modern web 2.0 option is using AJAX (Asynchronous JavaScript and XML) and this option sounded fine and dandy. Got myself exploring this path, finding some nice tutorials and simple guides that took away the black magic underneath the Javascript to reach the intended results.

However, I was having a lot of troubles to get it working as intended. On some browsers it would work, on some others it wouldn't. On some browsers I would know how to fix the issues while in some others remained a complete mystery.

This was no longer the simple solution I was hoping to apply and found a nice alternative: Meta tags.

The concept is simple, just add a meta tag requesting for the page to be reloaded within some seconds in the future. Simple, practical and works across all browsers.

Some obvious side effects: it will reload the whole page instead of a silent AJAX-style update. Other than that, it does get the job done in a stable manner.

Credits go to the about.com page that has a nice tutorial: http://webdesign.about.com/od/metataglibraries/a/aa080300a.htm

It is nice to enjoy the simple beauty of NoJax.

:)

The importance of database isolation

This week I've continued to progress on the new project.

One of the worries that has been roaming my head was the isolation of data between different components. On the current concept, components are isolated from each other to some extent but they still share some common resources like the database.

Below is a simple diagram that depicts the difference between shared and isolated approaches to database storage (credits to Mary Taylor @ IBM).

It was a relevant point to ensure that this resource would also stop being shared for the following reasons:

• One faulty component could wreck the database, causing other components to also fail
• 10 components can share a single database, could 100 or even 1000 use the same model?
• No duplicate table names on the database could exist, this issue is aggravated when sharing this resource with other components
• One single point of failure, if the database goes offline then all others will also fail to recover themselves

And some advantages also surfaced:

• Each component can define custom login/passwords to access their database
• Full control over the data that is stored, no other components change the data by accident
• Provides choice between running their HSQL database based on a disk file for optimum storage or stored in volatile RAM for optimum speed
• Each component can now individually store up to 16Gb of data using HSQL

I suspected that transitioning from a shared database model onto an isolated model would be somewhat troublesome, but the implementation was (fortunately) completed in a half a day and the effort was surely worthwhile. The end result passed all test cases and works exactly as intended.

Lesson learned:

When designing/implementing an architecture, do take into consideration the importance of keeping these resources isolated from each component as early as possible. In the long run you are improving the robustness of the system that is being designed.

Editing large text files (above 1Gb of size)

Recently I've began working with considerably sized text files that cannot be edited with the regular text editors such as plain notepad or notepad plus.

To keep on working, I found Cream (http://cream.sourceforge.net). This editor is free and handles fairly well files of larger dimension. It is supported across multiple Operative Systems, I could use VIM but I really prefer to use big round buttons and menus to get my work done.

Albeit the cream editor allows you to change big files, it is not a magic bullet and you should be prepared to wait some time until your changes are saved back to the file on disk.

Having said this, I think the tool is really worth to try out.

:)

Old school programming

This weekend was intense.

While working on my current project, I've slowly reached the conclusion across the past week that many things were wrong on the adopted architecture and that a simpler solution could be adopted.

Reminding myself of the words from a wise software engineer about efficiency of the good enough I could have kept on moving, but it would pain my soul knowing that things were not optimal. If there was a time to make changes, the time was now.

Couldn't afford more schedule slips as seen for the month of the March. So I've decided to plunge myself into a coding marathon to rearrange the code and do things right.

Started of at Friday after work around 17:00 and stopped around 04:00 Saturday morning to grab a snack and some sleep. Saturday and Sunday followed similar hour addiction for code cranking the intended result. The outcome was fabulous!

Not only the new framework is simpler in terms of architecture, it also looks great. The web user interface provides a neat appearance and makes life a lot easier than creating a Swing based interface for each component of the system.

Many other nice-to-have features were also added this way. People can use browsers or third-party developers can create wrappers that make use of the provided web services.

I know that anything coded during a hackathon weekend will haunt me with defects across the next times. That is a risk. But it is still better than living with an architecture that that would only add layers of unnecessary complexity and my own (human) resources are too limited to cope with them.

As result, there is absolutely no need to adopt a Google web toolkit, hibernate, SEAM, JBoss or ActiveMQ COTS for the moment.

The current result can rightfully be called old school programming (compared to current trends of course). And I say this perfectly aware of all advantages and disadvantages that come from this design decision. But nevertheless all that, there is elegance in simplicity and this is the route that I prefer to follow whenever possible.

And speaking of small, the entire framework when including the database (HSQL), message queue, process manager, web interface and remaining components is still using some whooping 3Mb of disk space.

Below is demonstration screenshot of the current status. The page demonstrates two applications. The first one is a simple file browser and the second demonstrates a simple page with text. Each application can host child applications and these are automatically added on the page tabs.

Tough weekend but happy results.

:)

Last night a findbugs saved my life

Do you know what FindBugs is?

It's a neat tool for Java that helps coders find part of your software that are plain redundant or might even run into "bugs" in the future (I prefer to call them "defects" rather than plain "bugs").

I had already used FindBugs in the Eclipse IDE last year, but only recently started using this tool for the NetBeans IDE and now I really appreciate its value.

To install this tool as an integrated plugin of Netbeans is fairly simple and covered widely across the Internet (here's an example).

When I started applying FindBugs on my current project, I noticed that my code was syntactically correct and ran as intended on the test cases, but FindBugs flagged some relevant concerns.

For example, it would flag a warning when new objects were created in a redundant manner or even when a given result might not be handled properly (null handling).

But what I found to be the most useful feature of them all, is the help for coding systems where multiple concurrent threads share information between them.

I mean, a developer already has some notion of practices necessary to prevent thread starvation and other concurrency errors but there exists a good amount of human effort and possibility of human flaw that frustrate your coding progress.

This is where FindBugs came to the rescue. While coding it was consistently able of reporting to me which methods were required to be synchronized in order to prevent thread locking and inherent locking of the outputs expected by other threads.

I would have been able of solving the synchronization issues on my own but having this tool available to help was a real time saver.

If you're still resistant to the idea of using FindBugs after reading all this, do try it by yourself at least once and then let me know what you think.

Take care!

:)