Ruby plug-in for Eclipse

I recently found out there is a Ruby plug-in for the Eclipse IDE: The "Ruby Development Tool."

Quick install instructions:

1. Start up Eclipse.
2. Help > Software Updates > Find and Install...
3. Select "Search for new features to install"
4. Click "Next"
5. Click "New Remote Site..."
6. Enter the URL of stable release branch is: http://updatesite.rubypeople.org/release
7. Click "OK"
8. Click "Finish"

Ruby Development Tool (RDT) web site: http://rubyeclipse.sourceforge.net/index.rdt.html

Article on using RDT: http://www-128.ibm.com/developerworks/opensource/library/os-rubyeclipse/

Count Perl Code

I've started working on a module to analyze perl code report of files, lines, packages, subroutines, etc.

A report could look like this:

% analyze.pl path/to/directory/of/perl/code

files:     39
lines:     15929
packages:  39
subs:      336

The module is (very tentively) named Perl::Code::Analyze and uses
Adam Kennedy's PPI module for the real work.

A (very) alpha version of the module is at
http://g5-imac.matisse.net/~matisse/Perl-Code-Analyze-0.01

Here's an example of a script that would use Perl::Code::Analyze
to produce the report shown above:


#!/usr/bin/perl

use strict;
use warnings;
use Perl::Code::Analyze;
my $analzyer = Perl::Code::Analyze->new;

my $analysis = $analzyer->analyze_files(@ARGV);

my $file_count = $analysis->file_count;
my $package_count = $analysis->package_count;
my $sub_count = $analysis->sub_count;
my $lines = $analysis->lines;

print <<"EOS";

files: $file_count
lines: $lines
packages: $package_count
subs: $sub_count

EOS

exit;


Apple releases Launchd as Open Source

Apple has released their launchd process manager under the Apache Open Source License (version 2.0)


Launchd combines most of the features of the venerable Unix cron and init facilities. You can use launchd to make sure a process is always running ("watchdogging"), to run jobs at specific times, to run jobs when/if a file appars in a specified directory, etc.

I cover the basics of launchd in my book, "Unix for Mac OS X Tiger", and ars technicha covers it in their Tiger review.

There is already a FreeBSD port of launchd.

Macscripter.net has an article describing how to use launchd with AppleScript to access a Flashdrive.

Mock Classes in Perl Unit Tests

UPDATE:
November 2, 2006: I finally released the Wrapper module described here on the CPAN system.

Today I added unit tests to a Perl module that uses the DBI module. My module, DBIx::Wrapper::VerySimple is one that I wrote years ago.

The tests use three tiny mock classes that take the place of the real DBI module. This allows the units tests to run in complete isolation from the actual DBI module.

Back when I wrote DBIx::Wrapper::VerySimple wasn't experienced enough to bother creating unit tests for my code. These days I create unit tests any time I create a new module for a project and sometimes for scripts as well.

The challenge in this case was that constructor method, DBIx::Wrapper::VerySimple->new() calls DBI->connect(), and I didn't want my unit tests to require connecting to an actual database. My solution is to have three tiny mock classes in my test code including a DBI.pm that the tests load before DBI::Wrapper can load the real DBI.pm.

Here's what my mock DBI.pm looks like:

#  Mock class - for testing only
package DBI;
use strict;
use warnings;

# warn 'Loading mock library ' . __FILE__;
my $MOCK_DBH_CLASS = 'DBI::Mock::dbh';

my %ARGS = ();

sub connect {
   my ( $class, @args ) = @_;
  my $fake_dbh = {};
   bless $fake_dbh, $MOCK_DBH_CLASS;
  $ARGS{$fake_dbh} = \@args;
  return $fake_dbh;
}
1;

My test script loads the mock DBI.pm and two other mock classes before DBI::Wrapper is loaded for testing. This way, when DBI::Wrapper is compiled my mock DBI.pm is used instead of the real one:

# Ensure that DBI::Wrapper loads our mock DBI.pm
use lib "$Bin/mock_lib";
use DBI;
use DBI::Mock::dbh;
use DBI::Mock::sth;

This approaches works very well, and I was able to create unit tests that intercept all the calls that DBI::Wrapper makes that would normally go to the real DBI, and my intercepting these I can check that DBI::Wrapper is passing the expected values to DBI. I am deliberately not testing the real DBI module which has its own extensive set of unit tests. I merely test that my module will make the expected calls to DBI.


More about DBI::Wrapper

The module is available online at http://www.matisse.net/perl-modules/DBI/Wrapper/
The version with the new unit tests is version 0.04.

From the README:

DBI::Wrapper is a simple module that provides a high-level interface
to the Perl DBI module. The provided methods are for fetching
a single record (returns a hash-ref), many records (returns
an array-ref of hash-refs), and for executing a non-select statement
(returns a result code).

The intention here is that your application will have much cleaner code,
so instead of writing:

$sql = 'SELECT name,address FROM $table WHERE zipcode=?';
$sth = $dbh->prepare($sql);
$rv  = $sth->execute($zipcode);
@found_rows;
while ( my $hash_ref = $sth->fetchrow_hashref ) {
push( @found_rows, $hash_ref );
}

You would write:

$sql = 'SELECT name,address FROM $table WHERE zipcode=?';
$found_rows = $wrapper->FetchAll($sql,$zipcode); # An array_ref of hash_refs

I wrote the my version of DBI::Wrapper several years ago after I got the idea from a co-worker when I was doing a gig at TechTV.

Compare BASIC, Ruby, Python, PHP, Perl, JavaScript, Lisp, False, Haskell etc.

Paul Bissex wrote three versions of a simple game, and posted it on E-Scribe news: http://e-scribe.com/news/193
Readers have contributes more versions.

Comparing Pair Programming to Solo Programming

Brian Slesinsky wrote recently comparing Pair Programming to Code Reviews and argues that Pair Programming is better. I agree with his reasoning. I also think we need more hard-data on comparison of pairing vs. solo programming. It is a multi-dimensional issue, involving at least:

• Total developer time spent.
• Code quality and increase/reduction in the cost of product quality (more bugs == higher cost.)
• Time-to-market. Two people spending 70 hours in parallel is faster to market than one person spending 100 hours.
• Personalities and social dynamics. People have widely differing and strong held feelings about pairing vs. solo programming.

Technorati Tags: agile, extreme programming, pair programming, programming, code review, software development, XP

How much eXtremism is too extreme?

Blain Buxton recently wrote about how Pair Programming all the time could be bad, and in general makes the case for not being extreme about being eXtreme.

I think the most important point Blaine makes is that one should always be focused on what is best for the process, not on adhering to any particular technique.

Technorati Tags: agile, extreme programming, pair programming, software development, XP