The Software Management Blog

What’s Test-Driven Development, anyway?

It still amuses me, after such a long time, to listen to people equating TDD to unit testing. But wait - in conversations and public forums, I’ve seen TDD and JUnit used interchangeably. Nothing wrong w/ the framework, of course. Plus, we know Kent Beck is working hard on v 4.7, so many new cool features are in the pipeline. But, whatever happened to the “other” tests - acceptance, functional, integration, database, performance, security and the myriad of special testing methods? From a value point, one can make the argument that automated acceptance tests are more effective in some cases than unit tests. Or, that functional tests can provide a better overall warm and fuzzy, if you need a little confidence before a release. Maybe, one [all-inclusive] test method is what we need to clear up the confusion

Scala - Replacement for Java?

Great blog post on Scala at http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html. After playing with the language for couple of months, it seems the concepts are really catching up with the developer community and the prospects of retiring Java a real possibility. The language is simple, elegant and potent. When combined with a strong user experience front like Adobe Flex it can really shine! I am excited about the possibilities.

Great Demo from the Xebia Labs Guys

Today we spent an hour with the build and deployment automation gurus over at http://www.xebialabs.com/ going in some depth on their enterprise deployment platform Deployit. It’s basically a Flex-based application for managing the deployment of highly complex JEE software into development, QA and production tiers. It does most of the daily tasks we’re all too familiar with, ranging from dropping an archive into a container to configuring various runtime parameters. What’s interesting about this particular product is the extensibility it comes with - you can write your own extensions in Java, Python or Jython, which is a great selling point for an integration obsessionist like myself. The fact that they wrote in Flex is also a great point, because it means usable UI without the pains of JavaScript/AJAX. I am looking forward to seeing more of the product in the near future.

Groovy and Grails Training in VA

You may have heard that Groovy was the fastest growing language of all times, attracting fans from around the world. OK, I made up the first part, but its true that bunch of cool people are coding lots of good stuff in Groovy these days. The language and process gurus Scott Davis and Andy Glover are teaching a 2-day Groovy and Grails course in Reston, VA. I wish I could attend as I am sure it will be informative and fun.

Agile 103: Continuous Integration and Agile Development

Compared to other disciplines, software engineering is still in its infancy and as such, it is undergoing significant transformations. This is a challenge because of the relentless innovation and ever changing standards; it is an opportunity because the low barriers of entry make it possible for virtually anyone with a computer to actively participate in the revolution and change course in significant ways.

Let’s take development methodologies for example. In the beginning of the century few people had heard of Agile development. Today, it is growing in popularity and adoption numbers suggest its value and effectiveness.

The Agile movement started largely out of necessity by looking at ways to increasing efficiency by reexamining the way people communicate and create software. The Agile model was explained as a collection of simple principles and practices. One of these practices is Continuous Integration (CI).

Continuous Integration (CI) is the practice of executing series of build steps in a scheduled or automated fashion. The build scripts may be run by a computer or a human; they can be automated or manual. The important thing is to run them often and provide the team with valuable feedback as soon as they need it.

CI can be defined as an umbrella practice enclosing sub-practices such as Continuous Builds, Continuous Database Integration, Continuous Unit Testing, Continuous Deployment, Continuous Functional Testing, Continuous Notifications, and Continuous Reporting. All of these are designed to shorten the time between the problem discovery and the solution. Agile teams can rely not only on the time-saving nature of automated builds, but also on the timely and accurate feedback. Depending on the CI configuration, when one of the steps fails the CI server may choose to continue or suspend further operation until the failure is taken care of.

The typical CI system starts with the compilation and packaging of the application. Any problems at this stage usually cause the CI cycle to fail and the system to notify the submitter or the entire team of the failure. Once the problems are fixed the CI server recompiles the source code and moves on to executing any Data Definition Language (DDL) and/or Data Manipulation Language (DML) scripts as part of the database integration step. This ensures the database gets synced with the source code and that any unit and functional tests that rely on the database changes execute properly. Depending on the server configuration unit test failures may or may not fail the CI cycle. If the application requires packaging and deployment, the CI server packages and deploys the archive into a container. After functional tests pass the CI server labels the source code with an automatically generated label. Finally, it generates a report of the integration cycle and notifies a list of recipients.

CI is an important practice for the Agile team. The CI system can provide feedback to all parties immediately after a problem is discovered. It can also generate valuable deployment artifacts and reports for various roles within the Agile team. Finally, the CI system brings teams closer to having the ability to plan faster and more frequent releases at the end of each iteration.

Way to go!

I’d like to take a moment to congratulate my friends Paul Duvall, Steve Matyas and Andrew Glover on their winning of the 2008 Jolt Awards in the technical books category for their exceptional work “Continuous Integration: Improving Software Quality and Reducing Risk“. It’s a well-deserved award for an exemplary book from which I learned a lot and one that I recommend to all of my clients. Good job guys, way to go!

PHP 101: Setting-up an Environment for Development and Debugging

After years of developing “enterprise” [read:big and bulky] software you are tired from the whole shebang J2EE/.NET and you are now looking for easy lightweight web development. PHP can be one of your choices.

How do you start? Easy, just follow these steps to quickly setup a development environment with all servers, IDE and a debugger. In a few quick steps you will be able to setup:

• XAMPP which comes with:
1. Apache
2. PHP 5.2.x
3. MySQL 5.0.45
4. Mercury Server (SMTP, FTP, etc.)
• Zend Studio for Eclipse

Let’s start:

1. Download XAMPP 1.6.5 for Windows from http://www.apachefriends.org/en/xampp-windows.html#641
2. Follow the intuitive setup wizard to install
3. Download Zend Studio for Eclipse from http://www.zend.com/en/products/studio/
4. Install Zend Studio
5. To enable the Zend Debugger first navigate to XAMPP_HOME\php\zendOptimizer\lib and create a new folder Debugger. Create a new folder php-5.2.x under Debugger.
6. Copy ZendStudio_HOME\plugins\ org.zend.php.debug.debugger.win32.x86_5.2.12.v20071210\ resources\php5\ZendDebugger.dll to XAMPP_HOME\php\zendOptimizer\lib\Debugger\php-5.2.x
7. Open XAMPP_HOME/apache/bin/php.ini and add disable the Zend Optimizer while enabling the Zend Debugger:
   
[Zend]
zend_extension_ts = "XAMPP_HOME\php\zendOptimizer\lib\ZendExtensionManager.dll"
;zend_extension_manager.optimizer_ts = "XAMPP_HOME\php\zendOptimizer\lib\Optimizer"
;zend_optimizer.enable_loader = 1
;zend_optimizer.optimization_level=15
;zend_optimizer.license_path = "XAMPP_HOME\php\zendOptimizer\lib"
zend_extension_manager.debug_server_ts = "XAMPP_HOME\php\zendOptimizer\lib\Debugger"
zend_debugger.allow_hosts = 127.0.0.1
zend_debugger.expose_remotely = always
8. To verify the debugger, navigate to http://localhost/xampp and click the phpinfo() link. You should see the Zend Debugger information on the page such as
This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend Technologies
with Zend Debugger v5.2.12, Copyright (c) 1999-2007, by Zend Technologies

9. In Zend Studio, create a PHP project or use the sample project to start debugging
10. Keep in mind that Zend Studio has two debugging modes: local and remote. In this example both are enabled. If you selected to install the Zend Firefox extension you can launch a debug session right from Firefox. Nifty.

Quick Tutorial: Installing Subversion on Linux

This tutorial explains how users with no root access can install Subversion onto a shared Linux server.

System specs:

• Linux 2.6.22 or higher
• Subversion 1.4.5
• Apache Portable Runtime (APR)
  • APR 0.9.17 - http://government-grants.org/mirrors/apache.org/apr/apr-0.9.17.tar.gz
  • APR-util 0.9.15 - http://government-grants.org/mirrors/apache.org/apr/apr-util-0.9.15.tar.gz
• neon - an HTTP and WebDAV client library - http://www.webdav.org/neon/neon-0.25.5.tar.gz

Step by step installation guide:

1. Start by checking the Linux version of the host to which you’re going to install Subversion

   # uname -a
   Linux myhost.com 2.6.22-9_1.BHsmp #1 SMP Fri Sep 28
   23:36:16 MDT 2007 x86_64 x86_64 x86_64 GNU/Linux
   

2. Install neon

   # wget http://www.webdav.org/neon/neon-0.25.5.tar.gz
   # tar -xzf neon-0.25.5.tar.gz
   # cd neon-0.25.5
   # ./configure --enable-shared --prefix=$HOME
   # make
   # make install
   

3. Install APR

   # wget http://government-grants.org/mirrors/apache.org/apr/apr-0.9.17.tar.gz
   # tar -xzf apr-0.9.17.tar.gz
   # cd apr-0.9.17
   #  ./configure --prefix=$HOME
   # make
   # make install
   

4. Install APR-util

   # wget http://government-grants.org/mirrors/apache.org/apr/apr-util-0.9.15.tar.gz
   # tar -xzf apr-util-0.9.15.tar.gz
   # cd apr-util-0.9.15
   # ./configure --prefix=$HOME --with-apr=$HOME
   # make
   # make install
   

5. Install Subversion

   # wget http://subversion.tigris.org/downloads/subversion-1.4.5.tar.gz
   # tar -xzf subversion-1.4.5.tar.gz
   # cd subversion-1.4.5
   #./configure --prefix=$HOME --without-berkeley-db --with-zlib --with-ssl
   # make
   # make install
   

6. Verify installation

   username @jacoozi.com [~]# svn --version
   svn, version 1.4.5 (r25188) compiled Jan 18 2008, 12:24:06
   Copyright (C) 2000-2006 CollabNet.
   Subversion is open source software, see http://subversion.tigris.org/
   This product includes software developed by CollabNet (http://www.Collab.Net/).
   The following repository access (RA) modules are available:
   * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
     - handles 'http' scheme
   * ra_svn : Module for accessing a repository using the svn network protocol.
     - handles 'svn' scheme
   * ra_local : Module for accessing a repository on local disk.
     - handles 'file' scheme
   

Agile 102: Continuous Integration Explained

One of the points in What is Continuous Integration (CI)? was the importance of having reliable automated build scripts and executing them often. CI can be seen as a natural extension of the Automated Builds practice since in most cases it relies on the presence of a set of ABS. A well-designed CI system encapsulates other sub-practices such as Continuous Builds, Continuous Database Integration, Continuous Unit Testing, Continuous Deployment, Continuous Functional Testing, Continuous Notifications, and Continuous Reporting. All of these are designed to shorten the time between the problem discovery and the problem solution. Agile teams can rely not only on the time-saving nature of automated asynchronous builds, but also on the timely and accurate feedback as a result of this type of CI.

Continuous Integration (CI) is an umbrella practice enclosing a sequence of logically related steps. Depending on the CI configuration, when one of the steps fails the CI server may choose to continue with the remaining steps or suspend any further operation until the failing step is fixed.

The typical CI system starts with the compilation and packaging of the application. Any problems at this stage will usually fail the CI cycle and the system will notify the submitter of the entire team of the failure. Once the problems are fixed the CI server will recompile and mode on to executing DDL and/or DML scripts as part of the database integration. This will ensure that the database will be up to date for the unit and functional tests that will follow. Assuming there are automated unit tests, the system will make sure to create test data and execute the unit tests in the suite. Depending on the server configuration unit test failures may or may not fail the CI cycle. In the next two steps the CI server will package and deploy the application. After all functional tests successfully pass, the CI server will label the code with an automatically generated label, it will notify a list of recipients and will generate a report of the integration cycle.

An Agile team can benefit from such a system in multiple ways. For one, the system can provide an immediate feedback to all parties shortly after a problem is discovered. Secondly, it can create valuable deployment artifacts and reports targeting different audiences within the Agile team.

One variation of the above diagram is if the CI server is configured to run code inspection tools as part of the CI cycle. Static analysis tools run from the CI server can generate reports on code metrics such as lines of code, test coverage, cyclomatic complexity, package coupling and dependencies, and can provide important data points for the entire team as to where the system stands in terms of code quality and architectural integrity.

A second variation of the diagram can happen when successful completion of the functional tests triggers a second deployment to another machine. Since the CI server knows it is a good build, this time it deploys to a user acceptance machine, targeting the customer directly. The advantage of redundant deploys is that semi-independent teams such the User Experience (UE) have a machine that always runs the latest good build.

Reference: This blog entry is derived from author’s own real-world experiences building CI systems and industry best practices. One of the leading sources for CI best practices is Addison-Wesley’s recently published Continuous Integration, a Martin Fowler Signature Series title, authored by Paul M. Duvall with Steve Matyas and Andy Glover.

ROI of Agile Development

Scott Sehlhorst at Tyner Blain has added an excellent article on ROI in Agile. Take a read!