sorted by: recent | see : popular

Content Tagged with & + tricks

Having spent the better part of a day googling and struggling, I figured it would possibly benefit others if I took a minute to post the steps I took to clone a VMWare Fusion image. The image in question is of Ubuntu Server (Hardy). I’m using VMWare Fusion 2 (beta 2).

Just find your “Virtual Machines” folder (should be in your Documents folder), and copy the image in question to a new location. (The images are actually folders; a simple “cp -R” worked fine for me.)

Then, open the copied image in VMWare Fusion and boot it. VMWare Fusion will ask if you if you copied or moved the image—be sure to say you copied it (that let’s VMWare set up a new MAC address for your image).

Go ahead and log in once the server boots. You’ll find networking is all hosed. To fix networking, this worked for me:

• “sudo hostname blah”, to set the hostname. This doesn’t change it permanently, so you’ll also want to:
• “sudo vim /etc/hostname”. Change the contents of the file to the hostname you want. Then:
• “sudo vim /etc/hosts”. Replace all mentions of the old hostname with the new hostname.
• “sudo vim /etc/udev/rules.d/70-persistent-net.rules”. There will be two entries in this file. The first points eth0 at the old MAC address, and the second points eth1 at the new. Go ahead and delete the first entry, and change “eth1” to “eth0” in the second (and now only) entry.
• “sudo shutdown -r now” to restart your virtual machine.

Once your machine comes back up, you should have a network again! Now, if only VMWare Fusion could bake all this in somehow… :/

(Related: installing VMWare Tools on Ubuntu server. It’s from 2006, but it still worked well enough for me, though I followed the instructions for tweaking the network that the VMWare Tools install gave at the end, rather than what this gent said.)

James Crisp wrote a nifty Contact Feedback plugin for Mephisto for the new Thoughtworks Studios site. The plugin looks nice, and fills a common need in Mephisto. Also, the Thoughtworks Studios site is extremely well-done. I had seen it before, but didn’t realize it used Mephisto. Major kudos to James Crisp and Thoughtworks!

For anyone that asks: it looks like the main difference between this, and my own feedback plugin is that mine doesn’t send emails. It stores them in the DB and lets you browse in the admin. Nice since your inbox doesn’t get the spam, but I’ve been finding that I often forget to check it :)

Last night I released the first preview of Net::SSH::Multi (gem install --source http://gems.jamisbuck.org net-ssh-multi). Today, let me show you a tasty hint of what you can do with it.

Consider the following Rakefile:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

def remote
  @remote ||= begin
    require 'net/ssh/multi'

    session = Net::SSH::Multi.start

    session.via 'gateway.host', session.default_user

    session.group :web => session.use('web1', 'web2')
    session.group :app => session.use(*(1..8).map { |n| "app%02d" % n })
    session.group :db  => session.use('db1', :properties => { :primary => true })

    session
  end
end

namespace :remote do
  task :hostnames do
    remote.exec("hostname").wait
  end

  task :app_hostnames do
    remote.with(:app).exec("hostname").wait
  end

  task :web_hostnames do
    remote.with(:web).exec("hostname").wait
  end
end

You can now do things like this:

1
2
3
4
5
6
7
8
9
10
11
12
13

$ rake remote:hostnames
(in /home/jamis)
[web1] web1.host
[app02] app02.host
[app05] app05.host
[app03] app03.host
[app06] app06.host
[app08] app08.host
[db1] db1.host
[app01] app01.host
[web2] web2.host
[app04] app04.host
[app07] app07.host

The Net::SSH::Multi library is still experimental, but it is stable and full-featured enough that I seriously considered implementing the next release of Capistrano on top of it. (I’ll probably put that off until cap3, though, due to the magnitude of the change.) If you do something cool with it, let me know!

James Crisp wrote a nifty Contact Feedback plugin for Mephisto for the new Thoughtworks Studios site. The plugin looks nice, and fills a common need in Mephisto. Also, the Thoughtworks Studios site is extremely well-done. I had seen it before, but didn’t realize it used Mephisto. Major kudos to James Crisp and Thoughtworks!

For anyone that asks: it looks like the main difference between this, and my own feedback plugin is that mine doesn’t send emails. It stores them in the DB and lets you browse in the admin. Nice since your inbox doesn’t get the spam, but I’ve been finding that I often forget to check it :)

Today I’d like to highlight the mephisto_article_image_fetchy plugin, from the twisted mind of courtenay. It scans the article body for any image tags, creates assets from any remote images, and replace the URLs in the body of the article. (see included image as an example, linked from here).

For any plugin developers, notice how this uses a module and #include_into to extend Article, and the little-known #body_doc method to grab an HTML::Document of the article body. I actually added #body_doc to the filtered_column plugin so that more plugins like this could be made without having to generate the document multiple times.

Jon Baker wrote a great article on creating Mephisto themes. There’s also a nifty Liquid for Mephisto PDF cheatsheet by George that was released on the same day.

Finally, who posted as Dr Acula in the previous post? Totally awesome…

Jon Baker wrote a great article on creating Mephisto themes. There’s also a nifty Liquid for Mephisto PDF cheatsheet by George that was released on the same day.

Finally, who posted as Dr Acula in the previous post? Totally awesome…

James Crisp wrote a nifty Contact Feedback plugin for Mephisto for the new Thoughtworks Studios site. The plugin looks nice, and fills a common need in Mephisto. Also, the Thoughtworks Studios site is extremely well-done. I had seen it before, but didn’t realize it used Mephisto. Major kudos to James Crisp and Thoughtworks!

For anyone that asks: it looks like the main difference between this, and my own feedback plugin is that mine doesn’t send emails. It stores them in the DB and lets you browse in the admin. Nice since your inbox doesn’t get the spam, but I’ve been finding that I often forget to check it :)

I use ActiveRecord::Base#find a lot in the Rails console. A lot. As a result, I’ve started doing the following:

1
2
3

class <<ActiveRecord::Base
  alias_method :[], :find
end

That little snippet saves me up to five entire keystrokes, every time I need to do a find!

1
2
3

prs = Person[5]
prs = Person[:first]
prs = Person[:all, :conditions => { :name => "Jamis" }]

And, thanks to the existing hash and array semantics, it loses none of find’s readability for most cases. Good stuff!

Ruby makes it very easy to raise exceptions:

1
2
3
4

def finagle_something
  raise "need a block" unless block_given?
  ...
end

Using raise like that (with just the exception message) is really handy for quick-and-dirty solutions. But for Serious Business Stuff™ you may often find the ambiguity of the default RuntimeError a little frustrating.

Ruby has a bunch of predefined exception classes that you can use. For the above, you’d do better to raise an ArgumentError, specifically (raise ArgumentError, "need a block"). It can pay big dividends to become familiar with the standard exception hierarchy in Ruby.

Sometimes, though, the standard exception classes just aren’t enough. For example, in Capistrano 2.0, I’d like any exception that Capistrano itself raises to be immediately recognizable as a Capistrano exception. The solution?

1
2
3
4
5

module Capistrano
  class Error < RuntimeError; end
  class ConnectionError < Error; end
  ...
end

Now, clients of Capistrano only need to look for Capistrano::Error to safely catch any exceptional conditions within Capistrano:

1
2
3
4
5

def use_capistrano
  ...
rescue Capistrano::Error => error
  warn "couldn't do a capistrano thing: #{error.message}"
end

Furthermore, the benefits of having more specific exception classes (like Capistrano::ConnectionError) are manifold; you can write code to easily detect and retry certain errors, or report some problems differently than others. When you start using specific exception classes, instead of the default RuntimeError, you’ll find you can handle your exceptions much more gracefully, and write much more robust programs.

Here’s a really simple little tip, related to displaying paginated results. Using offset/limit, it’s pretty trivial to pull back just the page of data you want, as long as you know what the last offset/limit values were:

1
2
3

rows = Person.find(:all, :conditions => { ...},
  :limit => page_size, :offset => last_offset + page_size)
more_results = (last_offset + page_size + rows.length) < Person.count

However, it’d be nice to do this in a single query, especially since Person.count can get spendy if there are a lot of rows in the database. Here’s a simple way to do it:

1
2
3

rows = Person.find(:all, :conditions => { ...},
  :limit => page_size+1, :offset => last_offset + page_size)
more_results, rows = rows.length > page_size, rows[0,page_size]

You query the database for one more row than you actually want (page_size+1). If you get that many rows back, then you know there is at least one more page of data after the current page.

Here’s a nifty trick. Route#to_s exists. Why is this cool?

1
2
3

ActionController::Routing::Routes.routes.each do |r|
  puts r
end

This will give you a list of all of the routes you have defined, in a very human-consumable format. It’s great if you are trying to figure out why Rails is having problems accepting a URL that you think it should be accepting.

Similarly, you can list all of your named routes:

1
2
3

ActionController::Routing::Routes.named_routes.routes.each do |name, route|
  puts "%20s: %s" % [name, route]
end

This is especially handy if you are using map.resources, where there are lots of named routes being generated for you behind the scenes.

This is hardly an original trick (it’s been mentioned many times before, on countless other blogs) but it is useful enough that it deserves mention yet again.

Ruby won’t let you divide an integer by zero—you’ll get an exception. However, thanks to the IEEE 754 standard for floating point numbers, when you try to divide a float by zero you get a rather special value back:

1
2

puts 1.0/0
#-> Infinity

It’s not a constant though, it’s just how that floating point result is represented as a string. However, you can easily assign that value to a constant:

1

Infinity = 1.0/0

Once you have that, you can use it for all kinds of nifty things; throw it in ranges, use it in comparisons, whatever suits your fancy:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# a rather useless range
everything = -Infinity..Infinity
puts everything.include?(5) #-> true

# use it for representing an unbounded value
storage_limits => { :demo => 0,
  :standard => 250.megabytes,
  :expert => 1.gigabyte,
  :unlimited => Infinity }

if bytes_used < storage_limits[account_level]
  # add another file or something
else
  # display "out of space" message
end

Like I said earlier, it’s old news, but no less handy for that.

The RESTful routes feature in Rails makes it really, really simple to nest resources within each other. Just give a block to the “map.resources” call, and define further resources on the value yielded to that block:

1
2
3
4
5
6
7

map.resources :accounts do |accounts|
  accounts.resources :people do |people|
    people.resources :notes do |notes|
      notes.resources :comments
    end
  end
end

That monstrosity would allow you to define routes like:

1
2
3
4
5
6
7
8

accounts_url         #-> /accounts
account_url(1)       #-> /accounts/1
people_url(1)        #-> /accounts/1/people
person_url(1,2)      #-> /accounts/1/people/2
notes_url(1,2)       #-> /accounts/1/people/2/notes
note_url(1,2,3)      #-> /accounts/1/people/2/notes/3
comments_url(1,2,3)  #-> /accounts/1/people/2/notes/3/comments
comment_url(1,2,3,4) #-> /accounts/1/people/2/notes/3/comments/4

Simple! However, in using RESTful routes more and more, I’m coming to realize that this is not a best practice. Rule of thumb: resources should never be nested more than 1 level deep. A collection may need to be scoped by its parent, but a specific member can always be accessed directly by an id, and shouldn’t need scoping (unless the id is not unique, for some reason).

Think about it. If you only want to view a specific comment, you shouldn’t have to specify the account, person, and note for the comment in the URL. (Permission concerns can come into this, to some degree, but even then I’d argue that judicious use of the session is better than complicating your URLs.) However, if you want to view all comments for a particular note, then you do need to scope the request by that note. Given the above nesting of routes, I’m finding the following a better (if slightly more verbose) method:

1
2
3
4
5
6
7
8
9
10
11
12
13

map.resources :accounts do |accounts|
  accounts.resources :people, :name_prefix => "account_"
end

map.resources :people do |people|
  people.resources :notes, :name_prefix => "person_"
end

map.resources :notes do |notes|
  notes.resources :comments, :name_prefix => "note_"
end

map.resources :comments

You’ll notice that I define each resource (except accounts) twice: once at the top level, and once nested within another resource. For the nested resources, I also give a “name_prefix”—this gets tacked onto the front of the named routes that are generated.

So, the above mappings give you the following named routes:

1
2
3
4
5
6
7
8

accounts_url          #-> /accounts
account_url(1)        #-> /accounts/1
account_people_url(1) #-> /accounts/1/people
person_url(2)         #-> /people/2
person_notes_url(2)   #-> /people/2/notes
note_url(3)           #-> /notes/3
note_comments_url(3)  #-> /notes/3/comments
comment_url(4)        #-> /comments/4

The URL’s are shorter, and the parameters to the named routes are much simpler. It’s an all-around win! I won’t go so far as to say that resources should never be deeply nested, but I will say that you should think long and hard before you go that route.

Remember Watching ActiveRecord Do Its Thing, where I talked about redirecting the log to STDOUT when using the console? I’ve got a new trick based on this that I’ve found quite helpful. Simply put the following snippet in your config/environment.rb:

1
2
3
4

def log_to(stream)
  ActiveRecord::Base.logger = Logger.new(stream)
  ActiveRecord::Base.clear_active_connections!
end

Now, when you’re at the console, you can just do:

1
2
3
4
5
6

>> log_to STDOUT
=> ...
>> Post.find(:first)
  Post Load (0.000138)   SELECT * FROM posts LIMIT 1
=> #<Post:0x1234 ...>
>>

The best part is, by clearing the active connections after setting the logger, you can change the logger at any time, even after you’ve made any number of find calls.

And, you can pass your own stream objects into it:

1
2
3
4
5
6
7
8
9

>> buffer = StringIO.new
=> ...
>> log_to buffer
=> ...
>> Post.find(:first)
=> #<Post:0x1234 ...>
>> p buffer.string
=> "  \e[4;35;1mPost Load (0.000138)\e[0m   \e[0mSELECT * FROM posts LIMIT 1\e[0m\n"
>>

Why would you want to do this? Well, for one thing, you can use log_to in your tests, and make sure that sensitive things like credit card numbers aren’t being written to your logs. Or, you can use this in tests to make sure that your latest optimization really does reduce the number of queries made to the database.

Good fun!

Here’s a quick little “advice” tip: don’t use assertions to test the structure of your views.

That is to say, don’t do this:

1
2
3
4
5

#make sure the text field is in the table cell
assert_select "table td input[type=text]"

# make sure the person's name is in the h2 header tag
assert_select "h2", person.name

Why not? Because you want your views to be very fluid. You want to keep the cost of change is so low that you have no hesitation to jump in and rearrange things to make the view cleaner. If you are using explicit tag names in your tests, you reduce that fluidity. Your views become rigid, because your tests imply that using anything but a table to format your form is wrong. Want to use an h1 for the person’s name, or a div? Don’t you dare, it’ll break the tests.

The better way to test your views is to think about what you are really wanting to test. First of all, don’t test static content, like table structures and the order of form fields on a page. Instead, test the dynamic parts of your view, especially those parts that are subject to conditional rendering. Secondly, test semantically, not syntactically. That is to say, don’t base a test on the type of the tag, but rather on what you want the content to represent. Use CSS classes and DOM id’s instead of explicit tag names.

Here’s a concrete example. Suppose you have a view like this:

1
2
3
4
5

<% if @user.administrator? %>
  Hi <%= @user.name %>! You appear to be an administrator.
  <%= link_to "Click here", admin_url, :id => "admin_link" %>
  to see the admin stuff!
<% end %>

The only really significant thing you ought to be testing here is that the admin link only shows up for administrators. You might also want to test that the link points to where you expect it to, though that’s a lower importance.

1
2
3
4
5
6
7
8
9
10
11

def test_admin_sees_link
  # set up session for an admin user first, and then:
  get "index"
  assert_select "#admin_link"
end

def test_non_admin_does_not_see_link
  # set up session for a normal, non-admin user first, and then:
  get "index"
  assert_select "#admin_link", false
end

Arranging your tests like this will make them less likely to break on cosmetic tweaks, which will increase your confidence in your tests and your willingness to tweak your views.

Names routes are hotsauce. We are all forever indebted to Marcel Molina, Jr. and his gift for elegant API’s. Without him, we’d still be stuck in the quagmire that is “map.connect”.

These days, I don’t use map.connect at all. Named routes for everything. Does that seem too extreme?

Let me clarify a bit. I don’t use map.connect with implicit routes. And just what is an implicit route? This is:

1

map.connect ":controller/:action/:id"

That’s an implicit route, because it implicitly maps any number of paths to any number of controllers and actions. Contrast that with an explicit route:

1

map.connect "/people/:id", :controller => "people", :action => "show"

The controller and action are now hardwired into the route. And if you’ve gone that far, you might as well go with a named route, too, since you can then access it directly:

1

map.person "/people/:id", :controller => "people", :action => "show"

So, why do I favor explicit routes over implicit routes? Consider some of the issues with implicit routing:

• If you want to temporarily “turn off” one of your controllers (say, you’re having problems with your RSS feeds and need to disable them for a bit), you have to somehow make sure the controller file can’t be found by the routing code, which means removing it, obfuscating it’s name, or some other hack. Using named routes, you just comment out the routes that point at the controller in question, and you’re all set.
• Say your application is a year old or so (ancient!) and has an established base of users, who have all bookmarked various areas of your app. Now, you go and refactor things, so that an action that used to be in one controller is now in another, and so forth. With implicit routes, you’re hosed, but with explicit routes your users’ bookmarks will continue to function as before, since the route that gets recognized remains unchanged—it simply points to a different place now.
• Implicit routes are extremely concise to define, but very verbose to use, since you often have to give the controller and action in the options to link_to, or url_for, or whatever you use. Sure, your routes.rb file is only one line long, but how much more did you have to type in your views?

Furthermore, I prefer named routes over unnamed routes, for a few reasons.

• Route generation using implicit routes is ugly, both internally and externally. I mean, seriously, who wants to type “link_to(person.name, :controller => ‘person’, :action => ‘show’, :id => person)” when they can type “link_to(person.name, person_url(person))”. It gets even worse if you want to pass HTML options to link_to, because you have to use explicit curly braces around the route options in that case. Named routes are, as I said, hotsauce.
• You can use named routes in functional and integration tests. Pretty cool! In functional tests, you can do “assert_redirected_to(person_url(people(:bob)))”. In integration tests, you