Brownie Points

I Want to Be a Duct Tape Programmer

Mike Brown — Wed, 30 Sep 2009 21:42:35 GMT

I think people misinterpreted Joel Spolsky's post "The Duct Tape Programmer" (not the best choice of words because of the connotations of using duct tape as a "temporary quick fix" in the developer's mind) but there is one key gem to take away from it.

"Shipping is a feature. A really important feature. Your product must have it"

His point is the same that most of his posts say (and even what the 37Signals guys tout). No one gives a flying fig about how your application uses the latest programming language (or UI engine). What they care about is whether your product solves their problem?

You can spend all day spit shining your API to make it more SOLID, or you can say "the feature works, let's move on to the next one". In the mean time, the company down the road who knows how to get things done has shipped v1 and are getting feedback from customers for V2.

He also makes the distinction between the guy who can pull this off and everyone else. This is the guy who uses techniques at which he is an expert (in the Dreyfus Model sense of the word) to tackle the task at hand rather than saying "here’s this new wrench (language/Framework) let's see how I can use it on this go cart (enterprise app/web browser) I'm working on." Or to bring it home better would you prefer a surgeon performing an experimental technique on you that he watched some guy perform at a seminar last week when the one he has performed 100 times over will work just as well? That's what Joel means when he says duct tape programming. It might not be made of the shiny new state of the art experimental components. But it sure as hell works like a charm.

No where in the talk did he mention throwing out best practices (okay he does mention not needing unit tests but he also mentions that those were extreme circumstances). In fact he suggests what should be a new best practice: don’t use something you’re not familiar with when your ass is on the line.

I know a few people I would apply the Duct Tape Programmer label to but they would be too modest to accept it. And that’s what I aspire to be.

Service Locator Revisited

Mike Brown — Thu, 13 Aug 2009 04:18:50 GMT

I guess I have awakened a slumbering giant by writing the post the other day. I went back to add more functionality to the Service Locator (to enable per transaction and per thread services). Before I started breaking stuff by adding new functionality, I decided to make unit tests for the existing stuff. My first test was simple enough, register and retrieve a service from the ServiceContainer (which might need to be renamed because of a collision with System.ComponentModel.Design.ServiceContainer).

[TestMethod]
public void CanRegisterService()
{
    var dummyService = new DummyService();
    ServiceContainer.RegisterService<IDummyService>(dummyService);
    var retrievedService = ServiceContainer.GetService<IDummyService>();
    Assert.IsInstanceOfType(retrievedService, typeof(IDummyService),"The returned service is not of the correct type");
    Assert.AreEqual(dummyService,retrievedService,"The returned service is a different instance.");
}

Simple enough right? Let’s run it and make sure it’s green and move on…to…hey why is it failing? What happened? After a quick bit of investigation, I found that the problem lay in RegisterService overload that takes the Func:

public static void RegisterService<TService>(Func<TService> creator)
{
_Container.AddService(creator);
}

Do you see it? Maybe the implementation of AddService might make it more obvious

private void AddService<TService>(TService instance)
{
    _ServicesLock.EnterUpgradeableReadLock();
    try
    { 
        if (!_Services.ContainsKey(typeof(TService))) 
        { 
            _ServicesLock.EnterWriteLock(); 
            try 
            { 
                _Services[typeof(TService)] = instance; 
            } 
            finally 
            { 
                _ServicesLock.ExitWriteLock(); 
            } 
        } 
    } 
    finally 
    {
        _ServicesLock.ExitUpgradeableReadLock(); 
    } 
}

Because of type inference, <TService> is Func<TService> when we try to retrieve it we’re looking for TService as the key, and of course we won’t find it. So there’s a lesson to be learned here. Actually there are two.

It’s the simplest of changes that open the door for the most insidious bugs (not that this bug is very insidious)
If it’s worth writing it’s worth testing. No matter how small the functionality is, you should write a test for it because when it breaks you want to know.

Anyway, now that I’ve got the tests in place for the existing functionality, I’m going to go ahead and see about implementing per transaction life management. But not tonight.

Service Locator Versus DI – A Clarification

Mike Brown — Mon, 10 Aug 2009 17:11:00 GMT

Update:

For some reason Community Server decided that it doesn't want to display the style for the code snippet nor the IFrame for the skydrive link. Here is the final file. Read on for explanation of what it is and what it does.

Browsing though the blog of my friend and co-work, Jon Fuller, I noticed this post on Dependency Injection and Service Location. Especially interesting was this quote:

I was having a discussion with a colleague the other day about DI and Service Location in the context of the question (posed by a third person):

Which DI container/framework should I choose?

His answer:

None; just roll your own and use simple Service Location

It definitely sounded like I’m the colleague in question here. He then goes on to argue against my love of the Service Locator pattern. I think I should clarify what I meant with my statement. For reference, here is my code for a simple service locator. The usage is simple, first I register a service with the Container:

ServiceContainer.RegisterService<ICalculatorService>(new ConcreteCalculatorService());

Then anyone who wants an instance of the ICalculatorService can simply ask for it:

var calc = ServiceLocator.GetService<ICalculatorService>();

This method works for a vast majority of the simple cases where you want to provide a Separation of Concerns. In most cases you don’t need advanced lifetime management (e.g. a single instance of a service will do just fine). The reason I suggested rolling their own was that I assumed from the question the person had no experience with an IOC container prior. It takes time to grok an IOC container, there are a lot of moving parts, and for a simple case, this solution works just fine.

So what happens when I want to allow for more intricate cases. Like different lifecycles for service (per request, per transaction, singleton, etc). Well the choice boils down to extending/enhancing your service locator implementation, or using the Common Service Locator library in conjunction with a container of your choice. You have to decide when the cost of maintaining your own outweighs the benefits. Adding support for a per request lifecycle is simple enough as well however. Here are the changes to the Service Container that supports both a single instance and per request lifecycle:

        private TService RetrieveService<TService>()
        {
            Func<TService> retVal;
            _ServicesLock.EnterReadLock();
            try
            {
                retVal = (Func<TService>)_Services[typeof(TService)];
            }
            catch (Exception)
            {
                throw new Exception(
                   String.Format(
                      "Service Type {0} not registered with container.", typeof(TService).Name));
            }
            finally
            {
                _ServicesLock.ExitReadLock();
            }
            return retVal();
        }

        public static void RegisterService<TService>(Func<TService> creator)
        {
            _Container.AddService(creator);
        }

        public static void RegisterService<TService>(TService instance)
        {
            RegisterService(()=>instance);
        }

I just added an overload to the static RegisterService method that takes a Func that returns an instance of the service, I then change the original method to call the new overload and change the private RetrieveService function to do things properly. To register per request, you now make this simple call

ServiceContainer.RegisterService<ICalculatorService>(()=>new ConcreteCalculatorService());

Using the service is the same as before Now let’s address some of Jon’s concerns regarding the alleged shortcomings of the Service Locator pattern.

Some of his concern stems from the API for the service locator. (Why pass in a separate key when you already have a ready made key in the form of the service type. Also, I’m assuming the “movies.txt” is the parameter for creating an instance of the concrete IMovieFinder. Again, this is not an issue because the instance is created at registration (or using the modified version, through the creator delegate).

With regards to testability, when writing a unit test it’s easy enough to configure a Service Locator to return mocks. Just register the mocks in your setup and call clear on your teardown.

That leaves us with discoverability for consumers of your code. Documentation is a good place to start. Also, to me putting the dependencies in the constructor opens the door for things like this:

var lister = 
  new MovieLister(
    new CsvMovieFinder(
      new AzureBlobFileRetrieval(
        new AzureKey("account","secretKey"));

True this could be caught in a code review. But it can also be outright prevented by using this great thing called encapsulation. When someone creates the MovieLister that uses the ServiceLocator and debugs, they will get a nice friendly message informing them that they need to register an IMovieFinder with the service container (hopefully they know to do so in the Main() function or wherever your project does it’s container configuration).

To me, there is no major detriment to using either style. Rolling your own involves dealing with maintenance of that solution, but it’s easy enough to swap it out with a third-party container once you have the need for it. Here’s the code for my basic service container. A lot of other scenarios are trivial to implement here as well. And I’ll share them with you in a later post.

An Elevator Pitch for View Model

Mike Brown — Sun, 14 Jun 2009 15:57:00 GMT

I recently gave a presentation on WPF and Silverlight at this year’s Indy Code Camp. During the talk, I gave a brief overview of View Model. After explaining how data binding works within WPF, I had set myself up for the ultimate punch line:

Since we have this rich data binding model within WPF, why not bind our UI to an object that represents exactly what we want our UI to do.

To demonstrate the power of WPF Data Binding and the View Model pattern I walked through a simple RSS Reader that displayed a list of feeds allowing the user to select one and see a list of feed items and selecting one of those select display the page associated with the feed item in a Frame, all using data binding against a View Model object and zero code behind. While one can argue there are easier ways to create a simple feed reader in WPF…the code was tailored to demonstrate the power of the ViewModel pattern. I saw a number of light bulbs turn on in the audience as a result.

Announcing Alexandria RTW

Mike Brown — Thu, 09 Apr 2009 21:20:40 GMT

Release to the World that is. Today at 4:33 PM my wife delivered our newest family member, Khara Alexandria Brown. She weighs in at a healthy 6 pounds 3 ounces and has a modelesque height of 19 and 1/4 inches. Happy Birthday my little princess and many more!

Blend Behaviors FTW

Mike Brown — Mon, 06 Apr 2009 19:12:00 GMT

Update: As promised, here’s the code read below for usage.
(Please visit the site to view this media)

Beyond SketchFlow (THE official coolest thing since sliced bread), Blend 3 has some other great features for improving the designer-developer workflow. Something I like a lot (and most of my fellow WPF Disciples) are Behaviors.

If you recall, I spent a couple of posts a few years back talking about using attached properties to enable adding functionality to controls without code. Blend Behaviors take the pattern and wrap it in a simple API making it much easier to get down to the business of hacking WPF.

Even more interesting than the standard attached behaviors is the new Trigger system implemented using the pattern. Including the capability of creating custom Trigger Actions. In the initial release of WPF, Trigger Actions were effectively sealed because they are abstract and the function that inheritors need to override is marked internal. This effectively stood in the way of providing a solution to this problem in the MSDN forums.

The new Behavior-based trigger system (which works in Silverlight and WPF) opens the door for custom Trigger Actions. Now that we have custom Trigger Actions, I’m able to create an ExecuteCommandAction that allows you to invoke a Command from any trigger. The code is simple as is its usage.

First we define the trigger action

   1:  using System.Windows;

   2:  using System.Windows.Input;

   3:  using Microsoft.Expression.Interactivity;

   4:  using System.ComponentModel;

5:

   6:  namespace AzureCoding.Agility.Core.Behaviors

   7:  {

   8:      public class ExecuteCommandAction : TriggerAction<FrameworkElement>

   9:      {

10:

  11:          [Category("ExecuteCommandAction Properties"),

  12:          Description("The name of the Command that will be executed by this Trigger Action")]

  13:          public string TargetCommand

  14:          {

  15:              get { return (string)GetValue(TargetCommandProperty); }

  16:              set { SetValue(TargetCommandProperty, value); }

  17:          }

18:

  19:          public static readonly DependencyProperty TargetCommandProperty =

  20:              DependencyProperty.Register("Target Command",

  21:                                          typeof(string),

  22:                                          typeof(ExecuteCommandAction),

  23:                                          new PropertyMetadata

  24:                                              (TargetCommandChanged));

25:

  26:          private static void TargetCommandChanged(DependencyObject d,

  27:              DependencyPropertyChangedEventArgs e)

  28:          {

29:

  30:          }

31:

  32:          protected override void Invoke(object parameter)

  33:          {

  34:              var path = TargetCommand;

  35:              var dc = AssociatedObject.DataContext;

  36:              var targetCommand =

  37:                  dc.GetType().GetProperty(path).GetValue(dc, null) as ICommand;

38:

  39:              if (targetCommand != null && targetCommand.CanExecute(parameter))

  40:              {

  41:                  targetCommand.Execute(parameter);

  42:              }

  43:          }

  44:      }

  45:  }

The new Behaviors framework is defined in the Microsoft.Expression.Interactivity namespace (in the assembly by the same name). We inherit from TriggerAction, a descendant of the base behavior class and declare a dependency property for the name of the command we want invoked (lines 11 – 30). Finally, we override the Invoke method from the TriggerAction class. Unfortunately, it appears that Binding does not work for TriggerActions and I haven’t heard if this will be addressed in the final version of the behaviors framework. At least for now we have to get a handle to the target command manually. Once that’s done, we just check that it can execute and then ask it to do so. The code uses the convention that the command resides on the Data Context of the object to which your trigger is attached. I also didn’t bother putting in robust error checking (so if the property doesn’t exist, you’ll get an exception).

Once we’ve built the library and referenced it in a Blend 3 project, we can see our new behavior in the asset library

Adding it to a target is as simple as dragging it to the objects and timeline panel. From there we’re able to edit the properties using the property editor.

So how do we use it? Well The convention of looking for the Command on the attached control’s data context works very well with the MVVM pattern. So let’s make a simple login control and matching View Model to drive it. Here’s the XAML for the Control

<UserControl
<!-- A bunch of xmlns definitions—> 
>
    <UserControl.DataContext>
        <AgVM:LoginViewModel/>
    </UserControl.DataContext>
    <Grid x:Name="LayoutRoot" Background="White">
<!-- A bunch of layout definitions-->
        <Button Margin="0,0,5,0" VerticalAlignment="Bottom" Grid.Column="1" 
                Grid.ColumnSpan="2" Grid.Row="2" Content="Login">
            <i:Interaction.Triggers>
                <i:EventTrigger EventName="Click">
                    <Ag:ExecuteCommandAction TargetCommand="LoginCommand"/>
                </i:EventTrigger>
            </i:Interaction.Triggers>
        </Button>
<!—More UI code--> 
    </Grid>
</UserControl>

There is no custom code-behind for the control. The ViewModel is instantiated in the XAML and all the elements are bound to properties on the ViewModel using data binding. Here is our ViewModel (or the significant parts thereof):

    public class LoginViewModel : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;
        public LoginViewModel()
        {
            PropertyChanged += (blank, blank1) => { };
            LoginCommand = new DelegatingCommand
                               {
                                   CanExecuteRequested = param => true,
                                   ExecuteRequested = param => ShowLogin()
                               };
        }

        private void ShowLogin()
        {
            MessageBox.Show(String.Format("Login by {0} successful", _UserName));
        }

Here I’m using the DelegatingCommand to expose an ICommand as a property on my ViewModel. I’ve also exposed a UserName and Password field. Running the application gives us this.

So now we have trigger driven command execution with zero code behind. I’ll upload the code later.

Mozilla Lab Concept Series, Aurora, and Flow

Mike Brown — Sat, 28 Feb 2009 06:45:00 GMT

Shortly after I started playing around with Flow and put my ideas on paper (or at least digitally), someone pointed me to Adaptive Path’s Aurora Project. The brainstorm that lead to me writing about Flow preceded the publishing of the first Aurora video. I believe that I had created the first prototype before the video was published as well. It was really inspiring to me because I envisioned in Flow many of the concepts demonstrated in that video. What’s very interesting to me is this quote from their site: This is not a demonstration of a real product. What you see in the video is a visualization of our ideas created by animators. Technologically, much of Aurora would be difficult or impossible to implement today. However, we expect everything you see to be possible in some form in the future. Their desktop browser concept is definitely feasible, I think the Flow prototype shows this. It wouldn’t be difficult to replace the graphs with The concept of synchronization across devices is enabled through Live Fx. WPF has a very rich visualization story and almost any data that can be pulled from a web page (for example a table of precipitation data) can be bound and transformed through different visualizations. I don’t think that “Flow” would ever serve as a primary browser. Or I should say it’s not one of my goals to make Flow a new web browser but rather an Information Browser. In order to make a good browser, Flow would need the capacity of rendering HTML to WPF natively. Hopefully, Microsoft will one day release a native WPF browser control. Or I will attract the attention of an HTML rendering wizard. Until then, web browsing in Flow will be limited by the capabilities of the BrowserControl.

...(read more)

Static Reflection: Say What?

Mike Brown — Mon, 23 Feb 2009 18:19:38 GMT

There’s a new oxymoron going around call Static Reflection. The basic gist is that by using expression trees you can do things that appear to be dynamic but in reality are checked at compile time. Like for instance, getting the name of a property for firing an INotifyPropertyChanged.PropertyChanged event. My colleague, Jon Fuller, showed me his code for Method Guards and my first comment was that this would be a great tool for implementing INotifyPropertyChanged. He informed me that he already went there and showed me that code as well.

I wasn’t too happy with the idea of wasting your sole base class on NotifyPropertyChanged so I suggested that we use extension methods instead. After a bit of finagling with the framework (Events don’t like to be fired from outside their declaring class), here is the result:

        public static void SetProperty<T>(
		this INotifyPropertyChanged source, 
		Expression<Func<T>> propExpr,
		Expression<Func<T>> fieldExpr,
		T value)
        {
            source.SetProperty(
		propExpr, 
		fieldExpr, 
		value, 
		() => { });
        }

        public static void SetProperty<T>(
		this INotifyPropertyChanged source,
		Expression<Func<T>> propExpr,
		Expression<Func<T>> fieldExpr,
		T value,
		Action doIfChanged)
        {
            var prop = 
		(PropertyInfo)
		((MemberExpression)propExpr.Body).Member;
            var field =
		(FieldInfo)
		((MemberExpression)fieldExpr.Body).Member;
            var currVal = (T)prop.GetValue(source, null);
            if (currVal==null && value==null)
                return;
            if (currVal==null || !currVal.Equals(value))
            {
                field.SetValue(source, value);
                var eventDelegate =
			(MulticastDelegate) 
			source.GetType().GetField(
				"PropertyChanged",
				BindingFlags.Instance | 
				BindingFlags.NonPublic).
				GetValue(source);
                Delegate[] delegates = 
			eventDelegate.GetInvocationList();
                var args = new PropertyChangedEventArgs(prop.Name);
                foreach (Delegate dlg in delegates)
                {
                    dlg.Method.Invoke(
			dlg.Target, 
			new object[] 
			{ 
			  source,
			  args 
			});
                }
                doIfChanged();
            }
        }

Now you can use a strongly typed NotifyPropertyChanged declaration without using your base class

    public class PersonStaticReflection : INotifyPropertyChanged
    {
        private string _firstName;
        private string _lastName;
        public string FirstName
        {
            get { return _firstName; }
            set { this.SetProperty(
			() => FirstName, 
			() => _firstName, 
			value); 
		}
        }
        public string LastName
        {
            get { return _lastName; }
            set
            {
                this.SetProperty(() => LastName,
                                 () => _lastName,
                                 value,
                                 () =>
                                     {
		// do something useful here
                                     });
            }
        }

        public event PropertyChangedEventHandler PropertyChanged;
    }

For those concerned, you can statically cache the PropertyChanged field in a dictionary mapped to the object type so that you only have to reflect on it one time.

Get Your Hands on Flow

Mike Brown — Thu, 19 Feb 2009 05:04:07 GMT

Quite a while ago, I first started hinting about “Flow”. I’ve given friends and colleagues information about the project, and have been teasing everyone with screenshots and videos. Monday, I started a series that I call “Refactoring to Patterns: WPF Edition” in which I started the task of building Flow from the ground up. A few moments ago I wrote a post discussing the background of Flow and finally made the prototype available for download. There is going to be some crossover between my other blog and this one here. But I’m getting ahead of myself.

I’d love to get your feedback. I will be publishing a Codeplex project where you can submit bugs, join the discussion, and even download the code. Until then, you can leave a message for me at either of my blogs. Happy coding!

Entity Framework Has Layers Like an Onion

Mike Brown — Wed, 18 Feb 2009 16:23:36 GMT

If you’ve been following my tweets, you’ll know that I’ve been experimenting with Entity Framework lately. I’ve been digging around, looking at the generated code for EF and realized something very interesting.

    [EdmEntityType(NamespaceName="DBO", Name="Project")]
    [Attribute(IsReference=true)]
    [Serializable()]
    public partial class Project : EntityObject
    {

You see that? My entity has Attributes on it…very similar to NHibernate attributes. Here’s another interesting tidbit from a property that exposes a relationship between two entities (a so-called Navigation Property)

[EdmRelationshipNavigationProperty(
  "DBO", "FK_tblTasks_tblProjects", "tblTasks")]
public EntityCollection<Task> Tasks{
   get{
     return RelationshipManager.GetRelatedCollection<Task>(
                 "DBO.FK_tblTasks_tblProjects", "tblTasks");
   }
   set{
     if ((value != null)){
       RelationshipManager.InitializeRelatedCollection<Task>(
         "DBO.FK_tblTasks_tblProjects", "tblTasks", value);
   }
}

Notice that the navigation property has an attribute giving the name of the relationship (here the same name as the foreign key) and the related entity name (again given the same name as the foreign table). Behind the scenes it uses a relationship manager (property of EntityObject) to get/set the values.

So What’s Your Point?

The point is that the generated code is nothing more than a strongly typed convenience layer over the EF API. The point is that it is possible to provide your own engine that lays over this API and removes the coupling to EntityObject from your Domain Objects. The core of Entity Framework…the database abstraction layer…is very solid. It’s begging to have a proper O/RM engine placed on top of it.

Starting the New Year With a Bang!

Mike Brown — Fri, 06 Feb 2009 17:52:07 GMT

Yes I know it’s February already, but this should show even more how big the start of this year has been for me. First and foremost is the big announcement that the new year brought.

First and foremost, I’ve been named an MVP in Client App Development (for my community contributions with WPF). This is an incredible honor for me. In addition to the title, being an MVP provides me an opportunity to have better interaction and feedback with Microsoft especially with regards to my specialization. According to the program guidelines, the award is for my past activities and I am not required to do anything else.

However, I want to leverage this opportunity to the fullest and will continue my community contributions going forward, both with regard to WPF and Silverlight as well as with Windows Azure.

Second, as an organizer for our local Alt.NET User Group, Indy Alt.NET, I’m excited about a few recent developments with the group. Chief among those being named an official INETA group – something that surprised me seeing that there was already an INETA group in the Indianapolis area. We are coming on our first anniversary and have seen our attendance stabilize at around 25 per meeting. With almost a year under our belt we have sat down and started a few initiatives.

One major decision will be to incorporate as a non-profit organization (an idea we had thrown about for a while but were too busy with day to day operations to act upon). This action will allow us to apply for grants and begin some community outreach initiatives that we are all excited about. It will also make us more attractive to potential sponsors as certain donations to us will be tax deductible.

Another initiative has been a marketing and sponsorship drive. We are trying to grow organically, but we have noticed that we have a chicken or egg scenario. Therefore, we are pushing our growth on multiple fronts. So far we are getting good feedback from our efforts.

Our biggest initiative about which we are all very excited is planning for a local conference. More on that later ;)

But wait there’s more! I just finished my first year with my current employer, Software Engineering Professionals. Management announced a number of initiatives here that are pretty exciting for me. I can’t necessarily talk about them right now, but it reaffirmed my decision to come here. I can honestly say that I have grown dramatically since I’ve been here. It is an amazing place to work, and I’m excited to see what the future has in store.

Finally, my family is counting the days until our latest addition is expected to arrive.

Like I said, this year is starting off with a bang…and there’s more to come. I’ll keep you posted with new developments.

Buzz In the Cloud December 4, 2008

Mike Brown — Thu, 04 Dec 2008 14:36:07 GMT

Sorry for the extended absence. I've been working on a crossover article series on refactoring between my WPF half and my Azure half. It's shaping up pretty nicely. But in the meanwhile, I've neglected my buzz duties. So without further ado, here are your buzz-worthy items for today.

Getting Webby With It

Next week (December 8th to be precise), the Live Framework team will be hosting a webcast. I think the topic will be about the future of the MacOS or something like that. I'm pretty stoked about the 1 and 15 minutes scheduled for Q&A on the agenda!

Steve Marx Says

"PDC Attendees Should Have Windows Azure Tokens" (that is if you registered for them). Also if you follow his blog, he has more Azure code samples (including the blog itself) than you can shake a stick at.

The Gift That Keeps on Giving

The PDC ended a month ago and I am still finding great sessions like this one that gives an in depth view of how the B2B sample Azure application shown during the opening keynote was built. It's funny, I went into PDC without a shred of interest in Microsoft's cloud platform (outside of Mesh/Live Framework). And now I'm so enthralled by it, I haven't spent more than 3 hours with VS 2010 (and that's just for the "Oslo" stuff). Anyway, I'm told there are good sessions on WPF 4.0, WF 4.0, TFS 2010, and other new stuff, and I'm going to get to them...eventually.

The Real Reason to Get Excited About Live Mesh

I've seen a lot of chatter about how cool Live Mesh is because you can synchronize your files. What if I told you that the file synchronization is really just a proof-of-concept. The Live Mesh client that you see today, is little more than an example of what the Live Framework enables. Don't believe me? Look at this video by Jamie Thomson where he shows the masses what the lucky few with Live Framework CTP tokens get to play with. BTW, I managed to win a few invite cards from the Live Framework team in an arm wrestling match. Leave a comment on this post for a chance to win one.

Today's Episode Guest Stars David Burela

Long Zheng decided to let someone else take the reins for a day over at his blog. David Burela took the opportunity to post a review of Azure. Don't go looking at the sidebar or anything. There's nothing to see there. Nope, nothing at all about a HP Magic Giveaway including a Touchsmart that is Windows 7 multi-touch capable.

Farewell "Blue Badge" Hack But We Don't Need You Anymore

Well soon we won't that is. Windows 7 Beta 1 (feature complete) will be given to attendees of the MSDN Developer Conferences. Basically, it's the PDC distilled and distributed at a more reasonable price point. I will be attending the Chicago event and promptly installing my Beta 1 copy on site!

Windows 7 Gives You Wings

Over at Redmond Developer News, you can read the new issue's cover story online. It is a review of Windows 7 Build 6801 that pretty much reaffirms my experience with 7.

The Signs Were Always There

Way back on October 1st Computer World posted a teaser article for "Windows Cloud".

You've Got to Love Fanboys

Windows 7 hasn't even released yet and the self proclaimed "Cyber Cynic" has written three different posts proclaiming that Windows 7 sucks and that Microsoft had to resort to bribery to get a good review. Like I said in my review, the only "bribe" I received from Microsoft was a copy of Windows 7 on a WD Passport drive. And my employer paid 2400 for me to get that.

The Live Framework Afternoon Special

In a new white paper by Nishant Gupta and Dharma Shukla, the two answer the question we've all been dying to know "What is it and Why Should I Care?". Next week it will be "Coping with Peer Pressure: Should I Use Live Framework?".

Well that's it for today fellow cloud dwellers. There's more news to tell, but not enough time to type it all out.

Getting Started With Azure Development

Mike Brown — Wed, 26 Nov 2008 07:02:00 GMT

I have posted an overview of getting started with Windows Azure development, our first article in the Azure Development Series. I will update the series weekly with walkthroughs and tutorials on Azure Development.

Buzz In the Cloud November 25, 2008

Mike Brown — Tue, 25 Nov 2008 12:29:20 GMT

Whoa...today is a doozy for buzzing, so let's get right to it.

I For One Welcome Our New Cloud Overlords

The latest Deep Fried Bytes episode (entitled "Windows Azure: the Overlord in the Cloud") includes an interview with Steve Marx, Program Manager for Windows Azure.

7's a Lucky Number

Oak Leaf Blog rounds out their Azure Storage Services Test Harness with a post on paging the LINQ query result sets and another on testing for table existence...hmm, maybe a management utility is in order to get rid of that pesky requirement. By the way, they also placed the harness up for your viewing pleasure.

If CTP Isn't Cutting Edge Enough

What's that you say? Living on the edge isn't enough for you? You want to jump off the edge with your bedroom sheets as your parachute? Okay, daredevil, I've got the fix for your thrill-seeking craving! Check out the SQL Services Labs where you'll find 7 projects in "incubation" status. Included in these projects are:

Data Mining in the Cloud: Just what it sounds like, it's SQL Analysis Services over SDS. I hope this becomes a final product.
URank: A search engine that lets "U Rank" the hits.
Project Codename Anchorage: Or as I like to call it YASPFM
Project Codename “Huron”: Sync Services for SQL Server...intriguing...
Reporting against SQL Data Services: Again, not a very creative name but it definitely gets the point across. This one lets you point your internal SQL Server Reporting Server at an Azure SDS database.
Codename “Astoria” Offline: Sync Services for SDS (not to be mistaken with Sync for SQL Server).
Accessing SDS using ADO.NET Data Services: I believe one of the SDK samples does this, but this incubation looks like it's aiming to make it a standard part of the Azure SDK instead of just a sample

Overall, I see the utility of all these projects (outside of "Anchorage" it really has me confused). I think it would be good to have them all graduate from incubation. But if I had to pick one, it would be the ADO.NET data services over SDS.

Saving Lives One Cloud at a Time

Over at the Joy of Code, Josh Twist tells us about his adventures in the clouds while coding a proof of concept for the RNLI (Royal National Lifeboat Institute). Basically, the software receives beacon data from fishing boats (relayed from satellites to the RNLI data center to the Cloud App). Should a fisherman go overboard, an alert signal is raised and the Coast Guard will have tracking data in order to send the proper assets to the right place. That is incredible if I must say so myself.

Two Pages We Have More Content in a Single Post

DevX finally decided that Windows Azure was worth space on their gargantuan site. So they wrote a two page introduction to Windows Azure. Oh wait, the introduction is on the entire Azure Services platform. Honestly, you'd be better served reading David Chappell's white paper. Heck the AzureWiki has more content than that introduction (with more on the way).

Chappell Show

I wonder how many people have hacked the pronunciation of poor David Chappell's name. To be honest, until I saw this interview, I was one of them. Now I know it's CHAPpell (like the Church) not ChapPELL (like the show). And knowing is half the battle.

Googling Azure

Dion Almaer, Googler and founder of Ajaxian, gives us a refreshingly honest view of PDC from a competitor's perspective. Our overlord in the cloud is pleased.

Must Have a Long Digestive Track

Kirk Evans writes a pretty insightful post on the PDC announcements in "The PDC That Took Weeks to Digest" He talks about letting it stew, simmer, and brew, but never eating. Maybe it would digest quicker if he hurry up and cook it.

Yet Another Blog Post About Silverlight and Azure

Although to give the author credit, it does discuss the limitations of Silverlight on the current release of Azure. Hey guys, can we get to working on that whole SSL certificate thing?

Okay that's enough for today's buzz. There's still a lot more that I could throw at you, but I'm getting fatigued. I'll be back tomorrow with more buzz.

The Synchronization Morass

Mike Brown — Tue, 25 Nov 2008 04:45:30 GMT

Microsoft loves them some synchronization like a fat kid loves cake.

Yet another synchronization platform from Microsoft has emerged. This one appears to be an evolution of the Synctoy which was a desktop application that seemed oddly similar to Live Mesh. Codename "Anchorage", or as Redmond Pie calls it, "A SyncToy for the Cloud" If you're totally lost at this point, it's with good reason:

Codename "Anchorage" represents our current thinking of where to take SyncToy in the future that not only provides value as a generic sync hub but also - an easy to use application capable of keeping content synchronized across PCs, services, and devices through a rich plug-in mechanism based on the Microsoft Sync Framework.

Come again? Isn't that what Live Mesh does?

With Live Mesh, you can synchronize files with all of your devices, so you always have the latest versions handy. Access your files from any device or from the web, easily share them with others, and get notified whenever someone changes a file.

Here's where it gets really loopy:

With this project, providers will be able to register and be discovered in a variety of sync groups including contacts, files, favorites, videos, as well as synchronization across services such as the Live Mesh, PhotoBucket.com, Smugmug.com, and more. Powered by the Microsoft Sync Framework - this E2E and hub for sync providers has value for both consumers AND developers.

So wait a minute..."Anchorage" is an extensible synchronization platform that integrates with Live Mesh which itself is an extensible synchronization platform. (And from all indicators is ALSO built on top of the Sync Framework). Well at least Live Sync is a purely end user synchronization platform...at least we hope.