reference architecture

Team Foundation Server (TFS) 2010 Branching Guide

The following guide is a very helpful resource. I recommend that you read it and determine the branching strategy that you want to use before you setup your team projects.

http://tfsbranchingguideiii.codeplex.com/

DbVisualizer - No install and uses JDBC drivers

DbVisualizer is a good tool if you want to access and navigate through your database using a graphical user interface.

It is a good solution if you don't have a tool installed to access and view your database. This is because it doesn't have to be installed, which means that you don't need local system administrator privileges to run it.

Also, because it uses JDBC drivers to connect to the database it is a good tool for validating your JDBC drivers if you are having issues connecting to the database from another application using the same JDBC drivers.

NuGet

NuGet is a free, open source developer focused package management system for the .NET platform intent on simplifying the process of incorporating third party libraries into a .NET application during development.

I haven’t used it but the example of incorporating ELMAH (a library that I use in almost all of my solutions) into a project hit home.

I will certainly give it a try on my next project.

Reuse Practices

Here are some key software development reuse practices:

• strong software architecture that provides framework for reuse activities
• software development process that promotes and controls reuse
• reuse more than just code; reuse at the architectural level
• practice domain engineering; develop reusable components at the domain level
• integrate reuse through all of the life cycle activities and the management of those activities
• use software tools that support reuse; modern IDEs along with supporting knowledge bases are very useful.
• organizational structure that facilitates partnering across project boundaries

Reuse can occur at many levels. Some of the levels, starting at the lowest level and working up are:

• code fragment (cut and past reusability)
• subroutine or function
• object (data and methods)
• component
• architecture
• business patterns
• packaged application frameworks

Effectively reusability doesn't just happen. It is a planned event that takes time and resources. A separate domain engineering and knowledge base is required to promote and push its use throughout the organization.

The problem with reusability is that it usually isn't cost effective until a component has been reused (with very little analysis or modification) 5 or 6 times. Designing components for reusability slows down the current design and implementation process and requires a domain engineering/knowledge sharing organization to support and carry-on the reuse efforts.

Reuse is most effective when it is tied to business or technical patterns. The lower the level that reuse occurs the smaller its payback. This is because the first four (4) levels that I listed above only affect the implementation or coding cycle. Architectural and business patterns and customized packaged applications cut across many more of the software development lifecycle (SDLC) cycles and therefore have a larger impact.

Why Every Brand Needs an Open API for Developers

 

Why Every Brand Needs an Open API for Developers

HTML5 Boilerplate Template

HTML5 Boilerplate is a HTML/CSS/JS template for a fast, robust and future-proof site.

I haven't used this yet but it looks interesting and promising.

Big Projects, Done Small - Computerworld

I agree with the premise of this ComputerWorld article by Frank Hayes - "propose big and build small".

Just make sure that you don't follow a huge waterfall methodology. This approach requires an agile methodology.

As you implement additional portions of the system you will have to revisit and refactor portions that you already finished. Don't stress out over this.

Change and release management are also important parts of making this approach work.

Evolving Database Design

The concept of the "golden" and immutable database schema makes me crazy.

Agile methodologies, like SCRUM, have been adopted by many development groups to account for the fact that a perfect and unchangeable requirements specification will never exist before programming begins.

However, a big impedance mismatch will threaten your efforts if the application's database schema is under the control of a separate DBA group that is following a traditional waterfall methodology. (Note that I am talking about the application's database schema and not enterprise data store schemas.)

Academically I have seen and discussed many different ways of dealing with the issues associated with database changes. Martin Fowler and Pramod Sadalage discuss many of these issues in "Evolutionary Database Design".

In practice I have favored individual developer database instances with data architecture/DBA review. Just as solution architects don't babysit each system design change I don't think that data architects or DBAs should either. Any issues related to a design change can be dealt with using regular reviews and subsequent re-factoring.

In this practice the database schema and build scripts are part of the solution. To get a local database instance to work with the developer just gets the latest solution from source control and runs the DB build script. If they need to make changes to the DB then these changes are made and tested locally by the developer and then finally checked into source control for the rest of the team. The developer who makes the DB changes is also responsible for making sure that any required code changes are also checked in at the same time. A communication mechanism needs to be put into place so that the rest of the team knows that they will need to update their database at their next integration point (i.e. source code get latest).

Depending upon the phase of development, changes may be made to the original schema and everyone will have to rebuild their database or changes will be implemented as alter scripts and everyone will only have to update their database. Once the system goes to production all modifications will need to be implemented as alter scripts.

Health Level 7 (HL7) Resource

InterfaceWare provides a good resource for the HL7 Standard v2.6.

Using this resource you can browse through the entire v2.6 of the HL7 standard. This includes messages, segments, and fields.

Windows Azure Application Security

Microsoft has released "Security Best Practices for Developing Windows Azure Applications".

This paper is a "must-read" if you are considering developing applications using Windows Azure. It is also helpful if you plan on developing applications in the cloud in general.

It contains the following sections:

• Overview of Windows Azure Security-Related Platform Services
• Designing More Secure Windows Azure Services
• Creating More Secure Windows Azure Applications
• Applying Microsoft Security Development Lifecycle (SDL) Practices to Windows Azure Applications

It also contains the following useful appendices:

• Windows Azure Deployment Security Threat Matrix
• Excerpt from the Windows Azure Partial Trust Policy Reference
• Using SDL-approved cryptography in Windows Azure Applications