Category Archives: thoughts

Double-checking for nil and the Maybe Pattern

While listening to The Ruby Show episode #176 I heard about the ThoughtBot post about the Maybe Pattern as discussed in their “If you gaze into nil, nil gazes also into you” post.

It took me a minute to figure out what was going on. (Maybe I’m just getting slower in my old age.) Plagiarizing from their post, they included the code required to set up the Maybe Pattern and I’ll try to add my own comments in red so I feel like I’m adding something to this conversation:

This is modifying the base Object of which every Ruby object is
a child. Yes, that means even Nil gets an automatic maybe()
method stuck in it.

The idea is that if you think a method *might* return a value
then you ought to return your value with a .maybe() on it.
That accomplishes the "wrapping". You'll see that it takes
itself and returns an instance of Some with itself stuffed
into it. Thus at this point you really get a Some() object
back, not your original return value.
class Object
  def maybe
    Some.new(self)
  end
end

... Except for Nil. This one definitely is empty/blank/nothing
so we need to create an instance of Some that will throw
exceptions if you try to unwrap it.
class NilClass
  def maybe
    None.new
  end
end

And here is the Some object that wraps anything you give
it by storing it in its own @object attribute.
class Some
  def initialize(object)
    @object = object
  end

  This is how you "unwrap" an object. Pay close attention
that the None version of this will throw exceptions.
  def get
    @object
  end

  This is one way you can check to see if there might
be values.
  def present?
    true
  end

  And this is the other.
  def blank?
    false
  end
end

And back to some Magic Sauce. It creates a new error type,
Unwrapped, and will return it when you attempt to call get().
This is because as a consumer of the Some or None values
you ought to have checked present?() or blank?() first. That's 
right, consumers need to be sure that they're not just going
to use a nil value.
class None
  class Unwrapped < StandardError; end

  def get
    raise Unwrapped
  end

  def present?
    false
  end

  def blank?
    true
  end
end

OK, great. So how do you use this in practice?

When you return a value that is absolutely true or false, then do so. If you think your return value might be null then wrap it by tacking on a .maybe() call.

The consumer of these return values should always check for present?() or blank?(). If something is not present or is blank then you should no longer need to access the return value because, well, you got your answer.

However, if you need to use the return value for something (e.g. it might be a single object, or might be an array, or a Hash, or ...) then you need to check if it's present?() and/or not blank?(). If that's true then you can call the object's .get() method to grab that value and continue with your logic. Like:

accounts = bank(me).accounts
# accounts might be nil ... check present?()
if accounts.present?
  account_list = accounts.get
  # Now account_list definitely has something which isn't nil!
end

The main thought I had in all of this is that this will create tons of wrapper objects that could just add bloat to your application. Plus there's the extra evaluation involved. In my own code I almost always just use the Rails .blank?() method to check if things are there. That seems to handle nil, empty strings, and empty arrays just fine!

Web pages with small fonts, 12px/0.9em at the very least please

So an interesting thing happened the other day. I was reading a popular site that deals with creating web content and I caught myself doing one of the tell-tale things that users do when the fonts on a web page are too small: they lean inward. Now, I know that I’m not exactly in my early 20s anymore and it is true that I do wear glasses almost all of the time now, but my eyesight really isn’t that bad. And I’ve read this site off and on for a while and I don’t remember having to have this lean-in problem before. Then I remembered one thing: I have a new laptop.

Yes, if you’ve read previous posts you know how I used to rave about my old 2008-edition MacBook Air. So light, so powerful, so fast, yada yada. And then I switched up to a 2010 edition at the end of last year. Bigger SSD, higher resolution, dual USB ports, yada yad—wait. Higher resolution? Yes, in fact I now have a 13″ display that has almost 128 dots per inch compared to the old 113 dots per inch. So how much of a difference does that make? Apparently a lot.

For comparison, let me put up this image:

Previously I had a 1280px-wide display that has about 11.26″ horizontal length. Now I have a 1440px display. That means those web sites with tiny fonts just got a heckuva lot tinier. I mean, you would think that 12% smaller might not be a great big deal, but I really do think it does.

I went around the web this morning looking at other examples of font sizing. It seems the smallest comfortable font size for me now is 12px high. The website which has the tiny fonts above works out to about 11px high. But if they just increased it a smidge …

We’re clearly into a time where LCD display technology has gotten so good that we now have displays *AT* (not “approaching”) print resolution. Case in point: Apple’s Retina Display technology gives us 300 ppi. A couple of years ago I had been looking at a Sony ultraportable that was at 220 ppi. We’ve reached the point where small definitely means small.

I don’t exactly know what the solution is here. We could ask browser manufacturers to set their default browser font sizes at a certain ppi. There are some web pages that depend on fonts being only a certain height. Maybe the new tablet era of computing with it’s pinch-zoom mitigates all of this because users just expand the text content until it looks comfortable.

In the meanwhile I’m recommending that anyone making web UIs not use a font smaller than 12px high or 0.90em high.

Ticket tracking and SCM, even for a team of one

On one of my newer projects I’m a development and project management team of one. Still, I use a ticket tracking system like Redmine and Git for many reasons.

I like being able to enter a feature or a bug into the ticket tracker to make sure I get back to those issues later. I could use a spreadsheet, a notepad, or something like Remember The Milk but Redmine has the big advantage of integrating with SCM systems.

And I definitely use SCM all of the time. I’ve run into way too many cases where I’ve made a change I regret or I just need to group changes together. Something like Git works perfectly for this. And when I commit code it also reflects in Redmine what I’ve done, when I’ve done it.

Plus there’s a more important thing: what if my development team grows from one person to more than just me? If I’ve been using these systems all the time then adding a new code author or a project manager is really easy. I’m ready to scale!