self.blogger?

If you've got used to using `dos2unix` and `unix2dos` and you miss them in recent Ubuntu Linux distributions, here's a recipe how to get them back: # apt-get install tofrodos # cd /usr/bin/ # ln -s fromdos dos2unix # ln -s todos unix2dos

I think this example pretty much speaks for itself: >> " do \t\n some stuff ".split => ["do", "some", "stuff"] You don't even need to `strip` your input.

Try this in IRB: >> 1.3333333333.round(2) => 1.33 If you care about compatibility, keep in mind that **under 1.8.7** it yields nothing less but: >> 1.3333333333.round(2) ArgumentError: wrong number of arguments (1 for 0)

I do a lot of metaprogramming, which sometimes involves multiline `eval` blocks. Those blocks are actually part of the program, which are subject to debugging. As we all know, one of the most accessible debugging methods is commenting stuff out. There's one little feature we should be aware of when using multiline `eval` blocks: the `#`-comment might not work as we expect it to. Consider this example: eval %{ puts "Setting name" @name = "Joe" } Fairly primitive, should obviously work. Now let's suppose that we want to temporarily comment out the `@name =` line. eval %{ puts "Setting name" #@name = "Joe" } Looks quite regular, but now this stuff happens: SyntaxError: (eval):3: syntax error, unexpected '=', expecting $end = "Joe" ^ First, **the workaround**. Use more than one `#` character or put a space bar between `#` and `@name`. Both should work: * `##@name = "Joe"` * `# @name = "Joe"` Second, **the explanation**. Try this in IRB: >> @s = "xys" >> "#@s" => "xyz" Aha! Ruby interpreter (both 1.8 and 1.9, by the way) treats `#@var` as an interpolation token. So now we know why the original example crashed: we tried to comment out `@name =`, put a hash sign before it, but inadvertently turned it into an interpolation statement. Moral: * Ruby isn't to blame. * `eval` isn't to blame. * String interpolation isn't to blame. * Just pay a little more attention to special chars sitting next to `#` in string values. :)

`File.expand_path` is one of the most useful path manipulation methods I use in almost every Ruby file. If you also use it often, please keep in mind that it doesn't always convert symlinks to real paths. >> File.expand_path("~/.irbrc") (1) => "/home/alexrb/.irbrc" >> File.expand_path(".irbrc") (2) => "/.devel/home/alexrb/.irbrc" My `/home/alexrb` is actually a symlink to `/.devel/home/alexrb`: >> ENV["HOME"] => "/home/alexrb" >> File.realpath ENV["HOME"] => "/.devel/home/alexrb" Note that example (2), based on current directory, did produce an absolute path, whereas (1) didn't. **Conclusion**: If you want real path for sure, use `File.realpath` on top of `File.expand_path`.

A single spec file may contain hundreds of examples. What if we want to stay focused on a particular one and skip the others for now? In other words, how do we filter? Up to this writing RSpec (2.11) supports the following ways to filter examples: * By line number in the spec file (`-l`). * By description string (`-e`). * By tag (`-t`). Filtering by line number: $ rspec some_spec.rb -l 159 Filtering by description string: $ rspec spec/models/user_spec.rb -e "User is admin" Filtering by tag: it "should generally work", :focus do true.should == true end $ rspec some_spec.rb -t focus I've been using all three methods for quite a while now. **Filtering by line number** seems to be by far **the most versatile and frequently used way**. Does your experience differ from mine?

Suppose we're listening to a message queue within an `EventMachine` scope. Suppose we've got a message, but it's not the one we're expecting, so we'd like to skip it hassle-free. How can we pass control back to EM without having to wrap everything in a long `if`? The short answer is: use `next`. Example follows. EventMachine.run do queue.subscribe do |message| if not message.match /known_to_us/ puts "Unknown message, skipping (message:#{message.inspect})" # Yield control back to EventMachine. next end # Proceed with reply. ... end end

I've been developing an AMQP application recently using RabbitMQ. Its control application `rabbitmqctl`, is allowed to be run by `root` and `rabbitmq` users only, which causes a bit of pain every time I want to list queues, exchanges etc. from my regular development shell. Hence this little hack to allow certain users to run `rabbitmqctl`. The recipe is for Ubuntu Linux, but should work for any Unix with a pinch of salt. There's a group called `rabbitmq`. We'll set it up the way all members of this group will be allowed to run `rabbitmqctl` without pain. * Create `/etc/sudoers.d/rabbitmqctl`: # Allow members of `rabbitmq` run `rabbitmqctl` without a password. %rabbitmq ALL=(ALL) NOPASSWD: /usr/sbin/rabbitmqctl * Fix permissions of this file, or `sudo` will carp every time we run it: # chmod 440 /etc/sudoers.d/rabbitmqctl * Create `/etc/profile.d/rabbitmqctl.sh`: if [ `id -u` != 0 ]; then alias rabbitmqctl="sudo /usr/sbin/rabbitmqctl" fi * Add intended members to group `rabbitmq`. Edit `/etc/group`: rabbitmq:x:120:alex,bob,carl * Re-login as one of group members and give it a try: $ rabbitmqctl list_vhosts Should work. If it doesn't, use the "Comments" box below. :)

Ability to use just one method, `def change` in Rails 3 migrations is a neat feature, but **be sure** to test that your migration works in both directions before you rely on it completely. One of the features that sadly **does not** work in a `def change` is `change_column_default`. Consider an example: def change [:users, :is_special].tap do |table, column| add_column table, column, :boolean, null: false, default: false change_column_default(table, column, nil) end end Works fine when we do a `db:migrate:up`, but at `db:migrate:down` it yields: == AddIsSpecialToUsers: reverting ============================================ rake aborted! ActiveRecord::IrreversibleMigration I switch to good old `def up` and `def down` in this case.

Consider this IRB snippet: >> eval("v = 1") >> v NameError: undefined local variable or method `v' for main:Object That's Ruby 1.9. In Ruby 1.8 it was possible to create locals via `eval`, but that's generally due to lack of proper optimization. Yakihiro [explains](http://www.ruby-forum.com/topic/155673) the mechanics behind it. To keep it short: In Ruby 1.9 locals are created compile-time. `eval` is dynamic and has its own scope. If the local exists, `eval` will assign it. If not, it will stay private to `eval`'s scope.

Git automatic merge occurs when you pull changes from the remote after you've made a few local commits already. It can be identified by the following commit message: Merge branch 'master' of git.isp.com:project into master Although most of the time it merges okay, there are serious reasons to think that letting branches merge automatically is a bad habit which shouldn't be practiced. If you merge, merge explicitly, but don't let it happen on its own. A nice hack I've found not long ago is aliasing `git pull` to `pull --ff-only`: git config --global alias.pl "pull --ff-only" Now, if you run `git pl`, Git will refuse to pull changes if they are not fast-forward. Which, in turn, means that you'll need to rewind, then pull, then merge your changes on top of the recent updates. Which I consider a **good practice**, especially if you work in a team. Here's a couple of good posts from good authors with good reasons why automatic merges should be avoided: * [Handling "git pull" Automatic Merges, by Andrew Berry](http://www.lullabot.com/articles/handling-git-pull-automatic-merges) * [Avoiding Git Disasters: A Gory Story, by Randy Fay](http://randyfay.com/node/89) Thanks fly to Andrew Berry for the `git pl` hack.

Using `respond_to?` to check if an object is capable of doing something? Me too! Please note that `respond_to?` returns `false` for private methods **even if you're in the context of `self`**. Hence, don't forget to pass `true` as the second argument to query for private methods: class Klass private def private_meth end public def query [ respond_to?(:private_meth), respond_to?(:private_meth, true), respond_to?(:actually_missing), respond_to?(:actually_missing, true), ] end end >> Klass.new.query => [false, true, false, false]

To keep it short: >> Array.wrap(nil) => [] >> Array.wrap(1) => [1] >> Array.wrap([1]) => [1] Might come in handy when you need to append a valid value to collection without extra fuss like `[(value if condition)].flatten` or similar. Please keep in mind `Array::wrap` is an ActiveSupport extension. >> Array.ri :wrap (from gem activesupport-3.2.8) ------------------------------------------------------------------------------ wrap(object) ------------------------------------------------------------------------------ Wraps its argument in an array unless it is already an array (or array-like). etc.

Suppose we've got this in our controller spec: get :edit, id: r.id response.should render_template "edit" Looks perfectly clear, but don't get over-assured about it. The matcher expects the word "edit" **anywhere** in the template filename, and, if found, the example will pass. For instance, if the actual template rendered is called `no_permission_to_edit` (which clearly assumes that editing is **not** allowed), the example will still be green. A simple and straightforward **workaround** might be: response.should render_template "/edit" , which will only match templates whose names **start** from "edit". More in-depth **solution** to the problem related to vague template matching is **using the HTTP codes** to distinguish situations like allow/deny. Consider this: Controller (simplified, proof-of-concept): def edit if not permission_condition return render "no_permission_to_edit", status: :forbidden end # Allowed, render stuff as usual. ... end Spec: get :show, id: r.id response.status.should == 200 # Is allowed. get :edit, id: r.id response.status.should == 403 # Is denied. delete :destroy, id: r.id response.status.should == 403 # Is denied.

# Marshal hacks. require_dependency "matcher/date" require_dependency "matcher/figure" require_dependency "matcher/url" module Parser class Sentence < ::Parser::Base def initialize @matcher = { :date => ::Matcher::Date.new, :figure => ::Matcher::Figure.new, :url => ::Matcher::Url.new, } ... end ... end end

module Mo class << self private def actually_private? "Oh yes... But you won't see this, I'm private you know..." end end end >> Mo.actually_private? NoMethodError: private method `actually_private?' called for Mo:Module

Pending examples are reported separately. Also, if colors are enabled, they are nicely decorated so you won't miss them.