bgror

New Ruby 1.9 Features, Tips & Tricks »

Created at: 03.02.2011 19:27, source: igvita.com, tagged: ruby ruby1.9 tips

Ruby 1.9 packs in a lot of new and improved features at all levels: it introduces a few new syntax constructs, the built-in libraries have been updated with hundreds of new methods and classes, it adds language level support for characters encodings, it ships with an entirely new virtual machine, and the list goes on. If you haven't already, you should seriously consider upgrading to Ruby 1.9 as it is a definite step up from the previous versions in all respects.

For the most part, you could upgrade from Ruby 1.8.x and remain blissfully unaware of the many updates and improvements within the language - but what fun would that be? For the curious, Ruby 1.9 Pickaxe is probably the single best resource to get yourself up to speed. To give you a flavor, below is a list of my favorite 30 tips, tricks and features - feel free to clone the gist and add your own!

New Ruby 1.9 Features, Tips & Tricks

In case you can't preview the gist: direct link, or see the raw file.

more »

Ruby Performance Testing Tips and Tricks »

Created at: 13.01.2011 01:31, source: Engine Yard Blog, tagged: Partners Technology tips

Use em_proxy to load-test code changes

by Jason Morrison Running a high-traffic site with little room for downtime could make deploying large changes daunting. What if your new code has a large impact on performance? We’ve been in this situation several times with Hoptoad as we make large changes and improvements to the codebase. Things like changing databases, upgrading major versions of Rails, and adding queueing can have unpredictable effects on performance. Little things can have a big effect, too, when most of your traffic is focused in one write-heavy API endpoint. We’ve boosted our confidence in rolling out these changes by performance testing ahead of time. We’ve tried a variety of synthetic load testing approaches, but the most realistic way to do this is by using real traffic. We use Ilya Grigorik’s em-proxy to fork traffic in real time from our production environment to a load testing environment which is identical save for the new code. (See the duplex.rb example in em-proxy). We use Engine Yard’s “Clone Environment” feature to make a reasonably up-to-date copy of production, and we use a Chef recipe to toggle em-proxy on and off. We use New Relic RPM to keep an eye on performance, and make sure that the load testing environment performance is acceptable. Once we’ve run a few hours to a day’s worth of traffic, we’ll shut down the load testing environment, and deploy the change live.

Automatic cucumber step generation with factory girl

by Dan Croak Did you know that Factory Girl includes some steps for your integration testing pleasure? They are currently available but remain relatively unknown. Let's assume you've defined your factories normally in test/factories.rb or spec/factories.rb:

Factory.define :user do |user|
  user.email                 { Factory.next(:email) }
  user.password              { "password"   }
  user.password_confirmation { "password"   }
end

Factory.define :author, :parent => :user do |author|
  author.after_create { |a| Factory(:article, :author => a) }
end

Factory.define :recruiter, :parent => :user do |recruiter|
  recruiter.is_recruiter { true }
end

Once those are in place, and assuming you've otherwise loaded factory girl correctly, add this to features/support/env.rb:

require 'factory_girl/step_definitions'

Then, write Cucumber features using the simple "create record" step:

Given a user exists

...or the "create record & set one attribute" step:

Given an author exists with an email of "author@example.com"

...or the "create record & set multiple attributes" step:

Given the following recruiter exists:
| email            | phone number | employer name |
| bill@example.com | 1234567890   | thoughtbot    |

These steps will be available for all your factories, so stop writing boilerplate steps and shake what Factory Girl gave you.

(Testbot * Fog) + Hudson = Faster Tests!

by Nick Quaranto Test suites can get slow, even when running on one high powered machine. So why not spin up EC2 instances and distribute the tests? This is made really easy with testbot, a distributed test runner. It works like so:

1. A requester kicks off the process, asking for tests to be run
2. The server determines how many tests to run and how they will be distributed
3. Runners on your army of EC2 instances execute the tests given to them
4. THE KICK! (back up to the server)
5. BAWWWWWWWW (results get returned to the requester)

Visually, it looks like: (thanks to the testbot readme)

Requester -- (files to run) --> Server -- (files to run) --> (many-)Runner(s)
^                               |    ^                                      |
|-------------------------------|    |--------------------------------------|
             (results)                            (results)

In our situation, the requester is Hudson (CI server project), which gets kicked off when we commit to GitHub. Testbot not only supports multiple machines but also multiple cores, so our tests run on 16 medium instances in 32 different processes. We start up the boxes on EC2 using a fork of cloud_bot, which uses fog to quickly spin up instances and runs a simple bash script to install what we need to run the app's tests. The result: Instead of a 60+ minute test suite, the tests run in around 10 minutes. If your tests need a major speed boost, definitely look into testbot.

Hoptoad deploy tracking resolves errors

by Matt Jankowski This has been around for quite some time, but we still get a lot of questions about it. People who use hoptoad, our web-based error tracking application, often will ask how they “resolve all errors” in their account. Typically, they’ve been running production code for a while and have accumulated a lot of “old” errors that they want to stop paying attention to. They’d like to focus instead on errors that are happening NOW and not be distracted by things they might have fixed. There are two ways to resolve all, and both are connected to deployment. If you have an account that supports this, and you use capistrano, then this feature “just works”. When you do a deployment using capistrano, you’ll see output towards the end of the deploy indicating a request to hoptoad has been made which tells it about the deploy. The next time you access your hoptoad account, you’ll see that all previous errors have been marked as resolved, and will only be reopened if they keep coming in. If you don't use capistrano, you can get the same effect by running a rake task. Running “rake hoptoad:deploy TO=production” (where production is the name of whatever environment you’d like to resolve all errors for) will have the same effect. We've found that on hosting platforms where you can't use capistrano, you can usually find some sort of post deploy hook to help automate this step as well. We’ve resisted adding this functionality to the web interface, because in our opinion there is never a scenario where someone should want to resolve old errors that doesn’t also coincide with a deployment.

more »

Getting Setup for Ruby on Rails Development »

Created at: 01.12.2010 21:30, source: Engine Yard Blog, tagged: Technology tips development linux mac rails ruby setup tutorial windows

The Resources for Getting Started With Ruby on Rails seemed to be useful for a lot of people. However, it was a post geared for people who had already setup their computers for development work. So I created a tutorial for those of you who haven't yet set up your computers for Ruby on Rails development. Just go to the Engine Yard Documentation Area, in the tutorials section. There you'll find instructions for setting up your computer, basic git commands, and a step-by-step tutorial on creating an application with Rails 3 and Bundler. Each section is designed to be useful by itself, so if you just want to learn more about Bundler or Rails 3 you can. If you have any feedback on how to improve the tutorials let me know in the comments section. Also, if you want to take a hands-on training course on how to develop a Rails application, you might want to attend the Zero to Rails 3 class which is happening (online) December 20-23.

more »

14 Bare Minimum Security Checks Before Releasing a Rails App »

Created at: 23.10.2010 02:48, source: Rails Inside, tagged: tips

When you upload your latest app to a production Web server and open it up to the world, you're really throwing your app to the elements - good and bad. If you don't pay any attention to security whatsoever, you're likely to fall foul of some cracker's nefarious scheme and your users will be complaining when something doesn't work or they're being spammed by geriatric Nigerian clowns with pots of gold to share. But what to do?

Luckily, help is at hand in the shape of the official Ruby on Rails Security Guide, but Irish Rails developer Matthew Hutchinson has trawled through that guide as well as several illuminating blog posts relating to Rails security, and put together a 14 step checklist of "bare minimum" security checks to do before releasing your Rails app.

In summary:

1. Don't trust logged in users. (Authentication is one thing, authorization to perform certain tasks is another.)
2. Beware of mass assignments. (Use attr_accessible in your models!)
3. Make some attributes un-editable with attr_readonly.
4. Watch out for SQL injection vectors. (Raw SQL in your code is a smell worth investigating.)
5. Prevent executable files from being uploaded.
6. Filter sensitive parameters from the logs.
7. Beware CSRF (Cross-Site Request Forgery) and use protect_from_forgery and csrf_meta_tag.
8. Beware XSS (Cross-Site Scripting) and use the h helper in views (this is the default in Rails 3, luckily).
9. Watch out for session hijacks.
10. Avoid using redirects to user supplied URLs.
11. Avoid using user params or content in the send_file method.
12. Make non-ActionController methods private.
13. Check your dependencies for security updates and patches.
14. Don't store passwords in the database as clear text.

Want more detail? Check out Matthew's article.

[ad] coder.io is a tagged developer news source. Want to subscribe to stories about Ruby but not Rails? Just use the query #ruby -#rails. Or how about Ruby screencasts?

Tweet This Post

more »

HOWTO: Unobtrusive JavaScript with Rails 3 »

Created at: 24.05.2010 16:04, source: Rails Inside, tagged: tips

This post is by Rizwan Reza. See footer for more info.

One of the big surprises and accomplishments is the fact that Unobtrusive Javascript made it into Rails 3. At first, we thought UJS wasn’t going to be included in Rails 3. Well, just before the first beta came out, the community responded well and a bunch of enthusiastic developers finished up one of the most wanted feature in Rails 3.

Rails has always been about staying on the cutting edge and Rails 3 is no surprise, UJS implementation in Rails 3 takes benefit of the new HTML5 data-*@ attributes. So Rails doesn’t spit out Prototype-based Javascript inline (the old helpers are still here). Rather, the helpers just define an appropriate data attribute in the tag, and that’s where Javascript comes in.

This literally means you can pick the data attributes in any Javascript framework and write generic code to support Ajax implementation of any kind. As you can imagine, this can be a highly flexible approach for demanding applications. But there’s more, the generic Prototype implementation is included with Rails 3 and the jQuery version is maintained officially here.

Let’s see how easy it is to swap jQuery in Rails 3. In the root of a Rails 3 application, run:

curl -L http://code.jquery.com/jquery-1.4.2.min.js > public/javascripts/jquery.js
curl -L http://github.com/rails/jquery-ujs/raw/master/src/rails.js > public/javascripts/rails.js

Here’s an initializer I got to know from Yehuda that you can define in config/initializers so javascript_include_tag :defaults uses jQuery instead of Prototype.

module ActionView::Helpers::AssetTagHelper
  remove_const :JAVASCRIPT_DEFAULT_SOURCES
  JAVASCRIPT_DEFAULT_SOURCES = %w(jquery.js rails.js)

  reset_javascript_include_default
end

With that set, Rails is now unaware of Prototype, all of the helpers with :remote => true will be grabbed by rails.js and worked through jQuery. You might also want to remove the Prototype libraries inside public/javascripts if you’re not going to use them.

As you can see, UJS in Rails 3 is pretty easy. Though there is a bit of a configuration to be done if you’re going against the default option in Rails, it’s far easier to work with than in the previous versions. You should also look at the fantastic Rails 3 Release Notes for changes in the concerned helpers and the section on Unobtrusive Javascript in my article on RailsDispatch.

[post by] Rizwan Reza is a passionate, self-taught developer and designer who’s been working with Rails since early 2005. He had his first Rails patch accepted in mid 2008, and has been contributing code and fixes ever since. Rizwan focuses on the start-to-finish product experience, all the way from branding to the application backend. Get in touch with him at contact at rizwanreza.com.

Tweet This Post

more »