Main Contents
July 29, 2008
I’m slowly gaining ground in the war against paper. I’m a packrat, which immediately calls into question the structural integrity of my house and garage. However, I’ve discovered that technology transcends the limitations of corporeal space. I can still hoard precious tidbits for posterity in digital form without risking premature burial under collapsing stacks of old bills. I scan the pages that I just know I will need to review again in a few years and store them on a network-attached hard disk.
Welcome to the new me: I’m a digital packrat.
I hear your smirks and chuckles, but to those who understand packratting, the digital difference cannot be understated. How often do you get to say “Hey, I didn’t know we had carpet in here!”
Digitization is helping to reduce the paper pileup, but it still takes time to do the scanning. Not that storage is really an issue, but pixels that look like text take up a lot more space than actual text.
Why not use paperless billing? Most of the major credit card vendors now offer some sort of online alternative to sending trees through the mail. Most of them even offer the documents in PDF format.
What I don’t like about paperless billing is that it requires that you log into each individual bank’s web site to retrieve your bill. It takes time and effort to go get that bill each month, from a different location and menu tree for each bank. Letting the paper bill come to me and scanning it when I get around to it seems like much less of my energy than running all over creation to pluck one apple from every orchard.
Email delivery might work, but then again I’m a techie who isn’t afraid of a “Save Attachment as…” dialog. I don’t know of many banks that offer to send bills electronically by email.
What would be really nice is if the monthly statements for all my recurring bills could be deposited into a storage location of my choice, online or on my local machine or network. I’d set up a different “drop zone” for each vendor and map that to a location on my hard disk (my home network hard disk, actually). The vendor could write documents into the drop zone I created for them, but nothing more. They can’t read, delete, or modify anything else, and they don’t have direct access to my local hard disk. The list of drop zones is only visible to me. I wouldn’t have to do anything to receive my monthly statements, store them in location(s) convenient to me, and ensure data safety through redundant storage. Packrat heaven!
Microsoft’s Live Mesh already implements nearly everything required for this scenario to work. You can define a folder in Live Mesh that is accessible only to certain Live Mesh users, and Live Mesh will take care of replicating that folder to local storage on devices you indicate. So, conceptually, I could create a different Live Mesh folder for each vendor, configure the Live Mesh folder to replicate to a local directory on my home network, and invite the vendors write the monthly statements into their respective folders. My home network could even be offline at the time a vendor writes a new statement to a Mesh folder - the mesh will sync up as soon as my network is online again and deliver the new documents that are missing from the local copy.
The missing piece is write-only access to a Mesh folder. The current public beta of Live Mesh does not appear to support granting someone write only access to a Live Mesh shared object, such as a folder. If that can be taken care of, then the only remaining piece to solve is to convince my banks and vendors to update their billing systems to deliver monthly statements into my Live Mesh drop zones. Compared to getting new features into a Microsoft product, that should be a piece of cake. ;>
Digital packrats of the world, unite!
Tags: digital packrat, Live Mesh, Microsoft, paperless billing, personal archiving, wishlists
Filed under: Work |
Comments (5)
July 28, 2008
In the fall of 2006 I was wrestling with VS debugging JavaScript in IE and Venkman in Firefox teasing out problems and holes in the cross-domain channel library we were building for Windows Live and the Windows Live Contacts Control.
One of the most aggrevating aspects of debugging cross-domain JavaScript is that JavaScript debuggers do not provide the same degree of omniscience we have come to expect from full-featured desktop application debuggers. The reason is that the debugger operates inside the browser, rather than above the browser. To evaluate an expression, the debugger has to ask the browser’s JavaScript engine for the element values, or to evaluate the expression itself. Since the debugger is relying on the browser for evaluation, and the browser has access firewalls all over the place to implement same-domain policy restrictions, the debugger can’t see anything more than what the JavaScript itself can see. A debugger attached to the execution context of a top level HTML page can’t see inside the iframes sitting on that page if the iframes are showing pages from a different domain.
This is fixable, but I doubt that it will ever be fixed. I suspect it would be a major restructuring of the browser code to allow a debugger to circumvent the browser’s security restrictions and see JavaScript state from all domain contexts concurrently. Even just a casual mention of this idea to Mozilla or Microsoft browser teams draws up such fear in their eyes that you change the subject to avoid someone going postal. I can’t really blame them - both browser code bases are huge and hairy, and infamous for inflicting great gouts of pain on well-meaning tinkerers who venture too far into the forest.
Besides, it’s fair to say that the browser teams’ first priority is data security and safety. Omniscient debugger support is understandably lower on their priority list.
At any rate, while I was poking and prodding my cross-domain experiments trying to get a mental picture of how code reality was diverging from the whiteboard spec, I would occasionally notice an odd artifact out of the corner of my evaluator. Well, this is JavaScript - odd side effects are the norm. On one of these sorties I noticed that the window.name property was preserved across reloads of an iframe.
Now that’s odd.
My tinkering took off on a wild tangent. Passing a lot of data in one string and round-trip would certainly be faster than doing it in multiple smaller round trips required by fragment identifier messaging (FIM). However, the more I dug into it the more I found that needed to be chased down. Frustrated and out of time, I pushed a note onto the “investigate this further” queue and forced myself back onto the plan of record.
Fast forward to 2008. Kris Zyp has implemented a cross-domain transport for the Dojo JavaScript library using window.name. Kudos to Zyp for doing the legwork to turn the window.name oddity into a usable data transport pipe and shore up the holes and security vulnerabilities of the raw technique.
I read his post (discovered via Ajaxian) with skepticism, armed with an array of ”Yeah, but what about…” challenges and security issues I vaguely recall running into in my late night tangent. Zyp knocked them all down one by one in his detailed writeup.
Well done!
Tags: cross-domain, Dojo, JavaScript, window.name, XDR
Filed under: Web |
Comments (1)
July 25, 2008
Eric Meyer has put together a proposal for HTML 5 to enable an HTML document to associate URL links with just about every visual HTML element type. This would make it much easier to make a blockquote link to the source of the quote, and would enable things that are currently impossible in HTML such as making an entire row of a table into a link.
The proposal outlines several possible avenues for extending HTML syntax and considers their repercussions for functionality and backwards compatibility. Most of the extension choices can be supported in older browsers using JavaScript to backfill support for the HTML attributes the browser doesn’t understand.
I like the idea of allowing any element, even large blocks, to have an optional link associated with it. This improves the scope of reference to more naturally reflect the semantic structure of the referring document. If you quote a whole paragraph from somewhere else, doesn’t it make more sense that the entire quote be a live link to the original source? The current HTML link patterns force you to inject awkward transition text into the article just so you can have something to hang a link off of. I find such callouts disruptive to the flow of narrative text. Callouts often give the reference too much visibility relative to the content around them - another distraction.
Decreasing the need for artificial link phrases could be a benefit and burden for search engines. Search engines typically place a lot of weight on what words are used in the reference to associate some keyword digest of what the referenced page is about. This is a key technique for finding images with text search queries. How does a search engine deduce that “DSC10034.jpg” is an image of a horse? By noting that three different pages link to it, and the text of the links contains the word “horse”.
A block quote or table row that references another document would likely overload the simple referring text search engine technique with too much data, so the link would not be as strong of a keyword signal as two or three word phrase calculated by a human semantic engine. On the other hand, human digests are notoriously bad. Mislabeling is extremely common on the web, either by ignorance, apathy, or malicious intent. (Somebody actually tagged my photo of an Adelie penguin as a “parrot”! Gah!)
Eric has a demo page showing how one of the HTML extension options might look like, and how JavaScript can backfill for browsers that don’t understand the extensions.
Keep in mind while tinkering with the demo that the proposal is about extending what information can be represented in HTML syntax - the proposal is not about how an HTML renderer would present that information on the screen. I absolutely not want entire blocks or table rows drawn with the traditional underscored text of a hyperlink.
Certainly, a page that uses links for blockquotes or table rows could define its own CSS style elements to make the linked element less obnoxious to the eye. I would hope for more subtle visual cues that let the reader know that the linked element has more information, more depth of content, available for drilldown without disrupting the flow of the eye across the page. I would also hope that browsers that support these HTML link extensions will consider these distinctions between a “hard” a link and a more subtle content drill-down link when setting their default rendering styles.
Discovered via Ajaxian
Tags: HTML, syntax, Web
Filed under: Web |
Comments (1)
July 23, 2008
Stoyan Stefanov writes about Non-Blocking JavaScript Downloads on the Yahoo User Interface Blog. Good content all around, but I’d like to add a note on an item he somewhat casually skimmed over.
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.
Tags: JavaScript, Programming, yahoo
Filed under: Programming, Web |
Comments (6)
July 21, 2008
Lukas Biewald lays bare his frustrations with Amazon’s S3 service, particularly after the recent S3 service outtage that left his FaceStat business offline for more than 7 hours recently. Actually, Lukas has double posted on this issue - he has a much more scathing criticism of S3 over on his own blog: “Amazon S3 Screws Us Over“.
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.
Tags: Amazon S3, Google, online hosting, service level agreements
Filed under: Web |
Comments (0)
July 17, 2008
Wordpress.org has announced a new 2.6 version of the WordPress online blogging and content management system.
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
Tags: Google Gears, Subversion, wordpress
Filed under: Web |
Comments (0)
July 15, 2008
I found a happy little email in my inbox this morning. It was a note from Handango informing me that my application to become a Handango Developer partner has been approved. Woohoo!
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.
Tags: .NET, Borland, Delphi, Handango, Programming, smartphone
Filed under: Programming |
Comments (1)
July 14, 2008
Radiohead has released a video for its “House of Cards” song that has the peculiar distinction of being a live-action video filmed without cameras. According to the Google Blog post ”No Camera, No Lights, Just Data“, the imagery was created using 3D scanning lasers and detectors.
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.
Tags: 3D digitalization, data visualization, Google, music video, Radiohead
Filed under: Misc |
Comments (0)
July 9, 2008
John and Bronwen of SoulSolutions have completed an RSS upgrade for the Australian government Prints And Printmaking web site, which gives free public access to something like 18,000 images of artwork in the National Gallery of Australia. With all those images indexed in RSS, you can now browse those works of art in PicLens halfway around the world.
Great work, John and Bronwen!
Tags: art, Australia, mediaRSS, PicLens
Filed under: Web |
Comments (0)
July 4, 2008
WordPress.com, the commercial blog hosting company that uses blog software from WordPress.org, is adding Google Gears support to their hosted blog service. Initially, this will only speed up use of the blog administration pages by caching the scripts and images locally.
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.
Tags: blogging, Google, Google Gears, offline web apps, wordpress
Filed under: Web |
Comments (1)