Moving Day

This blog has moved to http://blog.michaelgreenly.com

Just Maybe, Maybe - Pattern in Ruby

The original code I posted was flawed.  The gist below is modified and I think would work but it's not as clear as I'd like it to be.  I'll follow up on this soon.

I recently released a tiny Gem called JustMaybe.  This caused me to do more reading on the subject.  I ran across the If you gaze into nil nil gazes also into you post.  In the JustMaybe readme I sort of mention this but I wanted to express it more clearly here.

I don't really think using Maybe mixed in with the logic of your application is a good idea.  As an example I think the problem presented in that article could be solved much more clearly with this bit of code.  Here's a solution that will never return nil.



My suggestion is that if you find yourself wrestling with possible nil return values .  See if you can turn the operation on it's head.  Don't ask your object about it's associations.  Ask the association about your object.  I often find this will clean up the logic.

I did however just release JustMaybe so obviously I think it's useful in some way?  For me that's almost strictly in presentation.  When you are presenting information you often have to reach deep down into the hierarchy of objects to extract the necessary bits.  Interestingly, at presentation, is when I think you should be deciding what to display when information is missing.  To me that creates a perfect situation for using the Maybe pattern.

Apache HTTP to HTTPS Redirect

Here's a micro-nugget. The following Apache config redirects incoming HTTP traffic to the equivalent HTTPS page. Nothing special but I don't spend enough time working on Apache configurations to keep this stuff fresh in my mind so I find it useful to record what I learn in case I need to do it again later.

<virtualhost *:80>
  RedirectMatch permanent /(.*)$ https://example.com/$1
</virtualhost>

<virtualhost *:443>
  ServerName example.com
  # config...
</virtualhost>

Extending Date Parsing In Ruby 1.9.3

I had previously made posts about parsing user supplied dates in Ruby

• http://blog.michaelgreenly.com/2012/01/more-parsing-user-supplied-dates-and.html
• http://blog.michaelgreenly.com/2012/01/parsing-user-supplied-dates-and-times.html

Apparently in Ruby 1.9.3 the Date library was re-implemented in C for performance and of course that broke my extension.  I updated it to support Ruby 1.9.3 below




This may not work on Ruby versions prior to 1.9.3 I didn't try it.

I also found the american_date gem which apparently existed before I had originally written my extension and is almost certainly a better choice if you don't need any custom formats.

Generic ".rvmrc" File For Ruby Projects

I'm really lazy and have started using the exact same ".rvmrc" file for all my Ruby projects....

rvm use @$(basename `pwd`) --create

I'm not sure but I think I first seen this exact format while reading this code https://github.com/dkubb/veritas

Generic "config/database.yml" for Postgres

I'm really lazy and always use the exact same "config/database.yml" file with my Rails projects....

What The Hell Is SOPA?

Here's some links and a bit of explanation if you're new to the debate about SOPA.

I think the best place to start is this clip from "Up with Chris Hayes" on MSNBC which provides a fairly good intro.  The biggest problem I have with this video is that NBC exec, Richard Cotten, is never challenged in his assertion that it only covers foreign sites.  You can see Fred von Lohman, a laywer from Google and the EFF, in this video from the Standford Center for Internet and Society rebuff Cotten's position.

In the first video a poor attempt is made to present Internet piracy as a service problem.  That happens to be a view I agree with.  I think it's expressed much more eloquently by Tim O'Reilly in this Gigaom article or by Gotham Gal in this AVC.com post.  

Richard Cotten argues against "the service problem" by pointing out that Netflix, Hulu and others exist.  What he doesn't mention is they're prevented by licensing from providing the content consumers want.  In this blog post you can see Netflix only had 5 of the top 100 box office titles available last year.  The best score was by Amazon which only had 45 of the top 100 titles, less than half.  


Until they make the content available when people want to see it on which ever device or service they want to view it they have no footing in the argument against it being a service problem.


There's a ton more material out there but that's a good start if you're new to the topic.

More Parsing User Supplied Dates and Times in Rails

Rails does a pretty good job of making work with time zones feel transparent.  If you do everything it's way, including use ActionView::Helpers::DateHelper.  If you use a Javascript control that returns a text input field or if you allow the users to enter values directly or need to process uploaded content things get a bit more complicated.

If the string returned by the text input can be parsed by Date._parse your in luck.  Everything will still work as expected with no extra effort.  If on the other hand you want to do something as simple as display U.S. style dates, in the format "MM/DD/YYYY", you will have to manually parse the input.  Ruby's Date._parse understands 'YYYY/MM/DD' and 'DD/MM/YYYY' but not 'MM/DD/YYYY'.  In the case where you're processing the input from a Javascript control the most direct solution is to do something like this...



The example above does return a time value in the current timezone and will work as expected.  One big problem with strptime is that it isn't very flexible, the input string must match the provided format string exactly right down the the separator characters and spaces.  So this approach can work if your processing the output of a control but tends to fail if you need to process human input.

Another problem I have with the approach above is that it quickly becomes incredibly redundant if you're working with a large number of date/time fields in many different models.  To Dry that up a bit I decided to move my specialized processing into a modified version of Date._parse.  This means I don't have to litter my controllers with date time parsing code and I have a single entry point to test that all desired formats are supported.



Basically all this is doing is taking the input string and re-arranging the values into an order the original method will understand.  The biggest disadvantage to this problem is that it doesn't support per-locale input formats.  It guess I'll cross that bridge if I ever get to it.

Another Quick Rails/Postgres Tip

Assuming your local timezone is not 'UTC' you most likely will want to configure Postgres to use it anyway on your development machine so that your development environment behaves like your production environment.  To do this just find the 'timezone=' line in postgresql.conf and set it to 'UTC'.

Parsing User Supplied Dates and Times In Ruby

I'm in the middle of correcting some date/time handling in a Rails app. One of things that was wrong was the handling of user input date/time fields.  Obviously when users provide date/time values they're assuming we understand the information was provided from the perspective of their timezone.  Especially when we don't explicitly require them to provide timezone information.

The problem with this is that Ruby's DateTime.parse method always returns UTC based times.  You can see this clearly in the example below:
You can see the problem on the 6th line in the example above.  Even though the user input "2011/01/01T00:00" when that DateTime instance is converted to localtime the current timezone offset was subtracted.  In this case resulting in a time that's 6 hours earlier than desired.

The solution is straight forward of course. You just have to add the inverse of the users timezone offset to the value returned from DateTime.parse as demonstrated below.


On line 4 you can see it's correct even when converted from UTC to local time. 

As an alternative you could include the timezone information before parsing it but that's not always easy because you don't necessarily now the format of the user's input.


Of course all of this is generally pretty obvious but I shared just in case it can help some one less familiar with the issues.