Sunday, May 17, 2009

NYC .NET Developers Group – May 21, 2009

I will be speaking this Thursday night at the NYC .NET Developers Group.

My topic will be “Getting Started with Windows Azure.”

I will begin with a brief overview of Windows Azure, and then take an existing ASP.NET MVC application and migrate it to Windows Azure.

Since Bill Zack has already given a solid overview of the Azure Services Platform at past user group meetings in New York, I plan to keep the overview short and move quickly to the code.

If you’re interested in attending, you need to register at in order to be admitted to the building.

WPF/Silverlight Meetup Reignition

One of the projects that I have been working on for the last few months is bringing back the NY WPF/Silverlight Meetup group.

Tomorrow night will be our first meeting with me as the organizer.

The meeting tomorrow will feature Ronald Lintag.  He will be presenting doing agile development using the new Sketch Flow feature in the upcoming Expression Blend 3 to create low-fidelity mockups.

Next month will feature Dmitry Lyalin giving a presentation on using Prism 2.0 to develop composite applications with WPF and Silverlight. 

I have also been working to get presenters lined up for July and August.  I’ll post more here and at when I have the final details worked out.

Tomorrow’s meeting is currently full, but if you are interested please join the group and RSVP for the June 15th meeting.

In addition to my speakers, I want thank Bill Zack and Peter Laudati from Microsoft, Daniel Chait and Daniel Simon from Lab 49, and Alex Hung, my colleague from ThoughtWorks, for their assistance helping me to reboot this group.

Wednesday, May 13, 2009

Catching Up

I apologize.  I've been a lazy blogger. 

I’ve had lots of ideas to write about, but I’ve taken a position at a new firm and I’ve been dedicating myself to my first project.

This project took me to Cincinnati every week, and so I’ve been learning how to settle into the life of a jet set consultant.

It sounds much more glamorous than it is.   I don’t mind the actual travel, navigating the airports and TSA.  I’m a seasoned traveler and know how to avoid most of the common pitfalls.  Mostly, I have just missed being in New York during the week to do things in the city, like catch a play that is only on a Monday night or attend the local user groups during the week.

The travel has also eaten up most of my free time.  What wasn’t taken by travel has been spent apartment hunting and moving.  My lease was up and rent prices are dropping in NYC for the first time since I moved here, so I wanted to find a place where I could save more.  Between trips, I was able to find a new apartment in Astoria and I have finished the move.  Although there are still a lot of boxes waiting to be put away, it is starting to come together finally.

My project in Cincinnati has ended and I am back in NYC, so I am planning to catch up with my backlog of posts, so don’t be surprised to see a sudden flurry of activity before I am assigned to my next project.

Sunday, January 18, 2009

More Oslo Goodness

If you found my previous post Oslo == 42 useful, I highly recommend that you read Dan Vanderboom's Why Oslo is Important.   In his post he goes into depth about his perspective on why Microsoft has built "Oslo".  Check it out!

Monday, December 1, 2008

Getting Started with Azure Services Platform, A Reprise

I was surprised to have a lot of visitors after my last post!  I will be returning to DSL's and Oslo soon, but for right now I'm focusing on Windows Azure, including the Live Services Framework.

I've been quiet the last couple of weeks because I've been busy digging into Azure Services, getting everything installed, going through walkthroughs, and browsing blogs and the forums to see how others are faring.  

I thought I'd post a few hints about a few minor false starts that I've seen that several have run into (including me).

Let's start from the very beginning...

First, make sure that you have all the requisites:

If you will be working with Azure Services, Live Services, and Oslo, you will eventually need all of these.  If you can't or won't install Vista or Server 2008 on your own machine, you can download an evaluation copy of Server 2008 and run it in a virtual machine.

Because IIS 7.0 strives to be secure by default, you will need to explicitly enable both ASP.NET and WCF Http Activation if you haven't already enabled them both.  If you are configuring a new machine or VM, it's easy to forget these.

If you have SQL Server 2005, you will have problems installing the Oslo repository like I did, so save yourself the time and start with the upgrade to SQL Server 2008 first.

A very good place to start

After you've got all of the requirements, then you can use my earlier post for links to most of the Azure SDK's.

This does not include the tools for the Live Services Framework.  You will need to wait until you have a valid Live Services token and then follow Angus Logan's screencast

If you follow his instructions you should be nearly golden.  There is only one small issue.  You won't be able to unzip the Live Services SDK directly to your %Program Files% folder.  This is a protected folder, so you need to unzip the SDK to an unprotected location first and move the files manually.


After you have all the tools installed, there are some good training tools to get you started.

Going through the hands-on labs in the Azure Services Training Kit I ran into a small glitch with WCF when I followed the instructions precisely.  Dominic Green had already worked out what piece didn't work and posted the answer here.

UPDATE:  There is another problem in the SQL Data Services Lab, which you can fix by following the instructions from Ryan Dunn in his post, Fixing the SDS HOL from Azure Training Kit.

As you can see, there is a ton of stuff to go through.  Hopefully with these tips you can get started more quickly without any hiccups.

Later This Week

Later this week I will be attending the Microsoft SOA Launch in New York and the Live Services Jumpstart in San Francisco.  I'm looking forward to learning more details about Azure, Live Services, "Oslo" and "Dublin" but also getting a chance to ask questions directly to Microsoft.   If you're going to be there, send me a note or a tweet and maybe we can chat.

Sunday, November 16, 2008

Oslo == 42

In Douglas Adams book The Hitchhiker's Guide to the Galaxy, he tells how a supercomputer named Deep Thought worked to calculate the answer to Life, the Universe, and Everything.  After 7½ million years, the supercomputer came up with the answer:  42.   Unfortunately, no one could understand the answer because they didn't know the question.

Some might argue that "Oslo" is Microsoft's answer to "life, the universe, and everything" IT-related, but now that it has been revealed, many developers are confused and left wondering what is the question that it solves.

One of the posts on the "Oslo" forums queries "Why do we need Oslo?"

Doug Purdy gave his answer on his blog this week:  Oslo v1 is about developer productivity.  If you watch his PDC talk, A Lap around "Oslo", he explains that Oslo is about capturing the essence of the code without the ceremony.

The bold purpose of "Oslo" is to enable capturing the intent of the business in terms that are equally clear to humans and to computers.

How does the "Oslo" modeling platform attempt to meet this objective? 

In a nutshell, "Oslo" attempts to provide developers and analysts with the tools to abstract their intent as data and stores this data so that it can be executed later.

A simple Example

While at my previous employer I was responsible for an application framework for a line of business application.  One of the features that we supported was the ability to create forms to display entity fields to the user. 

To do this, we separated the implementation of rendering the forms and controls from the business entities.   We had an XML file to store which fields should be displayed for each form.  It looked vaguely like this:

<form entity="Defect">
<field name="Defect Number"/>
<field name="Found By" />
<field name="Title" />
<field name="Description" />
<field name="Repro Scenario" />

We then had a forms engine that could use this XML file to render a web form to the user using the appropriate web controls based upon the data type of each field, similar to the Dynamic Data Controls in ASP.NET 3.5 SP1

This XML file was effectively a custom Domain Specific Language, and each XML document was our form model.  Each of these form models were stored either on the file system or in the database as our repository.  The application framework served as the execution engine for our form models.  We even had a form designer for laying out the various components of the form visually.

So what did this give us?

  • Developers could rapidly implement a new form-based UI more quickly than wiring up the ASP.NET controls manually.
  • Customers and Business Analysts could design their own custom forms and add them to the system.
  • We were looking at the possibility of transitioning to use Silverlight or a 3rd party web control library for a richer user experience.  If we did, we would only need to update the application framework and the form models could remain untouched.

This approach allowed us to have a better separation of concerns.  The form rendering logic was baked into our application framework, while the business logic about which fields should be displayed were separated and could evolve separately.

why "Oslo"?

If you have already been separating your "what" from your "how", as we did in our forms engine, what benefit do you get from "Oslo"?

  • Better tools to do what you're already doing
  • Less isolation and fewer silos of information
  • Better transparency into your models

Our XML model was fairly simple, yet with a large form, it still became cumbersome because of all of the XML noise.   Using "M" we could have written a terser DSL that captures the essence of our intent, without all the ceremony of the XML angle brackets.

For example, here's a model more friendly to developers:

form Defect
Defect Number,
Found By,
Repro Scenario

Or, if you want a more human readable grammar for your customers and business analysts:

Defect has a form with the following fields: Defect Number, Found By, Title, Description, and Repro Scenario.

If this were stored in the "Oslo" Repository, we might have been able to have designer that was richer and easier to implement with Quadrant, and we would be able to integrate with our entity designer, too, to see which fields were available for each entity type.

Finally, if the model were stored in the Repository, other tools might be able to better discover information about these forms. 

For example, if we rename "Repro Scenario" to just "Scenario", or remove "Found By" from our entity model, we could immediately detect which forms use these fields and update our form model appropriately.

But, if you're already doing declarative, model-driven design like this, you probably can already imagine many more useful scenarios that "Oslo" enables.

What if you have never looked at your code this way before? 

Well, this might seem like a lot of unnecessary overhead.  Is it really that hard to write good ASPX code, and how often do you really need to swap out your rendering engine?

Shawn Wildermouth gave his answer to the broader question, "Why do we need DSL's?", and I think his post explains why there is value in taking this approach.

Today, customers talk to business analysts, who might capture what they think that they heard in some UML model somewhere, maybe in Visio.  They might do mockups of screen shots with Photoshop of how the user experience should work.   They then pass this onto the architect or developer to implement, who implement what they understand the customer's intent to be.  

This is like an elaborate game of telephone, though, and there is bound to be misunderstanding somewhere along the way.

If you have a good team, your developer will get this right most of the time.  If you are using Agile, you will probably get it right more often because your developers will be talking to your customers directly, and you'll get feedback quicker when it is wrong, but you will still have waste. 

Model driven development offers the opportunity to allow the customer to express their intent directly and see the impact of their decisions immediately without being translated through many different layers.

If "Oslo" can succeed in their goals, there can be much more rapid development with much less waste, which should matter to anyone who cares about business value.

Should I start building my code with "Oslo" today?

That depends on you and your needs.  

The "Oslo" Team has a large vision, which cannot be fully accomplished in v1.   They will have plenty of work to do in future releases.  Even this is still early and "nascent" according to Don Box and Ray Ozzie.  "Oslo" is still raw and will probably change before v1.  If you need your tools to be fully baked, then it is too early for you to build on "Oslo".

If you are just now trying to understand how model driven development and DSL's can help you with your development, maybe it would be useful for you to download the tools and play with it so that you can begin to grasp how this is different or similar to how you do things today.  Try thinking about the problems that your current project has that might benefit from this mind set.

If you have already been using this approach, try out using the tools from Microsoft to see if they will help you do what you already do more easily.  Discover the gaps, if any, that would prevent you from using "Oslo".

When you are done give your feedback to Microsoft on the "Oslo" forum so that they can make the necessary changes so that v1 supports as many scenarios as possible and it lays a solid foundation for future releases.

Sunday, November 9, 2008

NYC Connected Systems User Group

Keith Pijanowski will speaking about Windows Azure and Software + Services tomorrow night at the NYC Connected Systems User Group.

I expect that his presentation will be similar to the one he gave a few weeks ago to the IASA New York group.  If you're interested in Microsoft's Azure Services Platform, you might want to sign up to attend.