Don't Lose The Trail

Always wanted to experiment with new things, especially those with the potential to give me more power and leverage. So I got myself a new publishing platform, I'd recommend you keep the trail because I may be discontinuing Blogger any time soon.

So far it's been cool with my new toy and I am hoping that things stay this way for a considerable amount of time if not perpetually, I am very excited about the admin UI, the ease of use, the plugin system, the tagging / taxonomy system and the other wonderful features. Well Blogger had some of these, but this new toy expresses them differently and effectively. why change a winning team you may ask, well if you are one of those who cannot be comfortable with routine, then you'll understand. Cheers

Javascript UUID

UUID (Universally Unique Identifier) is standard (part of ISO/IEC 11578:1996) to create “universally unique” identifiers to identify objects within a system or across system boundaries. The identifiers are 128-bit in length (that’s 16 bytes) and while there really is no way to guarantee global uniqueness the probability of colissions are very small both thanks to the number of bits and the way the identifiers are created.

The number of theoretically possible UUIDs is 216 × 8 = 2128 = 25616 or about 3.4 × 1038. This means that 1 trillion UUIDs would have to be created every nanosecond for slightly more than 10 billion years to exhaust the number of UUIDs.

In its canonical form, a UUID consists of 32 hexadecimal digits, displayed in 5 groups separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters(32 digits and 4 '-'). For example:

550e8400-e29b-41d4-a716-446655440000

The UUID generation algorithms are specified in RFC4122 and several implementations exists for version 1 which is time based UUID, version 4 which is truly psuedo random UUID and version 3 and 5 which are named based UUID, using either MD5 (version 3) or SHA-1 (version 5).

In case you are interested in generating such UUID's, but in the client with javascript, Math.uuid.js is the solution, it supports RFC 4122-compliant UUIDs (or GUIDS)as well as non-standard random IDs of arbitrary length and radix. For examples of the types of IDs it can generate, or to see performance data, check out the Math.uuid.js Test page.

The practice is probably a little different. The uniqueness depends on how random the numbers generated by Math.random() are. Generating truly random numbers is a notoriously tricky problem, solved in different (imperfect) ways across browser platforms and OSes. It’s difficult to say for sure what the real-world uniqueness of these numbers ends up being, but I suspect it’s more than sufficient for most purposes. Regardless, this is a weakness that all javascript UUID generators will be subject to, unless they rely on an externally-provided unique value. For example, one could use AJAX to fetch UUIDs generated by a site like http://www.uuidgenerator.com/, but that has it’s own set of issues.

Rock'n The Web With Libraries

If you're a developer and you've not been hiding in a rabbit hole for the past 3 years then you'd be familiar with the buzz words of our today : ajax, social, user experience etc, these are all powered by Web 2.0, another loose term used to describe the "new wave" in web development, a paradigm long overdue.

The web has witnessed tremendous growth, from the gory days of the browser wars to the several W3C standards c'tees often dashing our hopes with standards that were either not adopted or poorly implemented by vendors, through to the proliferation of glorified hacks by developers or their numerous communities, all attempts to fix the web and make it a more robust platform. All these good-bad-and-ugly has led us to where we are today, and I can say (with hind sight) that happy days are here again.

Today, we develop with superb IDE's and powerful frameworks / libraries that have abstractions that normalize browser differences and put in our hands the requisite tools to build today's mission critical apps. We really don't have to debate over the significance of a library, especially since we must deliver critical functionality packaged with unobtrusive but intuitive and responsive UI. This is made even daunting by the fact that user experience or expectation evolves, just as Eddie Murphy's Coming To America don't stand a chance with Dan Brown's Angels & Demons as best movie of the year (2009), so does HiFive (by several opinions) not stand a chance with the Google Docs or Facebook or our day. The reason is simple and short, these recent expressions of ingenuity have raised the bar and pushed user expectation on deliverables even deeper, forcing the art of creativity (including web development) to be more involved.

The issue now is making the case for the library of choice, and for Ajax today, this judgment call is difficult without a bias, trust me!

Ok, some of the factors to consider include : functionality (of course), stability, documentation, collaboration / support, ease of use / development and very importantly, extensibility. For me, the case is settled, it's JQuery for sites and site-like apps and ExtJS for true Web 2.0 webapps, especially those that have to look and behave like desktop apps.

Though I've not forgotten my first love, YUI especially for the new YUI 3.x ecosystem, but JQuery and ExtJS has me bound ball n' chain.

JQuery's tiny footprint, ease of development and superb pluggability is a bait you'd be willing to take, and by any standard, Ext's just blows you away with their gorgeous UI, look-and-feel, and widgets, and a very solid and carefully designed component architecture, on which tomorrows demanding apps can thrive.

When it's time to make your judgement call, do make an informed one. Cheers.

The Editor of Our Dreams

I've always wanted an editor / IDE that is both strong and simple to use, and can edit as many file types as possible. Some editors claim this functionality but we know this is far from the truth, e.g Adobe Dreamweaver can edit PHP and JavaScript files, but serious PHP development is better handled by a tool like Zend Studio and Aptana for Javascript.

However the I in IDE means integrated and I'd loved that to imply a composite editor, capable of handling almost any (mainstream) technology or development language. I think this is what the Eclipse platform provides, either in it's core or via it's numerous plugins.

Ok, how about a platform like that, but one that runs in a browser. The Bespin Project is making my heart leap, and those guys in Mozilla Labs are simply ingenious.

Introducing Bespin from Dion Almaer on Vimeo.

How about building extensions easily, extensions that install without requiring a restart of the systems nor the browser (the user no longer loses his work or active sessions). For that you'd look at the new plugin infrastructure called Jetpack still from mozilla labs.

Create Jetpack Features in Bespin from Dion Almaer on Vimeo.

Will be keeping an eye on this experimentation to see how it matures, shouldn't you?

Polluted Javascript Namespaces

I quite agree that a great deal of development time can be saved (or gained if you prefer) by using a javascript library for any substantial Web 2.0 project, but I must say that some of these libraries are not fostering (at least not as of this writing) collaboration amongst themselves by conflicting on the global namespace.

Because we are building mashups and social apps today we will always have need to use two or more libraries at the same time in a project to achieve our feats. I once had a project built on JQuery and used a particular Mootools plugin throughout, and then came a page where I needed to use a Prototype plugin and I got disaster. JQuery, Mootools, and Prototype all use the $ smybol to denote their global namespace. They naver envisaged a very likely scenario as this ??.

Ok, JQuery has been proactive with JQuery.noConflict(), what about MooTools and Prototype, I think it's high time we got a solution to this.

Developing From Space

Software development requires more than coding especially in today's highly interconnected environments. We have run into the need to build larger systems often requiring that we use third party tools API's and intelligence. Up until now, I've been sharing my works from 'free' hosting services which have always hunted me, but what more could I do.

Just then, I discovered Google Code, an ingenuity in itself, now I have my projects in trusted hands (to a large extent of course), with rich tools like SVN, Wiki, Issues Tracker, Project Analytics, to name a few.

I must admit, I had to learn certain things to be able to utilize it - I had to read through some Software Licensing schemes to be comfortable with choosing a license for my Google Code projects. Also had to learn how to use a SVN client to access the repository, the Wiki tag was another one. Now I am better for it.

Thanks to google for fostering creativity ... , I just hosted my first project here