First of all, I don't recommended excessive redirects.
Sometimes though, you need more than 5 in your Capybara specs; this is the default redirect limit for Capybara. When you exceed this limit, you get a dreaded Capybara::InfiniteRedirectError.
In Capybara 2.0+, this limit is configurable:
Capybara.register_driver :rack_test do |app|
Capybara::RackTest::Driver.new app, \
redirect_limit: 15,
follow_redirects: true,
respect_data_method: true
end
Register a new instance of the rack test driver with options, as shown above. If you're on Rails, it may be necessary for you to set :respect_data_method to true; this instructs capybara to simulate the request method specified via data-method attributes in your link. With Rails, an extension like rails/jquery-ujs allows you to enable additional request methods via unobtrusive javascript in real browsers. This setting currently defaults to false in the RackTest driver; one of the primary configurations in capybara/rails is to set this option. So… you may be surprised if you omit this option and suddenly get missing route exceptions in your specs.
The best long term solution for you and your users is to figure out how to reduce or eliminate unnecessary redirects. Playing with the redirect limit in your test environment may be a good way to identify potential problem areas of your app.
By statistics alone, Wordpress is a winner. According to the stats on Wikipedia, it is a clear favorite amongst the top and new websites worldwide. The sheer volume of options for plugins, themes and customizations are enough to make it worthwhile as a content platform; the admin tools make editing and publishing a breeze.
And yet, yesterday, I ditched Wordpress. This site is now hosted on Github Pages.
So why switch? There are a few reasons. For one, site performance benefits of Pages over Wordpress have been well-documented. Now I don't have to worry about Bluehost suspending my service anymore. Pages is free. There's also my personal distaste for PHP, though it hasn't stopped me from hacking on my pages here and there.
There is, however, a more fundamental reason, illustrated when I ran into a close friend recently. My friend is brilliant and well-regarded in his field (finance). When he remarked on that fact that I had built my own website, my first thought was “Well, not really…”, though I said something more like “Thanks!” My friend and most people don't care if a website runs on Wordpress, Django, .Net or C#… but I do. If the general sentiment on Hacker News is any indication, most developers care as well. Many of us got into programming because we saw something that amazed us and we desperately wanted to know how.
To host on Github Pages means for me using git, hand-crafting html and writing markdown in my editor of choice, building with tools written in languages I love, and rolling my own theme built on CSS frameworks I like. It's a better representation of what I do and how I prefer to do it. Using Wordpress has always felt a bit disingenuous. And that's why I made the change.
The ember-rails gem is a great way to get started with Ember.js in a Rails project. Another approach is to create and serve an Ember app on a static webpage, totally decoupled from the backend environment. It would be great to have some of the modern front-end development tools we get with something like Rails in a static web environment. A great project to consider for this is Middleman.
Middleman is a static website generator enhanced with some key tools like the asset pipeline. It works really well as an alternative to Jekyll for rolling a blog. It’s comparable to Yeoman for the benefits it provides for the front-end workflow, though the underlying tools both are quite different. Middleman builds on top of Rack and Sinatra, so you can take advantage of Rack middleware in development or deployment.
To install middleman:
$ gem install middleman
A key feature for getting up and running quickly with Middleman are its use of project templates. You can use some out-of-the-box templates for setting up a Middleman project with the HTML5 Boilerplate. I’ve got a fork of an Ember app template that you can download or clone into ~/.middleman/ to get up and running with ember-1.0.0-rc1 with ember-data. To start a new Middleman project with my ember template:
$ git clone git://github.com/rossta/middleman-ember-template.git ~/.middleman/ember
$ middleman init my_new_project --template=ember
$ middleman server
If everything worked, you should be able to navigate to http://localhost:4567 to see Hello World generated with Ember.
There are lots of options for deploying a Middleman app. To deploy easily with Heroku, we can use a buildpack. Buildpacks are scripts that take advantage of hooks provided by the Heroku build process and also us to customize what happens when we run “git push heroku master”. For the app generated from my ember template, we’ll want this process to build the Middleman app, which will minify assets and provide cacheable asset urls through the asset pipeline, and serve it on Rack using the Rack::TryStatic middleware. Luckily, there are already some buildpacks out there that fit these requirements. It’s easy to configure our Heroku app to use a custom buildpack via a git url
$ heroku create my_app --buildpack git://github.com/indirect/heroku-buildpack-middleman.git
$ git push heroku master
If everything worked, you should be able to see your static web Ember app served up on Heroku.
I gave a quick lightning talk on this topic at the Ember.js NYC Meetup yesterday. Check out the slides, also on Speaker Deck
Today, I made a brown bag case to my colleagues: let’s approach client-side development in a more structured, disciplined and flexible way; in other words, add a model-view-controller javascript layer to our web app. Included is some background for the discussion and a brief introduction to Backbone.js. I use the phrase MV+ to embrace various implementations of MVC-like javascript frameworks, most of which have different takes on what object take on the responsibility for hooking up models and views.
Brown Bag Presentation: Javascript MV+
A useful feature of RSpec is the ability to pass metadata to tests and suites and configure the test environment according. For example, Capybara provides :js options to enable the javascript driver for a given spec. Another use case for RSpec metadata is to test the effects of Rails caching in requests.
The Rails test environment ships with controller caching disabled, which you might not prefer. Otherwise, it may be useful to be able to toggle it on/off during the test run. To provide an optional caching mechanism for your specs, configure an around block:
RSpec.configure do |config|
config.around(:each, :caching) do |example|
caching = ActionController::Base.perform_caching
ActionController::Base.perform_caching = example.metadata[:caching]
example.run
ActionController::Base.perform_caching = caching
end
end
The around block takes the RSpec example object as an argument. The block is triggered when :caching is detected as a key in an example’s metadata. The example object provides a number of methods for test introspection, allowing you to make changes before and after calling #run to execute the spec. Here, we are storing the previously set value of ActionContoller::Base.perform_caching, setting it for the local suite, and setting it back to the original value after it completes.
As a result, we now have a simple, explicit mechanism for introducing caching to individual specs and suites:
describe "visit the homepage", :caching => true do
# test cached stuff
end
Page 1 of 4
Next page