I’m working on an organizational Ruby on Rails app, code-named “Kyeliblocks”, which is basically a to-do list organized by date. Sort of like a slimmed-down 30 boxes. One of the features of Kyeliblocks is to be able to drag bubbles (to-do items) from one block (calendar day) to another. This was my first time using Rails and script.aculo.us for drag and drop, and I ran into a problem while studying the examples and demos. All the examples, like scriptaculous’s shopping cart demo, had a small fixed number of droppables, so they didn’t need to know which droppable was the target — it was obvious from the action. So I had some code like this to make the bubbles draggable:

<% block.bubbles.each do |bubble| %>
  <div class="bubble" id=<%="bubble_#{bubble.id}"%>>
    ...
  </div>
  <%= draggable_element "bubble_#{bubble.id}", :revert => true %>
<% end %>

and then in the block view, I made the block droppable like so:

<div class="block" id=<%="block_#{block.id}"%>>
  ...
</div>
<%= drop_receiving_element "block_#{block.id}",
  :update => "kyeliblocks",
  :url => { :action => "drag_bubble" },
  :accept => "bubble"
%>

Then in drag_bubble.html.erb, my problem became evident:

I just dragged bubble #<%=params[:id].split("_")[1]%> to some block.


I had just dragged the bubble to some block, but I had no way to know what droppable I had just dragged it to! The draggable id was passed into params as :id, but the droppable id was nowhere to be found. I didn’t want to perpetrate a horrible hack like using 14 different copy-and-pasted action names for each of the 14 blocks visible on the page at any given time — the action name was the only way I could see to differentiate the target droppable.

But I was just being completely dense. That’s what every parameter other than :action is for, in the :url hash. All I needed to do was this:

<div class="block" id=<%="block_#{block.id}"%>>
  ...
</div>
<%= drop_receiving_element "block_#{block.id}",
  :update => "kyeliblocks",
  :url => { :action => "drag_bubble", :block_id => block.id },
  :accept => "bubble"
%>

(note the :block_id parameter on the :url line), and then my drag_bubble.html.erb had all the information it needed, right there in the params hash!

I just dragged bubble #<%=params[:id].split("_")[1]%>
to block #<%=params[:block_id]%>.


Now of course this was just an intermediate step for debugging — I want the action to actually do something instead of just render a template. But I still wanted to share my embarrassingly simple solution with y’all, in case some other Rails noob can save themselves a couple of hours of hair pulling. (:

The most beautiful line of code I have ever seen is the following line of Ruby code, which I snagged from the Pickaxe book:

(words[key] ||= []) << word

Granted, if you don’t think that Perl can be beautiful and elegant, you’re not likely to think that Ruby is either. But I think that the above line of code is the most beautiful, elegant, and eloquent line of code I have ever seen. Let me walk you through it.

First we have

words[key] ||= []

which is shorthand for

words[key] = words[key] || []

just like i += 2 is shorthand for i = i + 2. So what does this do? If words[key] (the result of a hashtable lookup) is non-nil, it does nothing. But if words[key] is nil (uninitialized), it initializes it to an empty array. It’s a very nice Ruby idiom for initialization.

Then it wraps up the resulting array (Ruby, like Lisp, is functional, so every expression returns a value) and appends a new word to it.

It’s equivalent to the following 4 lines of C++-ish pseudocode:

if (words.lookup(key) == null) {
  words.set(key, new Array());
}
words.get(key).append(word);

One of the guiding principles of Ruby is that code is read more often than it is written. How lovely it is that we can end up with such elegant and eloquent results.

I’ve decided to go with Rimu to host my upcoming Ruby on Rails application application. (That is, the web application to handle job applications.) They seem very knowledgeable, very dedicated to customer support, and they provide root access on a VPS. I was worried about becoming a full-time sysadmin/babysitter of the RoR app, but they sent me the following email that clinched it for me. And I also learned something about Ruby on Rails uptime, admin, and deployment that I hadn’t been able to get a straight answer to until now.

About keeping your rails app up, rails is usually stable enough on most modern deployments to not need too much babysitting. But we can help you set things up such that your mongrel processes and other stuff get restarted, just in case they crash.

For the quick and routine stuff, we usually do the admin free of charge. But if things do get hairy, we charge $10/15 mins. And we tell you if something will be charged before we do it, so you won’t get unexpected charges.

When you get your hosting with us, you get really good support. All our support people are real linux engineers. We’re not call center people. We are knowledgeable about things and some of us are even rails developers. So if you ever get yourself into a tight spot, we will be able to help you.

When you’re ready to order your VPS, just head on to this page:

http://rimuhosting.com/order/startorder1.jsp?type=18

Just mention that you want the rimu rails stack to be installed. Also mention any other special requests you may have or what other specific apps you want installed. If you have other questions, just email us.

Sincerely,
Sim

So, I decided to go with Ruby on Rails for this project, because I got so many opinions from either (or both) sides of the fence that it seemed like I couldn’t go wrong with either RoR or Django, and the tiebreaker is that Ruby is more Lisp-like, and Lisp is my favourite language. Boy, was this a good decision.

Ruby is SO COOL. It’s like a wacky chimera of Lisp and Perl, magically brought to life by a wizard waving a magic OO wand.

Ruby has many of the things I love about Lisp, like lambdas and closures:

def n_times(obj)
  return lambda {|n| obj * n}
end

times23 = n_times(23)
times23.call(3) -> 69

Ruby doesn’t have macros (that I’ve learned about yet), but it does have code blocks, which are really frickin’ cool. They’re kind of like Java anonymous inner classes but far more flexible. Get this, as a toy example of a Lisp with-file macro:

class File
  def File.with_file(*args)
    f = File.open(*args)
    yield f
    f.close()
  end
end

File.with_file("testfile", "r") do |file|
  while line = file.gets
    puts line
  end
end

The do..end block forms a code block that is sort of passed to the with_file method as sort of an additional argument. It’s actually more like a coroutine to which control is surrendered by the yield statement. And the parameter passing can go both ways — yield can pass parameters back to the code block, as in this case it passes back the file handle, named f in the method and with a formal parameter name of file in the code block. If with_file were a Lisp macro, yield would be the comma.

And not only is the language itself really cool, but I really like the Ruby community. The foreword to the book I’m reading made me tear up:

“I believe that the purpose of life is, at least in part, to be happy. Based on this belief, Ruby is designed to make programming not only easy but also fun. It allows you to concentrate on the creative side of programming, with less stress. If you don’t believe me, read this book and try Ruby. I’m sure you’ll find out for yourself.”
-Yukihiro “Matz” Matsumoto, creator of Ruby

This post and its code examples were inspired by the PickAxe book.

I’m about to start writing a web front end to a PostgreSQL back end. After looking at oodles of choices (Nenest, OpenToro, Alpha Five, php, JSP, cocoon, Plone, etc.) I’ve narrowed it down to either Ruby on Rails or Django. Ruby on Rails has more hype, but Django also sounds really good, and I’ve heard good things about Python. I don’t know either Python or Ruby yet; I know Lisp, Java, and a smattering of Perl. I’ll post again with more details about my decision process and my perceived pros and cons of each, but first I want to get some input without biasing y’all. Does anyone have any experience with Ruby on Rails or Django? How about Ruby or Python? Any input would be much appreciated; I’m planning on making this decision by Tuesday.