My daily activities as Developer Founder of Firmhouse. Productivity hints, leading a team, working on code.

When you are creating software or other online products it might sometimes be hard to sleep at night. You might worry about the next thing that might go wrong such as a failing database, lost files or a web app being unavailable.

Things like that are always going to happen sooner or later. You really can't expect to always be running on the happy path. Some things will go awry. Maybe tomorrow, maybe next year.

You have two options here:

Control every change to the environment you are working on. Having fixed release dates, single access control or pre-approving every small thing your team does. Or, checking something 10 times before actually making a decision or taking action.

The other path you can take is to make sure tools and systems are in place so you can solve problems when they arise. Those problems might arise due to a mistake from someone in your company or they might just happen because life and nature decided it did.

Best results come out of companies and teams where people can do their work without having someone watch over their shoulders all the time. Personal responsibility and the freedom to try things that might go wrong often bring the most creative results.

What I'm doing right now? I'm trying to make our database backup system more easier to use for the team and more fail safe when someone needs to do a change on the production environment.

This is a small thing that will make me sleep better at night. Because I know when someone makes a mistake with typing some commands on the production environment, we can fix it within a few minutes.

I have been searching and Googling for this the past few days and after a very nice support chat with EngineYard I found out:

It is possible to run multiple applications in the same environment on EngineYard AppCloud. So, you can add an application to an existing environment.

I knew this was possible before, but I couldn't really find it in their documentation, hence this blog post.

You can just create your first application and create a single-instance, cluster or custom environment for it and than add other applications to it by pressing this button:

Add application to existing environment

If you want DelayedJob, Resque or Sphinx for one or more of the applications in that environment you will need to do some manual Chef configuration and I will write about that soon.

This blog post is a quick story of some paths I took to make some of my routes translated. I ended up with a pretty creepy solution for now (still in search for a better one) so bear with me because there is some crappy code in this article.

The thing is that I want the following to work:

http://siteinenglish.com/competition/some_custom_slug
http://siteinenglish.com/competition/some_custom_slug/new

http://siteindutch.nl/competitie/some_custom_slug
http://siteindutch.nl/competitie/some_custom_slug/new

Every site has it's own "top level" model that is named Challenge in my case. On the challenge, an admin can configure the locale that should be used on that site, which in this case can be en and nl.

Gems I tried

I tried the rails-translate-routes and the i18n_routing gems.

The first one didn't work for my Rails 3.0 app.

The second one kind of worked but resolved into some stack level to deep error when trying to apply it to the following resource:

get "competition/:phase_slug" => "phases#show", :as => single_goal_phase

^ Worked!

resources :contributions, :path => "competition/:phase_slug", :as => single_contributions

^ Stack level to deep on some I18n method

Creepy solution with a routing Constraint

The workaround I came up with was to create a route such as:

get ":competition_translation/:phase_slug" => "phases#show", :constraints => TranslationConstraint, :as => single_goal_phase

resources :contributions, :path => ":competition_translation/:phase_slug", :constraints => TranslationConstraint, :as => single_contributions

The TranslationConstraint looking a bit like this (I've simplified a bit to show the example):

class TranslationConstraint
  def self.matches?
    challenge = Challenge.where({:default_domain => request.host}).first
    if challenge && request.params[:competition_translation] == I18n.t('routes.competition')
      return true
    else
      return false
    end
  end
end

But, since I'm now using a parameter in the route for the resource I also have to override the method that generates the url for the named route and the resource. Like so:

def single_goal_phase_url(options)
  options[:competition_translation] = I18n.t('routes.competition')
  super(options)
end

Dirty to the bone

All of this feels so super dirty and I have no idea what direction I should go to solve this in a nicer way. My knowledge of the Rails router stops at routes.rb and some advanced Constraining.

Is there anyone out there who's smarter than me?

Just a quick note for the people (like me) for seeing an error like this in their exception notifications and to save you some Googling:

ActionView::MissingTemplate: Missing template challenges/show with {:handlers=>[:haml, :rjs, :builder, :rhtml, :rxml, :erb], :locale=>[:en, :en], :formats=>["*/*;q=0.6"]} in view paths

This is an issue in MIME::Type.parse and has been fixed in Rails master 8 February, 2012 according to this pull request.

There is a patch in the comments on the pull request page you can use to fix it for your current app until a new Rails is released.

You can use Cucumber in a lot of different ways. You can use it as an acceptance test, an integration test. Usually you it's a mixture of both.

There are a lot of right and wrong ways to write Cucumber tests in my opinion. I think I have been writing Cucumber tests the wrong way until now and I am trying to improve that.

Here is the thing:

When it is evidently clear a user will have to log in for your app I think you should not include a step like that in your Cucumber test. To illustrate, instead of:

Scenario: View stock for a regular product
  Given there is a product
  When I log in
  And I go to the product
  Then I should see the product's total available stock

Write this:

Scenario: View stock for a regular product
  Given there is a product
  When I go to the product
  Then I should see the product's total available stock

If you are writing Cucumber tests (and I can think of a lot of reasons why you would or you shouldn't) I think you should keep them as implicit as possible from your standpoint as a user.

If you're a regular user of the software you are writing, it's pretty obvious you need to log in if you need to do that for every action you are going to take in the application. Especially when it's some kind of business backend administration kind of app where there is no public facing page.

I do think you should create features like "Log in" and "Create account" to test those particular paths in your application.

However, when looking at the sample above, I think it's better to write a step like:

When /$I go to the product$/ do
  step "I log in"

  visit product_path(@product)
end

Maybe a good rule of thumb could be: When collaborating with a designer or sketching out a feature and explaining it to other people, would you actually draw out the logging in part? Or would you take that as out of scope for the sketch/mockup you are writing and assume it is obvious.