Software Development Automation

Wednesday, December 19, 2007 11:54:12 AM (Central Standard Time, UTC-06:00)

There is a new site that focus on software factories, domain specific languages and Visual Studio Extensibility.

http://sf.devrevolution.com/

Posted in  |  |Comments [0]     

Utilizing Software Factories in Software Development

Friday, June 08, 2007 6:46:06 AM (Central Standard Time, UTC-06:00)

Here is the presentation that I gave at the Twin Cities .NET user group last night.

UtilizingSoftwareFactoriesInSoftwareDevelopment.zip (655.03 KB)

6/8/2007 4:15 - The link has been updated and should work now.

Posted in  |  |Comments [1]     

MSDN Article - Smart Clients: Essential Requirements and Candidate Services

Tuesday, October 17, 2006 10:31:13 PM (Central Standard Time, UTC-06:00)

I collaborated on an article for Smart Client architecture called "Smart Clients: Essential Requirements and Candidate Services".  It was published out on MSDN not too long ago.  

Posted in  |Comments [0]     

DotNet HowTo Select Guides

Thursday, August 03, 2006 11:00:00 PM (Central Standard Time, UTC-06:00)
Wanted to quick bookmark this before I lost it.
 
 
Its an interesting site on what to think about when making decisions around designing specific areas of your application.

Posted in  |  |Comments [0]     

skyscrapr.net - Microsoft Architecture Site

Tuesday, June 06, 2006 11:00:00 PM (Central Standard Time, UTC-06:00)
Focused on the architect personas Microsoft has targeted for there certification program, the new site looks like it was launched without a lot of promotion.  Not sure why… but one thing I found interesting is that you are seeing Microsoft use the concept of persona a lot more to describe the audience they are targeting.  This site is an example of that, as is the roles( Architects, Developers, Testers and Database Professionals) they have defined for the different consumers of the Visual Studio.NET IDE.  They also got as granular as splitting up different developer types.
 
The concept is based on Alan Cooper's work and a basis of his Goal Directed Design, a process used to develop software.  It's an interesting process, I had a chance to use it back in 1998 when I worked on Orcas, a Long Term Care management application.  The UI looks somewhat dated now, but that screen shot was from 1997.  Everything was DHTML, Binary Behaviors and some ActiveX controls… using concepts of what many would call AJAX now. Its all about focusing on how the user will utilize the application.
 
 

Posted in  |Comments [0]     

Overview of Visual Studio Team System

Friday, March 03, 2006 12:00:00 AM (Central Standard Time, UTC-06:00)
The following is an overview of Visual Studio Team System and some of the benefits it brings to the table.  It’s a high level overview, but it may allows you to identify areas that you want to dig into.
 
 
You can also download it in pdf format:

IntroVSTS.pdf

Posted in  |  |Comments [0]     

Implementing the Singleton Pattern

Friday, February 17, 2006 9:11:59 AM (Central Standard Time, UTC-06:00)

Nice comparison of your options for creating a Singleton that is thread safe and pointing out what not to do.

http://www.yoda.arachsys.com/csharp/singleton.html

Posted in  |Comments [1]     

The Foundation of Design Patterns

Thursday, January 12, 2006 12:00:00 AM (Central Standard Time, UTC-06:00)
Since the popularity of design patterns in the mid to late 90's I have bounced back and forth between learning them and just being aware of them.  I bought a Java based book (Head First Design Patterns) on a recommendation of a friend (Ed Ferron) of mine last summer.  
 
I spent the next couple of weeks perusing through it.  One thing that dawned on me was that all design patterns have the core principals that many of us use everyday (or should use) to design and write software.  Forget the names for right now… all of these named/referenced patterns are based on core principals.  Many of these concepts have become engrained in how we do stuff.  The founders of design patterns combine these principals to solve common problems, and then give them names for reference.  These principals are identified in different ways through out the book, but really aren't compiled into one area.  The compilation of these principals is as follows:

Use Abstraction 
  • Identify the aspects of your application that vary and separate them from what stays the same.
 
Interfaces
  • Program to an interface not an implementation.
 
Favor Composition Over Inheritance
  • Encapsulate a family of algorithms into their own set of classes.
    1. Allows you set behavior at run-time as long you program to an interface.
 
Dependency Inversion
  • Depend upon Abstractions. Do not depend upon concrete classes.
  • High Level Components should not depend on low level components, rather they should depend on abstractions.
 
Guidelines for following principle:
    1. No variable should hold a reference to the concrete class.
    2. No class should derive from a concrete class (derive from an interface or abstract class).
    3. No method should override an implemented method of any of its base classes.  If you override, then your base class wasn't really an abstraction to begin with.  These methods are meant to be shared with your subclasses
       
Open/Closed Principles
  • Classes should be open for extension and closed for modification.
    1. Altering existing code that has been tested and is virtually bug free can be expensive.

Principle of Least Knowledge
  • When designing a class, be careful of the number of classes it interacts with.  There are a number of problems that arise if you are not careful.
    1. Creates heavy coupling among the implementation.
    2. Many dependencies create a fragile system that will be costly to maintain and complex for others to understand.
         
Guidelines for following principle:
  1. Only invoke methods on:
    • the object itself.
    • an object passed in as a parameter to the method.
    • any object the method creates or instantiates.
    • any components of the object.
       
Circular Dependencies   
  • Dependency rot happens when you have high-level components, depending on low-level components, depending on high-level components.
 
Guidelines for following principle:
  1. Low level components never call high level components.
  2. High level components determine when low level components are needed.          
     
Single Responsibility Principle
  • Classes should have only one reason to change.
  • Assign each responsibility to one and only one class.
 
Guidelines for following principle:
Classes that adhere to the principle tend to have high cohesion and are more maintainable then classes that take on multiple responsibilities.
 
High Cohesion --> a class designed around a set of related functions.
Low Cohesion --> a class designed around unrelated functions.
 
My point is… maybe I don't really have to memorize all of them… I can continue to just look them up when they come up in design reviews.  The key is to understanding the underlying principles they are based on and how those principles are accomplished.
     

Posted in  |Comments [0]     

Contract First Web Service Development

Thursday, November 18, 2004 12:00:00 AM (Central Standard Time, UTC-06:00)
I have a heard a lot of buzz about contract first development as of late.  I first heard about it from Ed Ferron and Matt Milner after they returned from their PluralSight training in the beginning of November.
 
Aaron Skonnard and Don Box have brought it up in their blogs.
 
I Googled it and found a reference to it on MSDN that was published late October.  It that was co-authored by James Duff, Eric Cherng both of Vertigo Software (the folks that brought us PetShop) and Dino Chiesa of Microsoft.
 
The concept of Contract First development comes down to taking more control over how the .NET Framework handles the creation of your web service contract (WSDL) that clients consume.  If you don't need the control, then you don't need to take on the additional complexity of hand modifying your WSDL.  As many have mentioned, the tool sets for creating WSDL are not there yet.
 
So when do you need that control?  Interop with other platforms seems to be the most popular instance, as the fidelity of data types my not translate well into other platforms.  By taking control of the contract, you can describe in more detail how to represent a type that may not have a direct equivalent in another platform. 
 
Another instance is working in BizTalk, which requires the schema of messages to be defined first.  I just finished a SOA project that included BizTalk as a component of the implementation.  We did a type of Contract First development, but not exactly the way it is described in the MSDN article.  We designed the way we wanted our messages to look by laying them out in xml.  Then converted them to a type, and from the type created our schemas which then was consumed by BizTalk and our web services.  The MSDN article suggests having the Xml Web Services framework  generate the wsdl for you, then modify the wsdl to meet the needs of interop and generate the types from that.
 
One of the things we really struggled with was getting the xsd.exe to produce the class structures we wanted.  We ended up abandoning the tool pretty early, looked at alternatives (Dingo, XsdTidy, SchemaTron, and modifying the xsd.exe source), but ended up writing an implementation that would take an xml document and create the class structure, gets/sets for properties and strongly typed collections we were looking for.
 
The folks at thinktecure have created an IDE add-in (WsContractFirst) that takes a wsdl and creates the proxy and server side classes based on your modified wsdl contract.

Posted in  |  |Comments [1]