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
- 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
- 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
Enhancements
- Clean up messages for filters/tags.
rspec-mocks-2.6.0.rc4
Bug fixes
- Support multiple calls to any_instance in the same example (Sidu Ponnappa)
rspec-rails-2.6.0.rc4
Enhancements
- Update the controller spec generated by the rails scaffold generator:
- Add documentation to the generated spec
- Use
any_instanceto 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_pathswith 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.more »
Engine Yard Cloud Out Loud S01E05: Crafting Rails Applications »
Created at: 15.01.2011 01:59, source: Engine Yard Blog, tagged: Uncategorized cloud out loud podcast
more »
Tag cloud
Categories
Links
Blogs: 43
Posts: 2516