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.
$> bundle update
was giving me a build error:
Fetching gem metadata from https://rubygems.org/........
Fetching additional metadata from https://rubygems.org/..
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
$> 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
$> 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
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
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
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.
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
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
and your page elements will stop jumping around.
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:
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
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.