Ugg. For the past four or five days, I’ve been struggling to get all my gems installed for a Ruby 1.9.3 project I’ve been helping on (which is annoying because everything was working fine the last time I worked on it.) I use RVM to manage my ruby versions, and for the longest time I’ve let it manage its dependencies by itself. RVM seems to prefer using Homebrew’s gcc compiler, which has never been a problem in the past, but seems to be having some difficulty finding source files in OSX 10.10. I don’t know if the files got moved in the 10.10 update, but I do know it’s causing me some headaches.

Running:

1

2
  $> bundle update

was giving me a build error:

1

2 3 4 5 6 7 8 9 10 11 12 13 14 15
  Fetching gem metadata from https://rubygems.org/........
  Fetching additional metadata from https://rubygems.org/..
  Resolving dependencies...

  Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

      /Users/rringler/.rvm/rubies/ruby-1.9.3-p551/bin/ruby -r ./siteconf20141118-1331-708ezv.rb extconf.rb
  checking for dns_sd.h... no
  unable to find dnssd header
  *** extconf.rb failed ***
  Could not create Makefile due to some reason, probably lack of
  necessary libraries and/or headers.  Check the mkmf.log file for more
  details.  You may need configuration options.


Inspecting the mkmf.log, I see that ruby/rvm is trying to use the homebrew’s gcc compiler (/usr/local/opt/apple-gcc42) to build the dnssd gem, and failing to find the dns_sd.h headers. I have no idea why Homebrew’s gcc can’t find it, but I do seem to have a solution: reinstall Ruby 1.9.3 using Xcode’s gcc compiler.

After uninstalling the existing Ruby 1.9.3

1

2
  $> rvm uninstall ruby-1.9.3-p551

I made sure I had the latest version of Xcode, and Xcode Command Line Tools installed. I opened Xcode’s preferences, and verified that it listed “Xcode 6.1 (6A1052d)” in the Command Line Tools section (under the Locations tab.) Finally, I reinstalled ruby instructing RVM to use Xcode’s clang-based gcc compiler:

1

2
  $> rvm install 1.9.3 --with-gcc=clang

and everything seems to work again; the dnssd gem now builds correctly.

Apparently earlier versions of Ruby 1.9.3 had issues with clang/llvm-based compilers, so this solution may not help if you’re trying to install something earlier than ruby-1.9.3-p125, but if you just want the latest 1.9.3 (p551) and are having difficulty, give this a shot.

Ruby’s Enumerable module is beautiful. Coming from a more procedural programming background, it can take some time to fully appreciate that beauty. One pattern I see new Rubyists repeating relates to transforming data structures. This is an easy problem for a proceduralist:

1
2
3
4
5
6
7
8
9
10
def some_method(collection)
  array = []

  collection.each do |item|
    new_item = item.do_something
    array << new_item
  end

  array
end

This works, but it’s not beautiful. It’s even worse if the proceduralist loops over the data to transform. Once the proceduralist embraces Ruby, and studies the Enumerable module, they learn of the #each_with_object method. This method allows us to simplify our code:

1
2
3
4
5
def some_method(collection)
  collection.each_with_object([]) do |item, array|
    array << item.do_something
  end
end

Enumerable#each_with_object allows us to declare the new data structure as a parameter, reference it in our block, and then returns it for us; all in one method call. For simple operations, this can often be a one-liner:

1
2
3
def some_method(collection)
  collection.each_with_object([]) { |item, array| array << item.do_something }
end

This is beautiful. Any time you find yourself instantiating a new data structure and then filling it, consider using #each_with_object.

Twitter Bootstrap is awesome. The amount of grunt work that Bootstrap makes easy is amazing. One of Bootstrap’s great features is animated carousels; they are a nice way to display a lot of information without taking up a lot of vertical height. With Bootstrap, we just wrap our content in a couple of divs, and before we know it we have a nice scolling carousel.

One thing that I don’t like about Bootstrap’s carousel implementation is that it dynamically resizes the carousel’s height based on the size of the content currently being displaying. If all your content is exactly the same height this isn’t such a big deal, but if it’s not you end up with page elements below the carousel jumping around as the carousel resizes. This seems like terrible UX to me.

Thankfully this is not all that difficult to fix. In just a few lines of JavaScript/jQuery, we can scan through the carousel slides and determine the height of the tallest slide, and use its height for all of them. The code is pretty straightforward:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
function carouselNormalization() {
  var items   = $('#carousel-id .item'),              // grab all the slides
      heights = [],                                   // array to store heights
      tallest;                                        // tallest slide

  if (items.length) {
    function normalizeHeights() {
      items.each(function() {
        heights.push($(this).height());               // add each slide's height
      });                                             // to the array

      tallest = Math.max.apply(null, heights);        // find the largest height

      items.each(function() {
        $(this).css('min-height', tallest + 'px');    // set each slide's minimum
      });                                             // height to the largest
    };

    normalizeHeights();

    $(window).on('resize orientationchange', function() {
      tallest = 0, heights.length = 0;               // reset the variables

      items.each(function() {
        $(this).css('min-height', '0');              // reset each slide's height
      });

      normalizeHeights();                            // run it again
    });
  }
}

Call that in a document.ready block:

[Edit: Calling this on window.onload will wait until all the assets have been loaded so a maximum height can be calculated correctly.]

1
2
3
window.onload = function() {
  carouselNormalization();
}

and your page elements will stop jumping around.

H/T to Eddie Staples’s post for providing the basic JavaScript.

Ruby on Rails takes care of most of our site security for us. About the only thing we have to do is be careful with our secret keys. This means keeping them out of public repos. If you realize you’ve revealed your secret key, Rails still has your back. There’s a very simple rake task to generate a new secret key:

1
2
$ rake secret
d781e04897092465...

and you’ll get a new, secure 64-character random key. Try not to check this one into source control.

H/T to James Badger’s post for spelling this out.

Ruby on Rails’s ActiveRecord supports the normal decimal SQL data type, with support for both precision and scale options. Unfortunately these two options are simple enough to understand, but similar enough to confuse.

In short, precision is the total number of digits in the decimal number, while scale is the number of digits to the right of the decimal place. Thus, the following migration:

1
2
3
4
5
6
7
8
9
10
class CreateNumbersTable < ActiveRecord::Migration
  def up
    create_table :numbers do |t|
      t.decimal :decimal_number, precision: 6, scale: 2
    end
  end

  def down
  end
end

creates a numbers table with a decimal_number column that will accept data in a X,XXX.XX format. Try to insert a number with more digits (say, 10,000.00) and it will give you an out-of-range error (as I wrestled with last night.)

H/T to Jtanium’s post for making this clear for me.