I recently lived through one of Sherlock Holmes famous quotes in development land the other day.

when you have eliminated the impossible, whatever remains, however improbable, must be the truth

It was a serious bug in a recent Adobe Flex project that was something so simple (appearing) but could not for the life of me find out why it was occurring.  I mean, I would not be releasing the software without this guy being fixed, it was a blocking issue.

Now I am far from an ActionScript junky that has been drinking the cool-aide since 2000 (yes AS is 10 years old, they grow up so quick).  Anyhow…

So the issue at hand was pretty straight forward: A AdvancedDataGrid on portion of a panel that had numerous columns, some with ItemRenders some without.  Not much data (still in a testing phase) and one huge bug:

DataGrid ALWAYS had the last row selected as soon as the grid gained focus.

You could interact with the grid and even ItemRenders that had sub-components reacted properly, but no row highlighting would ever move. ALWAYS that last row of data was highlighted.

So normal debug started to occur thinking some of the new “gee whiz” features I recently tacked on to the grid, was the cause (this is when version control saves you a zillion hours).

So I start rolling back to previous versions to go and find where the grid was acting like it should.

• Previous version, nope, OK, a little further back…
• Previous version, nope. jump further back….
• Dang this bug has been here since the beginning of time it seems. Boy that is a bad UI oversight.
• Where is the QA team!? I demand the QA guys head… oh that would be me. Dang, shut up, move on.

At this point I am thinking I have bad builds, bad development environment, start looking at other DataGrid’s in other projects (that are working and build fine). Making the whole thing much more worse and I think I have a huge underlying flaw somewhere. Not really, but we will get there.  This is when a sane developer becomes an insane one.  This is when the alchemy comes in and you start thinking the lead will always stay lead and there really is no gold at the end of the rainbow.  This is when a true coder at heart thinks they hear the code weeping.  But alas, we have a P that needs solving.

So I start ripping out the guts.  I mean everything, code that have nothing to do with the problem is tossed aside, just to see if it magically gets fixed. Nope, nope and still nope. So it was time to step back.

Deep breath, OK, this is NOT UI code issues at play here.  We have removed 99% of and it is still broken! Hmmmm. (I hear off in the distant, “when you have eliminated the impossible”)

So what was left? Not the UI, the source of the data? How could that be impacting what row was highlighted? The data is showing up fine in the grid and interacting with the data objects even work.  That can’t be it!  Ah, but it does.

A single lonely property that Adobe uses to keep track of its objects that normally would have never been an issue was the culprit this time round. See, it turns out that the ArrayCollection of data object’s remotely retrieved had a single property in it that should of never been there in the first place (dang badly designed data objects).

So what was the property in the DO that could of caused all this: UID

DOH

It actually would not have been a problem if it had been uniquely populated, but it wasn’t. It was null.

DOH DOH

So basically when the grid tried to uniquely look at the data objects so it knew which one was highlighted, they all looked the same since all the uid properties where all null.

Lesson learned and I swear those poor uid’s will never be overlooked and looked down upon ever again.  Of course in this happy ending of story, the damn UID was ripped out and thrown against the wall and post haste the DataGrid selection and highlighting was once again working exactly as it should.

– THE END –

I ran into the need to change a project I am working on from keeping a ton of java objects in the air due to real-time calculations and performance.  Didn’t need (or want) full database that would need to be maintained by a database group.

Every time the application was restarted, the entire thing would be reloaded based on other sources (other databases of data — all different db’s, data and transformation needed).  The transformation requires each base source to have different set of transformations and calculations performed on them.  Also since the sources have different real-time intervals there needed to be different levels or transformation going on.

Of course if I was a dba, I would be saying this should all be done in some huge db iron and storing it into some jumbo sized tables and all could be done with scripts, triggers, etc.  But I am not a dba, I like my logic in code, not a database.  That is just who I am.  I love Java and like to see what my code is doing to the data and db are used to store and get things for me, period.   Just wasn’t going down that road.  We can agree to disagree or not.

Ruled out in like 5 seconds that the use of flat files to store the calculated data would just not work.  I had to have the ability to retrieve the data fast (wanted hash maps or trees in memory, but that quickly ran out of steam due to quantity of data).  I also wanted to keep everything in the single app (single deployed war) at the end of the day.  Makes support easier in the long run.  One point to look at instead of 12!

So I came up with a list of what I wanted:

1. Needed to be quick.
2. Needed to be embeddable (not an Oracle, MySQL or anything like that) / memory friendly.
3. Needed to deploy when the web application deployed (all self contained).
4. Needed it to be support by ORM (Apache Cayenne) since already using in the project for other db work.
5. Needed to be open source.
6. Needed to be temporary, last only while web app was up and running and throw everything away when app restarted.

I had narrowed my list down to three choices I was entertaining (your experience might be different):

• Apache Derby aka Sun Java DB
• HSQLDB
• H2

They probably would all get the job down.  But I tried to narrow it down by my criteria by doing a little reading (Google + reviews + blogs + groups complaining about stuff + did I like what I saw):

1. Started reading, it appeared H2, then Derby (latest) and then HSQLDB was the speed arrangement. (YMMV)
2. More reading… All would meet the need, but H2 had some really nice instant up and running features that I liked. (IMO)
3. Same as #2, they all would meet the need more or less.  Just different feature set, but once again H2 was drawing my attention. (IMO)
4. All had native support in Cayenne since I am using 3.0 (H2 was not supported prior to 3.0, but that didn’t matter since I am using 3.0).
5. All met this need and would of been fine.
6. All met this need in some fashion and would of been fine as well.

So it really came down to how easy “did it appear” for me to get this started, embedded and actually working, using it in actual live code all in the same day.  For me it had to be H2.

There were quite a few reasons other than meeting my 6 requirements above.  I also liked that it had an active change log which every month appeared to have forward progress and making the project better.  Open source projects are either constantly evolving and or dead.  Get worried when a project hasn’t had commits or quite a bit of progress in months, 6 months, last year, etc.  Code is never perfect, it can always be better.  Don’t leave it there to just die.

I have to admit that venturing down the H2 path in the first day of use has turned out to be a great choice.

Love the embedded console you get by including 1 (one, yes one) jar in your project which you were going to do anyways since that is the only lib required.  Edit your apps web.xml and bang.  That is supporting your dev project front and back.  I can see it will come in handy trouble shooting the application both during development and even possibly productional since we are talking ever changing live data.

Integrated really quickly with Cayenne.  I have cayenne actually building the schema from its own XML each and every time the app starts up.  Talk about reuse and single place for describing the model.  ORM creates the model, creates the Java classes and now builds me my schema in my temp db.  That is a win, win, win situation folks.  No SQL monkey business, period!

With a little more code (I mean little) I have it dropping everything (entire schema) and db temp files when it shuts down (all through a single listener config in the web.xml).  I love when things are simple and just work.   Kudos to Thomas for creating such a great db that works right out of the gate.  Simplest Java library I think I have ever used.

I plan to write up some of the things I find interesting in the coming month or two (along with some other Wicket and Cayenne stuff I have mocked up, but not typed into here).   Here are some of those ideas I have already worked through turned out beautifully (eluded to above)!

• DB embedded in app config.
• Cayenne used to build H2 schema.
• Purge db on shutdown.
• Performance / usage.

It should be noted that H2 is developed by Thomas Mueller who was the creator of HSQLDB (H2 can be seen as HSQLDB2, just better and it even said that it could merge back into HSQLDB)… anyhow.

H2 +1 in my book.

It’s always interesting to see what other developers use as their real workspace when they have control over it.  (Unlike cubical heck).

Once such sweet space is something Mitch Haile built.  I stumbled across it in one of me RSS feed consumption extravaganas and have to admit the space is really, really nice, but I have to say the screen real estate and mini server room/closet is very nice for a home build.

Just had to share the nerd eye candy for others to consume!

http://www.biscade.com/office/

Snaps on Flickr:

http://www.flickr.com/photos/bwa32/sets/72157607284828899/

Very nice work Mitch!  Kudos

It appears Microsoft is updating their virtual earth product with all new imagery.  To do that, they are updating 48 Terabytes of data.

http://www.neowin.net/news/main/09/01/01/microsoft-virtual-earth-gets-a-48tb-update

That takes backing up and moving data around to an all new level.

Can you only imagine the hardware infrastructure in place to handle that upgrade, roll-out and production support.  I know I read specs on their server farm for virtual earth when they first turned the switch on quite a while ago, but I am sure that has only grown as they have continued to one up Google.

Matej Knopp recently released some nice grid (or table) components over at inMethods software site. They work really slick and should be very easy to integrate into existing projects. Not to mention that they make Wicket (as if it was great on its own) just that much better looking.

DateGrid Features

• ajax enabled
• resizable and reorderable columns
• horizontal and vertical scrolling with fixed header
• multi-column sorting support
• easy item selection
• advanced pagination (even without knowing the total item count)
• adapters for Wicket Extensions IDataProvider and IColumn

TreeGrid Features

• ajax enabled
• resizable and reorderable columns
• horizontal and vertical scrolling with fixed header
• multi-column sorting support
• easy item selection
• driven by a swing TreeModel and TreeNode

All wicket users should definitely take a look at the project that is in beta 2 right now.

http://www.inmethod.com

Mozilla has released Prisim last week (previously known as WebRunner).

So what is Prisim?

“…a simple XULRunner based browser that hosts web applications without the normal web browser user interface.”

Basically it is a dedicated website in a desktop client window that lets the website basically act like a desktop client application.   So far it looks pretty slick for such a early release.

Windows download: http://starkravingfinkle.org/projects/webrunner/prism-0.8-win32.exe