The latest, greatest thing which has come into vogue and has everyone buzzing (well the buzz has been growing steadily for a few years now), is Ruby. On or off Rails, the word is out and its pioneers are raving that it’s the next best thing since sliced bread….or Java. Well, I love rubies; that is the “I was born in July and it’s my birthstone ruby.” I wasn’t sure how I would feel about the other Ruby, but seeing that July (and my birthday!) are approaching I was curious enough to see what this proclaimed “gem” is all about.

Ruby, created by Yukihiro “Matz” Matsumoto can best be described as a pure object-oriented programming language with a super elegant syntax that makes programming fun. Fun and elegant? Hence the name choice? Actually, Matz wanted to use a jewel name for his new Perl-inspired language so he named Ruby after a colleague’s birthstone…before even realizing that a pearl (June) precedes a ruby (July) in the birthstone calendar too.

So why should I learn another scripting language? This question is better warranted when looking at it through a Perl versus Ruby perspective. To start, since Ruby’s code base was originally borrowed from Perl, programmers can easily migrate over to Ruby. Ruby kept all that was best about Perl, added workable OO features, and improved and simplified the rest. Not only do programmers feel they get more satisfaction (and have more fun!) programming in Ruby, but learning and maintaining Ruby is far more functional. This Perl of Perl is making the transition of learning this new language easy to justify.

What about Python? Both Python and Ruby attempt to improve on Perl. Both have a similar feature set, similar programming styles, and both essentially serve the same purpose. Matz originally designed Ruby to be more object-oriented than Python, but in recent versions Python’s OO has become more extensive. Becaues of this the battleground between the two really isn’t over the language but more the web framework space. Ruby has Rails (RoR). Python has many…TurboGears, Pylons, Django, Zope – just to name a few – by the way, who came up with these names? In essence you have all these developers spreading themselves among Python’s cornucopia of frameworks. Can the Python myriad possibly keep up to pace with the innovations of Rails?

The hype that the Ruby community has created certainly is helping to distinguish its magnitude in the land of programming languages. Ruby is poised to become the next big thing…with Rails in position to overtake Java as the language of choice for the web tier. Love to love it or love to hate it; clearly Ruby has made tremendous strides and in the end its existence will be secure for some time to come.

In my last blog entry, I discussed Software Quality for Acquisition Valuation and identified that acquiring companies can negotiate lower valuations for software companies who do not follow early testing practices.

The positive corollary to how these practices affect acquisition valuation is that early testing practices have material impact of the value of software assets. In fact, early software quality practices add critical components that dramatically increase the value of software assets for an organization.

In software engineering, we think mostly about problems and solutions, leaving the questions of business value to our fellow executives. A simple illustration of what developers tend to do is shown below:

In traditional manufacturing, the business value of “process” is well understood. Even lay people can appreciate that the value of an automobile manufacturer is not in the ability to produce a single instance of a car. It is in the reliable and repeatable ability to create high-quality cars at a predictable cost.

The actual business value of source code is related to its ability to reliably produce quality executable programs as requirements evolve. A primary factor in valuing source code as an asset is its independence from the developer who authored it.

Early testing practices have appreciable positive impact on the quality of executable programs. But, much more than that, they add artifacts to the source repository, which help build independence from authorship.

Using continuous integration practices and ensuring that code complexity, test coverage, source dependency and other metrics are maintained at reasonable levels helps increase the value of the source code assets.

Many software organizations discuss strategies that include a sale of their organization to a larger entity. Shouldn’t the engineering team consider the impact of their process decisions on the evolving value of its source code?

Russ Olsen, a developer at Reston based FGM wrote an interesting piece on 5 best practices for writing a unit test. I especially like #4- Don’t write the War and Peace of test methods- how true!! Also too, long and complicated test methods usually point to long and complicated code under test.

I’ll be giving a presentation on code metrics at this year’s Software Test & Performance Conference in Boston on Thursday November 9th. In “Using code metrics for targeted code refactoring” I’ll be covering various complexity metrics (and the tools which determine them) and how these metrics can be exploited to uncover code in need of refactoring.

If you are attending this conference, stop by and say hi!

NAnt contains an impressive set of functions that can be used to get anything from the current working directory to determining whether a file exists to getting environment variables. The syntax is a bit unusual for a build script and the NAnt documentation is sparse on examples. The example below demonstrates the use of the NAnt Environment functions to get the environment variable values for the working machine.

<property name="ncover.console.exe"
 value="${environment::get-variable('NCOVER_HOME')}\NCover.Console.exe"/>
<property name="nunit.console.exe"
value="${environment::get-variable('NUNIT_HOME')}\bin\nunit-console.exe"/>

Imagine this scenario…

Jenn (Developer): “I’m experiencing a lot of problems testing on v1.3.1.b1 of the database using build 418”
Mike (DBA): “When using build 418, you should use v1.3.1.b2, but I also need to make a few changes to it first”
Jenn: “I just spent three hours for no reason”
Mike: “You should have asked me first”

Back in the early days of my career, I worked on quite a few projects that had a relatively efficient process for developing software. However, when it came to the database, we seemed to throw out all good judgment and retreat to the days without configuration management by using a “throw it over the wall” approach to managing the changes in the database. There was an understanding that the DBAs were doing “their thing” and we (the developers) were doing “our thing”. In those days, as developers, it was seldom that we could recreate the database on our machine using Data Definition Language (DDL) and Data Manipulation Language (DML) scripts because they either A) Did not create the DDL/DML scripts or B) Did not check them into the SCM repository. Instead, we would be at the whim of the DBA if we needed any kind of change to the database. The scenario above is based on my own experiences (the names have been changed to protect the no so innocent).

Fortunately, some of us have awoken to what we could have been doing all along: integrating our DDL and DML into our build process to ensure we are working off the same schema and test data as our fellow developers and DBAs.

To effectively integrate your database definition and manipulation into the build process, you must establish the following: DDL scripts, DML scripts, an SCM tool, a local database, and build script(s). Each is described in more detail below.

DDL
DDL is just a fancy acronym for SQL that creates your database schema. Typically, you will see code like this in a DDL script:
CREATE TABLE beer(name VARCHAR(50), brewer VARCHAR(50), date_received DATE);
DML
DML is another one of them highfalutin acronyms for SQL that means inserting, updating, and removing (etc.) data in your database. You’ll find this type of code in your DML:
INSERT INTO beer(name, brewer, date_received) VALUES ('Sam Adams Lager','Boston Beer Company','2005-12-09');
Just remember, we’re talking about test data here; you’re not going to be inserting millions of records into your local database. This is for another time and place.

SCM Tool
You need to manage your DDL and DML just like you would your source code, so you’ll need a source code management tool such as Subversion, ClearCase, Perforce or whatever you’re using at your shop. You will check in the DDL and DML scripts that will recreate your database schema and insert all of the test data.

Local Database
You need a local version of your database running so that your can run the DDL and DML scripts. If you are running this database on your developer workstation, you will probably want a lightweight version of your database so that you don’t degrade your machine’s performance. If you’re using Oracle, look into Oracle Express or McKoi as lightweight options. If you’re using SQL Server, then SQL Server Express is a viable option. If you’re using MySQL, you’re in luck, as you can use MySQL locally.

Build Scripts
Now that you’ve got your DDL/DML scripts, a local database, and you are managing your database scripts in your SCM tool, you’re ready for the final step: making your database definition/manipulation as a part of your build process. In makes no difference whether you are using Ant, NAnt, make or other build tool just as long as the script is run as part of a standard process of developing and building your software. An example in Ant and MySQL is listed below.

<target name="db:create-database" description="Create DB and Insert data">
  <echo>Creating database...</echo>
  <sql
    driver="com.mysql.jdbc.Driver"
    url="jdbc:mysql://localhost:3306/brewery"
    userid="sam"
    password="@d@ms"
    classpathref="db.lib.path"
    delimiter=";">
    <fileset file="${db.dir}/create-database.sql"/>
    <fileset file="${db.dir}/insert-data.sql"/>
  </sql>
</target>

By making it a part of your build script, you can run it often as part of a continuous integration process. You can add more advanced features such as incorporating database migration into the process to ensure that changes can easily be applied to an existing database. On the projects I have used this process, it encourages a more collaborative effort between the developers and DBAs and allows the developers to make simple or more complex changes to the database (depending on their experience) that may be used by others on the team. Just as you do with your source code builds, when the build breaks, it must become a priority to fix the broken build. If you’re not integrating your database scripts into your build process, I’d encourage you to try it out and see how it works for you.

I had the opportunity to hear Grady Booch speak many years ago and one thing he mentioned that always remained in my mind was his prediction that some day, in the future, developers would be able to debug applications via the UML. He left me dreaming of the day when I could step through code via a sequence diagram. It looks like someone’s done it! Check out jBixbe.

I’ve previously written about Fit, which is a testing platform (implemented in various languages from Java to C#) that facilitates communication between those who write requirements and those who turn them into executable code. Having dug deeply into the Java implementation many times before, I was eager to see how quickly I could get things working in Fit’s C# version– needless to say, the authors of Fit have managed to practically port the exact code into C#, making the learning curve for those coming from Java virtually non-existent.

I created a quick Trender class, which has simple logic for determining the trend of two numbers (i.e. either the pattern is increasing, decreasing, etc). I then created a simple column table and a corresponding ColumnFixture type, dubbed TrenderFixture.

For example, the column table is defined below with three columns- the first two corresponding to input values and the last column corresponding to the expected result.

The top row of the table defines the fixture which will be matched with the table’s data by Fit. In this case, Fit will attempt to find the TrenderFixture class in the fit.net_example namespace.

TrenderFixture, shown below, extends Fit’s ColumnFixture and has two public properties corresponding to the two input values from the table above. The class also defines a Trend method, which corresponds to the last column in the table above. This method is accordingly invoked with the first two row values. Internally, the Trend method then invokes the Trender class and returns the result, which Fit will compare to the expected result defined in the table.

using System;
using fit;

namespace myfit.example
{

 public class TrenderFixture : ColumnFixture
 {
  public double value1;
  public double value2;

  public string Trend()
  {
    return Trender.Trend(value1, value2);
  }
 }
}

Invoking the runFile executable (which is bundled with the Fit .NET distribution) with the familiar input file, output file and desired assembly will yield a green table if all goes well as shown below.

Fit is an excellent framework for bridging the communication gap that seems to divide developers from stakeholders and as you can see, it is extremely easy to use.

For more information on Fit, see “In pursuit of code quality: Resolve to get FIT”.