Mock-up testing on another scale!

As a programmer, I often need to test code that interacts with other code. In the ideal universe, that testing would be done by interacting with the actual code. When this is not feasible, mocks and stubs are used as stand-ins.

Today, I had occasion to see mocks and stubs on a slightly different scale:


The reactor mock-up at the Darlington Nuclear Power Facility.

I was lucky to have a tour of the the reactor mock-up at the Darlington Nuclear Power Plant near where I live in Ontario, Canada. The power facility is due for some tender loving care over the next decade or so and it turns out that similar maintenance projects  on similar (CANDU) class nuclear facilities have a poor track record for going over budget and time. When it comes to saving time and money, I understand mock-ups.

The idea of a mock-up reactor is to allow testing of tools and procedures, and training of personnel in a safe, low pressure environment, with the clock (or geiger counter) NOT running. This is an excellent idea and I was reminded of the training methods used by NASA in preparing astronauts for work to be done in the vastly more dangerous environment of space.

Now for dollars! The mock-up facility has a (hefty) price tag of $40 Million, but is expected to return savings benefits of $100 Million during the course of the reactor work. This does not count its value for on-going operations or the possible sale of training time to other operators who need to prepare for their refurbishment projects.

All in all, the visit to the power plant was an interesting diversion from my normal routine. It was good to take the opportunity to see test and maintenance engineering on a scale I normally never deal with. As engineers, I feel we owe it to ourselves and our art to keep an open mind and broad horizons.

As always, comments and suggestions are invited!

Yours Truly

Peter Camilleri (aka Squidly Jones)

Announcing the format_engine gem version 0.0.1

Just recently in my programming endeavors, I began to examine the Time class in Ruby. There were many subtle and nuanced points about how Time values were handled, but one area that struck me as interesting was how it dealt with formatted string I/O. The Time class supports two function strftime and srtptime. Both are based on “C” library time routines. The strftime method takes a time object, and a format specification string and creates a formatted output string. The strptime method reverses this with a formatted string and format specification string as input and a time object as output.

As I was considering these methods, it occurred to me that a generalized mechanism for build these sorts of formatters and parsers would be a useful thing. A check of available gems did not reveal an obvious candidate for this task, so, I set about writing my own. The format_engine gem is the result.

This code has undergone a decent amount of testing so the 0.0.1 release version should not be seen as too discouraging to those seeking to try it out. The gem may be found at Ruby Gems and the source code at GitHub.

I hope you find this code useful. If you feel motivated to comment, leave me a note. If you find a problem, please raise an issue on the project in the GitHub repository.

Yours Truly

Peter Camilleri (aka Squidly Jones)