• defined parameters and return arguments;
• calling conventions;
• usage limitations.

For example, here's how a piece of Twitter REST API looks like:

• Twitter REST API Method: statuses update
• URL: http://twitter.com/statuses/update.format
• Formats: xml, json, rss, atom
• HTTP Method(s): POST
• Requires Authentication: true
• API rate limited: false
• Parameters: ...
• Response: ...

There are a few categorizations of APIs in the software development world.

Web APIs define interfaces for interacting with various web sites and services in the Internet. These APIs usually use Hypertext Transfer Protocol (HTTP) requests for passing around data represented in JavaScript Object Notation (JSON) or Extensible Markup Language (XML) formats.

Twitter REST API, mentioned above, is an example of such Web API.

Operating System APIs represent low-level methods exposed by the operating system (OS) that could be used by software applications to integrate with it. Windows API (or Win32) and POSIX definitions are among the most known examples.

Software APIs are usually exposed by software vendors willing to provide integration capabilities for their products.

Here's the simplest example of Virtual Machine - Windows 7 running Windows XP in a VM to provide backwards compatibility for the older applications:

Here's another example - Sun VirtualBox running Ubuntu x64 server within Windows 7:

These were the examples of Operating System Virtual Machines. Another type of VM is Application Virtual Machine, that runs applications and scripts in an isolated virtual environment. Examples of that would be Java VM or .NET Framework VM.

VMs and Software Development

Virtual Machines are getting very important and widely used these days. This happens due to the improvements in hardware and virtualization capabilities along with the numerous benefits offered by the technology.

Some of usage scenarios include:

• Quality Assurance teams get the ability to test applications, their deployments and upgrades more efficiently. Testers don't need to have multiple OS and installation configurations available any more. A set of VM files (that are easy to share) is a replacement for that.

  Additionally, it is quite easy to configure continuous integration to run actual integration tests within differet virtual machines (emulating various OS and setup configurations), thus providing a better code coverage and issue detection.

• Software Developers could try out latest changes and various multi-server deployment configurations within virtual development environments.

• Cloud service providers could sell finely-grained computing capacities to customers in form of the VM slices. Customer is able to configure his Virtual Machine any way he wants.

  Should they want to change hosting provider, they just need to move a single VM from one environment to another.

• For complex enterprise applications (spawning multiple machines and server roles) virtual machines provide high-level separation of concerns, simplifying software evolution and maintenance.

• It is really easy to launch multiple virtual machine clones from one VM file. This simplifies scaling and cloud bursting scenarios for organizations.

Related links:

• Virtual Machine on Wikipedia
• Development server meets virtualization
• Configuring Virtual Development Environment

Simply put, Agile Software Development is a group of software development methodologies that work quite well when:

• projects are not mission-critical;
• business requirements change extremely fast;
• there are great developers available;
• development teams are small;
• development culture and mentality favors self-organization and self-learning.

In other words, Agile works quite well in situations when some unique software project has to be delivered really fast in order to seize the market opportunity. This works because Agile software methodologies allow development teams to adapt quickly to the rapidly changing business requirements. This happens because of:

• short development iterations allowing to start getting feedback early in the project's life-cycle and incorporate it into the product fast by delivering working software repeatedly and in a timely manner;
• continuous integration helping to reduce development friction and improve quality of a rapidly developing project in self-organizing environment;
• feature-driven development focusing development on delivering features (functionality) bringing real business value to the client (and the project);
• lean software development laying out common principles for efficient software development process;
• eXtreme Programming pushing lightweight software development methodologies to the extreme.

Long-term planning (along with some other formalities of a totally controlled project management process) is mostly sacrificed in favor of the flexibility, fast delivery and self-organization. In such a situation we still have to maintain high quality of the project deliverables (while reducing the resource consumption). This is achieved with the help from:

• test-driven development - provides foundation for the Continuous Integration and facilitates change while maintaining stability of the software project;
• pair programming - improves code quality and allows to have more efficient knowledge sharing.

Related Links:

• Agile Software Development on Wikipedia
• Lean Software Development on Wikipedia
• Scrum on Wikipedia
• Planning poker on Wikipedia
• eXtreme Programming on ExtremeProgramming.com

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

Here's how it works.

Any program could be logically separated into distinct units (in object-oriented programming the smallest unit usually being a class). Developers, while coding these program units, also create tests for them (code blocks containing some assertions and expectations about units). These tests could be used to rapidly verify behavior of the code being tested.

When some other developer introduces new units or changes something in existing units, he can run all the tests available for the program and verify that everything is still operating as expected. Usually running unit tests is a fast operation (less than 30 seconds), so developers are encouraged to do that often.

Here's how unit test suite looks for the Lokad Shared Libraries project (running all 176 tests for the primary assembly takes just 3 seconds):

If unit tests indicate that something has gone wrong, then the root of these problems could be detected rather quickly (since failing tests point directly to the misbehaving unit).

Unit Testing is extremely important for software development, since delivering projects efficiently without unit testing is nearly impossible. There are software development practices depending on unit testing:

• Test-Driven Development (TDD) - software design method requiring developers to write tests before writing code (this may sound strange, but it works)
• Continuous Integration - software development practice that allows to isolate some bugs in time by automatically running unit tests after each change to the code.

There are some additional benefits of unit testing:

• it facilitates change - developers are encouraged to refactor and change code, since they have a way to rapidly verify that program units still behave as expected.
• a good unit test is living documentation for the code, since it describes how the code is expected to behave;
• unit test is a good way to communicate over issues in the code and distribute work between multiple developers.

It is important to keep in mind, that unit tests only facilitate change by testing individual code units. They do not guarantee that the entire program will be free from bugs.

Here's the simplest unit test in C#, using NUnit framework:

[TestFixture]
public class CalculatorTests
{

  [Test, ExpectedException(typeof(DivideByZeroException))]
  public void Divide_by_zero_should_throw_exception()
  {
    new Calculator().Divide(1, 0);
  }

  [Test]
  public void Adding_actually_works()
  {
    var result = new Calculator().Add(1, 15);
    Assert.AreEqual(16, result);
  }
}

As you can see, a unit test is simply a class that contains methods checking behavior of some Calculator class. This test class is sometimes also called test fixture or test suite. In this snippet above test methods are decorated with a special attributes that are used by NUnit framework to recognize them, run as needed (i.e.: within an automated build) and print results.

Although this unit test suite may look extremely simple, it does not have to stop there. Here are some advanced usage scenarios that simplify development of complex enterprise applications:

• setup a temporary database before unit tests start up and then check all data access routines against this sample database;
• have a test suite that executes every hour against methods in your web services, verifying that they are alive and processing data properly.
• use non-deterministic reproducible tests that verify behavior of your class in various unexpected situations, reporting back when something goes wrong;
• use unit testing framework to write code quality tests, that check and enforce some guidelines (i.e.: every controller class should be immutable and have name ending with Controller).

Related Links:

• Continuous Integration
• Test-Driven Development
• Using Lokad Rules to Simplify .NET Unit Tests
• How to Use SystemUtil to Write .NET Code With Testable Sleep and Time Calls
• Shortcuts for NUnit Exception Expectations
• Unit Testing on Wikipedia

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

The simplest usage of versioning is - you can easily go back to the previous working version of your files, should you mess something up with the latest changes.

Changes could range from fixing a typo in a text file up to a huge refactoring in a software project, spanning hundreds of files. Each change usually has name of the person introduced it, time of the change and an optional description message.

Version Control Systems became an essential part of software development due to the following benefits:

• collaboration - a team of developers (which could be distributed geographically) may be working on the same set of files at once without interrupting each other's work;
• change management - changes can be inspected, reviewed or rolled back as needed; if you need that App.config file the way it was on May 17, 2008 - no problem;
• tracking ownership - every change is associated with the name of the person, so we know whom to give kudos to or ask questions;
• tracking evolution - every change is associated with a short description, so you just need to pull a change log of some class to see how it evolved and who did what;
• branching - it is possible to create a copy (branch) of the entire project for some specific purpose (i.e.: prototyping or developing a fix for the important customer) without disrupting development workflow;
• continuous integration - ability to split evolution of a software project into incremental changes allows to run all sorts of checks and tests against each incremental change in a continuous manner.

Language

Common terms:

• Repository - database server that contains all files and their history.
• Working copy - local version of files on somebody's machine. It may contain local unversioned changes.
• Trunk - home folder for some project within the repository. It usually contains all the latest changes.
• History (or ChangeLog) - a list of changes that were done to a file or folder since it was created.
• Latest (or Head) - latest available version of some file or folder.
• Revision - another word that means current version of file or folder.

Common operations:

• Check out - first operation required to work with any repository. It involves creating working copy that mirrors some folder on the server (usually that's trunk).
• Commit (or Check In) - sending your local changes back to the server, so that other people can get them as well.
• Update - updating local working copy to have all the lasted changes that were committed to the server since the last time you've checked it.
• Revert - discard all your local changes to the working copy.
• Diff (or Change, Delta) - differences between two versions of the same file; or an operation involving actually looking up what was changed between two versions.
• Create patch - automatically create a file that describes all the changes that were done to the working copy (basically containing all diffs). Then these changes could be reviewed by somebody else and committed to the repository.

Advanced operations:

• Conflict - that happens when somebody else changed the file, while you were working on it locally.
• Resolve - to fix contradicting changes by reviewing and manually merging them (VCSs can automatically resolve majority of the conflicts).
• Tag - to place a human readable label on some revision (i.e.: when releasing a product); or a noun representing such a label.
• Branch - to start a separate line of development over some old revision (i.e.: when fixing bugs for the previously released version).
• Merge - bringing together changes from different sources (i.e.: when applying a bug fix from some branch to a trunk).

How it looks

Here's how usage of Version Control Systems looks like.

Checking out the trunk of Autofac IoC project:

Browsing through the revision history:

Looking at some revision in detail:

These screen-shots show TortoiseSVN, which is a widely-used open source software for accessing Subversion repositories. Here's the bigger picture featuring some popular Version Control Systems:

• Subversion - cross-platform open source VCS with great User Interface implementations (TortoiseSVN is the most known implementation for Windows shell integration).
• Git - open-source VCS for distributed development that does not require a central server, yet lacks a convenient UI.
• Mercurial - yet another distributed open source version control system which is less popular than Git (5 times less popular, if you trust Google).

Related Links:

• Continuous Integration
• Version Control System on Wikipedia

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

Once the produced code passes unit tests, it could be refactored and cleaned up. Developer will be able to ensure code staying stable in the process, by running unit tests frequently. Next iteration could be started afterwards.

Writing a test before the actual code and its refactoring helps to achieve higher quality, because:

• it forces developer to refine code contracts before working on the implementation;
• it forces developer to make and keep code easily testable. This requires loose coupling and a separation of cross-cutting concerns;
• presence of unit tests gives developers more psychological freedom to experiment with the code and refactor it; managers get lower risks related to introducing high-level changes to the project.

There are some limitations of the TDD:

• badly written or simply brittle tests can create a tremendous maintenance overhead and hinder any code evolution;
• complete code coverage by unit tests creates a false perception of security and may result in less QA than needed;
• unit tests written by the same developer tend to have similar blind spots that may actually require testing.

Unit Test Code Coverage

One of the most important metrics in the Test-Driven Development is unit test code coverage. It could be calculated automatically and indicates percentage of the code that is executed while unit tests are running.

Although code coverage does not indicate quality of the unit tests, it is still a good measure of code testability. It is a common practice to set a certain code coverage threshold (i.e.: 80%) and enforce it within the continuous integration scripts. This way, if a developer commits a significant amount of code without unit tests, this is likely to break the build, forcing him to concentrate on testing his code.

Test-Driven Development plays well along with Component-Driven Development, since both of these approaches favor doing design before the actual implementation.

Related links:

• Unit Testing
• Test-Driven Development on Wikipedia
• Testing MVC Controllers with Mock Containers
• Using Lokad Rules to Simplify .NET Unit Tests
• How to Use SystemUtil to Write .NET Code With Testable Sleep and Time Calls
• Shortcuts for NUnit Exception Expectations
• How to ensure that complex methods are covered with tests
• Writing .NET code analysis rules as unit tests

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

• Services are provided on-demand; customers can pay for them as they go, without the need to invest into a datacenter.
• Hardware management is abstracted from the customers.
• Infrastructure capacities are elastic and can easily scale up and down.

There is a powerful economic force behind this simple model: providing and consuming cloud computing services generally allows to have far more efficient resource utilization, compared to self-hosting and data center type of hosting.

This is especially true for bursting into cloud scenarios when cloud consumers use elasticity of the cloud services to handle any spikes they might get. More information is available in article Why is cloud computing important for us?.

Obviously, consuming raw hardware capacities may be too hardcore for some consumers that merely want to have a scalable storage. So it is natural that cloud computing services already got some diversity around them:

• Infrastructure as a Service (IaaS), where customer gets raw hardware resources (i.e.: virtual machines with OS of choice). Examples:

  • Amazon Elastic Compute Cloud - part of AWS that offers scalable Xen-based virtual machines.
  • Mosso - .NET or LAMP web sites, Storage and Linux-based virtual servers. People complain.

• Platform as a Service (PaaS), where service provider builds a platform to simplify solving some technological tasks. This simplifies life for the customer, but also comes with a lock-down cost. Some providers:

  • Microsoft Windows Azure - .NET driven and Microsoft-owned cloud infrastructure, which is behind Amazon in some areas.
  • Amazon Web Services - collection of scalable infrastructure pieces for building your cloud application.
  • Google App Engine - Python-based cloud framework.
  • Amazon Elastic Map Reduce - Apache Hadoop hosted on Amazon cloud services (EC2 and S3)

• Software as a Service (SaaS). At this level everything is way more simple for the customers to consume, since they are provided with actual services generating business value to them. Service providers handle all the technological complexity and provide the support as needed.

From the development perspective, cloud computing is a brand new field (which is especially true for the .NET world). So there are no established patterns and pactices in the field yet. However, common development guidelines tend to work quite well:

• Component-Driven Development with Inversion of Control Containers
• Test-Driven Development
• Continuous Integration for the projects
• Separation of Cross-Cutting Concerns

Related links:

• Cloud Computing article series
• Why is Cloud Computing important for us?
• Cloud computing: a personal review about Azure, Amazon, Google Engine, VMWare and the others by Joannes Vermorel
• Cloud Computing on Wikipedia

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

Simply put, Continuous Integration takes a lot of mundane and boring things away from the process of software development, while letting developers to concentrate on more enjoyable and creative tasks.

As the name implies, Continuous Integration is about integrating changes to the development project continuously and automatically. These changes usually come in form of modifications and additions to the source code. When we keep them as small as possible and automatically run all checks available (starting from the compilation process and up to the full test routines), we can detect most breaking issues whenever they are introduced. Since the changes are small, it is much easier to isolate and fix the root cause.

Continuous integration helps to achieve this by reducing development friction involved in project integration. This is done with the help of:

• Version Control Systems that allow large and distributed teams to work together on the same project, while sending their code changes (commits) to the central server. Each commit is stored on the server and could be reviewed or reverted.
• Build Automation that is basically about build tools and scripts that allow to start the complete integration build on a local machine with a single mouse-click.
• Unit Tests ensuring that code stays stable through all the changes (this normally comes with the Test-Driven Development practices).
• Code Quality Tests that consistently enforce development guidelines accepted by the team.
• Regular Commits by developers that reduce amount of change involved in every integration.
• Integrating Every Commit (as soon as it comes) on a central server allows to detect any compilation failures or broken tests immediately. Also this is the best way to deal with "but it works on my machine" problem.
• Publishing Integration Results that get created along with the build project might simplify getting feedback from people outside of the development team. Examples of these results are: unit test results, performance metrics, install packages, code quality reports etc.

From my personal experience, Continuous Integration is a must have in any single project that has a lifespan more than 200 human hours.

Here's the most simple example of CI benefits. When you have proper CI routine at hand, updating a customer with the latest fix (if the fix is in the desktop application, for example) is a mere matter of:

• write the code;
• test the code;
• commit the changes to the server, telling it to publish install packages along the way;
• tell customer to install the latest version (or simply restart the application, if you have autoupdate routine in the application).

Behind the scenes will happen:

• backing up a copy of changes;
• running full suite of tests against the entire codebase;
• computing code metrics and performance statistics;
• publishing development reports for the team;
• updating online documentation that is generated from the code;
• building the project and creating a new version of install package;
• creating a backup of this package (along with all the libraries and PDBs);
• putting install package to the deployment server and updating manifest needed for auto-updates;
• notifying all involved parties about the build and results.

Ability to take all this "behind the scenes" routine for granted definitely reduces development friction a bit, allowing to concentrate on more interesting and creative things.

Software Stack for Continuous Integration in .NET:

• Version Control Systems

  • Subversion (Open Source)
  • Git (Open Source)

• Unit Testing

  • NUnit (Open Source)
  • MBUnit (Open Source)
  • XUnit (Open Source)

• Build Automation

  • MSBuild
  • NAnt

• Continuous Integration Server

  • Cruise Control .NET (Open Source)

• Code Quality

  • Mono Gendarme (Open Source)
  • Microsoft FxCop

Related Links:

• Continuous Integration by Martin Fowler
• Continuous Integration on Wikipedia
• Some integration recipes for the efficient development
• Hunger for the integration builds.
• Recommendations on software and tools for the development
• Organization of xLim solutions: development, svn and integration
• Common development principles for xLim

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

Usage of Inversion of Control generally allows to create applications that are more flexible, unit-testable, simple and maintainable in the long run.

Consider the sample:

public class Car
{
  Engine _engine;

  public Car()
  {  
    _engine = new Engine();
  }
}

Here we have extremely strong dependency between Car and Engine. We actually, can't install any other engine inside, since Car controls instantiation of that Engine.

Let's open up the design a little bit:

public class Car
{
  IEngine _engine;

  public Car(IEngine engine)
  {
    _engine = engine;
  }
}

Now we have moved the control over the Engine creation outside of the Car and into the code that creates it. This is called Inversion of Control or IoC for short.

Often control over the dependency creation is delegated to specialized application blocks called Inversion of Control Containers. IoC containers are really good in determining dependencies that are needed to create a specific class and injecting them automatically. This process is often called Dependency Injection.

Consider the following example for Autofac IoC Container for .NET (there are many others as well):

// configuration that happens only once.
var builder = new ContainerBuilder();
builder.Register<Car>();
builder.Register<Engine>().As<IEngine>();

var container = builder.Build();

// somewhere in the code
var car = container.Resolve<Car>();

Inversion of Control and Dependency Injection can do much more than that. Check the links at the end of this article for more details.

Here are just some hints on what could be done without changing Car and Engine classes:

• automatically check IEngine for failures when it is plugged into the Car;
• write a log message every time we start the IEngine;
• plug-in a spare IEngine whenever the original engine fails;
• add a security check to prevent unauthorized driver from starting the Car.

Engine class from the example above could be called a component implementing IEngine service contract. Development approach that relies on separating code into composable and reusable components is called Component-Driven Development. It brings additional benefits in conjunction with IoC. One of these benefits is about injecting cross-cutting concerns that allows to avoid complex and repeatable code in a lot of scenarios.

Related links:

• Component-driven development and IoC Containers
• Autofac Inversion of Control Container for .NET
• Structuring .NET Applications with Autofac IoC
• What is Inversion of Control on StackOverflow
• Inversion of Control on Wikipedia.

List of popular IoC Containers for .NET:

(in the order of preference)

• Autofac
• Castle Windsor
• Unity
• StructureMap
• NInject
• Spring.NET

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

A component itself is a class that implements some service contract and explicitly defines the dependencies that it needs in order to fulfill this contract. Actual implementation is hidden from everybody else outside the component.

Component-driven development really helps to deliver multiple applications and systems efficiently. It happens because:

• important functionality is abstracted in components;
• components are coded and unit-tested only once;
• it is easy to reuse component in similar situations, reducing development effort and avoiding code duplication;
• every component has multiple use cases that provide additional feedback and help to find problems or limitations, if there are any;
• whenever a component is fixed or improved, all its consumers would benefit from that automatically.

As we go up in the complexity of the development, it becomes too cumbersome to manage components on the individual basis. That's where infrastructure shards come into the play. Infrastructure shard is a group of components used together in a similar manner to deliver certain functionality across multiple applications.

This scenario creates additional benefits for the component-driven development. Some synergy effects might include:

• Business functionality could be used to extend multiple applications. Since UI is shared, we could use shared documentation, tutorials and screenshots as well.
• Sometimes context requires infrastructure shard to be evolved. This brings potential improvements in all existing and new applications.
• When a group of components is developed to be used in multiple scenarios from the start, this polishes the overall design even further than TDD or CDD would alone.
• Localization or UI changes across the software product line become easier, since the effort does not have to be duplicated and tested in multiple codebases.

Related links:

• Component-Driven Development and IoC Containers
• Developing Component-Driven Applications powered by IoC Containers
• Infrastructure Shards and Optional Components
• What is Component-Driven Development on Stack Overflow