bgror

How to fix the Ruby 1.9 HTTPS/Bundler segmentation fault on OS X Lion »

Created at: 09.05.2012 21:38, source: Phusion Corporate Blog, tagged: ruby

If you’ve installed a gem bundle on OS X Lion the past few weeks then you may have seen the dreaded “[BUG] Segmentation fault” error, where Ruby sees to crash in the connect C function in http.rb. Upgrading to the latest Ruby 1.9.3 version (p194) doesn’t seem to help. Luckily someone has found a solution for this problem.

It turns out the segmentation fault is caused by an incompatibility between MacPort’s OpenSSL and RVM. MacPorts installs everything to /opt/local but RVM does not look for OpenSSL in /opt/local. We solved the problem by reinstalling Ruby 1.9.3 with the MacPorts OpenSSL, as follows:

sudo port install libyaml
rvm reinstall ruby-1.9.3 --with-openssl-dir=/opt/local --with-opt-dir=/opt/local

Five Common Rails Mistakes »

Created at: 06.05.2012 06:01, source: Mike Perham, tagged: rails ruby

I’ve worked with Rails for quite a while now and in that time I’ve seen a lot of Rails applications and both read and written a lot of bad Ruby code. Here’s five common mistakes that I see in almost every Rails codebase.

1. Migrations with no schema specifics

Your data model is the core of your application. Without schema constraints, your data will slowly corrode due to bugs in your codebase until you can’t depend on any fields being populated. Here’s a Contact schema:

  create_table "contacts" do |t|
    t.integer  "user_id"
    t.string   "name"
    t.string   "phone"
    t.string   "email"
  end

What is required? Presumably a Contact must belong_to a User and have a name — use database constraints to guarantee this. By adding :null => false, we ensure that the model is always consistent even if we have bugs in our validation because the database will not allow a model to be saved if it fails those constraints.

  create_table "contacts" do |t|
    t.integer  "user_id", :null => false
    t.string   "name", :null => false
    t.string   "phone"
    t.string   "email"
  end

Bonus points: use :limit => N to size your string columns appropriately. Strings default to 255 characters and phone probably doesn’t need to be that big, does it?

2. Object-Oriented Programming

Most Rails developers do not write object-oriented Ruby code. They write MVC-oriented Ruby code by putting models and controllers in the expected locations. Most will add utility modules with class-methods in lib/, but that’s it. It takes 2-3 years before developers realize: “Rails is just Ruby. I can create simple objects and compose them in ways that Rails does not explicitly endorse!”

Bonus points: introduce facades for any 3rd-party services you call. Provide a mock facade for use in your tests so that you don’t actually call the 3rd party service in your test suite.

3. Concatenating HTML in helpers

If you are creating helper methods, kudos, at least you trying to keep your view layer clean. But developers often don’t know the basics of creating tags within helpers, leading to messy string concatenation or interpolation:

str = "<li class='vehicle_list'> "
str += link_to("#{vehicle.title.upcase} Sale", show_all_styles_path(vehicle.id, vehicle.url_title))
str += " </li>"
str.html_safe

Yikes, it’s ugly and can easily lead to XSS security holes! content_tag is your friend.

content_tag :li, :class => 'vehicle_list' do
  link_to("#{vehicle.title.upcase} Sale", show_all_styles_path(vehicle.id, vehicle.url_title))
end

Bonus points: start introducing helper methods that take blocks. Nested blocks are a natural fit when generating nested HTML.

4. Giant queries loading everything into memory

You need to fix some data so you’ll just iterate through it all and fix it, right?

User.has_purchased(true).each do |customer|
  customer.grant_role(:customer)
end

You have an ecommerce site with a million customers. Let’s say each User object takes 500 bytes. This code will take 500MB of memory at runtime! Better:

User.has_purchased(true).find_each do |customer|
  customer.grant_role(:customer)
end

find_each uses find_in_batches to pull in 1000 records at a time, dramatically lowering the runtime memory requirements.

Bonus points: use update_all or raw SQL to perform the mass update. SQL takes time to learn well but the benefits are even more tremendous: you’ll see a 100x improvement in the performance.

5. Code review!

I’m guessing you are using GitHub and I’m also guessing you aren’t using pull requests. If you spend a day or two building a feature, do it on a branch and send a pull request. Your team will be able to review your code, offer suggestions for improvement and possible edge cases that you didn’t consider. I guarantee your code will be higher quality for it. We’ve switched to using pull requests for 90% of our changes at TheClymb and it’s been a 100% positive experience.

Bonus points: Don’t merge pull requests without tests for at least the happy path. Testing is invaluable to keep your application stable and your sleep peaceful.

Did I miss any common issues? Leave a comment and let me know!

Update: use find_each rather than find_in_batches, thanks readers!

Introducing Bloggy: A simple way to add a Jekyll blog to any Rails application »

Created at: 03.05.2012 20:22, source: Engine Yard Blog, tagged: Engine Yard Cloud Open Source ruby Technology

One of the most popular tools our customers use to help drive traffic to their site is a company blog. Blogs that are informative and helpful will attract your target audience and bring attention to your website, and more importantly, your work.

Here at Engine Yard, we have found that some of our best sources of traffic are the blog posts written by our team that help educate customers on our product.

In particular, there is one blogging platform that has really started to catch on with the hacker community and especially those of us who love Ruby.

Authored by Tom Preston-Warner, Jekyll is an open-source blog-aware static site generator. Unlike Wordpress, Tumblr, Posterous, Blogger and the like, it allows users to write posts in the editor of their choice with the markup they prefer and then commit the posts to git. I use Markdown to write my posts, but many others choose to write their posts in HTML because they were coming from WordPress and it felt more at home.

Currently, there are lots of posts out there detailing how to get started with Jekyll, how to run Jekyll as a Rack application, etc. What I want to talk about is just a little bit different from these posts.

Let's start with a simple concept. For SEO purposes it is better if your blog runs at http://mydomain.com/blog rather than http://blog.mydomain.com. We can go into detail here later but that's really for an entirely different post. Again there are numerous ways of accomplishing this task but I want to talk about doing it with Jekyll.

Finding a way to run your blogging platform within your existing application without many changes to the server configuration is a common cost cutting technique for bootstrapping startups, well-funded companies and even public corporations. One thing we know first hand is how time consuming and difficult that has proven to be for many of you over the years.

That’s why I wrote Bloggy. Simply put, Bloggy makes it easy to run a Jekyll blog right within your existing Rails application with no changes to your current configuration on Engine Yard.

Installing and configuring the Bloggy gem

Start by adding

gem ‘bloggy’

to your Gemfile in your repo, then just run

$ bundle

and it should be ready to go for you. Alternatively, you could install it by running

$ gem install bloggy

Once Bloggy is installed, all you need to do to get a working blog up and running is to use the provided Rails generator.

$ rails g jekyll:blog blog

BAM! This just generated your new blog and it’s live at http://yourdomain.com/blog

Go ahead start up your Rails server and check it out.

What Just Happened?

The static HTML generated by Jekyll (the magic behind Bloggy) goes to your public/blog directory, but the rest of the files live at config/jekyll and this is where you will create new posts, change the default look and feel of your blog and make any configuration changes you desire as you get acquainted with Jekyll.

If you’ve never used Jekyll before, you need to familiarize yourself with a few things.

1. Bloggy Generates static HTML from the markdown files that live inside the config/jekyll/_posts directory, so this is where you will create new posts (more on how to make the generation happen later).

2. The default layout of the Bloggy generated blog is found at config/jekyll/_layouts/default.html. This file is plain ole HTML and can be edited to your liking just like you would edit any other HTML file.

3. The config/jekyll/css directory contains, wait for it … your CSS files!

Configuration and new posts

If however, you are familiar with Jekyll already you will be delighted to know you can still choose from all of the options you enjoyed with the Jekyll gem previously.

The same familiar config elements of Jekyll can be accessed using the _config.yml file that is now neatly tucked away in the config/jekyll directory of your Rails application.

Now that your new blog is installed and serving pages at http://yourdomain.com/blog you probably are thinking:

“Zach this is great, but how do I write a new blog post? How do I get rid of the test post you provided me?”

Those are great questions. I’ll start with the simplest:

1. To get rid of the generated test post, simply delete the file from your config/jekyll/_posts.

$ rm appname/config/jekyll/_posts/2012-04-25-a-test-post.markdown

2. And to create a new post it’s not much more complicated. Just run the Rake task provided with Bloggy, which will automatically generate a post and open it so you can start writing right away.

$ rake np your_post_title

This will by default open up your new post in TextMate. If you don’t have TextMate or prefer another editor you can just change mate on this line at the end of the new_post.rake file located in your appname/lib/tasks directory.

‘mate #{path}’  - for example if you wanted to use vim you should use  ‘vim #{path}’

Now, if you’re looking carefully at the created post you will notice that your post was named with a slightly different scheme than just your title. This is critical to Jekyll being able to recognize and generate your posts into static HTML files that your application can serve, so please do not change this. For example if you ran that task today your post would look something like this:

2012-05-03-your-post-title.markdown

Feel free to change the date just make sure you leave it in the correct format, but keep in mind that YAML is required at the top of your post (including the dashes) for Jekyll to generate Metadata when generating the final HTML that you will see your posts rendered in. So the top of your file should always look something like this:

---
layout: post
published: false
title: A Test Post
---

The Rake task provided takes care of that for you but be sure to edit your title and add any other metadata you want included. Other than that, just be sure to change published: false to published: true so Jekyll knows your post is ready to go live on your blog for the world to see. Once you have written, edited and reviewed to your liking all you need to do is another Rake task.

$ rake generate

From there Jekyll will automatically regenerate your posts as static HTML files stored in the public/blog directory and these files will be served from http://yourdomain.com/blog with no additonal Nginx configuration.

You will have to hit CTRL + C on your keyboard after the files are generated to stop the Jekyll server as it wants to stay on and continually look for new posts to generate.

Now from your application directory you can just run a few commands to make sure you have added your changes to git and pushed them to your repo.

$ git add .

$ git commit -m ‘your commit message’

$ git push

Then deploy to Engine Yard using our awesome CLI tool! by running

$ ey deploy

That’s it! It’s really that simple.

So go check out Bloggy and be sure to fork and contribute if you want to see something added to Bloggy that would help you even more!

I have a sample application for you guys to play around with at our Engine Yard GitHub account.

Alternatively, you can just checking it out in action by clicking here.

Happy blogging!

One Quarter of Sidekiq »

Created at: 02.05.2012 06:34, source: Mike Perham, tagged: ruby

It’s been about three months since I released Sidekiq. Let’s get to the numbers:

• 668 GitHub watchers
• 171 issues, 11 open
• 7 commercial licenses purchased!
• 54 pull requests with 30+ different developers!
• 1 EngineYard podcast interview
• 1 RailsConf lightning talk by @jwo
• 1 South African Ruby group talk on Sidekiq!
• 1 new license (LGPL rather than GPL)
• 0 locks in the multithreaded codebase

I consider that a success; I’ve never had a project grow this fast with just my own promotion and community word of mouth. TheClymb switched to Sidekiq last week and our biggest problem so far has been that Sidekiq can be too parallel and crush servers with traffic; we’ve had to rewrite some jobs to be serial!

My goals remain the same:

• Provide the easiest and best supported queueing system for Ruby.
• Be the first Rubygem people mention or consider when choosing a queueing system
• Improve Ruby’s overall efficiency and perceived performance through multi-threading.
• Evangelize multi-threaded infrastructure written with actor abstractions as relatively straightforward for knowledgable developers to build. Celluloid continues to be a huge asset to Sidekiq’s ease of development and stability.

Thank you all for your support so far! Thank you especially to EngineYard, Tony Arcieri and the early adopters that have made hacking on Sidekiq an exciting adventure rather than a lonely chore.

rspec-expectations-2.9.1 is released! »

Created at: 03.04.2012 22:18, source: David Chelimsky, tagged: bdd rspec ruby

This is a bug-fix only release, and is recommended for everybody using rspec-2.9.

full changelog

Bug fixes

• Provide a helpful message if the diff between two objects is empty.
• Fix bug diffing single strings with multiline strings.
• Fix for error with using custom matchers inside other custom matchers (mirasrael)
• Fix using execution context methods in nested DSL matchers (mirasrael)