Loading new sections or pages in a Rails app using AJAX can do a lot to increase overall application snappiness and lengthen the life cycle of each page load, but if any of these pages use the periodicallycallremote helper, then these periodical calls may persist longer than you would like.

The trick to fix this is to note that in the documentation for periodicallycallremote, the options for defining the target URL and callbacks are the same for the link_to_remote helper, which include an option called :condition.

So if you want your periodical calls to cease when different pages in your app are loaded using AJAX, then use the :condition option to have periodicallycallremote check against a variable:

I do not know, use, or have an opinion on the Ruby language yet. But since this language climbed up to the 13th place in the Tiobe index, it deserves to be taken seriously. Bruce Tate is a well know proponent of Ruby. While some people are quick to blame any Java developer who is looking into other languages,in my opinion it’s an attitude of weak people. If we want Java keep evolving, we need to look around. I’ve asked Bruce several questions about this programming language, and this is our blitz-interview.

Why this 13-year old language was not known in the programming community until the Ruby on Rails came about?

I looked into this extensively for my Beyond Java book. Three important points in time are

1) The emergence of a language. This does not always coincide with the emergence of the catalyst.

2) The emergence of the catalyst. With Oak/Java, you could argue that this catalyst was applets in Netscape.

3) Point of no return. We’ve never seen a language emerge, wait twenty years, and then explode. At some point, we decide that we know all there is to know about a language, and then nothing can really help it. I’d put Smalltalk and Lisp into the camp of good languages that will never dominate commercially.

Ruby is a little strange for two reasons: it has no major commercial support (outside of Japan), and it stayed below the radar in Japan for such a long period of time. But the real point that you’ve got to measure is the emergence of the catalyst. Right now, the whole Ruby community–book sales, education, components–everything is wrapped up in Ruby on Rails.

I’m interested in Ruby, and a whole lot of other people are in this camp too, because it’s a dynamic language with a catalyst. Other languages have better web development experiences–Seaside on Smalltalk, for example. But Rails has traction, and the combination of productivity in a clean language with good market share is tough to beat.

Is creation of Web applications the main/only area where this language shines (I’m talking about the real-world business applications)?

Specifically, Ruby is a great language for metaprogramming. Think domain specific languages, open classes, templates, etc. Ruby is a higher level language than Java, with some functional programming tendencies, and powerful idioms that Java doesn’t yet share. A few things that I notice about Ruby are:

Dependency injection happens, but not through a framework. You can redefine an object or class to do method injection trivially. (The concept is called open classes in Ruby.) This capability makes testing much easier than it is in Java.

Ruby has a JSP-like model for substitution, and you can use it as a template for HTML/XML documents, but also for code. For example, you can have a template with variable substitution, and append that text as code to a class. This capability makes application generators almost trivial. You’ve probably seen Rails scaffolding if you’ve seen a Rails demo. But you can extend this scaffolding to build a surprisingly complete application, given a powerful enough metamodel. The streamlined project does exactly this. (streamlinedframework.org).

You don’t see much emphasis at all on AOP. Ruby uses the language itself to handle crosscutting concerns. Ruby 2.0 will hook before and after, and then you really won’t need AOP. Just open up the class and add interceptors in the places you need them with a handful of code.

So Ruby is a fantastic applications language. I’m doing projects now with around 150 tables, a very sophisticated web interface with tree views and AJAX on 20% of the views, and very complex business logic around rebalancing trees and optimal distribution algorithms. Ruby’s symbolic programming model makes this logic easier to reason through, and Ruby’s superior testing help me tremendously. I’d do this project with 3 times the Java programmers, and it would take a little less than twice as long. (It won’t be as fast as I’d make it with Java, but I don’t need it to be. The latency, as always, is in the database.)

But all of this flexibility comes at a cost. I can’t see Ruby as a platform for building middleware or operating systems. Enterprise programming (distributed 2pc, hard core orm) will take some time, and more investment than you see at this point. Right now, Ruby is a great applications language. I’d expect to see Ruby grow as a rich client framework. But it’s not a one-size-fits-all tool.

I’d love to see better Java/Ruby integration. I think it’s going to be important over time.

Imagine, that you have the right to add five Ruby language elements to the next version of Java. What would they be? Can you include quick code samples as well?

Closures.

Closures give you the ability to pass a code block as a parameter. At times, I’m simply looking for convenience. I can use a closure to print something 10 times:

10.times {puts "Hello"}

call do_something on each item in an array (this code example uses do and end in place of {}):

array.each do |item| item.do_somethingend

build a collection containing the squares of all items in an array:

array.collect {|number| number * number}

Other times, I want to customize the inside of a block of code. For example, when you deal with a file, you must make sure you handle exceptions, and clean up resources, leading to a repetitive ugly block of code. But with closures, you can do something like this:

File.open(filename) {|f| doSomethingWithFile(f)}

The open method can take care of all of the repetitive details for you. Closures help whenever you want to deal with blocks of something. Closures are a huge win for Ruby, and the design pattern is actually used frequently in Java within frameworks like Spring.

Continuations

The second feature is the continuation. Using a continuation, you can capture the state of execution within one instance variable. Think of a continuation as a save_game in an adventure game. You can pick up the game, in progress, when you restore the game. This is a code example of a continuation:

def loop for i in 1..10 puts i callcc {|c| return c} if i == 5 endend

This code captures the state of the loop method at the point where i is 5. If you called the method with the command:

continuation = loop

Ruby would produce

1 2 3 4 5

Then, you could type

continuation.call

and get the result

6 7 8 9 10

This type of processing is extremely important for the next-generation web server, and for implementing things like virtual machines (if you use a continuation-passing style, you can easily implement virtual machines with more stack depth, lightweight threads with cooperative multiprocessing, and many other interesting algorithms. RIFE builds their own version of continuations, so some Java frameworks already need this capability.

Mix-ins

Within Ruby, you don’t need AOP as frequently. You can implement something like a Java interface, but a module can give you both the implementation plus a specification. Java uses whole frameworks to give you the same capability. In the age of pojo programming, it would be incredibly useful to say I want this POJO, and mix in security, persistence, and transactions. Ruby modules, which provide mix ins, can do just that.

4.Open classes

Open classes let you open up and redefine a class in any context. You don’t have to rewrite the Integer class, for example, to add in the processing for units that an ingeger, or fixnum in Ruby, might need. You just implement methods that handle the math and the syntax you need.

For example, you could say

class Fixnum

// A fixnum represents a time in miliseconds.

def days // convert to miliseconds self.hours * 24 end

def hours // convert to miliseconds self.minutes * 60 end

def minutes // convert to miliseconds self.seconds * 60 end

def seconds // convert to miliseconds self * 1000 end

def from_now Time.now + self end

def ago Time.now – self end

end

Now, I can say things like 10.days.ago, and 6.hours.from_now, adding a certain richness to my domain specific languages. This capability is extremely powerful for testing also.

Full object orientation

In Ruby, everything is an object. When that’s true, frameworks become much easier to consume and write, because you don’t have to deal with so many mind-numbing special cases. Autoboxing gets you closer, but not all the way. Look at the API for an array. With a similar number of methods, the Ruby array is much, much more powerful. The reason is that the Ruby array doesn’t have to deal with every special case for primitive types.

Those are a good place to start, but there are many others as well.

I make my living working as a Java architect/developer. Can you give me a good pragmatic reason to learn Ruby? Is there a job market demand for Ruby skills?

Whenever you learn a new language, it changes the way you think. The Java programmers that I know that also know Ruby don’t use as much configuration, and take better advantage of their collections than Java counterparts do. They also look for more opportunities to do metaprogramming.

But there’s certainly a demand for Ruby developers, too. My latest book, From Java to Ruby, helps managers who need to do Ruby for technical reasons, understand the political implications of such a move. I wrote the book because of an increasing demand for literature for people seeking to use the right tool for the job, rather than blindly using the most popular choice of tools. I found that Ruby development efforts are out there.

I think we’re also constantly underestimating the possibilities for integration across languages. The ReST-based web services in Rails are very rich, and the integration options for JRuby, a Ruby virtual machine implemented in Java, can blow your mind. Think of Ruby scripting in a JSP, or Ruby rules in a Java rules engine, or Ruby tests for Java code. Minimally, Ruby is a fantastic scripting language, and Java developers can take advantage of this exploding frontier.