Mother of all mashups

Welll...maybe not, but surely excellent! Google has done it again. Enabled the right thing at the right place!! Out in the world is "Google Mapplets", a mashup of map based mashups and enabled right alongside google maps, in an unobstrusive way (as always)....there but not there types, invisibly visible.

Google opened up Maps a couple of years back (maybe even less than that) and a lot of interesting and innovative mashups that use this come up every other day .. Eg:- HousingMaps.com, ChicagoCrime.org, GasBuddy.com..Many of these innovative creations haven't been exploited the way they should have been/could've been because of one very obvious reason...They are very useful, but just not popular! Some are quite popular, but a little/lot more popularity won't hurt them :)..Google Mapplets is an excellent way of getting this information to a user's fingertips...

So what are these Mapplets? In Google's words:


Mapplets are mini-webpages that are served inside an IFrame within the Google Maps site. You can put anything inside this mini-webpage that you can put into a normal webpage, including HTML, Javascript, and Flash. Google provides a Javascript API that gives the Mapplet access to services such as manipulating the map, fetching remote content, and storing user preferences.

Google has once again shown us the difference between a good product and a great product...good products are conceptually good, have a lot of potential, show a twist in thought...but great products are all that and add twist to life ... You don't have to think about the most innovative product in this world...to enable access at the right places to innovative creations is by itself quite innovative..

Check out Mapplets for more information..

Blades, Virtualization, VMWare

Virtualization is one very common term floating around Corporate IT circles. It means different for different people and no matter what it means, everybody agrees on one thing, which is basically that it is a means of cost-savings. People consider virtualization to be server consolidation, hosting your company's services on Amazon etc etc, but to me ..

Virtualization is about creating a virtual, rather than actual, version of a computing environment. Virtualization is useful for consolidation because one physical server can host several virtual versions of an operating system/systems or applications.
Virtualization is a good option for IT shops with several servers that are running applications that do not use up much of the capacity in the box Eg: VMware and Microsoft platforms in the virtual data center...Remember all those systems in Certification, Integration that "hardly" hum and remember that testing you couldn't do because you didn't have a server with the environment you needed to test it on? Virtualization can be the silver bullet for you! You can use the idle capacity of your boxes to launch different OS's basically making one machine assume different characteristics based on the need! Simulating a heterogeneous test environment for product platforms becomes a cakewalk...product demos to customers on multifarious platforms by Marketing becomes easy...have various VMware instances (each instance is only a file :)) and pick and choose as per customer demand..one laptop, no partition!
Infact, what I would ideally like to see is Product vendors coming out with pre-configured VMWare versions for products on platforms they support. A solid example on how this would be useful is from my own experience...We have a major memory leak going on for one of our application in Production running on a Linux Opteron server...we have been evaluating java profiling tools and have almost decided on JProbe and we thought that it would be a great fit for our needs currently...BUT now after talks with JProbe, we realise that don't have a version of their product for Linux,Opteron...Would have been good if they had a VMWare packaged version of their product in a friendly platform...we would have grabbed it with open hands...Java is java anywhere .. on Opteron, Sparc whatever...so just being able to run JProbe on our machine was more important to us!

Talked a lot about cost savings by flexibility, grouping above...there are other advantages too...especially when combined with blade servers, the cost savings can be enormous...less space occupied, easier maintenance, savings in power costs, flexibility, easier configuration, faster response to needs and more! In fact, there are claims from companies saying that they saved around 70% or more in datacenter costs...not a very easy number to achieve, but nevertheless i think you can save quite a bit if you use it the RIGHT way!!

Though in Corporate circles I should say, Might is RIGHT :P///Right ?

Java - made for Real time?

Java is a great language. Made to run anywhere, it started running everywhere, captured a million developer hearts and then bloomed to perfection. Well, almost ... It has the largest developer base now, is a part almost of all open source initiatives, has grown leaps and bounds above any Microsoftian language/platform, but still lacks in ----

One of the strongest points and the weakest chinks about Java has been it's automatic Garbage Collection. It is really very convenient to have a self-contained application (in terms of memory usage and security) and get over the rigmarole of code-based memory management, but everything that comes easy has a cost attached to it. Java's cost is it's unpredictability at times... times when GC takes over and strangles your app, sometimes to an extent of choking it to death (mean OutOfMemory exceptions :)). My move to CTO brought me closer to applications, mainly applications with problems and one such association brought me to an application that just died every 10 hours. Closer analysis revealed that GC's were very frequent and almost all of them were full GC's. We are tuning the GC parameters to make the app perform optimally, but some other thoughts started sprouting in my head...

What if there was a way we could take control over GC and schedule it around better times...most GC's always happened during peak hours...many app's can take this delay (well, if it is in the order of <5 sec), but some mission critical systems just cannot..say for example missile launching systems/ time critical financial systems where every second is just too precious...with bigger heaps, GC takes longer -- maybe in the order of minutes at times and this might be unbearable to quite a few "lenient" systems too..after all, all our applications are driven by SLA's from our customers that specifically measure delivery times and accuracy. Can we afford to let our JVM's run scot free when we are SLA bound? A time-based GC strategy I thought made some sense when such mission critical systems were in question..why not run GC like our nightly batch processes when customers are hardly online? This would mean that during peak hours, our JVM works uninterrupted and during the nights, it just unloads...well, made some sense to me (not a lot :)) as this would make Java behave more "predictably"..but on the flip side is the enormous memory chunk that one would have to allocate to keep our JVM whirring...doesn't make practical sense and maybe that's why SUN didn't have anything like that to offer....my thoughts I thought were in the right direction though and I talked to my colleague Ryan about this and he pointed me to a silver bullet :)

Running a JVM with "deterministic latency"...namely setting some stiff targets to a JVM and make it operate within it..SUN had been worrying about this problem from day 1...JSR 001 was all about this, but the implementation really did take quite a bit of time..SUN came up with the RTSJ spec this May (Real Time Specification for Java) that addresses this concern.

You can find the spec here RealTime Spec for Java

This is a good article for the same...O'Reilly RTSJ

Real-time Java offers a much more reliable and predictable scheduling mechanism, memory handling methods, different memory models, a more predictable threading and synchronization model, asynchronous event handling, and high-resolution time handling. It makes predictable execution the first priority in all trade-off decisions, sometimes at the expense of typical general-purpose computing performance measures. It achieves predictability by having RealTimeThreads that have higher priority over GC threads, by direct memory access i.e by allocating objects on memory that isn't in the heap (so that the app remains unaffected even during collections) and many more features...Read the spec and the article to learn more !!!
Did Java fix the last chink in it's armour? Well, there is still the Swing bloat problem :)....Developers are never a satisfied bunch!!