bgror

rspec-2.6.0 is released »

Created at: 12.05.2011 15:58, source: David Chelimsky, tagged: Uncategorized

rspec-core-2.6.0

full changelog

• Enhancements

  • shared_context (Damian Nurzynski)
    • extend groups matching specific metadata with:
      • method definitions
      • subject declarations
      • let/let! declarations
      • etc (anything you can do in a group)
  • its([:key]) works for any subject with #[]. (Peter Jaros)
  • treat_symbols_as_metadata_keys_with_true_values (Myron Marston)
  • Print a deprecation warning when you configure RSpec after defining an example. All configuration should happen before any examples are defined. (Myron Marston)
  • Pass the exit status of a DRb run to the invoking process. This causes specs run via DRb to not just return true or false. (Ilkka Laukkanen)
  • Refactoring of ConfigurationOptions#parse_options (Rodrigo Rosenfeld Rosas)
  • Report excluded filters in runner output (tip from andyl)
  • Clean up messages for filters/tags.
  • Restore –pattern/-P command line option from rspec-1
  • Support false as well as true in config.full_backtrace= (Andreas Tolf Tolfsen)

• Bug fixes

  • Don’t stumble over an exception without a message (Hans Hasselberg)
  • Remove non-ascii characters from comments that were choking rcov (Geoffrey Byers)
  • Fixed backtrace so it doesn’t include lines from before the autorun at_exit hook (Myron Marston)
  • Include RSpec::Matchers when first example group is defined, rather than just before running the examples. This works around an obscure bug in ruby 1.9 that can cause infinite recursion. (Myron Marston)
  • Don’t send example_group_[started|finished] to formatters for empty groups.
  • Get specs passing on jruby (Sidu Ponnappa)
  • Fix bug where mixing nested groups and outer-level examples gave unpredictable :line_number behavior (Artur Małecki)
  • Regexp.escape the argument to –example (tip from Elliot Winkler)
  • Correctly pass/fail pending block with message expectations
  • CommandLine returns exit status (0/1) instead of true/false
  • Create path to formatter output file if it doesn’t exist (marekj).

rspec-expectations-2.6.0

full changelog

• Enhancments

  • change matcher accepts Regexps (Robert Davis)
  • better descriptions for have_xxx matchers (Magnus Bergmark)
  • range.should cover(*values) (Anders Furseth)

• Bug fixes

  • Removed non-ascii characters that were choking rcov (Geoffrey Byers)
  • change matcher dups arrays and hashes so their before/after states can be compared correctly.
  • Fix the order of inclusion of RSpec::Matchers in Test::Unit::TestCase and MiniTest::Unit::TestCase to prevent a SystemStackError (Myron Marston)

rspec-mocks-2.6.0

full changelog

• Enhancements

  • Add support for any_instance.stub and any_instance.should_receive (Sidu Ponnappa and Andy Lindeman)

• Bug fixes

  • fix bug in which multiple chains with shared messages ending in hashes failed to return the correct value

rspec-rails-2.6.0

full changelog

• Enhancements

  • rails 3 shortcuts for routing specs (Joe Fiorini)
  • support nested resources in generators (Tim McEwan)
  • require ‘rspec/rails/mocks’ to use mock_model without requiring the whole rails framework
  • Update the controller spec generated by the rails scaffold generator:
  • Add documentation to the generated spec
  • Use any_instance to avoid stubbing finders
  • Use real objects instead of mock_model
  • Update capybara integration to work with capy 0.4 and 1.0.0.beta
  • Decorate paths passed to [append|prepend]_view_paths with empty templates unless rendering views. (Mark Turner)

• Bug fixes

  • fix typo in “rake spec:statsetup” (Curtis Schofield)
  • expose named routes in anonymous controller specs (Andy Lindeman)
  • error when generating namespaced scaffold resources (Andy Lindeman)
  • Fix load order issue w/ Capybara (oleg dashevskii)
  • Fix monkey patches that broke due to internal changes in rails-3.1.0.beta1

more »

rspec-2.6.0.rc6 is released! »

Created at: 06.05.2011 14:59, source: David Chelimsky, tagged: Uncategorized

We’re doing one more release candidate to update rspec-rails to work with rails-3.1.0.beta1. This will hopefully be the last release candidate, with a final release coming in just a few days.

rspec-rails-2.6.0.rc6

full changelog

• Bug fixes
  • Fix load order issue w/ Capybara (oleg dashevskii)
  • Relax the dependencies on rails gems to >= 3.0 (Joel Moss)
  • Fix monkey patches that broke due to internal changes in rails-3.1.0.beta1

rspec-core-2.6.0.rc6

full changelog

• Enhancements
  • Restore –pattern/-P command line option from rspec-1
  • Support false as well as true in config.full_backtrace= (Andreas Tolf Tolfsen)

more »

rspec-2.6.0.rc4 is released! »

Created at: 01.05.2011 15:55, source: David Chelimsky, tagged: Uncategorized

This release addresses issues that were raised in the rspec-core-2.6.0.rc2 release.

NOTE: this was originally released as rc3, but there was a problem related to rubygems that made it uninstallable.

rspec-core-2.6.0.rc4

full changelog

Enhancements

• Clean up messages for filters/tags.

rspec-mocks-2.6.0.rc4

full changelog

Bug fixes

• Support multiple calls to any_instance in the same example (Sidu Ponnappa)

rspec-rails-2.6.0.rc4

full changelog

Enhancements

• Update the controller spec generated by the rails scaffold generator:
  • Add documentation to the generated spec
  • Use any_instance to avoid stubbing finders
  • Use real objects instead of mock_model
• Update capybara integration to work with capy 0.4 and 1.0.0.beta
• Decorate paths passed to [append|prepend]_view_paths with empty templates unless rendering views. (Mark Turner)

more »

Bundler Usage — Installing Gems »

Created at: 18.03.2011 17:52, source: Ruby Rockers, tagged: Uncategorized bundler rails ruby Ruby on Rails

Every time you change your Gemfile then you might adding/removing any dependancies in your application.

Just bundle install will install gems for you.

The output may look like

$ bundle install
Fetching git://github.com/rails/rails.git
Fetching source index for http://rubygems.org/
Using rake (0.8.7)
Installing abstract (1.0.0)
Your bundle is complete! Use `bundle show [gemname]` to see where a
bundled gem is installed.

You can specify groups for special environments

$ bundle install --without development test

$ bundle install --without test

You can specify installation directory for your gems.
This will install all the gems into tmp/bundle folder

$ bundle install --path tmp/bundle

You can check your applications bundler config.

$ bundle config 

Settings are listed in order of priority. The top value will be used.

disable_shared_gems
  Set for your local app (/Users/arunagw/errorapp/.bundle/config): "1"

path
  Set for your local app (/Users/arunagw/errorapp/.bundle/config): "tmp/bundle"

For more details about bundler you can checkout http://gembundler.com/
And also http://railscasts.com/episodes/201-bundler

more »

Front-end Maintainability with Sass and Style Guides »

Created at: 20.01.2011 04:22, source: Engine Yard Blog, tagged: Uncategorized haml sass ui ux

At Engine Yard, the User Experience team works frequently on the front-end (HTML & CSS) of our application, AppCloud. It's also common that our Ruby developers write front-end code as well. When the UX team began realigning the AppCloud UI, it involved refactoring the HTML & CSS for better efficiency. We also created a style guide to document the new front-end architecture. We're sharing the methods we've used and how it's helped us to work more efficiently on the AppCloud UI.

Modular CSS

Haml and Sass are two gems that are easy to include into your Ruby on Rails application. At Engine Yard, we use both of these to maintain our front-end code. Sass variables and mix-ins are amazing resources that make managing styles much easier. This is fantastic for maintaining UI elements and adhering to brand guidelines. Within our AppCloud front-end framework we have variables we've set up for our colors based on our branding color palette. That can look something like this:

// --------------------------------------------------
// COLOR
// --------------------------------------------------
$color_border =           #ccc      // light grey
$color_background =       #f8f8f8   // lightest grey
$color_background_alt =   #cfdbe8   // light blue
$color_background_alt2 =  #e3e5cf   // light beige
$color_text =             #555      // dark grey
$color_text_alt =         #999      // medium grey
$color_text_alert =       #910f0f   // bold red
$color_text_callout =     #236DA6   // bold blue

This way, when we need to use the color for our borders, we can just call on the color variable, $color_border. If we decide to change this color, we only need to change it in one place. If we need variations on this color (like for shadows and highlights), we can use that variable combined with Sass's built-in functions:

h1 {
  border-bottom-color: darken($color_border, 10%);
}

We've used the "color_" prefix in these variable names to help avoid any clashes we might run into. It also helps provide some inline context (documentation is always a good thing). The important thing here is we keep our variable and mix-in names descriptive, but we avoid using presentational names that could change one day. By using $color_text_callout instead of $color_text_blue we don't have to change all of our variable names if we change the text from blue to red. We can use comments to help remind us of hex value colors which are located in the one place we'd make changes, if need be. Variables and mix-ins are a great way to help improve and clean up semantic HTML (if it's done right). In our last related blog post, we mentioned that we're using the 960 Grid System which uses CSS classes like “grid_1”, “prefix_9”, and “alpha”. For the semantic front-end neat-freaks out there, this can be cringe-worthy. However, if you're not already using a framework like Compass, you can simply modify the 960 Grid System, allowing you to have the best of both worlds (modular efficiency and clean, semantic HTML). You can turn all the class names within the framework into mix-ins, which will make HTML go from this:

<div id="sidebar" class="grid_1 prefix alpha">
  (content goes here)
</div>

to this:

<div id="sidebar">
  (content goes here)
</div>

That's so much better, isn't it? We can do this for other common styles like clear fixes, rounded corners, visibly hiding elements, etc. If you define your UI elements' visual design styles as variables or mix-ins, you can have a much easier time updating these styles in a consistent way.

Maintaining an Interface Style Guide

Interface Style Guides are an essential way to keep track of branding and visual design guidelines and front end architecture requirements. The key to keeping a style guide useful is that it should stay relevant and informative. However, this can be a tedious task that often gets forgotten or avoided. Online style guides are easier to maintain and distribute as opposed to printed documents. To keep our style guide relevant, it lives in our internal-only admin section on the very same application it describes. We display our color palette alongside the relevant Sass variables and since we've built the style guide into the application using the same front-end, we can use the same variables we're referencing to render this palette. When we change values to these variables, the palette updates automatically. Another benefit to adding your online style guide to your application is you get one central place to check to make sure all HTML elements are looking the way they're supposed to. If the styles are broken here, most likely they're broken elsewhere. Finally, this method allows development teams to have a reference guide so they know what code they would use to get the effect they're looking for, such as icons. We continue to evolve the AppCloud front-end through iterations; good organization and documentation is essential to make this front-end architecture work for both designers and developers on our team. What methods does your company or team use? We'd love to hear from you.

more »