Astoria and Jasper: Old Ideas New Technology

October 18th, 2007 Comments
Microsoft .NET

SubSonic is an excellent open source DAL generation tool developed by Rob Conery that has been around for almost a year. In most cases SubSonic can just be added to your project, pointed to a databse, and you magically and immediately gain access to a rich and strongly typed object model that can be used to query and persist data to and from your relational data source.

SubSonic also has a cool feature called the REST handler that essentially allows one to use HTTP protocol as an interface to data stored in a back-end relational database. It is URI based and returns data back in XML format. This data can then be used by decoupled client applications as they see fit. If you have never looked at SubSonic, you owe it to yourself to checkout this very cool tool.

Recently Microsoft unveiled their plans to release similar features codenamed Astoria and Jasper with .NET framework 3.5 and Visual Studio 2008. The CTP of Astoria and Jasper are available for download from Microsoft.

Jasper is described by Microsoft as:

Project Jasper is geared towards iterative and agile development. You can
start interacting with the data in your database without having to create
mapping files or define classes. You can build user interfaces by naming
controls according to your model without worrying about binding code. Project
Jasper is also extensible, allowing you to provide your own business logic and
class model. Since Project Jasper is built on top of the ADO.NET Entity
Framework, it supports rich queries and complex mapping.

Pablo Castro, the mastermind behind Astoria describes it as:

The goal of Microsoft Codename Astoria is to enable applications to expose data as a data service that can be consumed by web clients within a corporate network and across the internet. The data service is reachable over HTTP, and URIs are used to identify the various pieces of information available through the service. Interactions with the data service happens in terms of HTTP verbs such as GET, POST, PUT and DELETE, and the data exchanged in those interactions is represented in simple formats such as XML and JSON.

The Astoria web site also includes sample online services that showcases how this new technology can be used. It also allows anyone with a Passport account to design and host their own experimental data services .

Microsoft Build Engine (MSBuild)

October 21st, 2006 Comments

Up until Visual Studio 2005 and .NET Framework 2.0, the actual build process of solution or project files was pretty much a black-box phenomenon for developers. With .NET Framework 2.0 and Visual Studio 2005, Microsoft unveiled its new build platform called MSBuild. MSBuild essentially provides a transparent build process through Visual Studio IDE, as well as allows developers to build projects and solutions from the command line. This allows us to fully customize our builds and create builds on machines where Visual Studio is not even installed.

On a recent team project I was using continuous integration or CI (an Agile practice) via CruiseControl.NET. It was a breeze to automatically build projects and solutions using MSBuild on our build server (a run-of-the-mill Dell workstation running Windows XP without Visual Studio 2005 installed) whenever someone checked-in any files to source control. This allowed us to be confident at all times that various pieces our distributed project integrate well. Moreover, since MSBuild can build projects and solutions from command line, I had some batch files setup that would build release versions of our projects, create setup files (using NSIS), archive older versions of setup files, and move new setup files to a network share where MIS / Operations folks could install the new version on the production server from.

In Visual Studio 2005, project and solution files are nothing more than MSBuild XML build scripts. This allows us full control over the build process. For example, in a web project, Visual Studio 2005 does not provide any user interface to modify pre and post build actions. However, since solution file is simply an MSBuild script, we can modify such actions manually by opening up the solution file in any text/XML editor.

MSBuild can perform several key tasks out of the box. Each task is essentially a unit of work (UOW) that contributes to the entire build process, e.g. copy files and folders, compile files, etc. If we ever require tasks that do not ship with MSBuild, we can always create custom tasks in any .NET language by simply implementing the ITask interface or deriving from the Task class.

In conclusion, MSBuild allows developers full control of the build process so that builds can be fully customized. This may not be so crucial in smaller projects, but for enterprise solutions that typically comprise of several projects and many dependencies, MSBuild is definitely a God-send!

ISP: Interface Segregation Principle

August 28th, 2006 Comments

The Interface Segregation Principle (ISP) deals with cohesion and is closely related to the Single Responsibility Principle (SRP). In Uncle Bob’s terms, the ISP states that:

Clients should not be forced to depend on methods that they do not use.

In other words, this principle states that if a class performs multiple functions that may be used by different client classes, then those functions should be seperated out into different interfaces according to their usage.

The idea behind this principle is to confine the aount of rework to only clients that use a certain interface, should the interface of a depended-upon class changes.

MSF Agile v4.0 Team Model

August 27th, 2006 Comments

Out of all the Agile methodologies I have studied so far (XP, Scrum, AUP, and MSF), I really like the fact that MSF provides a Team Model that goes into details about how project teams should be structured. While it may be obvious to some, I know from experience that properly structuring teams is not something that that comes naturally to many organizations. In fact some organizations have less success with agile only because of their ineffective team structures.
MSF Team Model is based on the following basic principles:

  • A team of peers with clear accountability, shared responsibility and open communications. Each role is accountable for a specific share of the quality of the overall solution.
  • Advocacy for all key constituencies that must be represented on a successful software project. Every perspective is represented to provide the checks and balances that prevent errors of omission and lopsided decisions.
  • Stretch to fit to the scale necessary for the specific project. Constituencies may be combined in small teams or further refined as teams scale for larger projects.

There are 7 advocacies that are represented in the MSF Agile Team Model. In my opinion it’s imperitive that these advocacies have proper representation in order to ensure success of a given project. Since MSF offers a stretch-to-fit approach, it’s possible to map these 7 advocacies into fewer role clusters as determined by the phyical size of the team.

Following are the advocacies and their respective focus as presented by the MSF Team Model:

Product Management

Goals

  • Understand, communicate, and ensure success from the standpoint of the economic customer requesting the solution.

Functional Areas

  • Marketing
  • Business Value
  • Customer Advocacy
  • Product Planning

Responsibilities

  • Acts as customer advocate
  • Drives shared project vision/scope
  • Manages customer requirements definition
  • Develops and maintains business case
  • Manages customer expectations
  • Drives features vs. schedule vs. resources tradeoff decisions
  • Manages marketing, evangelizing and public relations
  • Develops, maintains, and executes the communications plan

Program Management

Goals

  • Right solution is delivered at the right time and all expectations are understood, managed and met.
  • Deployed solution will meet qualities of service & business objectives, and be viable in the long term.

Functional Areas

  • Project Management
  • Solution Architecture
  • Process Assurance
  • Administrative Services

Responsibilities

  • Drives development process to ship product on time
  • Manages product design and specifications
  • Facilitates communication and negotiation within the team
  • Implements and ensures standards
  • Maintains the project schedule and reports project status
  • Drives implementation of critical trade-off decisions
  • Develops, maintains, and executes the project master plan and schedule
  • Drives and manages risk assessment and risk management

Development

Goals

  • Implementation, estimates, high quality maintainable code and unit tests.

Functional Areas

  • Technology Consulting
  • Implementation of Architecture and Design
  • Application Development

Responsibilities

  • Specifies the features of physical design
  • Estimates time and effort to complete each feature
  • Builds and/or supervises building of features
  • Prepares product for deployment
  • Provides technology subject matter expertise to the team

Quality Assurance

Goals

  • Ensure solution quality.

Functional Areas

  • Test Planning
  • Test Engineering
  • Test Reporting

Responsibilities

  • Ensures all issues are known
  • Develops testing strategy and plans
  • Conducts testing
  • Reports test results

Release/Operations

Goals

  • Timely readiness and compatibility of infrastructure.

Functional Areas

  • Infrastructure
  • Support
  • Operations
  • Commercial Release Management

Responsibilities

  • Act as advocate for operations, support and delivery channels
  • Manage procurement
  • Manage product deployment
  • Drive manageability and supportability trade-off decisions
  • Manage operations, support, and delivery channel relationships
  • Provide logistical support to the project team

User Experience

Goals

  • Provide user documentation and training
  • Understand and communicate users’ context, and ensure usability from user perspective

Functional Areas

  • Technical Communications
  • Training
  • Usability
  • Graphic Design
  • Internationalization
  • Accessibility

Responsibilities

  • Acts as user advocate on team
  • Manages user requirements definition
  • Designs and develops performance support systems
  • Drives usability and user performance enhancement trade-off decisions
  • Provides specifications for help features and files
  • Develops and provides user training