In the “Dependencies” section of the article, Stefanov describes using the onLoad or onReadyStateChange events of the dynamically generated script tag to receive notification when that script has been loaded by the browser.  Once you know it’s loaded, then you know it’s safe to begin using the code it contains.

This works great for Firefox and IE, but fails completely in the Safari browser.  Safari doesn’t implement onLoad notifications for script tags.  This forces you to abandon the onLoad technique and instead use the technique of embedding something at the end of each script file to signal when the file has been loaded. 

The script libraries for the Windows Live sites use this technique - every source file contains a function call at the bottom that tells a central notifier that it has been loaded.  Other code can ask the notifier to signal them when a file or set of files have been loaded.  This works in all browsers without relying on diverging browser idiosyncracies. 

Unfortunately, this also requires that all the JavaScript you want to load dynamically (using this technique) knows about your particular load notification pattern.  If you want to dynamically load JavaScript from multiple libraries or authors, you will either end up with multiple notification systems (which should coexist peacefully) or you’ll have to modify those files to use your load notifier.  This is bad from a design standpoint because it requires that all your code modules have carnal knowledge of your application - erodes the modularity of the source files - or require that all your code modules follow the design patterns of a particular JavaScript toolkit, like DoJo or Prototype or YUI.  The latter isn’t a terrible tradeoff except that it limits your options.

 Discovered via a note by Steve Trefethen on FriendFeed.

Lukas says he’s had it with S3’s reliability problems and is looking for a replacement, but isn’t all that impressed with the available alternatives in the scalable online hosting space.  Google’s App Engine has earned similar criticism after a June 17 service outtage, reported on TechCrunch in “Google App Engine Goes Down and Stays Down“.  So, Lukas indicates he’ll have to go back to the old solution of building dedicated servers, and shouldering all the associated costs and risks that massive online hosting data centers were supposed to do away with.

It sounds like the market is ripe for someone - anyone - who can deliver scalable services with ironclad uptimes and service guarantees that pay out true value of business lost when the service goes belly up.  It’s not about the cost of the service itself - it’s about the value of your business lost when the service goes down, which is almost always significantly higher than the cost of the service.

The first comment on Lukas’s Delores Labs blog post suggests that if a business can’t survive a 7 hour outtage, then something must be wrong with the products or the business itself.

Service outtages do more damage than just lost sales. They damage your site’s reputation, which is much harder to repair than lost sales. Web consumers are very flighty and very finicky and generally follow patterns of addiction with their favorite web sites.  That is, when they can’t get to their favorite sites, they get cranky.  When they can’t get to their favorite sites for hours at a time, they find a new favorite and probably never return.  Worse, they will shift from being advocates for your web site to vocal critics, and thus indirectly channel traffic away from your site via the social network influencer effect.

Few online services today do not have a close competitor, and the barrier to switching is usually little more than inconvenience and emotion.  The best way to retain your current customers is to not give them a reason to go looking at alternatives. Consumers are couch potatoes - as long as they’re satisfied enough with what they have, they aren’t likely to pay attention to alternatives - even when they have criticisms of the product, and even when the alternatives are superior.  Same as TV:  If you like the current program, you’re less likely to switch channels.  (Works great until the most disruptive element in commercial television - the commercial break) 

I think part of the problem, part of what is missing from hosting providers such as Amazon’s S3 and Google App Engine are service agreements that provide meaningful consequences in the event of service failure.  Google offers no service guarantees - it’s up when it’s up, and we’ll get around to fixing it when it breaks when we can.  The Google engineers definitely have their hearts and souls in fixing things ASAP, but Google the corporation protects the koffers and offers no promises.  Lukas indicates that Amazon S3 offers a 25% refund in the form of future service credits in the event of outtages.  25% might take a bite out of Amazon’s profit margin, but it doesn’t come anywhere close to the kind of horriffic damages provided by “utility grade” service agreements. 

Hosting services don’t yet conduct themselves as true utility grade operations.  Compare the service level agreements of any online service with those of, say, an electrical power company.  If you’re a multimegawatt industrial power customer, chances are good that you can demand service level agreements that are downright terrifying to the service provider. From friends and colleagues I hear stories of manufacturing plants in Silicon Valley that crank out a million dollars worth of product per hour, every hour, 24 hours a day, 360 days a year (allowing for only 5 days of systemwide downtime). When the power fails, the service agreement has the power company make up for the plant’s losses - the power company is held responsible for that million dollars per hour, until they fix the problem and restore power service.

Now that’s what I call an incentive.  Invest in redundant systems, continuous monitoring, and rapid response teams, or your power company will go broke within minutes of the first outtage.

Hosting provider service level agreements won’t leap to the extreme of 2x loss of business damages, but as new players enter the hosting market, they will have to do something to differentiate themselves from other hosting services.  There’s not a lot of room for differentiation in the hardware or the service itself, so the new guys will have to distinguish themselves on cost and service guarantees.  A new hosting provider will make deeper concessions to the consumer in service agreements than the old guard offered.  Google and Amazon don’t need to offer significant service level guarantees primarily because nobody else is forcing their hand by offering better.  Over time, competitive pressures will force an improvement in service level agreements for online hosting services as the hosting market becomes deeply commoditized.

All we need now are more competitors.

Major features in this release include revision history, comparison, and rollback of edits made to articles, a “Press this” link to automate blogging about other web pages, theme previews to see how a theme would look on your content before committing to it, support for using Google Gears to cache WP administration scripts locally, and many smaller improvements such as built-in support for placing captions on photos included in blog posts, better WYSIWYG image control in the editor, SSL support for WP administration, and quite a bit more.

As mentioned earlier, WP’s initial use of Google Gears only accelerates loading of WP administration pages (manage the blog, edit posts, etc) by caching the WP scripts on the local machine.  While this may seem like a minor improvement (except to those with slow Internet connections), this is an important first step towards being able to create and edit blog posts in WP while offline.

Of these new features, the image caption and improved image control in the editor are probably the items that I would use and appreciate the most. I don’t see a burning need to roll back to previous edits on an article or preview new themes (I have my theme, now leave it alone).  I might take the Gears support for a spin, but I doubt it will make any noticable improvement to my WP administration experience on my multimegabit Internet connection.

As much as I’d love to play with these new features (and WP 2.5 as well), the biggest obstacle for me (and many others) is the update install process.  The WP update instructions do a great job of whittling it down to a “Three Step Upgrade“, but one of those three steps (33% of the process) is potentially delicate and/or scary.  If you don’t dedicate your full attention to what you’re doing, you risk wiping out your blog content or your blog custom settings completely.  This is a not a one-button install.

WP update step #1 starts with the instruction “Copy the new WP files to your server, overwriting old files in the root” but then follows with a list of very important exceptions of things not to overwrite.  That doesn’t instill confidence.  You have to read all the instructions and apply the subsequent exceptions and filters in reverse order.

I’ve updated WP on my server before.  It went smoothly, and the actual update step did only take about 5 minutes, but it required more than an hour of my attention in nervous preparation and validation.

I would love to switch over to using Subversion to update my WP installation directly from the WP servers.  This would be the closest thing to a one-button install of WP.  I have much greater confidence that Subversion would preserve my local changes when applying updates, or at least notify me when there are conflicts I need to sort out, than I have in doing the same work myself by hand.  However, installing Subversion on the server requires root access, and my web host does not have Subversion in their suite of installed software.

So updating to the latest WordPress release falls back to the “some rainy day” list of chores.  (And we’re unlikely to see a rainy day here in Santa Cruz until at least November!)

via Weblog Tools Collection

Ya, you know, that application I submitted more than THREE YEARS AGO when I was at Borland experimenting with writing .NET CF apps for my smartphone with Delphi. At first I thought this confirmation email was evidence that somebody was trying to create a fake Handango account (but why would they use my real email address?), but upon closer examination of the account contact info, it’s all mine.  My previous home address (I moved three years ago), previous phone number, previous employer, the whole previous nine yards.  I immediately changed my previous password, just in case.

Thanks for letting me in, Handango! Look for a new smartphone app from me in, say, 2011.

The video, hosted online by Google, is visually interesting, but the novelty is quickly worn down by the poor continuity and distracting skips and flicker in the digital data.  As the imagery seems to have nothing to do with the lyrics, it feels to me like a case of tech-neato trumping content.  Your brain is so focused on trying to make sense of the visuals (with a flicker-induced migraine) that the music hardly even registers.  Was that the band’s objective?  Hide a dreamy but otherwise mediocre tune beneath artsy, scruffy digital pointilism? 

It’s true the video shows state of the art 3D digitalization.  It also shows how far 3D digitalization has yet to go, and how much of a chore data cleanup is.  If the flickers and jitters in the video are an artifact of the digitizer, shame on the data sampling team for not cleaning it up a bit.  If the jitters were added deliberately in post editing, shame on whoever thought that was a good idea.

Great work, John and Bronwen!

This isn’t really the best use of Gears, since the browser will cache content as it’ is accessed, but it’s a reasonable first step.  Clearly the longer term goal (in the upcoming WordPress 2.6 release?) is to support blog post editing and administration while offline.  I imagine this prequel to full offline mode benefits WordPress.com (by reducing server traffic) more than end users. 

Some of the comments on the WP.com blog post indicate little or no noticable performance boost for the end user.  If you have a fast Internet connection, that’s probably going to be the case. It sounds like what WP.com is using Gears for (for now) is to prefetch the admin scripts, pages, and images to the local cache. WP.com bloggers who would see the greatest performance improvement would be those on a slow or crowded Internet connection.

I was surprised to see on other blog posts on this news comments expressing fear of “sending all their data to Google” and the like.  That’s not what Gears does. Gears is a browser plugin to enable a web site (wp.com) to store data on the client.  None of your WP.com data should ever be sent to Google, period. I don’t think WP.com even has to have a reference to Google to get the Gears JavaScript - the Gears JS code can be completely hosted on the WP.com server.

Some will raise the concern “What if Google embeds a trojan horse in the Gears code?”  Well, it’s open sourced so somebody will see it if there is such a thing, so this shouldn’t be a real concern.

There is no issue of Google getting access to WP.com blog data as a result of using Gears.

The three headliners for this 1.7 release are a new “discovery” mode for finding cool content you didn’t know about, an Amazon search feature, where you can search and browse photos of Amazon products, and a “return to PicLens” button that takes you from the browser back to what you were last looking at in PicLens.

Discovery mode is a feed aggregator - it pulls together content from all over the web into categories like news, sports, entertainment, and so forth. For those of you who love PicLens but were having trouble finding stuff to look at, Discovery is for you. ;>

The Amazon search & browse is pretty much what it sounds like.  You can enter a search term and see results returned from the Amazon store.  Click on an item and you go directly to the Amazon product page where you can purchase it or see reviewer’s comments, etc.  (I wonder who gets the affiliate fee for sending you to Amazon?  Hmmm…)

 Return to Piclens is my baby - the last Piclens feature I worked on at Cooliris.  When you click on the attribution link of an item in PicLens (the little blue globe in the caption bar of the selected item), PicLens opens the original web page containing that item in the web browser, and PicLens closes its full-screen display. 

When your curiousity about that item has been sated, how do you go back to what you were looking at in PicLens?  Prior to the 1.7 release, you had to fire up a new PicLens session, reconstruct the search query you used last, and then scroll back to where you were before you hopped out to the browser.

Now in Piclens 1.7, when you click on an attribution link to view a page in the browser, PicLens displays a translucent “Return to Piclens” button in the bottom right corner of the screen.  When you’re ready to go back to PicLens, just click that button and the PicLens full screen display returns, showing exactly where you left off.  You can even navigate around in the browser (click on links, view different pages) before returning to PicLens.

I think Return to Piclens is only implemented in the Windows versions of the PicLens plugins (IE and Firefox) - for the moment.  The Mac guys were busy with another project while I was working on this, but they’ll get this return button implemented on the Mac side of the house soon I’m sure. 

There’s also a navigation helper in PicLens itself that appears at the top of the display when you start a new PicLens session instead of using the Return to Piclens button.  This is another handy way to go back to the site or search query you were last looking at in PicLens.

Congrats to the PicLens team!  Can’t wait to see the next round of stuff.  :>

Colt was an external contractor to Google handling HR functions such as benefits, 401k plans, etc.  Google itself was not burglarized.

The letter from Google also offers to cover the cost of a one year subscription to a credit report and identity theft monitoring service.  Well, that’s something at least.  I appreciate Google’s gesture.

Both are right, and both are wrong.

First off, I have to agree with Dion that Dare’s use of “exodus” is a bit excessive. A dozen or two Googlers joining Microsoft would be an exodus when Google was a few hundred employees, but a dozen out of 20,000? Perhaps noteworthy on a case by case basis, but not an exodus.

However, Dare does make some good points that Dion sidesteps by omission. Google’s interview and hiring process are infamous, both from those who didn’t make the cut and from those who did. Dare cites Sergey Solyanik as an example of a dispassionate Googler taking up the Microsoft yoke and Svetlin Nakov’s close encounter with the b0rg. Both mention the oddities of the Google hiring system.

From my personal experience, I’d say that Google’s hiring system is highly optimized for acquiring fresh college grads straight out of school - bright, idealistic, inexperienced, don’t know what they want to do with their lives, few or no time demands in their home life, and would be thrilled to do anything at a place as cool as the big G. The Google interview style - evaluating the person as a whole on intelligence and creativity, with no particular interest in experience and no particular job title in mind - reflects that.

A Google offer letter looks more like a college acceptance letter than a job offer: “Congratulations! You’ve been accepted. Your base pay is X. Please show up to orientation on Monday to receive your work assignment.” In many cases, you literally don’t know what project you have been hired into until you step out of orientation. As you exit orientation, you step into a sea of managers holding up signs with names on them, just like limo drivers waiting outside airport customs.

For new college grads, I’m sure this is all terribly exciting (and vaguely familiar to college life), but for old farts like me that have opinions about the world and know what they don’t want to work/waste time on, it leaves a lot of room for nasty surprises. The job you get can have little or nothing to do with the people you interviewed with or the topics that were discussed. Why? Because the people doing the interviews are in no way related to the job that needs to be filled. Matching new hires to job openings is done by a small committee dealing out cards to projects in priority order. Your name gets put into that deck only after you accept the offer blindly.

These odd procedures make for a very efficient hiring machine.  It’s a great way to feed Google’s insatiable appetite for new hires, but it leaves those being hired feeling distinctly bovine.

On my first day at Google (Oct 31, 2005 - everyone was dressed up for Halloween), I met my manager after orientation and was informed what I had been assigned to work on. In the space of about 15 minutes, I decided that wasn’t worth the commute or the money and headed for the door. I give a lot of credit to my manager (Linus Upson) for being quick on his feet and catching me before I had a chance to slam the door. He asked if instead I might be interested in this other project that he had been trying to get off the ground. I was, and that became Google Gears.

If you’re a senior engineer looking for a senior engineering position in a particular topic at Google, don’t go through the front door.

Dare makes a few observations at the end of his post:

1. Startups don’t have career paths for employees.

Agreed. The draw of a startup is the chance to get rich when the company “makes it big” or gets bought by a bigger company desperately seeking innovation. But let’s face it - the days of employees becoming millionaires on company stock are long gone for Google, Microsoft, and Yahoo. I knew I was too late to the stock party when I joined Google in 2005.

2. There is no legacy code at a startup, so fast and loose rules the day.

Agreed. Startups often pride themselves on how many nights and weekends went into the latest release. They also often don’t know exactly what code went into that latest release.

2b. As organizations mature, they add PROCESS to protect against human failures and past pain points.

Agreed, but this is a double-edged sword. Some startups pride themselves on having no process at all, because if you have no process then you have clearly avoided the evils of bureaucracy that live under the process banner.

Microsoft’s greatest enemy is itself. As a company that has succeeded despite decades of litigation and human error, Microsoft has accumulated so much process that an entire employment category spontaneously evolved to deal with it: PM! Program Manager, Product Manager, or Process Manager? You decide.

I’m pretty sure I fall into the category of senior developers Dare mentions as having an appreciation of the value of process. I definitely value dedicated testing, repeatable testing, and comparing results over time. The last time I saw all of these was at Borland in the mid 90’s. I haven’t seen them since, in all my wanderings. Others have commented on Google’s lack of testing discipline. I’ll just add that Microsoft’s corporate commitment to process that Dare mentions is no guarantee of quality either. Processes created out of pain exist primarily to protect the corporation more than anything else.

3. There is less politics at a startup.

True, but not for Dare’s reasons of consensus. Microsoft is all about consensus. For startups, though, it’s not that startups can reach consensus more easily than a larger company because they’re smaller / have fewer people to bring to consensus, it’s that startups don’t have to bother with consensus at all. Startups can often trace their creative energy back to one or two key people, key decision makers who make decisions, be they right or wrong. In some companies these thought leaders are on the management side, in others they’re on the engineering side with support from management.

Gary Whizin, R&D manager of the Turbo Pascal / Delphi team during Borland’s heyday, made it clear and simple: “We value your input, we need your input, but let’s be clear: this is not a democracy.” Gary didn’t make the decisions, and he wasn’t overly concerned with building consensus, but he did have the uncanny ability to get decisions made by the people who needed to make them. Many times “all” Gary had to do was lay out options A, B, and C that the expert had discussed earlier and say “Ok, now pick one.” They’d squirm, they’d protest, but more often than not a course would be plotted by the time Gary left that meeting.

Microsoft isn’t ideal either

We can pick apart Google’s peculiar hiring process all day, but that doesn’t mean Microsoft’s process is beyond reproach. Many people in the Delphi community were surprised I went to Google and not Microsoft as many Borlanders before me had. Why did I choose Google over Microsoft in 2005? Because Google made an offer, while Microsoft continued to drag its feet.

Microsoft’s recruitment system is highly segregated - plenty of inside recruiters, but none of them talk to each other. A recruiter is responsible for filling the job openings of a particular team. If a particular candidate isn’t a perfect match for that team, the recruiter doesn’t seem to have much incentive to shop that candidate around to other teams, or to inform the candidate of other possibilities. In six months of off and on conversations with Microsoft in 2005, I often found myself informing Microsoft of what other groups within the company were looking for!

The main obstacle between me and Microsoft was that I had (and continue to have) no interest in moving to Redmond. Microsoft is extremely Redmond-centric. Google is even more MountainView-centric. Both place a lot of emphasis on face time - in meetings, meetings, and more meetings. It is extremely difficult to break into either of these companies as a remote employee. You have to find a team that is motivated to work with you even across the remote chasm and a manager who knows how to manage remote staff effectively. That requires time and perseverance. In other companies, the notion of having a remote team member is less exotic, even commonplace. Chad Hower runs his whole software team as a network of remote workers! A truly distributed system.

Microsoft is gradually warming up to the idea of remote workers.  This is partly driven by the perpetual office space crunch in Redmond and the terrible traffic congestion in the whole Redmond / Seattle area.  More of the corporate internal apps work over remote VPN connections now (compared to a year ago), and the VPN itself is a thousand times better (more reliable) now running on Vista than it was a year ago on XP.

Dare’s blog post will undoubtedly stir up a lot of responses, both from the Google-can-do-no-wrong fan club and from Google employees who still drink the corporate Kool-Aid. I do find movements of individuals between projects or companies interesting news to follow.  Changing jobs is never an easy step to take, and often justified with emotions and reasons laced with disappointment or disillusionment with the old company and perhaps overly optimistic hopes for the new company.  Rarely do such movements of individuals have a significant impact on a well-run company.