Does the Single Responsibility Principle still apply in SOA? . . . YES!

In reading this blog post:

http://davidpallmann.spaces.live.com/blog/cns%21E95EF9DC3FDB978E%21257.entry

David asserts that a service contract should have a theme, and all the operations should fit in with the theme.  I couldn’t agree more, and it sounds remarkably like long-standing guidance found in the OO world. 

To summarize, SRP, or the Single Responsibility Principle:

. . . every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility

Service Oriented Architecture isn’t a wholesale shift from OO, but it’s a compliment that focuses on system-to-system interaction instead of object-to-object interaction, and the SRP holds true with this focus as well.

In software, we create units (whether they be systems or objects), and each unit does something over, and over, and over, and over.  In factories (think Ford), each unit (person) on the assembly line does something over, and over, and over.  Like Tom DeMarco, Ford found that the whole factory functioned better when every unit(object or person) had a single responsibility and performed that responsibility well.  So now, with SOA, each service should have a single responsibility and perform that responsibility well.

To expand this thought, perhaps the SRP can be applied to any situation where the tasks are known ahead of time and repeated exactly the same over, and over, and over.

Question to readers:  Are there situation in creating OO software (that might function within an SOA) where SRP does not or should not apply?

Subversion presentation available on GoogleCode

I’ve shared a presentation on source code with Subversion on my GoogleCode.  It covers how to use SVN for a project as well as recommendations for setting up the repository, tagging, and branching.

You can find it here:

svn co http://palermo.googlecode.com/svn/subversiondemo svndemo-trunk

Or if you just want the PPT, http://palermo.googlecode.com/svn/subversiondemo/trunk/Source%20Control%20fundamentals%20with%20Subversion.ppt

Demo on automating your build with NAnt and CCNet

I’ve prepared a presentation and demo of automating a build with NAnt and CCNet.  It uses Subversion for the trunk, and all you have to do is checkout the trunk and run the build.  You can check it out anonymously from the Google Code Subversion repository.

In order for this to work,

checkout http://palermo.googlecode.com/svn/automatedbuilddemo/trunk
svn checkout http://palermo.googlecode.com/svn/automatedbuilddemo/trunk demo-trunk

After getting the trunk, you’ll want to run “build.bat” from the command line.  Here are the dependencies:

  • .Net 2.0
  • SQL 2005 Express in a named instance “sqlexpress” – which is the default.

That’s it.  All other dependencies are included in the trunk.  This demo demonstrates how to create/update a database during a build, version, compile and test.  The tests include some unit tests and an integration test that test the database whose schema is created during the build.  Compilation is done by delegating to msbuild.exe from NAnt.

I’ve also attempted to include CCNet itself in the trunk, but there are still a few issues running CCNet from that location.

What are the Alt.Net principles? – my answer

I’ll be attending the AltNetConf.  Convenient for me that it’s in Austin, TX.  It’s an open space conference, and I consider it the founding conference of a conversation that is “Alt.Net”.  I’ll be proposing the topic: What are the Alt.Net principles?.

The definition of Alt.Net isn’t defined yet.  It’s not even at a point where I can explain what it is and actually have other agree with me.  

Since I know the guy who originally coined the term, I have some insight into what David meant, but I’m going to propose some principles that, together, should be the definition of Alt.Net.

First, Alt.Net inherits Agile, and IS Agile.  Therefore:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan 

Extended principles:

  • Excellence and quality
    In a world of wizard-generated, disposable software (disposed 2 years later by necessity, not choice), Alt.Net focuses us on excellence in the software we create.  While the world may pay for and accept software that lives for 2 years before becoming utterly unmaintainable, we don’t accept shoddy work.  We know that we can deliver high quality software faster than others can deliver low quality software, so we accept no less than the highest in quality.  We strive for excellence through solid engineering practices and a high level of software education.  Coincidentally, Extreme Programming helps in this area, but Alt.Net does not specifically _mean_ XP.
  • Alternative Vendors
    A  common theme in many .Net shops is they are “Microsoft” shops.  In other words, if it doesn’t come from Microsoft, they won’t use it.  This makes no sense.  Microsoft is not a large enough company to be the vendor to the whole world.  .Net is a great platform, and we as a community have chosen the platform and choose to participate in this segment of the industry.  We strongly believe that 3rd party vendors complement the .Net platform in a way that can contribute to excellent working software.  In fact, some 3rd party offerings are superior to Microsoft’s offering.  For instance, in a strive for excellence in an e-commerce website, a team may choose a mature O/R Mapper like NHibernate to accelerate team speed and produce a flexible data layer; however, Alt.Net does not _mean_ ORM.  Open source software is a source of excellent 3rd party alternatives built on the .Net platform, and it should be used over Microsoft alternatives when they contribute to excellence; however, Alt.Net does not _mean_ open source.
  • Joy in our work
    We know that we will produce better software if a team is motivated and morale is high; therefore, we use libraries, tools, and practices that add joy to the working environment.  We abandon or correct libraries, tools, and practices that make it a drag to work on the software.  For instance, many find that Visual Studio is a bit slow to work with and that adding Resharper to the IDE adds a high level of joy while working with .Net code; however, Alt.Net does not _mean_ Resharper.
  • Knowledge
    We know that we will never know everything there is to know.  We strive for a greater understanding of software through studying successes and failures of the past as well as the present.  We educate ourselves through many sources in order to bring the most value to our clients.  We keep up with other platforms, such as Java and Ruby, so that we can apply their good ideas to .Net development and increase the quality of our .Net software.  The technology is always changing, but the knowledge accumulates.  We know that the knowledge applies no matter how the technology changes.  With knowledge comes humility because without humility, knowledge would pass us by.

The above are principles, so they are intentionally abstract.  Below, I’ll list some items that are concrete.  These items apply the principles but are more directly applicable:

  • Read more than just MSDN magazine and MS Press.  Authors like Feathers, Fowler, Martin, Evans, etc have a lot to give (Knowledge)
  • Use Resharper.  It makes working with Visual Studio a (Joy).  But if another vendor comes along that does even better than JetBrains, consider switching
  • Use NUnit  over MSTest,  Subversion over TFS SCC,  Infragistics/Telerik over in-the-box controls,  RedGate over in-the-box SQL tools.  Each of these is a better alternative to that which Microsoft provides (Alternative Vendors).  Use NHibernate over hand-rolled stored procedures and especially over DataAdapter/DataSet, but if EntityFramework proves to actually be superior to NHibernate in a meaningful way, consider using it.
  • Use a responsible application architecture.  Don’t put everything in Page_Load like you see demonstrated at MSDN Events.  Use knowledge to create an application that can stand the test of time and not be rewritten every 2 years.  Deliver (high quality and excellence). 
  • Automate every repetitive task; builds, tests, deployments, etc – excellence and joy

The concrete examples could go on and on, and I hope AltNetConf produces a long list.  I’ll be interested in having my proposed principles accepted by the community there or revised into something better.  Either way, I’d like to get to a point where there is an accepted definition of Alt.Net.

VS 2003 development without going crazy

I’m doing a little work with a team on a Visual Studio.Net 2003 codebase that includes the goal of upgrading the codebase to .Net 2.0 (at which time it can be developed with VS2008 using “multi-targeting”.

Here are some points I had to recall that make developing with VS2003 not so bad

  • Resharper 2.0 works with VS2003 and make programming a joy.
  • VisualSVN integrates with VS2003 and helps me track what’s been modified through TortoiseSVN integration.
  • TortoiseSVN needs to be configured to use “_svn” directories instead of “.svn” directories to work with VS2003 web projects(see below)

Instead of re-checking out the entire trunk, you can run a shell command to rename all _svn directories to .svn recursively:

From http://ankhsvn.tigris.org/faq.html#XSLTsection126120121120:

Rename to _svn
@ECHO OFF
FOR /R %%f IN (.svn) DO IF EXIST "%%f" (
ATTRIB -h "%%f"
RENAME "%%f" _svn
)

Rename to .svn
@ECHO OFF
FOR /R %%f IN (_svn) DO IF EXIST "%%f" (
RENAME "%%f" .svn
ATTRIB +h "%%~pf.svn"
)

My recommended Subversion repository structure

I would recommend one line of versioning per repository for most cases.  Here is a sample trunk set up with a VS.Net solution.

root
– trunk
  – bin
    – nant
    – log4net
  – src
    – project 1
    – project 2
    – mysolution.sln
    – CommonAssemblyInfo.cs (for version number, etc)
  – automatedbuild.build
  – clickToBuild.bat
– tags
  – 1.0.0.1
  – 1.0.0.2
  – 1.0.0.3
  – 1.0.3.1
  – 1.0.3.2
  – 1.0.0.4
  – 1.0.0.5
– branches
  – 1.0.0.3-hotfix

TechEd 2007 DVD shipment includes podcasts

As all Tech Ed 2007 attendees know, 3 months after the conference, the sessions appear in the mail on several DVDs.  Last year, I jumped through a few hoops to convert the fragmented sessions files into a single *.wma file that could be played on my music player.  It was a bit frustrating.

This year, I was pleasantly surprised to find that all sessions on the DVDs come with an extra audio file (*.wma).  This means, I just drop the .wma into my music player with the rest of my podcast queue and listen on my commute, while mowing the lawn, etc.  Good show, Tech Ed committee!

Sharepoint is not a good development platform

What makes a good general-purpose development platform?



  • Easy to install

  • Easy to configure

  • Integrates well with simple tools

  • Easily extended to make simple tools

  • Easy to debug

  • Easy to create test automation

  • All configuration stores easily in source control

  • Others I’m forgetting

I’ve heard many times that Sharepoint can be used as a development platform.  Technically, that statement is correct, but there is so much friction involved with it, many get frustrated in the process.  Consider the dependencies:



  • Must run on a server OS, Not XP/Vista, Full Stop

After that one, I don’t see a need to go on.  In a team environment, every developer needs to have a dedicated development environment.  What does that mean?  Everything necessary to build and run the system fits on the developer workstation.  Why not run a server OS on the developer workstation?  Perhaps.  I’ve done it before, but there is other friction associated with that.  Why not use a server OS VM to run Sharepoint on the box?  Perhaps, but again, more friction.


A development environment should be a pleasure to work with, and that require minimizing friction.  The harder it is to make a batch file that completely builds, tests, and deploys the system, the harder it is to develop for that platform.


My purpose for this post isn’t to say that “Sharepoint sucks”, notice the worst I say is that it’s not a good development platform.  For content-management and list-based stores, it’s great, but as a development platform, there is plenty to be desired. 


In the comments below, astute reader clarify that Sharepoint excels as a content management system but not as a general development platform.  I would yield that point.  In fact it makes more sense to me for Microsoft to market the product for that niche and have users singing its praises than for Microsoft to present it as a higher level ASP.Net platform and have users (see comments below) lamenting the pain involved.