I’m using RSpec in most of my recent projects. In fact, whatever new I start gets RSpec installed by default. Recently I began using Sorcery gem for authentication. It’s a small and non-intrusive solution that I find very well-fitted for how I do things. If you are using Sorcery, you may be glad to find out that it’s possible to make your whole functional testing suite almost twice as fast.

Yesterday, while I was reading a book on Erlang, I’ve got this idea to devise and implement prime numbers finding algorithm without looking up anything. So I did. But then figured my friends may also want to get their feet wet and so I tweeted about the “challenge” and got 3 submissions (2 in Ruby and 1 in Erlang). Later, I discovered that a couple more would have wanted to try but never saw my tweet. Well, it’s a shame.

I’m reading excellent “Programming Erlang” by Joe Armstrong and find some new stuff I haven’t seen in “Erlang programming” by Francesco Cesarini. This is largely a self-note post, so take it with a grain of salt.

Lists

• If your code prepends elements effectively reversing the order of the original list, you need to call lists:reverse(...) as opposed to concatenating lists (L ++ [ X ]). The reverse call is way more efficient and even though it’s defined in lists module, when VM sees the call, it invokes an internal version.

Exception handling

• The value of the after block is lost
• The after block can be omitted

• If you don’t need any guards in the try ... catch block, you can use this shortcut:

  try Expr
  catch
    ...
  end
  

• To catch all exceptions, one needs to pattern-match _:_ in catch-block. Matching bare _ will assume catching only throws

General notes

• Use export_all in development only. This is for two reasons. First, when you come to read your code later, you’ll know that the only important functions are the exported functions, and all the other functions cannot be called from outside the module so you can change them in any way you like, provided the interfaces to the exported functions remain the same. Second, the compiler can produce much better code if it knows exactly which functions are exported from the module.

• Use match operators to avoid rebuilding atoms and other constructs that you’ve matched in the method signature:

  fun1([{user, Name, Age} = U|T]) ->
    ...
    f(U),
    ...
  

• Data types ordering is as follows (any number is less than any atom etc.:

  number < atom < reference < fun < port < pid < tuple < list < binary
  

As I move on, I’ll be posting more of these self-notes…

Recently I’ve switched to MacVim from Textmate, and done so for a couple of reasons:

• I use Vim remotely when administering servers all the time, and practicing it locally makes me much more productive.

• Vim is evidently more mature than Textmate. With the whole Open Source ecosystem around it, tons of plugins and superior text-editing features, it leaves Textmate far behind.

Of course, programming doesn’t happen in the editor, but you have to transfer your thoughts to the screen somehow and that’s where your tool chain comes into play. I found that after several days of practice MacVim started to feel at home and the fact that I keep discovering shortcuts makes it a game where you unveil more and more hidden goodness. Love the feeling…

RubyC is officially over and so I’d like to share my thoughts on the event – what went well and what desired to be better.

Let me start by saying I have a tiny bit of prejudice here. I lived in Australia, and the fact that three of key speakers were from the AU meant a lot to me. I met Pat before and so pairing with him and other mates in the park for two days would be as exciting as hearing them out in the conference room. Having this said, here’s what I liked and didn’t like that much.

Monitoring services, CPU, disk and memory usage has become a common practice for IT companies big and small, but what often overseen are Cron jobs. (If you are unfamiliar with Cron, it’s the standard *nix way of running periodical tasks.) In this short post I show one simple way just to get you going.

A couple of posts ago I wrote about the HTML5 Mobile Pro desktop edition the guys were doing a poor job with. Today I’d like to show what I consider a really good product.

I’m a big fan of everything that’s even remotely connected with Ruby. The language turned my world upside down and gave me my present life full of freedom, fun and amazing opportunities. That’s why when one of the guys I know pointed out that Peter Cooper is working on The Ruby 1.9 walkthrough, I (a bit skeptically) went to look around. Our ways didn’t cross too often, but he curated one of the rounds on Ruby Challenge and runs Ruby Inside, so he felt authoritative enough for the job.

It turned out to be right.

Sometimes you need to access an asset from a Rake task. One example is one of our projects where we need to compile a package for a Phonegap app that includes images, Javascript and CSS. Before Rails 3 and the Asset Pipeline we knew the location and the names of our assets exactly, but now they may be located anywhere and have the hashes in the names. Instead of recreating all the hashing and locating functionality, the most logical path is to reuse what’s there in Rails.

One way I figured is this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

namespace :app do

  task :my_task => :environment do
    AppyTravels::Application.configure do
      config.assets.debug = false
      config.assets.digest = true
    end

    include AssetsMaster

    image_path('my_image.png')
  end

  # Assets master gives the access to helpers like #asset_path from rake tasks
  module AssetsMaster
    include Sprockets::Helpers::RailsHelper

    def config; Rails.application.config; end
    def controller; nil; end
    def relative_url_root; nil; end
  end

end

We have an AssetsMaster module that includes the Sprockets::Helpers::RailsHelper. This helper contains all path / url methods and some other asset-related goodness. Including this file would be sufficient in Rails 3.0, but it’s not in Rails 3.1+. In the latest version we need to have three more methods: config, controller and relative_url_root. The first one should refer to the app configuration, and the other two can be nil.

You may have noticed how I adjust the assets configuration in my Rake task (lines 4-6). As you can see, I disable debugging and enable digests explicitly to break the ties from the environment config.

After all this magic, you can finally enjoy your desired image_path helper that will obey Asset Pipeline configuration to the letter.

Mongoid is an excellent piece of work and makes MongoDB a first-class citizen in the Rails world, but in its present state it has one nasty trait – it attempts the connection to DB even when you do something as innocent as precompiling your assets. Here’s what you’ll see if you try to run bundle exec rake assets:precompile with your MongoDB being shut down:

Failed to connect to a master node at localhost:27017

Moving a Rails 3.0 project to Rails 3.1 can be surprisingly tricky and especially if you use Mongoid, embedded collections, pagination and AJAX updates.

Mongoid 2.0.2 dropped own pagination and now fully relying on third-party tools. That’s a great idea and modularisation effort. However, now there’s a dilemma about what to use. I chose Kaminari for its up-to-date state and overall simplicity. I’d like to show a tricky part of making it all work.