Poetry of Programming

Its about Ruby on Rails – Kiran Soumya


Conditional periodically_call_remote in Rails

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:

<%= periodicallycallremote(
:condition => “check_var == true”,
:update => “myupdatediv”,
:frequency => 20,
:url => { :action => “bar” }) %>

Then in your templates define check_var true or false depending on whether you want the periodical updates to take place:

< script type=”text/javascript”>

 check_var = true;

The :condition option can take any sort of JavaScript code, you can be as creative as you like in defining when and under exactly what conditions your periodical calls are made. Take back control!


Google releases AJAX development toolkit

Google announced yesterday the official release of the Google Web Toolkit (GWT), a Java-based platform for the development of AJAX web applications that work in all mainstream web browsers. Designed to simplify AJAX development, GWT generates consistent, browser-neutral Javascript from simple Java source code.

According to Google, the modularity of Java facilitates a higher level of code reusability. Google also claims that using Java for AJAX development is beneficial because powerful Java IDEs like Eclipse significantly increase developer productivity. GWT provides a number of unique features that contribute to more effective AJAX development. With GWT, developers assemble applications by laying out various AJAX widgets in panels and associating operations with application events.

In some ways, it seems like GWT makes it possible for AJAX developers to leverage the same techniques used for conventional desktop application development. Developers can also create their own custom GWT widgets by combining existing widgets. New GWT widgets can then be deployed in JAR files and made available to other developers. The ability to create and distribute custom AJAX components that can be used in multiple web applications is certainly compelling, and it could potentially reduce the amount of time it takes to develop web applications. In addition to providing support for modular user interface construction, GWT also provides a robust RPC mechanism, a system for managing browser history, and a native Javascript interface that allows developers to mix Javascript into their Java code.

GWT comes with support for two different run modes. Hosted mode, which is primarily used for debugging, will run GWT applications as Java bytecode within the Sun’s Java virtual machine using a specialized web browser designed by Google. To run an application in web mode, developers use GWT’s custom compiler to generate Javascript and HTML that can be deployed on any web server.

Although Google’s Java-oriented approach is innovative, generative AJAX development is hardly a novel or unique idea. A number of other development platforms are available that provide similar functionality. Ruby on Rails, a powerful web application development platform that leverages the model-view-controller pattern, also uses sophisticated generative programming techniques to enable construction of robust AJAX applications. In general, Ruby on Rails is more conducive to rapid development than most comparable Java technologies, and Ruby code tends to be easier to read and maintain. The dynamic nature of Ruby eliminates the need for compilation, which also serves to improve developer productivity. While GWT appears to be geared towards developing AJAX interfaces with familiar desktop application idioms, Ruby on Rails provides a more comprehensive architecture that focuses less on client side functionality and includes complete support for database functionality and other elements of web application development. GWT also seems similar to Microsoft’s Atlas toolkit, which facilitates AJAX development with the .NET platform. Unfortunately, early reports indicate that Atlas provides less than stellar support for alternate browsers, a problem that will hopefully be fixed eventually when it becomes more mature.

Which platform will developers choose? Browser support and language preference are probably the two most relevant factors. Developers that favor Java will probably be more inclined to use GWT or other Java-based technologies. It is likely that many .NET developers will prefer Atlas. Ruby on Rails is best suited for developers that prefer the enhanced expressiveness of dynamic languages, or developers that need an end-to-end solution that also includes database support.


Can Ruby Live Without Rails?

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?

  1. 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|

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.

  1. 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

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


Then, you could type


and get the result


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.

  1. 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

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

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

def seconds
// convert to miliseconds
self * 1000

def from_now
Time.now + self

def ago
Time.now – self


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.

  1. 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.