XP: Continuous Integration

Good paper by Martin Fowler of ThoughtWorks regarding Continuous Integration philosophy. While a mainstream technique, good to see the technical rational written down by a developer of CruiseControl.

Here are his talking points. Our team needs improvement on automated testing.

• Maintain a Single Source Repository
• Automate the Build
• Make Your Build Self-Testing
• Everyone Commits To the Mainline Every Day
• Every Commit Should Build the Mainline on an Integration Machine
• Keep the Build Fast
• Test in a Clone of the Production Environment
• Make it Easy for Anyone to Get the Latest Executable
• Everyone can see what's happening
• Automate Deployment

Concepts: SCRUM

Scrum in less than 10 minutes.



my short outline

• I. Team Members

• a. Production owner
• b. Scrum Master
• c. Developers
• d. Testers
• e. Customers
• f. Executives

• II. Release Planning

• a. Product Backlog - wish list
• b. Release Backlog
• c. Sprint Backlog - create an estimate for each sprint
• 1. sprints - short duration milestones - 2 to 30 days
• d. Burndown Chart - day by day measure of amount of work remaining
• e. Bugs - Track bugs separately from features
• f. Daily Scrums

Design Patterns: Naming Conventions

Microsoft's Guidelines for naming conventions. At first glance, naming guidelines seem unnecessary (a variable is variable). However, after working on various legacy projects, anything that improves readability and understanding is a good thing.

The most basic concepts are the capitalization names:

1. Pascal - The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. Used for class names, property names, method names, and events. example BackColor
2. Camel - The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized. Used for parameter names. example backColor
3. Hungarian - including a prefix in order to encode some metadata, such as the data type, about the parameter. Should not be used. example stringBackColor

Framework: .NET Dynamic Versus Static Typed Languages

This MSDN article discusses the new C# 4.0 "dynamic" keyword, but also helps illustrate dynamic versus static typing in .NET.

Short notes:

1. Dynamic languages don't perform compile-time type checks and identify the type of objects at run time only. Code is faster and easier to write, but doesn't give the benefit of compile time errors.
2. VB.Net can be made to be more strongly typed by including the "Option Strict" setting.
3. While the level describing how strongly typed a language is certainly relative, a good definition I found in Stack Overflow is "if I can concatenate a string and an integer without casting then it's not strongly typed."

Design Patterns: Cohesion And Coupling

Posting a few articles regarding basic design frameworks and patterns. This one is from MSDN Magazine regarding cohesion and coupling.

1. Decrease Coupling - Aspire to design loosely coupled classes or class which are not dependent on one another.
2. Eliminate Inappropriate Intimacy - Careful with business logic class which needs too much information regarding data access.
3. Increase Cohesion - Make the code inside a class directly related.

Observation of decrease coupling/increase cohesion creates these positive benefits:

• Keep things that have to change together as close together in the code as possible.
• Allow unrelated things in the code to change independently.
• Minimize duplication in the code.

RSS: .NET Syndication Feeds

Need to perform this task for creating RSS feeds in the near future. Keep this article in mind for the helper classes within the .NET framework.

.NET Debugging: IL Disassembler

Learned a helpful new debugging and troubleshooting tool today with the .NET Framework IL Disassembler. The simple application shows classes and even method signatures inside a compiled DLL.

This article goes further into understanding the various intermediate language operations as well as advanced switches.