Anyone like a Google+ Invite let me know in comments – I’ll give out as many as I can.

Update: I’ve just realized that for current gmail users, the “Find and Invite” tab under  Google+ circles practically gives you an instant social graph within Plus, without the need to import contacts and invite them etc.

Gmail unfortunately gives you no easy way to merge these records, and that got me thinking about the best way to handle something like this from a UI point of view, not necessarily just for Gmail (which of course I can’t change!) but for any system in general.

The concept that I’ve now come up with is a UI that lets you drag one record (e.g. a contact, a user account, etc.) from a list over on top of another record that you want to merge it with. Once you drop that record on top of the other, a modal box comes up asking you which record should be the master for the merge. Following your choice, the system then prompts you in turn for each field of data for those 2 records that will result in a conflict (or data loss, depending on how you look at it) giving you the choice to accept the master record’s data for that field, or to use the non-master’s instead. For fields where only 1 record has data and not the other, no choice need be made.

When all conflicts have been resolved, the system shows you a preview of what the final merge record would look like, which you can confirm or go back and edit any of the merge choices made earlier.

Sounds good, yes? Now we just need to build it!

1. Jquery Datepicker

Not strictly speaking a plugin, Datepicker comes out of the box as part of the Jquery UI add-on library, and is a tried and true rich UI date picking widget, with lots of config options. If you need something that “just works” quickly and gets the basic (date picking) job done fast, look no further than this one.

It looks like this:

As with all other Jquery UI widgets, it can be thoroughly styled to meet your look and feel needs.

Now a common use case in web forms with date fields is to also feature time entry fields. Although Datepicker does not come with time picking options out of the box, this isn’t a big issue as my next favorite plugin handles that quite neatly…

2. Timepicker Plugin for Jquery UI Datepicker

The Timepicker Plugin for Datepicker does pretty much what you would expect – it extends the basic Datepicker interface to include a nifty set of sliders to specify the time, like so:

The latest version of Timepicker is highly configurable and includes an option to use it as a standalone time-picking widget, without the date picking portion at all. However, some might not like the slider interface, and so enter another one of my favorites…

3. ClockPick

Clockpick uses an interesting cascading menu style interface which I find intuitive to use and easy to manipulate.

While I like Clockpick a lot and am currently using it on one project that I am working on, the look of the interface is admittedly not quite as stylin’ as Jquery Datepicker. So for a time picker widget with the cool looks of Datepicker but with the ease of use factor of the cascading menu style interface, we have…

4. jquery.Timepickr

This one has a REAL slick interface, and as an added bonus (which you can see from the screenshot below), it’s a snap to use any of the standard Jquery UI themes of your choice – making for a smooth integration on a form where you are already using Jquery Datepicker.

These are by no means the only date / time pickers out there for Jquery, but in my experience using and integrating these, I have found them to be among the best in class.

This is quite simple to implement server side with a function such as this that takes a date and returns a nicely worded string in the form of “X mins/hours/days/weeks/months ago”. However for this project we needed to do heavy page caching, rendering the page in PHP first and then caching the full HTML for 30 minutes, long enough that the time ago format would quickly show outdated numbers.

To the rescue……a very nice Jquery plugin called appropriately enough, timeago. Since time ago is calculated and rendered client side with this plugin, you can cache pages as long as you want and yet still have accurate time ago numbers displayed. As a bonus, the numbers even auto-update as time passes without the need for a page refresh, making them even more accurate than a pure server side solution.

And to cover all bases, you can still do a server side time ago calculation, output that string, and then let the timeago Jquery plugin update that number in real time client side.

To make matters worse, during a large part of this outage, Intermedia’s own website was unavailable, so affected customers could not even go onto the Intermedia website to check for status updates or open support tickets. Needless to say, their PBX was being bombarded by thousands of irate customers as well, so getting someone on the line for an update wasn’t that easy either. Twitter ended up being the best source of updates, first from other customers who tweeted what info they could glean, and then later from Intermedia’s own Twitter account when they managed to get more caught up and started giving out some official updates.

Today I received their formal RFO (Reasons for Outage) letter via email which goes into great details describing why this outage occurred and what steps they are taking to try to prevent a re-occurrence for the same reasons in future. In a nutshell, there was a hardware failure in one of their EMC SAN devices, and this failure occurred in such a way that prevented the device’s own in-built fault tolerance mechanisms from allowing the SAN to effectively remain “up” – that is, they are saying this is one of those failures that should not have happened. These devices are designed precisely NOT to fail under such circumstances, but nonetheless it did fail.

Intermedia’s letter goes on to describe the actions they are taking along with the hardware vendor to guard against this in future. All very good and well. Now on to the little gem in the letter that I found the most surprising, and from which all technologists with “uptime” responsibility for Software as a Service (SAS) systems would do well to learn from.

Here’s the bit that really caught my attention:

“During the event, our ability to communicate status effectively was hindered by an outage of our corporate communication tools until 9:50 a.m. PST. The databases for www.Intermedia.net, Intermedia’s client control panel and Intermedia’s trouble ticket system were located on the affected SAN and therefore were not available during the SAN event. These systems were restored as soon as the SAN performance issue was resolved. All available personnel were directed to answer incoming customer calls. Intermedia logged over 2,000 incoming calls to our PBX and effectively answered more than 1,000 of those calls.”

In hindsight it seems pretty obvious doesn’t it? Why locate your “corporate communications tools” and “trouble ticket system” on the same infrastructure as the core service that you provide? In this case, it might have been the thinking that the EMC SAN just couldn’t possibly fail as it was inherently designed to be fault tolerant, and indeed, EMC SANs are extremely heavy duty devices with very good track records for what they do. Yet fail it did and with it, came down key parts of the foundation, all in one go. Or maybe it was to save on costs. Or maybe it was just a careless oversight. We don’t really know why, but we do know it was implemented that way and that it was clearly a flawed design decision.

Naturally, Intermedia themselves now intend to fix this:

“As a high priority for completion, no later than Q2, Intermedia will also be isolating corporate communication infrastructure from the same infrastructure that provides our Exchange services, guaranteeing that we will be able to communicate effectively with clients at all times during a service interruption. “

Again, this revision might seem like the obvious system and network design that should have been implemented from the get-go, especially for a SAS provider as long in the business and as large as Intermedia. But yet it was not done as such, and it took an outage on this scale to force a change that now seems so obvious in hindsight. Certainly a lesson we can all learn from.

Now one would expect that since you are paying the same amount of money to Amazon for each server instance created of this same type and size, that you should be getting the same performance out of each one. Sadly, that is a very wrong assumption, as our sys admin found out.

It turns out that the underlying hardware for each instance created impacts the actual performance that each instance gives you, even though the instances are all virtualized and marketed by Amazon as if they are all created equal. In our case, we found that the different underlying hardware that the virtual instance sits on has a significant impact on application performance, at least with respect to MySQL database performance. Instances that were created on machines with AMD’s Opteron 270 processors (2ghz 1mb L2 cache) showed significantly poorer MySQL performance compared to instances created on machines with Intel’s Xeon e5430 processors (2.66ghz 6mb L2 cache). Well, the hardware techies among you out there might be saying “well duh… of course the Xeon will spank with the Opteron, tell me something I don’t already know.” But that’s not the point.

The point is in both cases, the EC2 customer is paying the same for an instance that is marketed as having identical compute units (i.e. processing power), but the reality is very different. Bear in mind that one cannot select what underlying hardware you want your instances to be powered up on – what we did was simply keep destroying and creating new instances until we found that the new instance was created on the Xeon-based hardware that we wanted (TIP: from the Linux shell of the new instance, run this to see what hardware your instance was created on: cat /proc/cpuinfo).

Moral: while cloud computing with Amazon (or likely any other vendor of this ilk) has definite pluses, there are hidden gotchas that they don’t tell you about.

My favorite “oops, I wish I never said that” quote is Michael Dell’s “shut it down and give the money back to shareholders” advice to Apple. Of course, this was circa 1997 when Apple was in quite dire straits. But still…

On to the solution: A modified version of memcached found here:

http://code.jellycan.com/memcached/

I’m not sure why this works, but the important thing is it does!