jasondew.com

For a project that I'm work on at my day job, we have a governmental client for which we are building a pretty large and complicated online/offline Ruby on Rails application. As part of this app there are tons of data-specific rules. For example, if a client with HIV is being assessed then certain fields may have to be displayed/hidden and there are rules that get applied differently.

So lets say you have the following setup:

Now, somewhere in your code you want to be able to do take a specific action only if that client has a particular diagnosis. Without named_instances you might do something like:

With named_instances you can do the following faster and more concise code:

We've been using this functionality for about 6 months now and its been great. The gem is out on GemCutter (which rocks) and the repo is at GitHub. Hopefully it will be useful in your projects. Comments, criticisms, and patches welcome.

So based on some customer feedback on a project I'm currently working on, I added a validation requiring that one of the dates be in the past. The validation is pretty straightforward:

After re-running the test suite though, I got a couple of failures. After digging into the code, it turns out that the following code snippit evaluates to true!

Of course this makes no sense. What's more is that I tried the code again while writing this blog post and now its false. So I did some digging into the Ruby internals and it turns out that Time#< is implemented in C in the following method:

The best I can come up with is that there's an problem with the GetTimeval method since its just a macro that pulls out some data from a time struct -- but the Date class is implemented in pure Ruby. Anyone come across this or can explain better?

So I've been working on the Darwin hobby project again recently and decided to find out where the program is spending all of it's time. It turns out that there are some really nice profiling tools in Haskell (GHC to be specific). Armed with that, I found out rather quickly that the bottleneck was the getPixel function I added to the GD bindings.

getPixel :: Point -> Image -> IO Color

getPixel (x,y) i = 

  withImagePtr i $ 

  \p -> gdImageGetTrueColorPixel p (int x) (int y)

My first thought was that it would be nice to grab all of the pixels at once instead of repeated (slow) calls to getPixel. So I read up on Haskell FFI and the GD documentation and churned out the following:

getPixels :: Image -> IO [[Color]]

getPixels image = 

  do (width, height) <- imageSize image

    pixelsPointer    <- withImagePtr image $ 

                        \gdi -> #{peek gdImage, tpixels} gdi

    columnPixelArray <- peekArray height pixelsPointer

    mapM (\a -> peekArray width a) columnPixelArray

This code returns a nice Haskell array of arrays with the color information. This improved the speed from 1 minute per 10 iterations to 1 second per 10 iterations -- about a 60x improvement!

However, this only works with true color images at this point; no indexed palette support since that information gets stored elsewhere in the GD image struct. All in all, it was a very pleasant and rewarding experience into Haskell. Next on the list is (Erlang-style maybe?) parallelization.

BTW, the GD binding code is under the dependencies folder here.