Virtual Surreality
It’s too real to be true

My colleague Jay Fields recently blogged about the value of test names.

We had a little discussion about it yesterday on IM. Here’s a summary.

Josh Graham

I feel the test name is important for two reasons:
1) it is intentional programming - a neural pathway is established in your brain as you write the name of the test method so your mind tries to think about what the hell you are trying to achieve by doing all that typing
2) for those test consumers you speak of to get a sense of the behaviour of the system as specified by the stories and high level acceptance criteria

Jay Fields

2) [is] fair enough. Before introducing expectations on any client project I’ve brought it up as “what do you think about” and let the team decide. The last thing I want is an idea to be branded as bad because the wrong ppl used it
1) I think is based on the person. I always found it 10 times harder to write a sentence, I just want to get to the code but, I’m crazy for making the code intention revealing

Josh Graham

Picking a reasonable moniker for the test name is useful too, when something breaks (particularly if it occurs often)… “That #$%#$%! shouldRejectLostOrStolenCard test is failing again - must be the clearing house API has changed or they’ve crashed once more”.

Jay Fields

yeah, that’s an interesting point
wish you would have replied with that one, I’d have put it in my entry

We then talked about how to attach a moniker to the test on different languages - method names in Java being the easiest, while anonymous inner classes being a way to do so without having a moniker (other than perhaps a comment) at all.

I still contended that a method was a reasonable level of granularity to contain a test and use the method name as the moniker. A method (it’s declaration and its body) is location independent - it can be moved around in its module and you can still find it and its moniker appears in the abstract syntax tree so it’s very easy to find when using an editor that maintains an AST.

Jay’s responses to my scenarios in which this proves useful assume a short TDD cycle and also good developers.

So, while the test name may be superfluous in some cases, I don’t mind the extra mental effort of summarising the intent of the test into its name - and if that is overly difficult or not needed (both of which are plausible) then a banal label like enclosing the test in a method called “test1″ is a small price for me to package it up in a manageable, easy-to-find chunk.

YMMV.

My CTO, Rebecca Parsons, announced the publication of the ThoughtWorks Anthology a few days ago:

I am thrilled to announce that the ThoughtWorks Anthology is now ON SALE!

http://www.pragprog.com/titles/twa

There are essays by Roy and Michael Robinson, Martin, Neal Ford, Tiffany Lentz, Stelios Pantazopoulos, Ian Robinson, Erik Doernenburg, Kristan Vingrys and James Bull, as well as ex-TWers Dave Farley, Jeff Bay and Julian Simpson. (And of course your’s truly made her own contribution). Mike Aguilar wrote the introduction.

Some comments that appear in the book:

Jim Fischer writes, “The anthology provides a peek into the diversity of views and perspectives held by a company that dares to take on the long-accepted tenet of the IT industry that custom software is too hard and too costly.”

Big Dave Thomas writes, “Software is in many ways a team sport, and the leaders shape the software culture. Often successful organizations don’t take the time to document them, and hence others don’t benefit from them. This interesting collection of personal essays gives a glimpse into the culture of ThoughtWorks through some of its leaders.”

I’m really excited that this project has come to fruition and I hope you all enjoy what you see.

Rebecca

I was lucky enough to review the content earlier this year. It’s a keeper.

UPDATE: Some press… http://www.sys-con.com/read/541124.htm

After a meeting of the office of the CTO, most of us stayed around in our San Francisco office for a few days to do some podcasts and to participate in a Code Jam for Inveneo, a not-for-profit who provide computers and connectivity to developing countries (especially their schools, hospitals, and poorer villages).

They install a server in, say, a hospital with a few lower-powered, custom desktops (almost iMac in configuration). These, as well as the servers, can run off solar panels for power.

We were presented with a worthwhile problem with a number of interesting constraints:

• Low-power server running Ubuntu, with two small SATA hard disks in a Linux software RAID-1 array
• VMWare images of the servers for testing
• Python, bash, mdadm, and beep as our “programming languages”

When a RAID array fails, we need to alert any (if any) humans who are near the server. This can be interesting as the only things nearby might be the tree it is mounted in with a long-range WiFi, or the goat who uses it as a heat source at night. This means that any alert should be sufficiently frequent and annoying for the locals to contact someone who can let the support technician know. The conflict is that it also might be the nurses in their office at the hospital who have work to do and don’t want to be disturbed.

The solution was to use the PC speaker to beep. We can control the pitch and duration of the beep. Some combinations sounded too much like an ECG machine so that was no good. In the end, we chose a simple rising scale that would sound odd in any environment (except, perhaps, in a Mike Oldfield recording). This is repeated by default every 30 minutes.

We also had to send an email to the support technician. This doesn’t work when the server doesn’t actually have any connectivity (as some are used only as a local communications hub), or when connectivity is unreliable. Even then, many of the technicians are hours or even days away from the servers.

As many of the technicians aren’t particularly technical, we also had help by identifying which of the two disks had failed and allow them to simply change the one labelled “Disk 1″ or “Disk 2″. Serial numbers are good for this but VM hard disks don’t have serial numbers (I think that’s a feature request to both VMWare and Parallels).

We had Jeff Wishnie from Inveneo as the customer, Anda Abramovici as IM, Jonny Leroy as BA, Paul Hammant and Chad Wathington as QA, and the star developer crew of Drew Olson, Sammy Zahabi, Ola Bini, Erik Doernenburg and your’s truly. We quickly learned the following:

• The skills we needed (and had, just a little rusty) were more along the lines of Unix devices, shell, ASCII control characters, and simulation
• Python sucks (a bad tradesman blames his tools? perhaps - but it still sucks)

Anyway, we got most of what we wanted done in the time, and given the context, more than we anticipated. But we all would have liked to get a lot more done and would have if we were using our tools of choice (which are chosen for very good reasons).

Nonetheless, we’re doing it for the kids and it was great!

What a buzz. Super Agile. Super Fun. Go Inveneo, you rock!!

Charles Nutter has just written up a nice summary of the things in Thomas Enebo’s announcement of RC2 of JRuby 1.1

He talks in general about the astoundingly improved performance characteristics, particularly when compared to the Ruby 1.8.6 and 1.9 native interpreters, as well as the better use of JVM resources. Let alone the 260 bug fixes since RC1.

There’ll be more from me soon about our commercial experiences with JRuby and hopefully give you some fuel for introducing Ruby into your large, conservative corporate environment. I have to say, going back 2 years and thinking about the “enterprise readiness” of Ruby, things have changed a lot - almost exclusively due to the work done on JRuby. The pace at which the JRuby team work to address issues and improve the platform is outstanding, and puts commercial software vendors (particularly those hawking development tools) to shame. Things also have a long way to go - there are many, many solutions that would still be recommended around a recent version C# / .NET or Java implementation and that doesn’t look like changing for some time. The team behind JRuby is multi-skilled and very aware of innovations in other languages and platforms and I think this is one of their key success factors.

If you are evenly remotely interested in working on an OSS project, I encourage you to contribute to JRuby, even if it’s just to identify a problem to be fixed - it’s fun, it’s a great community, you’ll learn a lot about Ruby and the JVM, and you’ll work with some of the best guys in the business.

I suppose we Aussies might give up too easily, Ola

Antonio Cangiano let everyone else who isn’t on the list know the disappointing news from earlier this afternoon.

Nonetheless, stalwarts like M. David Peterson (happy birthday!, you’re still younger than me) and Ted Neward (and others who want to see a CLR and/or community-based implementation) may continue the work.

Language ninja, Ola Bini made a remark that Ruby was strongly-typed. Without confusing “strong” with “static”, this still made me pause.

I knew it was type-safe. I knew it was dynamically-typed. I knew it used Duck typing. I didn’t think about it in terms of strong types. I suppose arithmetic exceptions and array-bounds checking make a language strongly typed (and we all like that) but I would have put this more into the “type-safe” category.

What I didn’t think about so much is that Ruby does also raise type conversion exceptions and it raises exceptions if the object (ultimately) doesn’t accept the message it is sent (two other important aspects to what most people mean by “strongly typed”). It’s obvious - and if you’ve ever tried to add a number to a string, or vice versa, in Ruby then you have met the strong typing of Ruby.

Eli Bendersky has a good taxonomy of typing systems which I encourage you to read (as well as the comments).

I now figure that Ruby is strongly-typed just as long as you don’t do anything to weaken it. At least from the Ruby user’s (the application programmer) point of view. As Ola pointed out on #jruby, “but manipulating it can’t crash the underlying implementation (in a perfect world, of course)”. This means that while the following adds apparent weak typing, it doesn’t actually corrupt the Ruby runtime to remove the strong typing protections it has built in.

Adam Glasgall also on #jruby pointed out that he thinks of strong typing as “every value has a type, and that type doesn’t change”. There wasn’t consensus about the latter phrase (it is also a little ambiguous), and even so it doesn’t seem to truly apply to Ruby.

Operations on incompatible types

x = 5
y = "42"
x + y  # => TypeError: String can't be coerced into Fixnum
y + x  # => TypeError: can't convert Fixnum into String

Open classes and operator overloading weaken this, though.

class String
  alias old_add +

  def + (other)
    begin
      self.old_add other
    rescue TypeError
      self.old_add other.to_s
    end
  end
end

y + x  # => "425"

With some appropriate patching of the usual types, you could have the implicit Perl-like coercion in Ruby. Do you reallly want it? Perhaps not.

The important thing is that unless you do something explicit to weaken it, the Ruby runtime will strongly enforce the checking of operations on incompatible types.

Unknown messages

x.foobar  # => NoMethodError: undefined method `foobar' for 5:Fixnum

Again, open classes help weaken this, as does the method_missing method.

class Fixnum
  def method_missing (methId)
  end
end

x.foobar  # => nil

So, as long as you have a special method_missing method defined, you can weaken the rejection of unknown messages too. You could have an empty method_missing on Object and weaken this feature too.

The important thing is that unless you do something explicit to weaken it, the Ruby runtime will strongly enforce the checking of acceptable messages for a type.

For those of us in the not cool enough for school camp and developing Ruby apps on Windows, try http://e-texteditor.com/ a TextMate clone for Windows. It uses TextMate bundles directly, so you get lots of goodies. It also installs cygwin automatically if you need to.

Not free, but a 30 day trial.

Will update with experiences.

Most of my ThoughtWorks colleagues love tests. We love writing tests and watching them fail, and we love writing the code that then makes them pass. We love tests so much that most of the time taken in building the software is in the running of the tests to make sure we haven’t done something dotty to break the software.

We hate when the time taken to run all those tests takes more than a few minutes, and this causes a lot of discussion internally as well as on our blogs. My strategic preference is to make the application smaller and thus the builds quicker, by building the software as discrete components (built and deployed independently) that are composed into an application. But before that, there’s a long list of things to make the builds and tests quicker. The list is never long enough, though.

We regularly discuss/concoct innovations in testing at the Sydney TW office. A few weeks ago Stacy Curl started a discussion on an idea he’s had for a while around optimising acceptance tests. During this discussion, we talked about various techniques, including profiling and coverage, which then prompted thoughts around knowing which code each test covered.

This then blossomed into a requirement which was to instrument the code that is covered by each test such that when that code is changed, the tests that cover it are known. This then lets us run only the tests that “need” to be run when we change some code. I say “need” because there are always things below or outside the code that may alter behaviour, so a full test suite still has to be run at some point, just not in a way that delays feedback on the most likely problems.

In essence, we wanted a tool that defines the smoke tests (pre-commit build, initial CruiseControl pipeline build) dynamically. The “changed” code could be based on file system modified times, Subversion status, CruiseControl modificationset, etc.

Unfortunately, the context provided by tools like Clover, Emma and Cobertura isn’t sufficient to indicate which test is running (no stack is available in the metrics). The upshot was I went off and looked at using AspectJ aspects to trace the code during a test run. Gianny Damour helped with early optimisations of my advices and gave me the introduction to “cflow” which allowed me to remove my own stack-peeking logic. I was going to call it TestThis! (as in this.method()) but because of the annoyance in lowercase called it TestMe instead (no throwback to VB intended), with the almost obligatory “J” prefix for Java. Josh Price rightly pointed out that the resultant name “JTestMe” is lame - another reason to merge with ProTest (see below).

Only the source file name is tracked. While we could instrument to the method level, we felt that this was too granular and that any change to the source file should trigger all tests that touch any of that class’ logic. It also works for superclasses, inner classes and called classes - that is, the tests may not call the code directly, but because the code is within their control flow, they’re all tracked.

public aspect TestCoveringAClassObserver {
    pointcut allTestMethods(TestCase test):
        target(test) &&                                                   // capture the TestCase
        execution(public void TestCase+.test*())                          // and advise execution of any JUnit test methods
    ;

    before(TestCase test):
        cflow(allTestMethods(test)) &&                                    // within the control flow of the allTestMethods advice
        (execution(!private * *(*)) || execution(!private * *())) &&      // when executing any non-private method
        (execution(* !TestCase+.*()) || execution(* !TestCase+.*(*))) &&  // that is not in the test case class
        within (!com.thoughtworks.testme..*)                              // and not within any JTestMe class
        {
            recordLink(thisJoinPointStaticPart.getSourceLocation(), test);
        }
    ;
}

Even with the extra guards to avoid recursive advice explosions and to ignore instrumenting the test code itself, you can see that the core piece of code is a ridiculously few lines of AspectJ. The “database” updated by the recordLink() method is a fat ugly (but very fast) object de/serializer that I haven’t bothered cleaning up much.

To allow you to easily run your code with or without instrumentation (you may be nervous that AspectJ has subtly altered behaviour), I’ve used the AspectJ Load Time Weaving (from the AspectWorkz merge). It also means you can continue to use your own custom JUnit test runners. Instrumented - use aj5’s java --javaagent). Normal - use java.

At CITCONF in Sydney a few weeks back, where I gave this a quick demo, the crowd were very encouraging and the Atlassian Clover (nee-Cenqua) guys, who demonstrated a tops new version, were academically interested in the neat and tidy use of aspects (they can’t use them for a reason I can’t remember?? Will find out next meetup).

There’s a long to-do list, the first of which are make it more “one-click” to use and explore a merge into ProTest (a test prioritising tool - and I figure the tests that JTestMe identifies are just another way to prioritise tests). Others are SVN integration and Ant task, and a filter for the excellent Continuous Testing tool (which also allows for prioritising tests).

It’s just been accepted into the Codehaus so have a peek and let me know. The usage is clunky (change the JTESTME_HOME values and the aj5 java agent path and test cases in the Windows cmd files) but it works for HelloWorld demonstration purposes (no automatic file modification detection yet).

My clever co-worker Shane Harvie just blogged about making Ruby constructors protected in a nice way.

Shane, here’s something slightly more terse which might be the new content of your make_constructor_protect.rb file:

class Class
	def protect_constructor
		class_eval(%Q[
			class << self
				protected :new

				def inherited(klass)
					klass.class_eval do
						def self.new(*args); super; end
					end
				end
			end
		])
	end
end

Seems to pass all the tests. So, your party.rb might look like this now (I’ve left the other stuff commented out, and added access to annual_cost just to be sure).

With a little more effort messing around with the Module.protected, I reckon you could make “protected :new” work as a more natural idiomatic approach - the way you originally hoped it might.
Update: not really as some kernel behaviour appears to be suppressed. See comments.

require 'make_constructor_protected'
require 'test/unit'

class Party
#  include MakeConstructorProtected
  attr_reader :name

  protect_constructor
  def initialize(name)
    @name = name
  end
end

class Employee < Party
  attr_reader :annual_cost

  def initialize(name, id, annual_cost)
    super(name)
    @id, @annual_cost = id, annual_cost
  end
end

class Department < Party
  def initialize(name)
    super
  end
end

class PartyTest < Test::Unit::TestCase
	def test_new_raises_no_method_error
	 assert_raise(NoMethodError) { Party.new("some name") }
	end

	def test_department_initialize
	 d = Department.new("name")
	 assert_equal "name", d.name
	end

	def test_employee_initialize
	 e = Employee.new("name", 5, 12)
	 assert_equal "name", e.name
	 assert_equal 12, e.annual_cost
	end
end

A little while ago, my ThoughtWorks colleague Neal Ford was discussing Polyglot Programming.

He highlights a renewed interest in a diversity of programming languages, particularly those that display constructs that are dynamic, functional, or declarative. Those of us that have been around a while don’t actually think this is a new thing. I’ve learned over 15 languages to proficiency in my 21 years of programming and was looking at the DDJ and Byte CDs for alternative languages well over a decade ago.

Today in Sydney (and later this week in Melbourne), Scott Shaw from our Melbourne office is presenting a ThoughtWorks Quarterly Technology Briefing with the following magnificent title: “Are Dynamic Languages the Next Big Thing? Fight Bloatware to Achieve Faster Time to Market. What IT Decision Makers Need to Know About the New Dynamic Languages”.

At a point in his presentation, Scott asks if corporate IT developers can be polyglot programmers. I asked if it’s all just Greek to them. (Hilarious? It’s gold, Jerry, gold!).

I’m figuring that “it depends”. It depends largely on the level of software craft they employ or enjoy. It depends on the environment they work in and whether a Renaissance view and humanist learning is encouraged. It depends on whether they are seen as, or see themselves as, monkeys pounding keyboards until something good enough is churned out.

Some less esoteric thoughts:

• The difference between C-derivative languages has been minimal until recently.
• Perl is dynamic and has some neat features but appears to have lost the plot on simplicity and expressiveness (Perl 6 is even further off beam).
• Java and C# are mostly object-oriented (although applications written in them generally aren’t)
• Java has incorporated Doug Lea’s fine concurrency package into the API, providing some effective, if somewhat inorganic (due to the nature of Java) concurrency features, and continues that through at least Java 7 with his ongoing work.
• Java and C# are now incorporating dynamic features into the programming model (BSF, DuckTyping).
• More importantly, C# 3.0 incorporates some of the fine language research from Microsoft Labs and includes declarative and functional features (Linq, lamdas).

Some languages you should know about today:

• Ruby. If you’ve used Lisp, Smalltalk, Python or Perl, you’ll probably want to give this one a whirl. If you’re using Excel or Access to glue enterprise data together, learn it - you’re going to have to know it soon. If you’re building a web application that does what most of the other web applications do, learn it and Rails - you’re going to have to know it soon.
• Erlang. If you can hear the avalanche of demands for highly-available, concurrent, non-monolithic processing in business applications coming, start learning. You’ll also understand the purpose of ForkJoinTasks in JSR166y / Java 7.
• Haskell. If you want to understand how high order functions contribute to effective DSLs, or how concurrent life becomes easier when you do away with global mutable state, give it a go. You’ll truly grok the concurrency features in JSR166y / Java 7. Also making some headway in the game software space. Scary syntax, but not as scary as Lisp. It’s a “Maybe Language” (mildly hilarious Haskell in joke).

All of them have growing IDE support (at least Eclipse and IntelliJ, some Visual Studio) and varying levels of development tools (Rake, RSpec, and Migrations will impress).

You could wait until C# and Java catch up with building these features in as core constructs in the language, making them more idiomatic, less cumbersome and error-prone than the bolt-on after-thoughts they largely are now (C# has done a better job). Or you could understand and utilise them from first principles now. Even if you don’t actually program in such languages on a day-to-day basis as part of your accountant-like job (although we believe the change is inevitable), you’ll at least approach the same problems with fresh insight while using your more pervasive language.

As those that speak Greek might say: Τι περιμένεις (What are you waiting for?)