Today I started using a new trick. Google has recently released MacFUSE. The neat thing here is that you can also download the sshfs file system and use it to mount an SSH server as a network drive.

Needless to say, this works like a charm with Rubyforge. Just fire up the sshfs.app file after installing the MacFUSE core and the sshfs.app bundle.

It will ask you for a server, type ‘rubyforge.org’. Enter your rubyforge id as well, and for the directory, enter something like

It will ask you for a password, and then like magic, your rubyforge filespace will be mounted like a drive. Now you have no excuse for not putting some documentation or a spiffy web page up there.

Incidentally, once the connection is established, you can quit the ’sshfs.app’ program. There are also instructions on the Google code web page that tell you how to use this from the command line. The mounted rubyforge.org drive will also be accessible from the command line as ‘/Volumes/rubyforge.org

1. go to Rails Google co-op
2. right click on the search box.
3. select ‘Add keyword for this search’
4. fill out the resulting form and add a keyword like ‘rails’
5. move focus to the address bar (CMD-L on a Mac)
6. Type ‘rails sciwerks’ on the address bar

You can also do this with rails or ruby API methods.

You could also set up a quicksilver web search for this too.

Installation

Features

1. Significantly improved speed
2. Will use the ‘Chronic’ gem to interpret times/dates if loaded
3. some nice time helpers.
   ‘1 day’.from ‘now’ #=> Wed Oct 04 18:27:13 EDT 2006
   ‘1 day’.ago #=> Mon Oct 02 18:38:56 EDT 2006
   ‘7 days’.before ‘1/1/2007′ #=> Mon Dec 25 00:00:00 EST 2006
   ‘7 days’.after ‘12/25/2006′ #=> Mon Jan 01 00:00:00 EST 2007
   ‘days’.since ‘1/1/2006′ #=> 275.436 d
   ‘days’.until ‘1/1/2007′ #=> 89.7683 d

   (works for sec, min, hours, days, weeks, fortnights, years, decades, centuries….
   but not months).

   and some others..
   these helpers will automagically give you a DateTime object
   if a Time object won’t work.

   ‘years’.since ‘1/1/1900′ #=> 106.756 y
   ‘50 years’.from ‘now’ #=> 2056-10-02T18:46:55Z
4. units can now identify themselves (sort of..)
   ‘60 mph’.unit.kind #=> :speed
   ‘9.8 m/s^2′.unit.kind #=> :acceleration
5. some new constructors
   Unit(10,’m') #=> 10 m
6. Now throws an exception if it donsn’t understand a unit (during creation)
7. Temperature handling improved
   “0 tempC”.unit #=> 273.15 degK
   “310.15 degK”.to(’tempC’) #=> 37 degC
8. Trig functions can accept angular units
   Math.sin(’90 deg’.unit) #=> 1.0
   Math.sin(’100 grad’.unit) #=> 1.0

Ruby has a few libraries (notably, Facets) available that handle unit conversions in one form or another. However, most of these systems don’t quite meet my somewhat demanding and arbitrary requirements, so I set out to write a new one.

Installation

You can get ‘ruby-units’ using

Usage

To use this gem, you need to do the standard

Creating a Unit object

Because I use a lot of units in my work, and I’m lazy, there are several different ways to create a new ‘Unit’ object.

1. unit = Unit.new(”1 mm”)
2. unit = Unit(”1 mm”)
3. unit = U(”1 mm”)
4. unit = “1 mm”.to_unit
5. unit = “1 mm”.unit
6. unit = “1 mm”.u
7. unit = “mm”.unit (yields ‘1 mm’)

Of these, I use #5 the most since it is reasonably terse without becoming obscure.
You can also create Unit objects from Numerics, Arrays, and Time objects. Numerics just become unitless Unit objects, Arrays are interpreted as [scalar, numerator, denominator], and Time objects are converted into a number of seconds.

Unit objects can be serialized through YAML using ‘unit.to_yaml’, which facilitates them being stored in database columns using Rails’ :serialize functionality.

Unit strings generally consist of text in the following format:

Since Units are constructed from strings, it is easy to have a user specify them in input fields. Because the format is fairly standard, there should not be too many problems with misinterpreted units.

A couple of points:

1. only one ‘/’ per unit. No ‘m/s/s’
2. everything after the ‘/’ is in the denominator
3. you can use negative exponents (’9.8 m*s^-2′)
4. use either a space or a ‘*’ to separate units (’9.8 ms^-2′ == ‘9.8 1/ms^2′)
5. ruby-units understands all SI prefixes, and a few others as well

Unit Compatibility

Sometimes it is helpful to know if two units are ‘compatible’. Compatible units can be converted into each other, so ‘feet’ and ‘meters’ are compatbile, but ‘feet’ and ‘liters’ are not.

Unit Conversion

Units can be converted to each other so long as they are ‘compatible’. Ruby-units will throw an exception if units need to be compatible, but aren’t, so be sure to trap those exceptions when malformed input is possible.

Explicit Conversion

Explicit unit conversion occurs when the user asks for it. There are a couple of ways to force conversion to a particular unit.

Implicit Conversion

There are times when unit conversions are implied or assumed for simplicity. For example, when adding two units, the gem will convert the second unit to the same base units as the first prior to doing the math.

Unit Math

Unit objects come in really handy when doing complex math calculations:

You can add, multiply, subtract, and divide units as you can with any Numeric class. You can also exponentiate or root them, although I restrict roots to integer values, since ‘m^0.5′ doesn’t really make any sense.

As an added bonus, all Trig functions (sin, cos, tan, sinh, …) can accept units that are compatible with radians. The values will be converted to radians before returning the result. So you can do this..

Temperatures

Note that we specified the temperature in this equation as a ‘tempC’. Specifying a temperature will convert that unit into the equivalent number of degrees kelvin. So in this case, “0 tempC”.unit => 273.15 degK.

This is necessary to make the calculations work out right. Most times unit conversions are done by just adjusting the size of the units, but temperatures require you to also specify the zero point on the scale.

You can convert ‘degree’ units (like ‘degC’, ‘degF’, ‘degR’, or ‘degK’) to a temperature this way…

This really only makes sense when the value represents the degrees between absolute zero and the point of interest. Only the user knows when that is the case, so use it carefully.

Time and Date Math

Ruby-units understands a wide range of time units, and can convert back and forth between them with ease. Nothing new there.

However, ruby-units can add and subtract time units from Date, DateTime, and Time objects. Throw in a few rails-esque helpers and you can write code like this…

Formatting Output

You can format the output of a Unit object by using the “.to_s” function and string format specifiers…

Miscellaneous Stuff

You can create ranges of units, so long as they have scalar integers.

If a unit is ‘unitless?’ then it can be converted back to other types of Numerics.

Note that ‘Unit’ objects are pretty slow compared to more common ones like Integers and Floats, so if performance is a big issue, you might want to consider using these sparingly.

Defining new units

You can define custom units by adding a code block like this..

The format for the array is [%w{primary_name synonyms}, conversion_factor, unit_type, %w{}]

Useful References

Wikipedia: Units of Measurement

Can you tell what the expected result of this test is?

It turns out that you can’t tell from reading this test if it will pass or fail without knowing if ‘Item.new’ returns a valid or invalid object. If ‘Item’ has a ‘validates_presence_of’ statement in there, this new item will be invalid and the test will fail. In addition, this test is ‘fragile’, subtle changes to the model definition can make the result of this test change. This isn’t such a big deal if all you are doing is testing to see if an object is valid or not, but if you are writing a more involved test that depends on this assumption then you might be in trouble.

Currently the only way to ensure that your test data is valid is to add an assertion to each test making the appropriate test. This isn’t very DRY.

One trick that I use to avoid repeating myself a lot in tests is to define a mock object like this..(putting this in a mock object keeps these methods out of production mode).

Then in my tests I add…

This way I am guaranteed to get a valid or invalid item when I need one. in addition, if the definition of valid or invalid changes sufficiently the ‘test_valid’ and ‘test_invalid’ tests will fail, warning me that my assumptions in the rest of the tests are incorrect.

One problem with this approach is if your tests care about HOW the object is invalid. In that case, you might need additional methods like ‘new_with_invalid_name’.

Needless to say, that isn’t very practical advice.

Over the course of developing my own rails application, I have developed a list of ‘tests’ that I like to run on my models and controllers. This article will discuss some of the strategic design of tests, but won’t cover how to implement them (well, not much anyway).

Positive Controls

Tests should be designed with both ‘positive’ and ‘negative’ controls in mind. A positive control is a test or assertion that succeeds when you expect it to, and likewise a negative control fails when you expect it to. For example, if you create and save an object using predefined good data, an appropriate positive control could be…

In this case, we just check to make sure that the object is valid and that the number of them in the database has increased by one. These types of tests don’t really tell you much. The only time these types of tests fail is when something is seriously wrong with your database server, your ruby install, or your rails install. The only other time this type of test will fail is if you change the definition of the ‘Item’ model so that creating one using the ‘new’ method results in an invalid object (more on that later). The problem with positive controls is that when they pass, all they tell you is that nothing in the test caused an assertion to fail. This could mean that everything is hunky-dory, or it could mean that your assertions are not working as expected.

Passing the test doesn’t mean much if the test itself can’t detect a failure. Our test would pass just fine, even if the object model should really have a ‘validates_presence_of :name’ specified. It’s also easy to see that if we write a test like this…

This test will still pass, even if the validation is not specified. Still, it’s nice to know that things work as expected.

Negative Controls

Negative controls are really much more handy. A Negative control is a test that is designed to detect when things fail.
If we write another test for our ‘item’

If ‘test_invalid’ passes, then you can be confident that your ‘validates_presence_of’ is working. If it had been commented out during a bug fix and never replaced, this test would fail, while ‘test_valid’ would still happily report a success.

The same approach should be used when testing model methods. At least one test for each type of expected output, and one for each possible failure mode. Then make sure that the negative controls are in place so that they will pass when the model is fed corrupt data.

The bottom line… tests should be written to pass when you pass valid data, but they should also be written to pass when you pass missing, corrupt, or extra data. The failure modes are the most useful during development since they will point out places where bugs and security holes may creep into your application.

Ranges of letters don’t work as well.

What? Why doesn’t the second example work? That’s a valid series, it should return [ "Z", "AA", "AB" ].
The problem here seems to be that these strings don’t sort the way that ‘range’ expects them to. (Thanks to Robert Dober for pointing this out)

So one solution to this problem is to simply create a class that implements the correct semantics and sorts properly.
Here’s one implementation.

Now some tests….

Feel free to use this code if you find it handy.
See http://www.ruby-forum.com/topic/67300?reply_to=83726#83612 for the original discussion that inspired this code.