system.reflecti0n.net

I open Windows’ Live Writer, I type, I press “Publish” and I’m done.

For all those who dispute Microsoft’s ability to make something simple that works well—well, I wouldn’t need to argue with them. Just knowing Live Writer is out there tells me people who make these spurious statements have the wool pulled over their eyes or aren’t looking in the right direction.

Sure, there’s more to do in Writer than my description in the first paragraph but that’s just added value. You don’t need to use the extras if you don’t want to. This is a fundamental to good application design. No, it’s the highest principal of all, an axiom:

Extra features are nice, but they shouldn’t stand in the way of getting the job done.

Axioms are all well and good, but how do we make those that have influence on our apps understand this principal? Honestly I often go home feeling like I’ve spent the entire day talking to a brick wall. And those walls are impossible to get around. This frustrates me like only fellow developers can understand. Shabby applications are not all our fault. They are often the sum of many decisions and arguments: good, bad and unfortunate.

Tags: axioms, good design, simplicity, creativity

I used to have a problem when I booted into Windows Vista. Even waiting a few moments before I logged-in, my network connection wouldn’t be ready. No IP address was available, even if I set one manually the NIC just would not serve up anything network-related. Rebooting the NIC by disabling-enabling it from the Manage Network Connections would never fail.

It seems to me that the order my hardware is booting it probably at issue here. While the NIC is trying to go online, some resource required to initialize it is in use by something else. Sifting through Event Viewer did not turn up any clues either. But by the time I’m logged in that resource is free again, by the process that initializes the NIC has given up trying by that time.

So this got me to wondering why there couldn’t be a background process that’s surveying all your services and hardware to determine what’s running and what’s not running? You know:

1. RAID-array: check
2. Video-display: check
3. NIC: check
4. Database-server: check
5. Web-server: check
6. …ad nauseum…

…Then if one of those services was to fail, the background process that’s noting these problems would check to see if it had a history of failing, note its dependencies and determine a better order for booting. For example, a web-server booting before the NIC would be a problem in most cases, so the algorithm that determines the boot order would push that service down the ordered-list of services to boot up.

Furthermore, if this boot-up analysis saw things were all booting up fine, but detected some services could boot in parallel because they had mutually-exclusive dependencies then the ordered-boot up list could be optimized by reordering and re-synchronizing the boot order again.

This would be advantageous to a Windows or Linux based PC because the hardware and services of all the machines out there covers a very wide spectrum of configurations and duties. Today, boot order optimization is a manual task that is probably overlooked by all but the uber-geek administrator types. This automated approach is well within our grasp already and we only need to write an application that will do the dirty work for us.

Tags: optimization, windows, linux

You didn't have to be anywhere near a tech blog to hear Google's shot across the bow of Microsoft and Mozilla this week when they released Chrome version 0.2 (beta), Google's take on the web browser. You'd have to go back to the past two iPhone releases to match the the press coverage and buzz generated by the appearance of this browser. Honestly, I didn't think I was going to need to field any Google Chrome questions from non-techie relatives until at least Christmas but there I was answering my mother of all people about Google's new browser, the same week it was released. This thing got more than coverage, it got real press-- as in print like your local newspaper and evening news were covering this thing. Wow.

But Don't Believe It

...The hype, that is. Why? Well, this time around it's not a question of eliminating one browser or another. Netscape put an end to that tactic by releasing the Mozilla browser to the open source community ensuring it, and any other browser that gets overshadowed by Internet Explorer, a life beyond death. No this time we're not going to see the annihilation of any browsers.

So What IS IT, Then?

What we're watching is the first arms race in browsing technology. Google, Mozilla and Microsoft are going to start working exceptionally hard on features that ensure the mutual destruction of their competition. Each of these companies has invested time and energy in accelerating Javascript, improving CSS support through ACID2 compliance and NOT inventing new HTML standards. That is, each of these companies are working on improving their software in areas where failure means everyone fails. If we reach the limits of Javascript optimization in one browser, the others will catch up and get stuck in more or less the same place; after reaching 100% compliance in ACID2, no browser is going to be "more ACID2 compliant".

What About Us, The Users?

We win. With each company pushing the other to new heights in better operation, not better features, the technology of Javascript processing in general gets better, CSS compliance improves to the point where it's not an issue anymore. The user experience in any browser just gets more robust because intentional or not, the big 3 browsers are all working in step. No browser, Chrome, Firefox or IE8 is really lagging at any given time, the ones not in the lead are merely drafting in the leader's wake until it's their turn to push to the front. Good times!

Tags:

Are we co-workers, or what?

To all managers: doing your job isn't just deciding what needs to get done. Shit, that's the easy part. But when you sit on an idea for months and months, then start rushing people to wrap up their other projects to get on to your work, at least have the courtesy to have stuff prepared. Nothing major...

1. How about writing down your goals for starters? Not writing anything out convinces your co-workers you don't know what you're asking for.
2. When you leave it up to no one to do your job, then no-one is going to do your job. Before you delegate, you must articulate. We're not going to guess. This isn't a game.
3. Don't piss me off by acting all pissed off when I ask you to meet me halfway. As a manager, preparation is the most significant thing you do in your job.
4. When I do a good job it makes you look good. If you frustrate me at every turn, why would I care if you look good or not?

I could go on, but you'll never listen with your head that far up your ass.

Tags:

I am really getting to hate all the sites that matter-of-factly ask you for your login and password to your GMail/Hotmail/Yahoo account so you can "tell your friends" about the new website you joined. This was a dodgy proposition the first time I saw it nearly 2 years ago, and I still think its dodgy no matter how big and popular the site is, no matter how nicely they ask for it. My login and email provides unfettered access to my email and any of the associated services. It's simply STUPID to trust that to anybody. I image it's akin to leaving your PIN number at BestBuy so they can purchase something on your behalf when you're not around, just because their management thinks you's like it.

I'm not against the notion of sharing my whereabouts with people, but my passwords? Nope, no chance. That doesn't mean I can't share my list of like-minded friends with new and exiting websites I join. All that's needed is a more sensible and secure way to share information that leaves third-party access up to the discretion of the end-user at all times.

Enter the Contact-Management API

Suppose each of the big email engines confirmed to a small data-sharing API... Basically just a small agreement that when you enter a URL like this:

http://mail.somesite.com/sharing/7a45e9b923749d839f8f093eee

...The URL part would be an MD5 sum or one half of a GPG-key, unique to the third-party requesting the shared data, and unique to the website hosting your email account. A well-formed request like the one above would provide a response like this:

bob@example.com,Robert Terwilliger
tina@somesite.com,Tina Argent
...
melvin@somesite.com,Mel Absolute

This is a simplistic example. The response could easily be a microformat or RDF or any format that could be easily understood among third-parties.

 

How Sharing Works in the Contact-Management API

When the need arises to share your contacts with another website the site making the request would email you with a 'sharing' key. On opening the email you would copy the key into your email site's "Contact Sharing Manager" along with an expiry date selected by you. It would look something like this:

r.rowa td {background-color:#ccf} tr.rowb td {border-top:1px solid #ccc}

Sharing With	Sharing Key	Expires On	Edit
www.example.com	a8e8626ecfg537d65d56772aaf43253	Jan 1, 2011
www.somesite.com	8626eg53be5ddd32a4f665d3d368d89	July 28, 2008
www.anonymous.com	53fg72a5d567a8e8626ec3af47d6253	June 2, 2008
www.eponymous.com	6ad3903ed5672f2947ab4de6789828bc	Feb 15, 2008

Now the you get to decide who, how often and when a third-party gets access to your contacts. Without sharing your password. And the best part is the sharing is under the control of the user.

More advanced features could be added at the discretion of the email portal, like providing the user a way to select which contacts get shared, on a per-sharing-key basis, access logs (in case the website keeps coming back to get more contacts).

I think this is simple enough to be managed by almost anyone who grasps the utility of sharing their contact info when they sign on to a new website.

Preventing Contact Siphoning

How Much Data to Share?

The user-selected expiry date for sharing could prevent some abuse of sites extracting too much from a credulous user, especially if it's understood within the API that there is some upper-limit to how many contacts get shared per-request. This could curb abuse when the API only coughs up 5-10 contacts a day, giving the user an opportunity to monitor a new website through the shared contacts and decide if he wants to "open up" more or all of their contacts for sharing. If the newly joined website turns out to be a bit dodgy, the user can stem the tide by revoking the key immediately. Revoked keys could be tracked by the email provider and possibly warn others of high incidence of user-revokes.

Where Does the Data Go?

We can take the security/paranoia up a notch by requiring the sharing key to not return raw data, but decrypt a URL at the third party making the request. This URL would be an endpoint where the email provider could "inject" the contacts into your third-party account. This would be a handy way to verify where the data is being sent to, and enforcement could be done by declaring ahead of time which domain the Sharing Key belongs to. This two-step process would stop anonymous third-parties from "phishing" popular email portals for Sharing Keys.

This is only the beginning of the protection measures that could be provided. Optionally logging, tracing and emailing usage reports could also enhance the end-user's control over their personal data sharing. Heuristics or machine-learning could be applied at the email portal to build a profile of legitimate use of the Contact-Management API.

Nice Idea, But Who's Going to do the Hard Work?

Well, even as I wrote this I considered the possibility that this sort of sharing is already developed at that new Data Portability workgroup but they are directing their energy in documenting and organizing the work that's already been done, a lot of which is just different markup standards and microformats for identifying what kind of data you're sharing instead of how to control sharing. I was a little disappointed to see that, but they're pretty up front that they're not about developing new technologies.

Then I looked at Google's OpenSocial API Developer's Guide but at a glance the security is based on trust of a site in general. I think if I wrap my head around it you could make the OpenSocial API into something that provides some of the features I describe, but Googles documentation actually says: "but this decision is up to the container" - the container being website that can host OpenSocial gadgets so really it's up to the site itself if it trusts third party sites so no, it's not within the user's control.

In the Future, Everybody Will Share Data for More Than Fifteen Minutes

I've only made a cursory survey of the options and features available in either Data Portability or OpenSocial but I still think there is a gap here that would provide untold value to the people who actually use, instead of those who create the places to visit in, the Internet. Greater control exercised by the end-user has been the trend in more recent waves of popularity on the Internet. Now it's time for users to do more than just cast a vote on their favourite bookmarks. The Contact-Management API is one step toward the inexorable goal of letting the end user decide who, where, when and how often their data is shared.

Tags: data portability, contact management, social graph, security, architecture