Turns out it’s pretty easy.

import random

list = ['a', 'b', 'c'];

random.choice(list);

You can use Rails’ automatic translation scoping to translate flashes in a clean, concise way.

app/controllers/posts_controller.rb:

class PostsController < ApplicationController
  def create
    @post = Post.new(post_params)

    if @post.save
      redirect_to post_url(@post), notice: t('.flash')
    else
      render :new
    end
  end
end

config/locales/en.yml:

en:
  posts:
    create:
      flash: 'Post has been successfully created.'

config/locales/pl.yml:

pl:
  posts:
    create:
      flash: 'Post został utworzony pomyślnie.'

At the time of writing this post, Atom editor doesn’t support file-specific buffer settings. It’s very easy, however, to add this functionality manually, using Atom’s excellent API.

For example, let’s say we want to enable soft wrapping in Markdown and use hard tabs in Makefile (as the format requires it). All you need to do is to add the following code to your ~/.atom/init.coffee file:

path = require 'path'

atom.workspaceView.eachEditorView (editorView) ->
  editor = editorView.getEditor()
  grammar = editor.getGrammar()
  name = grammar.name

  if name is 'GitHub Markdown'
    editor.setSoftWrap(true)
    editor.setSoftWrapAtPreferredLineLength(true)

  if name is 'Makefile'
    editor.setSoftTabs(false)
    editor.setTabLength(4)

Restart Atom and keep coding!

Rails 4.1 introduced Spring. Spring is an application preloader which makes developing large projects easier by reducing time required to load them.

Spring works with Rails’ minitest out of the box, but RSpec support requires one additional dependency, namely spring-commands-rspec.

First (as usual), you need to add spring-commands-rspec to your Gemfile:

group :development do
  gem 'spring-commands-rspec'
end

Note that this gem should be required in development environment only. Don’t forget to bundle install.

Next, inject a springified RSpec binstub by running:

bundle exec spring binstub rspec 

If you already have a binstub named rspec (most likely generated with bundle binstubs rspec-core), I’d recommend removing it beforehand.

Finally, run spring stop to make Spring pick up the new command. After that your bin/rspec runs will use preloaded code whenever possible.

Happy testing!

I’m wondering how will that impact TextMate’s development.

I’m starting to become more and more convinced to start decoupling business models (e.g. ActiveRecord classes) from business logic. The whole “fat model” anti-pattern just looks silly to me now.

Tinkering with Rubnius. Trying to figure out if it would be a suitable choice for a production environment. I have yet to find a library that Rubinius can’t handle (even those using C extensions compile without any problems, let it be psych or pg).

Adding an explicit version number to the Gemfile is definitely fine. However, I consider it useful in the case where you know a priori that you need a specific version of a gem e.g. because of an incompatibility with a later version.

The problem you are describing is precisely what the Gemfile.lock file is for. It records the version number of each gem, so you don’t have to remember and you don’t have to manually specify. This is why it is so important to have that file in version control with your app–it ensures that everyone is using the exact same versions of all gems, with no extra effort necessary.

Also note that bundle update should only be used if you need to update to a newer version of a gem that Bundler already knows about. For example, when a new version of httparty comes out, you run bundle update httparty. Otherwise, you should always run bundle install.

From one of the comments on Bundler Best Practices.

A follow-up to the e-mail receiving methods focusing on tests.

Comprehensive article about receiving e-mails in Rails 3.

© 2014 Adrian Pacała