May 2007 - Posts

I'm not entirely sure what to think of Google Gears.  It seems most people are focusing on the Database portion of the stack, but it's the LocalServer portion that has me confused.  Does this not reek of complexity and severe duplication? 

After first reading through the LocalServer Overview I thought, cool, this thing is going to serve up my server app when the client is offline.  That's kind of sweet, but how do they know what pages people are going to need?  I sure hope they don't cache on demand, because that breaks down with the first button I click?  Maybe they crawl my pages and pick up links, that might work.  Well, it turns out you have to tell them up front what pages to cache either via a Manifest file or via their LocalServer API.  Manifest file is cool I guess, there will undoubtedly be server-side tools to generate these.

What happens if my client's browser has caching disabled or your page's client side cache expires?  How do you get to the first page that loads the Gears API and starts loading the Gears Cache?  Maybe I'm missing something here.

I think I can handle all link activity and user actions requesting pages from the LocalServer.  I'm sure that stuff can be wrapped into our AJAX frameworks; I'm sure Google's Web Toolkit will soon enough.  What about Mashups' though?  Aren't we supposed to be pulling data from site A and displaying it with relevant information from our site?  Is everyone going to start caching everyone else's data?

But, heck, it's not like any of the RIA platforms out there today are doing any better at providing infrastructure to move the Internet App as is to the offline client.  This seems like a decent start.  I personally like the idea of having two different targets: client or web, while providing a different targeted experience for either.  We have too much horsepower and money invested in our personal computers to waste it on a serving local web pages.

We'll see.  It's still only beta.

with no comments
Filed under:

You know you need to reevaluate your web site when you see the following:

 Every now and again I find a tool that changes my life.  Baretail is just such a tool.  I don't know what I did before, but it couldn't have been good.  Baretail is a log file reader/watcher that trails the end of your log files.  This may not be too exciting for you, but here in the Speedy Rewards team, we have some terribly verbose 3rd party log files that are our only real insight into activity.  This has made my week!

with no comments
Filed under:

Vista Sidebar Gadgets can be cool, but the developer experience out of the box is severely lacking.  Microsoft doesn't provide a Visual Studio project template, so Tim Heuer was nice enough to provide one for us.  He does so via a Web Site template, which makes sense since a Sidebar gadget is nothing more than an Html page with a splash of JavaScript, minimally, of course.  If you are like me, you like to be able to touch something up and then look at it, but I'm not about to edit, copy, run every time I want to see what my little icon change has affected.  Here's a tip to help you out: create a symbolic link in your %userprofile%\AppData\Local\Microsoft\Windows Sidebar\Gadgets directory.  Here's how:

    1. Run Command Prompt as an Administrator
    2. mklink /D "%userprofile%\AppData\Local\Microsoft\Windows Sidebar\Gadgets\<gadgetname>.gadget" "%userprofile%\Documents\Visual Studio 2005\WebSites\<VisualStudioProjectDirectory>"

This allows you to keep your projects where they belong (VS won't let you open a folder in AppData without jumping some hoops anyway) and still reload your Gadget in Sidebar whenever you make changes.

with 2 comment(s)
Filed under:

While up in Redmond for the WPF Bootcamp, we had a short time to work with some of the WPF/E, now Silverlight, team members.  At the time Silverlight didn't make a whole lot of sense in our strategy.  That said, I hope everyone sees the great potential that comes from some of the features surrounding Silverlight 1.1 specifically.

Let's put this into context. Over the last couple of years, true web-based applications have really started to take shape.  I'm talking Google Docs & Spreadsheets, Yahoo! Local, Yahoo! Pipes and not YouTube, which is a glorified photo sharing site.  A bevy of AJAX toolkits have attempted to fill the enormous development gap between LCD-JavaScript and C#, Java, VB, Ruby, and Python, but there is only so much one can do with JavaScript before you go crazy.

Now imagine some "real" applications that actually attempt to provide a full feature set which accentuates an existing web model.  My favorite example is Shutterfly Studio.  They probably could have given you 20% of the Collage functionality with some goofy JavaScript or lots of uploading and postbacks, but how long would you wait around for your photos to upload while trying out different layouts?  Not long I'd imagine.  This is where Silverlight comes in.

Silverlight takes the untold story of Java and actually runs with it by providing a consolidated branch of the full .Net CLR, including JITter, Garbage-Collector, BCL, Threading namespace, Network stack and more.  Well this is all well and good, but why not just use Flash?  Well, if you want to deploy a Flash application, you are forced to use ActionScript, which doesn't provide nearly the feature set of .Net nor is it useful in any other environment other than Flash, so your experience is isolated.  Flash also doesn't provide the huge WCF communications platform for secure, transport independent communications, WPF for rich interactive media, and one of the most powerful IDE platforms in Visual Studio.

Imagine starting your family collage with Shutterfly Studio at home on your laptop, getting to work in the morning and flipping through real layouts with your pictures at work (lunch of course) and then sending your parents a link to the catalog of pictures where they can browse any layout and order their own version of the collage?  No Shutterfly Studio desktop icon or Start Menu shortcut.  Just a one time 20 second download of the Silverlight CLR - yeah the Silverlight CLR is only 4mb.  That's what removing 90% of the named color members in System.Drawing.Color and asking people to look up the HEX value.

Have fun.

with 2 comment(s)
Filed under: , ,