More specifically, the rake asset:precompile task was failing during slug compilation.

The Heroku assets:precompile toubleshooting page contains several explanations, but none of these was my case. In fact, my application was working properly with Rails 3.1.

It turns out there are some changes in the Rails 3.2 initialization process that conflicts with Heroku slug compilation. The solution is very simple. All you have to do is to set the Rails 3.2 initialize_on_precompile configuration to false in your application.rb file.

This option is new in Rails 3.2 and prevents the Rails environment to be loaded when the assets:precompile task is executed. Because Heroku precompile assets before setting the database configuration, you need to set this configuration to false or you Rails application will try to connect to an unexisting database.

This configuration is also documented in the Precompiling Assets section of the new Rails 3.2 asset pipeline guide.

Related posts

1. Using Sprockets without a Rails/Rack project
2. Configuring Rails 3 to use HTTPS and SSL
3. VMware Fusion “The network bridge device on /dev/vmnet0 is not running” error

This is the second Olsen’s book about Ruby. In 2007 he published Design Patterns in Ruby, an other great example of how common programming practices like Design Patterns apply to the Ruby world.

Eloquent Ruby is a very lightweight and pleasant reading. The colloquial tone is friendly and engrossing. The books has plenty of code snippets and it requires only a few days to read it from start to end.

Be prepared, this is an unconventional Ruby book. To use author’s words

This is a book about making that final leap, about absorbing the Ruby programming culture, about becoming truly fluent in Ruby.

This is something I have been claiming for the last 5 years. Learning Ruby is not difficult, start thinking in Ruby and becoming a Rubyist is the real challenge.

A formal understanding of the mechanics of Ruby isn’t the same as really looking at the programming world through Ruby-colored glasses. You need to absorb the cultural part of Ruby, to see how real Rubyist use the language to solve problems.

This is one of the reasons that convinced me to create the Rubyist.

Structure

The book is divided into 4 parts:

1. The Basics
2. Classes, Modules, and Blocks
3. Metaprogramming
4. Pulling It All Together

Each part is divided into chapters. The book counts 31 chapters and about 400 pages.

The first part covers some basic Ruby features in a way you normally won’t read in any other Ruby reference. Ah, if I only had the Symbol chapter available when I started learning Ruby!

The second part covers Classes, Modules and Blocks and it explains how to use modules successfully, how to deal with inheritance, equality and operators. This is by far my most favorite section.

The third part is about Metaprogramming. Whilst the name of the section is technically correct, it can be misleading. If you are looking for a complete Ruby and Metaprogramming course, check out Metaprogramming Ruby (US | UK). This section covers common Ruby metaprogramming topic such as hooks, method_missing (a must read!) and monkey patching.

The forth part wraps several topics all together and talks about creating and implementing a DSL in Ruby.

The book ends with a rich list of books about Ruby and programming in general. The list contains amazing Ruby titles like Ruby Best Practices (US | UK) or The Ruby Way Second Edition (US | UK), as well programming masterpieces like The Elements of Programming Style (US | UK). If you are looking for some inspiration about your next reading, you might probably find some there.

Chapters

1. Write Code That Looks Like Ruby
2. Choose the Right Control Structure
3. Take Advantage of Ruby’s Smart Collections
4. Take Advantage of Ruby’s Smart Strings
5. Find The Right String With Regular Expressions
6. Use Symbols to Stand for Something
7. Treat Everything Like an Object – Because Everything Is
8. Embrace Dynamic Typing
9. Write Specs!
10. Construct Your Classes from Short, Focused Methods
11. Define Operators Respectfully
12. Create Classes That Understand Equality
13. Get The Behavior You Need with Singleton and Class Methods
14. Use Class Instance Variables
15. Use Modules as Name spaces
16. Use Modules as Mixins
17. Use Blocks to Iterate
18. Execute Around with a Block
19. Save Blocks to Execute Later
20. Use Hooks to Keep Your Program Informed
21. Use method_missing for Flexible Error Handling
22. Use method_missing for Delegation
23. Use method_missing to Build Flexible APIs
24. Update Existing Classes with Monkey Patching
25. Create Self-Modifying Classes
26. Create Classes That Modify Their Subclasses
27. Invent Internal DSLs
28. Build External DSLs for Flexible Syntax
29. Package Your Programs as Gems
30. Know Your Ruby Implementation
31. Keep An Open Mind to Go With Those Open Classes

Requirements

This book assumes that you have a basic knowledge of the Ruby language. You don’t need to be a Ruby master, but some advanced sections such as Metaprogramming and DSL may require you to stop for a moment and refresh or improve your specific knowledge of Ruby on that topic.

Don’t expect this book to explain you the basic details of Ruby or its syntax, this is behind the scope of this publication. There are plenty of commented examples, but if you want to learn about a specific Ruby feature make sure you keep a reference like Programming Ruby (US | UK) or The Ruby Way (US | UK) handy.

Another requirement is that you must be ready to read printed source code: this book is full or Ruby code. At least the 50% of the pages contain code, making this book a valuable practical reference.

Plus

Aside from being an excellent resource to help you thinking Ruby and programming in the Ruby way, this book constantly adopts a practical approach providing tons of examples to read. Every chapter ends with an In the Wild section containing examples extracted from real Ruby libraries, and a Wrapping up section that helps you to fix the concepts in mind.

As as long time Ruby developer I really loved the Use Symbols to Stand for Something, object and block chapters. Some of them didn’t necessary teach anything new, but the way used to present the concepts was very helpful and understandable.

I appreciate the focus on tests and the RSpec chapter. The most part of Ruby books dedicate a specific section about tests, then seem to forget them for the rest of the chapters. This is not the case of this book, where several examples are verified by tests.

Finally, the simple colloquial tone makes the book really friendly. It seems like a person you always worked with is now teaching you programming and thinking in the Ruby way.

Minus

It’s really hard to find some real negative in this book.

I found the Regular Expression chapter pretty boring and misplaced. In fact, it was the only chapter in the book where the main focus was teaching Regular Expression basics, instead of focusing on using Regular Expressions in the right way.

The same applies to the RubyGems sections. There have been several changes in the Gems community in the last years and the chapter appears to be slightly outdated. Again, I would have left this topic outside the book.

Finally, I would have appreciated a wider usage of Ruby 1.9 over 1.8 in order to discourage the adoption of Ruby 1.8.

In Conclusion

If you are a beginner to intermediate level Ruby programmer, this book is a must read that it’s likely to help you improving your Ruby skill and writing code in the Ruby way.

If you are completely new to Ruby, personally don’t recommend this book as a first reading. You might want to start with a Ruby reference to learn how programming in Ruby, then read Eloquent Ruby to learn how programming in the Ruby way. Also, don’t forget about the Rubyist, you’ll find several Ruby common practices and coding conventions.

If you are a Ruby expert and you have been writing Ruby for the last 5 years, don’t be too self-confident. I’m quite sure the book will be able to provide you some valuable advice more than once.

Where to Find Eloquent Ruby

You can get a printed or Kindle copy at Amazon.com, Amazon.co.uk, or at your other favorite book seller.

Kindle Preview

Related posts

1. Design Patterns in Ruby Book Review
2. Learning jQuery 1.3 Book Review
3. Getting Real Book Review

Sprockets is now integrated in Rails 3.1 and is the core library behind the new Rails 3.1 asset pipeline. What about if you want to use Sprockets outside a Rails project?

Sprockets exposes a very powerful Rack interface to serve assets over HTTP. Integrating Sprockets in a Rack application, such as a Sinatra project, turns out to be a very straightforward task.

But in my case, I wanted to use Sprockets preprocessing and bundling feature outside an HTTP application. And it turned out Sprockets is very good at doing this as well.

I have a custom shared template I created several months ago called docss. I use this for several projects such as Ruby Whois and RoboWhois. The template is composed of several CSS files. I have a Ruby rake script that merges these files and packages them into a single asset, then compress it and publish the result to Amazon CloudFront.

Instead of processing and merging the files using file system tasks I’m now delegating this task to Sprockets. The project directory structure looks like this

And here’s my compile task

First I create a new Sprockets::Environment instance passing some configurations, such as a custom logger.

Then I append the asset paths.

Finally, I process and package the assets to the build directory.

Because sometimes I need to reference a single CSS file (e.g. alignments.css) instead of the entire bundle, I also build a standalone package for each CSS source. You might not want to do that.

Please keep in mind that if you want to use processors you must include the corresponding libraries. For example, if you want to support SASS processor you need to add the sass gem.

Here’s my Gemfile.

That’s all.

Related posts

1. Heroku and Rails 3.2 asset:precompile error
2. The Road to Rails 3: make your Rails 2.3 project more Rails 3 oriented

The result of this effort is the Rubyist, a collection of conventions and standards for Ruby programmers. The project is now open source, you can fork it and contribute.

the Rubyist Homepage

When I first started learning Ruby, several years ago, there was a very nice project called RubyGarden. This project was a real treasure for those learning Ruby because it was full of resources and information about the Ruby world. If you have been developing in Ruby for a long time, I’m sure you’ll remember it.

But most of all, the RubyGarden has been extremely helpful to me (and many others) in learning about Ruby conventions and the most notable Ruby best practices. One page in particular, the RubyStyleGuide, was a collection of Ruby coding standard and naming conventions that every Ruby developer ought to have been familiar with.

RubyGarde Ruby Style Guide

A lot has changed since then.

The RubyGarden project was shut down a few years ago. As far I remember, the wiki was invaded by spam and the www.rubygarden.org domain has now been hijacked.

The Ruby language has evolved. Ruby 1.8 and Ruby 1.9 have introduced several new syntax changes and conventions. Moreover, the adoption of the Ruby programming language has increased over the years and several new common programming patterns have arisen.

GitHub was born. If you are in the habit of read the source code, GitHub is like a chocolate factory for a child. You can find an countless number of Ruby projects, filter them, sort them and read the source code to learn from it. Just pick some random accounts owned by notable Ruby developers, explore their programming habits and learn new exciting best practices and patterns.

Even with these newly available resources, there are many times when an quick reference can come in most handy.

Whether you are a Ruby master or a newbie, I hope you’ll find the Rubyist to be a source of inspiration.

No related posts.

This article targets Rails 3 and Rails 3.1. The information contained in this page might not apply to different versions.

There are several ways to force your Rails application to use SSL and the HTTPS protocol.

Rails >= 3.1

If you are using Rails 3.1 (currently available in beta1) or greater, this commit makes it incredibly easy to switch from HTTP/HTTPS and vice-versa.

Simply use config.force_ssl = true in your environment configuration.

You can also selectively enable https depending on the current Rails environment. For example, you might want to keep HTTPS turned off on development, and enable it on staging/production.

Behind the scenes, Rails adds the awesome Rack::SSL Rack middleware to your application middleware stack. Rack::SSL automatically filters the request, redirects not-HTTPS requests to the corresponding HTTPS path and applies some additional improvements to make sure your HTTPS request is secure.

Rails < 3.1

If you’re not using Rails 3.1 don’t worry. Enabling HTTPS is as easy as adding the following line to your environment configuration.

Note that I’m passing Rack::SSL as string to delegate the loading of the class at the end of the Rails application initialization. Also note the middleware must be inserted in a specific position in the stack, at least before ActionDispatch::Static and ActionDispatch::Cookies.

Don’t forget to define Rack::SSL dependency in your Gemfile.

Enabling HTTPS and HTTP in parallel

Transitioning an HTTP-based application to HTTPS might not be as easy as you think, especially if your application embeds assets from third-party hosts.

There are cases where you want to make your application available using both HTTP and HTTPS. For instance, we adopted this strategy in RoboDomain for a while when we moved the application to HTTPS.

Rack::SSL has a very interesting and undocumented feature. You can pass an :exclude option to determine when to enable/disable the use of HTTPS.

The following code enables Rack::SSL and all its filters only in case the request comes from a HTTPS connection.

Both the following URLs will continue to work, but the first one will trigger the Rack::SSL filters.

This solution also works very well for cloud providers like Heroku and completely replaces home-made solutions like the one I posted in this StackOverflow answer months ago, also featured here and here.

If you want to use SSL on Heroku and redirect the HTTP traffic to HTTPS, my suggestion is to go with Rack::SSL.

Related posts

1. Upgrading to Rails 3: You are using the old router DSL which will be removed in Rails 3.1
2. The Road to Rails 3: make your Rails 2.3 project more Rails 3 oriented
3. Configuring a Git repository with Redmine

A couple of days ago I was notified about a but in a Rails application. The application crashed when trying to create a new record.

I changed the new action the day before, but I was sure all the tests passed and the action was covered with a pretty reasonable RSpec test suite. Moreover, the action method was one of the most simplest methods I have ever written.

I run the test suite, all green. I executed the page in the browser, it crashed.

My face when I discovered all tests passed but the action kept crashing.

After several minutes of debugging I discovered the culprit: RSpec (actually the RSpec Rails gem) doesn’t render the content of the action by default, like the common Rails functional tests do. In fact, @response.body always resulted in an empty string.

The view contained a statement like the following

that was misspelled and crashed when the template was rendered. But because RSpec doesn’t render the Rails views, the view was not covered by the tests at all.

The solution is simple and is called render_views.

To tell a controller to render the content of the view, simply call render_views.

You can also enable render_views globally, in your spec_helper.rb file.

The reason behind this choice is because RSpec Rails actually provides a special RSpec group called “view specs”.

According to the documentation, this is the right way to test Rails templates in RSpec. Honestly, I never really liked this feature and I tend to keep using controller specs — the RSpec equivalent of functional tests — (or alternative test tools) to test the views.

Related posts

1. Get the currently described class in RSpec
2. User profile permalinks with Ruby on Rails (and Authlogic)
3. New in Whois: Gem Testers

This article targets Rails 3. The information contained in this page might not apply to different versions.

This is article is part of my series Understanding Ruby and Rails. Please see the table of contents for the series to view the list of all posts.

A small-but-interesting feature introduced in Rails 3 is the built-in support for lazy loading.

Lazy loading is a very common design pattern. The concept is to defer initialization of an object until the point at which it is needed. This design pattern decreases the time required by an application to boot by distributing the computation cost during the execution. Also, if a specific feature is never used, the computation won’t be executed at all.

With Rails 3 you can now register specific hooks to be lazy-executed when the corresponding library is loaded.

In this case we register the block to be executed when the ActiveRecord library is loaded. If you read the ActiveRecord::Base source code, the very last line is a call to

This line of code executes all the hooks previously registered for ActiveRecord.

lazy-load hooks in the wild

Perhaps one of the most frequent usage of the lazy-load hooks is in Rails plugins.

For example, if your plugin needs to register some helpers, you can write a hook to include the helpers in ActionView only when ActionView is loaded. If the environment is loaded from a rake task (which doesn’t necessary need ActionView), then your plugin hook won’t be executed and the Rails application will boot faster.

Here’s an example from the will_paginate gem.

Using lazy load in your libraries

So far, we only discussed about using lazy-loading to hook Rails core library. Because lazy-loading is an ActiveSupport feature, you can use it in your Rails applications but also in your own Ruby classes.

First, make sure to add a call to ActiveSupport.run_load_hooks at the end of your Ruby class.

Now you can register on_load hooks everywhere passing the name of the library used in run_load_hooks.

Hook context

The run_load_hooks method takes a second parameter representing the context within the hook will be executed. It’s a common pattern to pass the class/instance the hooks refer to.

For instance, the ActiveRecord library mentioned at the beginning of the article passes self. In that context, self references the ActiveRecord::Base class.

This is useful because, if you want to include some custom methods into ActiveRecord, you can use the following block

instead of

There’s also an other interesting use case for this feature. If you want to perform some kind of lazy-initialization when an instance of a class is created, just pass the instance itself.

Source Code

The source code of the lazy-loading feature is available in the lazy_load_hooks.rb file.

Related posts

1. Understanding Ruby and Rails: Reading Source Code
2. Understanding Ruby and Rails: Rescuable and rescue_from
3. Understanding Ruby and Rails: extract_options! from Arrays

Whois is an intelligent, pure Ruby, WHOIS client and parser. It provides a flexible and programmable API to query WHOIS servers and look up IP, TLD, and domain WHOIS information. It also offers command-line interface to run WHOIS queries from the console.

This second major release, the 60th since I released the gem, is a very important milestones. I started working on this project with the idea of creating a Ruby parser for each TLD available and it took me two years and countless hours to reach this goal.

Some stats

To give you a rough idea about the complexity of this project, here’s a few numbers about Whois 2.0.

• 866,706 different WHOIS records (~3.3 GB of data) analyzed as of March 16th, 2011
• 425 RSpec test files
• 444 fixture files extracted from real WHOIS records
• 3787 RSpec examples and an unknown number of matches (sorry, I stopped keeping track of them when they reached 15k assertions) that probably makes this project one of the gems with the largest RSpec test suite
• ~20.000 lines of code, including the test files
• 168 different WHOIS parsers

Oh, man. You can’t believe the amount of work required to cover all the existing WHOIS servers, their features and especially their whims.

New and Notable

The increasing support for all existing TLD servers is probably one of the most important changes for this milestone. But the CHANGELOG is very huge and there are a few other changes that are worth a mention.

I already blogged about a few of them.

• The #nameservers property now returns a Nameserver object. This change allows the parser to also extract name server IPv4 and IPv6 addresses.
• A new caching mechanism reduces the number of instance variables created.
• The library now supports the Gem Testers project.
• You can now bind a different address or port to the WHOIS socket request.

Last but not least, the Whois::Answer class has been renamed to Whois::Record.

There are a couple of backwards-incompatible changes to the API. These changes were necessary to evolve the API to better reflect the representation of the existing WHOIS responses.

What’s Next?

The Whois library is pretty stable. It is now used in production for several big projects.

The API is mature. A few changes have been made in this major release to support additional WHOIS properties, however I don’t expect big changes in the future.

The following releases will focus on increasing the list of supported properties for each parser, as well closing some of the existing issues.

The biggest change in the API in the near future is likely to be the standardization of the status property.

In the last months I received some great feedback from people using my library with other platforms, such as Java and .NET. This is amazing.

If you have any case study, case history or feedback, please let me know. I would love to learn more about how you use the library.

How to Upgrade

To upgrade to Whois 2.0 please follow the instructions in the documentation page.

Related posts

1. Whois 0.9.0: WHOIS parsers, CLI and performances
2. New in Whois: Applying the Principle of Least Surprise
3. New in Whois: property is set?

Mark is the author of several other publications including Dive Into Accessibility, Dive into Python, Dive Into Greasemonkey. Not surprisingly, his site is called Dive Into Mark.

But hey. Why isn’t this book called Dive Into HTML 5? I’m glad you asked. Actually, this appears to be the original title. The book is entirely available for free on the web at the Dive Into HTML 5 website. Honestly, I don’t know the reason why the title was changed for the printed version.

HTML5 Up and Running provides a practical overview of the new features already available in HTML 5. HTML 5 is not a standard (yet), but browsers such as Safari, Firefox, Opera and Chrome already support many if its feature.

One of the first things you’ll learn reading this book, is that HTML 5 is not one big thing. Here’s what Mark said in the introduction.

You may well ask: “How can I start using HTML5 if older browsers don’t support it?” But the question itself is misleading. HTML5 is not one big thing; it is a collection of individual features. So you can’t detect “HTML5 support,” because that doesn’t make any sense. But you can detect support for individual features, like canvas, video, or geolocation.

HTML 5 is closer than you think.

For example, by reading this book you will learn that the iPhone and the iPad already support the new HTML 5 input features and attempt to adapt the keyboard layout according to the input type.

An email input type, like this following one

on the iPhone and iPad will trigger the email-keyboard that contains a smaller-than-usual space bar, plus dedicated keys for the @ and . characters.

Isn’t this amazing?

Structure

HTML5 Up and Running is divided into an introduction, 11 chapters, and 2 appendix.

Here’s the table of content:

• Introduction: Five Things You Should Know About HTML
• A Quite Biased History of HTML5
• Detecting HTML5 Features: It’s Elementary, My Dear Watson
• What Does It All Mean?
• Let’s Call It a Draw(ing Surface)
• Video in a Flash (Without That Other Thing)
• You Are Here (And So Is Everybody Else)
• A Place To Put Your Stuff
• Let’s Take This Offline
• A Form of Madness
• “Distributed”, “Extensibility”, And Other Fancy Words
• Manipulating History for Fun & Profit
• The All-In-One Almost-Alphabetical No-Bullshit Guide to Detecting Everything
• HTML5 Peeks, Pokes and Pointers

The book is very easy to read. It contains tons of examples, a very simple tone and several references. However, previous programming experience is recommended, especially if you plan to use advanced JavaScript-oriented features.

Examples, Examples and Examples

As I already mentioned, the book is full of contextual hints and examples. This is really cool because examples help you to remember an information.

You don’t need to trust me, you can check with your own eyes. Go for example to the Canvas chapter and see how well it is explained. I honestly can’t imagine a better way to do this.

This is not a book to learn HTML

Remember, even if HTML5 Up and Running is easy to read and full of examples, it isn’t the right book to start learning HTML. This book assumes you already know about HTML, CSS and JavaScript.

Nevertheless, the How did we get there chapter is one of the best article I ever read about the history of HTML.

And if you happened to migrate all your websites to XHTML (like the 90% of developers did) in the last 5 years, you might probably want to read the everything you know about xhtml is wrong paragraph — *sigh*.

Remember, JavaScript is the future

Since I mentioned JavaScript, let me take the time to highlight a very important concept: JavaScript is the future.

It doesn’t matter if you are developing a mobile web site, an iPad product, a Rails application, an interactive HTML 5 interface. JavaScript is the future.

JavaScript stands to development like parsley stands to kitchen. You find it almost everywhere. Think about jQuery Mobile, Sencha Touch, unobtrusive Rails 3 helpers, Cappucino, HTML 5 Modernizr library, etc. these are just a few examples of how JavaScript is evolving and entering our life.

If you are a developer or designer, you can’t continue to ignore JavaScript. And JavaScript appears to be even more important in HTML 5 because several features are designed to work with JavaScript. I’m talking about Geo Localization, Canvas and Local Storage, just to name a few.

So do yourself a favor: take the time to start learning and experimenting with JavaScript.

In conclusion

I enjoyed this book. I appreciated the HTML 5 introduction, the history of HTML and the tutorial about detecting HTML 5 features. But the chapter I enjoyed the most is the one about the new HTML 5 form inputs, probably because I have been able to start experimenting with them immediately.

Where to Find HTML 5 Up and Running

You can get a printed or Kindle copy at Amazon.com, Amazon.co.uk, or at your other favorite book seller.

Related posts

1. Learning jQuery 1.3 Book Review
2. Design Patterns in Ruby Book Review
3. Eloquent Ruby Book Review

After a brief discussion, we ultimately agreed that he couldn’t effectively use Rails without being a Rubyist. For this reason, I offered him to start with a Ruby concentrate, carefully prepared keeping an eye on Rails.

The presentation is called Ruby 4 Rails and is now available on GitHub. It is based on ShowOff, a Markdown-to-HTML presentation tool created by Scott Chacon. Make sure to read the README to learn how it works.

The initial part of the README is largely inspired by John’s post about Ruote.

Ruby 4 Rails is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. Based on a work at github.com.

Related posts

1. Ruby on Rails and Canonical link tag
2. TabsOnRails: creating and managing Tabs with Ruby on Rails
3. User profile permalinks with Ruby on Rails (and Authlogic)