A colleague emailed me today regarding some information I had sent him previously.  Apparently, Lotus deleted all of his data which wasn't archived.  Why?  Who knows.

Anyways, I suggested that he simply ignore the company email system and use a GMail account.  To this, he replied:

If I could I would NEVER use Lotus email. WHAT A nightmare!!!

Emphasis his.  So please, if you're an IT administrator or a CTO, don't punish your minions by subjecting them to Lotus Notes (unless, you know, you're into that sort of thing).

Okay, maybe "death" is a bit severe.  But certainly, I think in the next few years (if not months), Office will start to lose marketshare...significantly.

Now don't get me wrong; I love Office (okay, not really, but I work with it on a daily basis and the whole product strategy for my group revolves around the Office client and server suite), but there are some severe usability issues which have, amazingly, to this day, been pretty much unresolved.

The crux of the shortcomings of Office (aside from interoperability pre-12) is really document sharing.

Today, in the Office world, if you want to share documents (either with yourself (i.e. work on a different machine) or others), you really only have a few options:

1. You can access your desktop remotely using a remote desktop client.  This sucks for a variety of reasons including responsiveness and the require setup to enable a remote access scenario.  It may not even be possible due to corporate firewalls.
2. Email the document to yourself and/or collaborators.  This is what most people do today, I would gather.  It's one of the most annoying things that I deal with because I end up with a folder with a bunch of documents title "Spec rev.1", "Spec rev.2" and so on.  Not to mention what the clusterfuck that happens if I modify the document and rename it with "rev.X" and another collaborator does the same.  It sucks...but even I've been known to do this.
3. Copy the document to a physical medium and pass it around.  This includes CDs, USB drives, external drives, etc.  I do this quite often when I travel and I know I will need to prepare a document.  But it sucks.
4. Use a corporate SharePoint site to share your document.  This is a great solution...if your company has a SharePoint site.  What if you're not a full Microsoft shop?  What if you work for a small company?  It also means you'll probably need VPN access, which is generally annoying.  For the record, I've been using Office personally and professionally for more than 10 years now and I've never shared a document using this method.
5. Use Office Live!  This is a relatively new offering from Microsoft who finally realized "Hey, maybe the rest of the non-corporate world would also like to share documents in a non-shitty way!" However, what sucks about this is that you still need to have the Office client...we'll touch on this point in a bit.
6. Use some sort of remote file share (FTP location, network file share, etc.).  This has various perils as well in addition to the inconvenience of having to have a VPN connection.

None of these options are really appealing, but until recently, there really wasn't a choice.  Regardless of what desktop processor you use, you're pretty much constrained to the same set of options (you can replace SharePoint with whatever web platform your client integrates with).

This sucks, for the reasons listed above, but it also sucks because it means that you have to lug around your laptop everywhere you go to work on documents.  It's the reason why you see business people scrunched up in coach, contorting their bodies and praying that the person in front doesn't put their seat back so they can fold out their laptop.  The desktop document processor client makes us all slaves.

But the future is coming.  For personal use, I don't think I'll ever author another Word document in Office ever again.  Both Google Docs and Zoho offer what I need so far as basic document processing goes and I have the added convenience of being able to easily share documents with others.  There's also the absolute coolness of being able to edit the same document in a live session with your collaborators.  This alone is not enough to change how we work with documents.  The iPhone and the impending release of Android (along with the next generatin of smart phones) will leave the Office stack in the dust.

My house backs a small forest.  So from time to time, we get some interesting visitors.

I saved these guys while I was mowing the lawn...I hope I didn't kill any of their siblings

I briefly considered feeding them to my bearded dragon, Quincy, but decided that it was better to just put them back.

This deer came by about two weeks ago:

It was pretty cool because he walked right out into the main yard before he got spooked and ran back into the woods.

We've also had a red fox visit our back yard one time.  There's also this little garden snake living under our front stairs which I keep seeing every few weeks.  I've been trying to catch him, but who knew snakes could crawl backwards?

I spent bout two hours today tring to figure out why I kept getting a weird error while using prototype to call a WCF service.

There are various other resources on the web regarding how WCF has a few quirks with error handling using the default endpoints, however, none of these scenarios were applicable to me since the JavaScript call worked fine in FireFox.  To complicate things even further, it actually all worked fine in IE7 as well with one caveat: it only worked on the first load of the IE7 process.

After that, any refreshing of the page would return 400/"Bad Request" errors, mysteriously.  Just to make sure that it wasn't isolated to prototype, I also tried jQuery as well.  Still nothing.

Well, as it turns out, that setting the AJAX request content type to application/json wasn't enough; I had to set it to application/json; charset=utf-8.

So if you're encountering weird issues with any AJAX library, IE7, and WCF and/or ASP.NET, be sure to check your content type setting.

Update 6/20/2008: bah!  I woke up this morning and it's not working again!  Oddly, it works fine if I have Fiddler running and as soon as I shut off Fiddler, it stops working.  To complicate matters even more, it's only happening on methods where I have post content.

Update 6/22/2008: after further investigation, I'm concluding that it's related to SharePoint.  To isolate the different components, I created a custom WCF service and a simple runtime which models our current custom WCF runtime.  When I used a plain HTML page or even an ASPX page with a script manager on it, prototype AJAX requests worked fine.  Okay, so it wasn't how we were hosting the service and it wasn't an issue with a collision between ASP.NET AJAX and prototype.  I then hooked a SharePoint layout page up to the same service and boom, it all breaks

I've broken it out into the following scenarios:

1. Using FireFox, the requests always work.  No matter how many times I refresh the page, the AJAX request always works fine.
2. Using IE7, it will always work on the first load of the IE process. 
   1. If I hit CTRL+F5, it will continue to work.
   2. If at any point, I hit F5, it will fail and even CTRL+F5 will not fix it.
   3. If I have Fiddler running, it will always work, even if it entered a failure state after hitting F5! (So Fiddler must be doing something to the HTTP message??). As far as I can tell, the only difference between the Fiddler request and the native request, from viewing the WireShark trace, is the "Authorization" header and the fact that the failed request has a "Content-length" header value of 0 (manually setting the header doesn't work either).  I verified that prototype was not somehow mangling the POST body content by writing a trace of the XHR request body right before and right after the request is sent (both came out okay).

One of the really weird things about this error is that it cannot be observed when I have Fiddler running; somehow, Fiddler "fixes" the issue.  I had to hook up WireShark on the server and watch the raw TCP messages to finally see that on the unsuccessful attempts, the POST content to my WCF service was empty.  The method required one parameter, so the WCF serializer threw a formatter excpetion when it received an empty message:

I've tried playing around with various cache avoidance strategies to no avail (setting the "Cache-Control" header, setting the "If-Modified-Since" header, setting the "Pragma" header, addin randomness to the POST URL) so for now, I'm just going to have to give up on this.  I've confirme the error using three different OS environments (XP SP2 (desktop), XP64 SP2 (dev), and 2003 R2 SP2 (VM)), all running IE 7.0.5730.11.

I know there are various articles out there regarding IE issues with XHR and how the ordering of the open(), onreadystatechange, and send() operations must be called; however, I verified in the prototype source (lines 1213-1223) that the correct order of operations are being performed.

Thinking that perhaps some Microsoft mojo was behind all of this, I gave the Sys.Net.WebRequest a shot.  This also did not yield any postive results.  Oddly, ASP.NET AJAX to web service calls all work fine (we had some existing AJAX components which were calling to a web service, but the goal was to transition away from writing these "empty" proxy services and call directly to the WCF service).

If any SharePoint development team members or program managers are reading this, please look into it!  I'm not sure if it affects IIS hosted WCF services at this point, but a sample project can be downloaded from here: WcfAjaxWonkiness.zip.  Create a layout page which calls the service and add it to SharePoint and observe it blowing up.

I've previously posted on how to move compiled binaries into a remote GAC automatically from your development environment to your SharePoint environment using SysInternal's PsExec utility.

But what about moving content files from your SharePoint environment to your development environment?  When I'm developing content for layout pages (ASPX, js, css), for the most part, I don't want to develop in Visual Studio; I will usually use EditPlus (my weapon of choice) and edit the files directly on the remote server.

However, this poses a problem: synchronizing files between the SharePoint environment and the development environment.  It's quite time consuming and painful to do it manually since you may have to dig through various directories and keep tabs on which files you've edited on the server.

Enter 2BrightSparks' SyncBack utility.  Using this, I can create a synchronization automation between my SharePoint environment and my development environment.  And because I've set up my files to have the same structure on both sides, it's easy to set up the synchronization settings.

The image above shows the layout of my project. You can see in the image below at the directory layout mirrors the project layout, making automated synchronization a snap.

Working smarter > working harder.

If there's one man who could do this, it would have to be Venter.  Newsweek has a story on how Venter is working to revolutionize the way we view energy:

In a Maryland lab, he's manipulating chromosomes in the hopes of creating an energy bug—a bacterium that will ingest CO₂, sunlight and water, and spew out liquid fuel that can be pumped into American SUVs

Talk about having your cake and eating it, too.

People want to bury that CO₂ in the ground or pump it into oil wells or coal beds. We want to use that CO₂ and the carbon in it to make new fuels.

We think the first fuels are maybe one to two years away. We're definitely thinking in terms of years, not decades.

Such a breakthrough would create a sudden shift in the geo-political climate to one where the Middle East becomes nearly irrelevant and perhaps the US dollar rebounds to become king (once again).

Venter also brings up a very intriguing point:

Right now oil is being isolated around the globe, and there is a major effort in shipping, trucking and otherwise transporting that oil around to a very finite number of refineries. Biology allows us to make these same fuels in a much more distributed fashion. I envision maybe a million micro-refineries. Companies, cities and potentially even individuals could have a small refinery to make their own fuel. This would eliminate a lot of the distribution problems and associated pollution.

Sounds like the days of $0.99/gallon fuel just might be in our future.

One of the most awesome features of WCF in .NET 3.5 is support for REST-style AJAX requests to the services.

Rick Strahl has an excellent post on how to get it up and running with jQuery.

Just some notes on working with it myself which I hope can help clarify some some issues:

• When using POST and the postBody option with Ajax.Request, the format must be {"argument-name":"value"}.  I struggled with this for a while using single quotes and no quotes.  For example: {arg:'hello'}, {'arg':'hello'}, {arg:"hello"} will all result in 400 "Bad Request" errors.
• The contentType parameter must be set to "application/json".
• Be sure to decorate the service contract using the WebInvokeAttribute with ResponseFormat and RequestFormat set to WebMessageFormat.Json.

You can download a sample project from here: WcfAjaxSample.zip (3.83 KB)

I like this Kamen interview:

Outfitting wounded veterans with dramatically better prosthetic limbs has been an emotional and rewarding journey for famed inventor Dean Kamen. But the project that has the biggest hold on his heart is a nonprofit called FIRST. The organization features a series of intellectual and scientific competitions. Students celebrate robotics the same way they celebrate football – complete with arenas, crowds, and cheerleaders.

Kamen says declines in graduating students and qualified engineers and scientists aren't an educational problem -- but a cultural one. When you celebrate sports and entertainment culturally, that's what kids naturally want to become. Solution? He's bringing sexy back to science. In this clip, he shares FIRST's results, and what corporate America is getting out of it too.

It needs a bit more love.  He makes a good point about the "unlimited class" of competition.  Whereas a cheetah can run faster than any human and an elephant can lift more than the strongest human, no animal can out-think humans.  Thus competitions of intellect are truly competitions of "unlimited class".

I like this story:

China is banning free plastic bags common at shops and supermarkets and ordering customers to be charged for any they use, the government said Wednesday.

Shops have been instructed to mark the price of the plastic bags clearly and not fold them into the cost of other items.

Environmental organizations, including Greenpeace, praised China's move, and Christopher Flavin, president of Worldwatch Institute, an independent research organization in Washington, said "China is ahead of the U.S. with this policy," AP reported.

The Chinese use up to 3 billion plastic shopping bags a day.

Often, the flimsy bags are used once and discarded, adding to waste in a country grappling with air and water pollution as a result of rapid economic transformation, officials said.

"Our country consumes a large amount of plastic bags. While convenient for consumers, the bags also lead to a severe waste of resources and environmental pollution because of their excessive use and low rate of recycling," the statement at the Web site Gov.cn said. "The ultra-thin bags are the main source of 'white' pollution as they can easily get broken and end up as litter."

I think it's time for the US to do the same.  Not only are they not environmentally friendly, plastic bags are made from petroleum, contributing to the rising energy costs (fractionally).

Google's new AJAX Libraries API should help quite a bit with developing web UIs.  From Dion Almer:

I just got to announce the Google AJAX Libraries API which exists to make Ajax applications that use popular frameworks such as Prototype, Script.aculo.us, jQuery, Dojo, and MooTools faster and easier for developers.

Whenever I wrote an application that uses one of these frameworks, I would picture a user accessing my application, having 33 copies of prototype.js, and yet downloading yet another one from my site. It would make me squirm. What a waste!

When I joined Google I realised that we could help out here. What if we hosted these files?

Read more about it here.

By the way, I caught this little tagline from ajaxian:

Because after 10 years, we're still hand-coding.

There's a lot to be said for the productivity gained from drag-&-drop RAD tools, but ultimately, software engineering is still at a stage where craftsmanship matters (a lot) and there is no substitute for a skilled craftsman.