bgror

Coming soon: rvm get stable »

Created at: 07.11.2011 19:53, source: Engine Yard Blog, tagged: ruby

rvm get stable

rvm get head

rvm get stable

rspec-2.8.0.rc1 is released »

Created at: 06.11.2011 19:02, source: David Chelimsky, tagged: bdd rspec ruby

I just released rspec-2.8.0.rc1, which includes releases of rspec-core, rspec-expectations, rspec-mocks, and rspec-rails. Changelogs for each are at:

• rspec-core
• rspec-expectations
• rspec-mocks
• rspec-rails

What’s new

Nothing really changed in rspec-rails or rspec-mocks, but rspec-core and rspec-expectations have both gotten some nice improvements.

Configuration (rspec-core)

rspec-core offers a number of configuration options which can be declared on the command line, in a config file (.rspec, ~/.rspec, or custom location), as well as in an RSpec.configure block (in spec/spec_helper.rb by convention). Before this release, some options, but not all, could be stored in config files and then overridden on the command line. The problems were that it was inconsistent (not all options worked this way), and we couldn’t override options that were set in RSpec.configure blocks.

With this release, almost all options declared in RSpec.configure can be overridden from the command line, and --tag options can override their inverses. For example, if you have this in .rspec:

--tag ~slow:true

That means “exclude examples tagged :slow => true“. So the following example would be excluded:

it "does something", :slow => true do
  # ...
end

You can also exclude that example from RSpec.configure like this:

RSpec.configure do |c|
  c.filter_run_excluding :slow => true
end

Note: the naming is different for historical reasons, and we will reconcile that in a future release, but for now, just know that --tag on the command line and in .rspec is synonymous with filter_run_[including|excluding] in RSpec.configure.

Override from command line

Whether the default is stored in .rspec or RSpec.configure, it can be overridden from the command line like this:

rspec --tag slow:true

“Profiles” in custom options files

The rspec command has an --options option that let’s store command line args in arbitrary files and tell RSpec where to find them. For example, you could set things up so your normal spec run excludes the groups and examples marked :slow by putting this in .rspec:

--tag ~slow

Now add a .slow file with:

--tag slow

Now run rspec to run everything but the slow specs, and run rspec --options .slow or rspec -O.slow to run the slow ones.

Override from Rake task

RSpec’s Rake task supports an rspec_opts config option, which means you can set up different groupings from rake tasks as well. The fast/slow example above would look like this:

namespace :spec do
  desc "runs the fast specs" do
  RSpec::Core::RakeTask.new(:fast) do |t|
    t.rspec_opts = '--options .fast'
  end
  RSpec::Core::RakeTask.new(:slow) do |t|
    t.rspec_opts = '--options .slow'
  end
end

Or ..

namespace :spec do
  desc "runs the fast specs" do
  RSpec::Core::RakeTask.new(:fast) do |t|
    t.rspec_opts = '--tag ~slow'
  end
  RSpec::Core::RakeTask.new(:slow) do |t|
    t.rspec_opts = '--tag slow'
  end
end

Implicit true value for tags/filters

This is not new in rspec-2.8, but all the tags/filters in the example above can be written without explicitly typing true:

--tag slow
--tag ~slow

RSpec.configure {|c| c.filter_run_excluding :slow}
 
it "does something", :slow do

You have to set a config option to enable this in rspec-2.x:

RSpec.configure {|c| c.treat_symbols_as_metadata_keys_with_true_values = true}

In rspec-3.0, this will be the default, but without setting this value in 2.x you’ll get a deprecation warning when you try to configure things this way. It’s ugly, I know, but this enabled us to introduce the new behavior without breaking compatibility with some suites in a minor release.

Ordering

With 2.8, you can now run the examples in random order, using the new --order option:

--order rand

The order is randomized with some reasonable caveats:

• top level example groups are randomized
• nested groups are randomized within their parent group
• examples are randomized within their group

This provides a very useful level of randomization while maintaining the integrity of before/after hooks, subject, let, etc.

If you want to run the examples in the default ordering (file-system load order for files and declaration order for groups/examples), you can override the order from the command line:

--order default

Pseudo-randomization

The randomization is managed by Ruby’s pseudo-randomization. This means that if you find an order dependency and want to debug/fix it, you can fix the order by providing the same seed for each run:

--order rand:1234

The seed is printed to the console with each run, so you can just copy it to the command. You can also just specify the seed, which RSpec will assume means you want to run with --order rand:

--seed 1234

Every time you run the suite with the same seed, the examples will run in the same “random” order.

Built-in matchers are all classes in rspec-expectations

The Matcher DSL in rspec-expectations makes it dead simple to define custom matchers that suit your domain. The problem is that it is several times slower than defining a class to do so. While this doesn’t make much difference when you have a custom matcher that you use a few dozen times (where talking hundredths of seconds here), it does make a difference if every single matcher invocation in your entire suite suffers this problem.

The short term fix is that all of the built-in matchers have been re-implemented as classes rather than using the DSL to declare them. This has the added benefit of making it easier to navigate the code and RDoc

Longer term, we’ll try to refactor the internals of the matcher DSL so that it generates a class at declaration time. Eventually.

Summing up

So that’s it. Nothing ground breaking. Nothing compatibility breaking. But some nice new features and improvements that will make your life just a little bit nicer when you upgrade. We’re doing a release candidate because enough changed internally that I want to give you time to try it out, so please, please do so! And please report any issues you’re having with this upgrade to:

• rspec-core
• rspec-expectations
• rspec-mocks
• rspec-rails

Assuming there are no significant issues, I’ll release 2.8 final within a week or two.

Happy spec’ing!

David

The Number One Trait of a Great Developer »

Created at: 04.11.2011 00:25, source: Engine Yard Blog, tagged: ruby

Maybe the best programmers aren’t those who spectacularly solve crazy problems, but those who don’t create them, which is much more silent. – Lena Herrmann

When I look around at other companies hiring Ruby on Rails developers, I see them focusing on three major traits: Super-smart; Large community following; Deep Ruby knowledge. They’re all wrong. While these are great aspects in moderation, they all miss the number one quality of a fantastic developer: Judgement.

A story about Jack and Dianne

Jack is a Rockstar. Jack talks about all the latest trends at all the coolest conferences around the world. Jack makes a point of starting each project with at least three new technologies. When asked to produce an internet-based backend for letting kitchen devices synchronize their list of recipes, Jack went to town. The result was a combination of Google Protocol Buffers, node.js, and Cassandra. Elegant, scalable, and totally unmaintainable.

Dianne is a good developer. Dianne started as a Unix Admin, and moved into Ruby two years ago. When asked to produce the same system, she immediately started asking questions:

“How many devices do we expect to have?”
“Well, we hope to sell 500 in 12 months.”
“How often will they need to report in?”
“Roughly once an hour.”
“How reliable is the network?”
“It’ll use WiFi, so fairly reliable.”

Dianne wrote a RESTful API endpoint in Sinatra with a MySQL DB. PostgreSQL would have been better, but she “knew mysql.”

Will Dianne’s solution scale to 10k users? No, but it doesn’t need to. Dianne’s solution is simple, easy to understand, and highly maintainable. Dianne knew it wasn’t the most elegant solution, but she also knew that anything much more complex would be beyond her current skills.

It’s all about trust

When given what has the oportunity to be a “fun problem,” developers without judgement tend to run to their cave to craft the most elegant solution possible. They have a natural desire to over design the solution either in terms of flexibility, speed, feature scope, or simply to get a chance to play with their new pet technology. They need to be constantly checked on to make sure they aren’t half way down a rabbit hole.

What’s worse is that they won’t know when they’re out of their depth, so they’ll leave code bombs littered throughout your project. Clever little bits of code just waiting for the unweary teammate to trip over.

Hire for Judgement

I leave the team to decide if a candidate is smart and fits our culture, but I take responsibility for figuring out if he has good judgement. To do so, I take him out for a beer, and I ask a couple of leading questions:

1. What’s your least favorite part of Ruby and the Ruby on Rails framework, and why?
2. Tell me about the last time you used an interesting bit of technology, and what you learned from it.

These questions are great for getting a coder to talk passionately about where they’ve been burned and where they had their mind blown. You learn a lot about who they really are and where they’re coming from. Which do they fear most: magic or cut-n-paste? Have they fallen in love with NoSQL stores? Have they learned when not to use them? Have they learned the hells inherent in multi-threaded code? Are they more comfortable in a Kingdom of Nouns, programming functionally, or juggling a bunch of hashes, and why?

Listen to the why’s, and not the what’s, and you’ll hear judgement.

Sass, Compass, and the Rails 3.1 Asset Pipeline »

Created at: 03.11.2011 19:07, source: Engine Yard Blog, tagged: ruby Technology

TL;DR

Compass and the Rails 3.1 Asset Pipeline can play nice to improve how you create, maintain, and serve stylesheet assets, but you’ll may need to tweak your setup to boost speed during your stylesheet development.

Since the advent of dynamic web pages, there has remained a dichotomy in web development. Developers tend to keep server-side code and templates in one spot and all the other static images, stylesheets, and client-side scripts in another. Agency-driven, split team workflows in which designers hand off static pages to web developers to break them into server-side templates have reinforced this model. We even call our stylesheets, images, and scripts assets, as if they were meant to be deposited into our /public folder, not to be handled with our application code. The Rails 3.1 Asset Pipeline breaks down this firewall and makes static assets first-class citizens in your web application. While it also handles images, CoffeeScript, and many other content types, let’s explore what the asset pipeline does for stylesheet authors.

What does the Pipeline do for me?

For serving CSS, the asset pipeline performs a few key functions.

Concatenation. Stylesheets can be stitched together from multiple source files, reducing the number of HTTP requests for CSS assets. The default application.css in Rails 3.1 is a manifest and tells the pipeline which source files to concatenate and serve to the browser:

/*
 * This is a manifest file that'll automatically include all the stylesheets
 * available in this directory and any sub-directories. You're free to add
 * application-wide styles to this file and they'll appear at the top of the
 * compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require_tree .
 */

By default, all stylesheets will be included. Sprockets, the gem that powers the pipeline, allows for more granular control:

/*
 *= require vars
 *= require typography
 *= require layout
 */

Just like view partials, we now get the benefit of organization by splitting up large stylesheets across several source files.

Minification. Whitespace and comments are removed from stylesheets before getting served up to the browser, reducing file size.

Fingerprinting. In Rails 3.1, cache-busting fingerprinting is baked right into the asset filename instead of relying on querystring parameters which have drawbacks in multi-server environments and some transparent proxy servers.

Pre-processing. Perhaps the biggest feature of the asset pipeline is preprocessing. Stylesheets can now be authored in Sass, Less, even ERB (gasp!), introducing dynamic methods to create static stylesheets.

Compass in the pipeline

Many of the above benefits have been available previously with Compass, the stylesheet framework for Sass. It’s no surprise that someone recently asked on the Compass mailing list if Compass was somehow obsolete with the arrival of the asset pipeline.

While it is true that there is some overlap in functionality between Compass and the asset pipeline, Compass does so much more. In addition to concatenation, minification, and preprocessing via Sass, most importantly Compass provides powerful modules for common stylesheet tasks including:

• CSS3. The Compass CSS3 module provides Sass mixins for CSS3 features, allowing you to target multiple browsers’ vendor namespaces using a single syntax.
• CSS sprites. Reducing the number of HTTP requests is a key factor of web application performance. The sprite helpers will create CSS sprites from a folder of separate assets, handling all the geometry for sprite layout, allowing you to reference icons by name.
• Grid frameworks. Compass has great support for Blueprint, 960.gs, Susy, Grid Coordinates, and more.
• Typography. Compass makes it easy to create and maintain vertical rhythm, tame lists, and style links with its typography helpers.
• Plugins and so much more. There is a growing list of community plugins that make it easier to package styles for use across projects.

Installation

To use Compass inside the asset pipeline, be sure to add Compass version 0.11.0 (or edge if you’re brave) to the asset group in your Gemfile:

group :assets do
  gem 'sass-rails',   '~> 3.1.4'
  gem 'coffee-rails', '~> 3.1.1'
  gem 'uglifier',     '>= 1.0.3'
  gem 'compass',      '~> 0.11.0'
end

Once you’ve updated your gem bundle, you can now use Compass mixins in your stylesheets.

Changes for Compass users

If you’ve used Compass prior to Rails 3.1, there are some changes you should be aware of when using Compass in the asset pipeline.

Choose a bundling option. First, decide if you want to let Sprockets manage your stylesheet bundles or simply use Sass partials. You can use Sprockets manifest require and include directives in your Sass files, however there is a simpler approach to include CSS assets in your stylesheets. Simply rename any CSS files to use the .scss. file extension and you can use them as partials in your Sass stylesheets, even if your main stylesheets use the indented syntax and .sass extension.

Watch your assets. If you use the Compass helpers image-url, font-url, etc., note that these helpers will now resolve to /assets instead of /images and /fonts. This means you’ll need to put your images and fonts in app/assets/images and app/assets/fonts respectively instead of their previous homes in the public folder.

Optimizing for development

For all of its features, the asset pipeline comes with tradeoffs. The biggest impact is speed. With the asset pipeline, the entire Rails stack is loaded on each asset request. For small applications, this is trivial. For larger applications with many gem dependencies (especially those employing Rails engines) where many classes are reloaded with every request in the development environment, assets may render much more slowly when rendered via the asset pipeline.

Tweak your setup

If slow asset compilation is slowing down your front-end development, take a look at the rails-dev-tweaks gem from Wavii. The gem provides the ability to tweak Rails’ autoload rules, preventing reloading between requests in development. The default rules skips reloading classes for asset, XHR, and favicon requests:

config.dev_tweaks.autoload_rules do
  keep :all

  skip '/favicon.ico'
  skip :assets
  skip :xhr
  keep :forced
end

You should notice a speed bump, but keep in mind that if you have custom Sass functions, you’ll want to bounce the server to see those changes.

Precompile engine assets

You can speed up your development environment considerably by precompiling assets as you would in production, effectively bypassing the asset pipeline altogether. While this is encouraged for team members who aren’t modifying stylesheets, it doesn’t help stylesheet authors much. There is one noticeable exception - Rails engines.

Rails engines like Devise, Spree, and Refinery are powerful. Just by configuring a gem and running a generator you can add authentication, storefront, or CMS features to your Rails app with little effort. If your app uses engines, and you find your development environment begins to slow to a crawl, make sure your engine assets aren’t clogging the pipeline. In the case of Spree, we can improve asset performance by precompiling assets with a Rails Rake task:

rake assets:precompile RAILS_ENV=development RAILS_ASSETS_NONDIGEST=true

This will compile all application assets into /public/assets, allowing Rails to serve them without needing to recompile on each request:

drwxr-xr-x  17 wynn  staff   578 Nov  2 08:36 .
drwxr-xr-x   8 wynn  staff   272 Nov  2 08:35 ..
drwxr-xr-x  16 wynn  staff   544 Nov  2 08:36 admin
-rw-r--r--   1 wynn  staff   155 Nov  2 08:30 application.css
-rw-r--r--   1 wynn  staff   143 Nov  2 08:30 application.css.gz
drwxr-xr-x   7 wynn  staff   238 Nov  2 08:36 creditcards
drwxr-xr-x   3 wynn  staff   102 Nov  2 08:36 datepicker
-rw-r--r--   1 wynn  staff  1150 Nov  2 08:19 favicon.ico
drwxr-xr-x   6 wynn  staff   204 Nov  2 08:36 icons
drwxr-xr-x   4 wynn  staff   136 Nov  2 08:36 jqPlot
drwxr-xr-x  15 wynn  staff   510 Nov  2 08:36 jquery-ui
drwxr-xr-x   3 wynn  staff   102 Nov  2 08:35 jquery.alerts
drwxr-xr-x   3 wynn  staff   102 Nov  2 08:35 jquery.jstree
-rw-r--r--   1 wynn  staff  6694 Nov  2 08:36 manifest.yml
drwxr-xr-x   5 wynn  staff   170 Nov  2 08:36 noimage
-rw-r--r--   1 wynn  staff  1608 Nov  2 08:19 spinner.gif
drwxr-xr-x   6 wynn  staff   204 Nov  2 08:36 store

With precompiled assets, our load times are reduced dramatically, however we won’t see changes to our own stylesheets. In the example above, we can simply remove application.css and application.css.gz so that those will be compiled on each request via the asset pipeline. However, having our engine-provided stylesheets precompiled is a big win.

As we mentioned above, one of the big gains of the asset pipeline is concatenating our stylesheets into a reduced number of files. If you are serving multiple application-specific stylesheets, consider precompiling all your assets and then removing your current work-in-progress stylesheet from /public/assets.

X-Request-Id tracking and TaggedLogging in Rails3.2 »

Created at: 21.10.2011 18:04, source: Ruby Rockers, tagged: Technology rails ruby

Rails 3.2 will come with X-Request-Id tracking and TaggedLogging support!! Recently DHH added this feature here!

This makes it easy to trace requests from end-to-end in the stack and to identify individual requests in mixed logs.

If you have application on SAS model. Where you have logs filled with mixed request for all your customers. May be you need to filter out requests start with some specific subdomain. TaggedLogging will help you in that.

Where as the X-Request-Id feature will help you to track log with the same request. So in mixed logs you can easily find out the unique id logs for a request.

It will tag the log with the unique id for that request in the log. So later you can easily trace them down.

May be later on you can add more tags for your logs. If those methods are supported by the request object!

I am showing here some logs here with X-Request-Id

[2011-10-21 19:57:55] INFO  WEBrick 1.3.1
[2011-10-21 19:57:55] INFO  ruby 2.0.0 (2011-10-19) [x86_64-darwin11.2.0]
[2011-10-21 19:57:55] INFO  WEBrick::HTTPServer#start: pid=1585 port=3000
[9fda80066583f52e695a089d8622439c] 

Started GET "/blogs" for 127.0.0.1 at 2011-10-21 19:57:59 +0530
[9fda80066583f52e695a089d8622439c]  Processing by BlogsController#index as HTML
[9fda80066583f52e695a089d8622439c]    Blog Load (0.2ms)  SELECT "blogs".* FROM "blogs"
[9fda80066583f52e695a089d8622439c]    Rendered blogs/index.html.erb within layouts/application (8.8ms)
[9fda80066583f52e695a089d8622439c]  Completed 200 OK in 32ms (Views: 30.4ms | ActiveRecord: 0.3ms)
[2011-10-21 19:57:59] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
[0962521e4215d645367b58fa41da9f0d] 

Started GET "/assets/application.css?body=1" for 127.0.0.1 at 2011-10-21 19:57:59 +0530
[0962521e4215d645367b58fa41da9f0d] Served asset /application.css - 304 Not Modified (0ms)
[2011-10-21 19:57:59] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
[a7204cec4d2b2e930ac05b41fa1a5c65] 

Started GET "/assets/jquery_ujs.js?body=1" for 127.0.0.1 at 2011-10-21 19:57:59 +0530
[a7204cec4d2b2e930ac05b41fa1a5c65] Served asset /jquery_ujs.js - 304 Not Modified (1ms)
[2011-10-21 19:57:59] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
[202eadd97820dfbf429f87f4725324c3] 

Started GET "/assets/blogs.css?body=1" for 127.0.0.1 at 2011-10-21 19:57:59 +0530
[202eadd97820dfbf429f87f4725324c3] Served asset /blogs.css - 304 Not Modified (2ms)
[2011-10-21 19:57:59] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
[769a2752906bb0c2c5d1eae0a76ac328]

Here I showed some logs in strong. They are the same request for the index page tagged with the same unique id.
The same concept for the subdomain. The subdomain will also come as a tag.

You can also log some of the custom events in log file with the tags!

Logger.tagged("BCX") { Logger.info "Stuff" }                            # Logs "[BCX] Stuff"
Logger.tagged("BCX", "Jason") { Logger.info "Stuff" }                   # Logs "[BCX] [Jason] Stuff"
Logger.tagged("BCX") { Logger.tagged("Jason") { Logger.info "Stuff" } } # Logs "[BCX] [Jason] Stuff"

How to configure it ??

Open up your production.rb or your custom environment file, uncomment the line for log_tags

config.log_tags = [ :subdomain, :uuid ]

And you will get tagged logs with useful information.

Useful links :

Commit URL : https://github.com/rails/rails/commit/afde6fdd5ef3e6b0693a7e330777e85ef4cffddb
Feature Branch : 3.2

Cheers,
@arunagw