Bob Remeika pointed us to his recent labor of love: Drails:
Introducing Dojo support for Ruby on Rails!
drails is a helper library for using Dojo alongside Rails. It provides a Dojo implementation for all of the Rails helpers that would normally generate Prototype/Scriptaculous code so now ajaxifying your Rails application with Dojo is as simple as using the built in support that Rails already provides for Ajax, effects, and drag-and-drop.
Along with this release, drails also includes support for the following:
- Generating Dojo Dijits (along with the appropriate test files)
- Generating modules (along with the appropriate test files)
- Generating a dojo build profile based on the scripts that currently reside in your application
- Rake tasks for creating a dojo build which can easily be added to a capistrano task for deployment
I wanted to say a big thank you to all that have helped, especially Jon Moeller and the Dojo Foundation, for providing great ideas and code during GSoC. The project has been a long time coming and I’m very happy to say that it’s finally at a point where it can be used.
The source and installation instructions are available on github:
The team at Nextpoint has released the open source project Growl4Rails, a component providing Growl-like functionality in Rails web applications.
Nextpoint’s e-discovery product deals with many very large documents. Indexing, imaging and PDF-ing of those documents can take a bit of time, which requires us to execute these tasks asynchronously. Background processing demands a solid way of notifying users when that process has completed. We’re a Mac shop, and one of the first things most Mac users install is Growl. We thought that Growl’s interface could really be successful on the web and provide a great way of notifying our users when this background processing has completed.
Growl4Rails is available as a Rails plugin on Github. It requires Prototype 1.6 and Scriptaculous 1.7, and it has been tested on FF, IE 6-8, Safari, Opera and Chrome.
The all-new Red is a Ruby-to-JavaScript transliterator backed by a custom ruby.js library designed to let your code run in the browser exactly* the way Ruby would run on your machine. The JavaScript output is optimized to contain only the fraction of the ruby.js source library needed to run your code.
What does this mean for today’s Ruby developer? Simple. You don’t need to learn JavaScript.
Trek Glowacki shows us what this is all about. When I wrote about running JRuby in the browser I talked about the desire for a nice API to the browser side of things. Having Ruby is fine and all, but what about the APIs? What about the standard library?
In the demo screencast below you get to see some of the APIs in question, such as:
Ken Collins has rewritten his Homemarks application, a Rails app that "allows you to dynamically create and sort Columns, Boxes, and Bookmarks into your own custom start page."
What is interesting about the rewrite is the new approach that Ken took; the Ajax Head Pattern as he described it:
HomeMarks was built using the Ruby on Rails framework with a heavy emphasis on object oriented JavaScript to make AJAX requests to a RESTful back-end. Unlike most Rails applications it does not use any inline JavaScript helpers nor does it rely on RJS (Remote JavaScript) for dynamic page updates. Instead it is nearly 100% unobtrusive JavaScript which uses simple HEAD or JSON responses to communicate to the objects on the page. This has yielded very slim controller code which is decoupled from the views and easily testable in isolation at a functional level.
You end up with a lot of code that deals with HEAD:
With my Google hat on, I got to interview Michael Marcus and Rui Ma, two recent graduates from a masters program at NYU. They joined me to discuss Gears on Rails, their open source framework that makes it easier than ever to take a Rails code-base offline.
They take the approach of giving you a high level Ruby-ish way of developing your Rails app and having it work offline against local storage.
This means that you end up building actions like this:
def create_local
'
post = Post.build(params("post"));
Post.create_local(post);
window.location.reload( false );
'
end
They build the local framework on the Jester framework that is a "JavaScript client for REST APIs that uses Rails conventions, and is inspired by Rails' own ActiveResource".
This means that you can write client side code like this:
Eric Falcao has released Clientperf, a simple client-side Rails performance plugin.
The tool came about as Eric is giving a talk on "14 rules of high-performance websites in the typical rails mongrel/nginx stack, the main idea being to focus on some of the important implementation details when it comes to client-side performance optimization."
As I was planning, I realized that there was no simple as in the we’re-all-spoiled-with-rails simple way to measure client download times in production. Now, there is clientperf. It’s just a start, but decent enough to benchmark the actual client performance impact of any optimizations you make.
How it works
It injects javascript into the page that takes a timestamp at the top of the page and at the bottom of the page. Once the browser is done downloading, evaluating and rendering all assets, clientperf makes one last image request to your server with the start time, end time and the URL. Piece of cake.
Aptana took over the RadRails open source project a few months back, and now have fully integrated it with Aptana Studio with the RadRails 1.0 release.
RadRails 1.0 runs as a plug-in to Aptana Studio. So in addition to all the Ruby on Rails IDE goodies and the integrated Rails shell command-line console, developers get the great HTML, CSS, DOM, JavaScript and Ajax features in Aptana Studio, which can run stand alone or within Eclipse to that all your other Eclipse tools can be right there as well.
The new version has a slew of new and enhanced functionality such as:
Rails 2.0 support
JRuby support
Bundled auto-installing gems for rails development
A Ruby profiler for Pro users
An RDoc preview view
Extended RHTML/ERb color preferences
Code completion for ActiveRecord model fields and finders
Code completion suggesting method call arguments
Significant expansion of code warnings and analysis, including syntax changes from Ruby 1.8 to 1.9
Heroku is a new YCombinator startup that joins the growing number of "use your browser to build your apps" type of applications.
You can create new Rails applications, and they are magically hosted up in the cloud. You can import your own Rails application, or you can use the inline editor and tools to built the application directly in the browser.
Heroku itself is a Rails application. I wonder if they now self hosting :)
Being able to quickly build an application and have it running live is great (using Amazon EC2), and this is just the beginning. They already tie into the usual tools like Rake, but there is room to go further and have nice DB utilities, cloning of functionality, and much more.
The editor itself could use a bunch of work too. I can never see where the cursor is, let alone have all of the Textmate / Aptana / IntelliJ goodness.
Last week we posted about Jaxer which offers an approach of turtles all the way down where JavaScript is used on the client and the server.
Then, I got to interview Steve Yegge. Last year, Steve posted about Rhino on Rails, his port of Ruby on Rails to the JavaScript language on the Rhino runtime.
What can't you do since JavaScript doesn't have the same meta programming facilities?
Rails = a group of Active*, so did you re-implement everything?
What do you gain out of having JavaScript all the way down?
Does it actually make sense to have jjs? Server side JavaScript generating client side JavaScript? Argh!
What is the state of Rhino?
Will Rhino support JavaScript 2?
And of course, the big questions:
When do I get to see it!
I happen to be in Seattle at the Google offices, so I was able to ask all of these questions and more. Steve was a fantastic host, and I really enjoyed chatting with him.
This is the kind of video I want to explore at Google. We have many great developers working on cool technology. I want to get them on camera, participating with the community when I can. Sometimes we can talk about products and APIs, but sometimes we will talk about fun ideas and projects that we are working on such as Rhino on Rails.
Anyway, give it a watch and let me know what you think:
The Ext Scaffold Generator Plugin provides a custom MIME type alias :ext_json to be able to handle requests from the Ext frontend separately. The generated controllers show how to do this.
To make data delivery to the Ext frontend easy, the plugin extends the Array and ActiveRecord::Base classes to provide a to_ext_json method. Here’s a simplified example of a potential index method in a PostsController:
# GET /posts
# GET /posts.ext_json
def index
respond_to do |format|
format.html # index.html.erb (will fire ext_json request)
format.ext_json { render :json => Post.find(:all).to_ext_json }
end
end
He also has some other good articles on integrating Ext JS and Rails in general.
I was at the PCWorld innovative product awards at CES last night, and ran into Tastebook, a site that allows you to build a personal cookbook from both online and your grandma's recipes.
The site is Rails based, and uses a mixture of JavaScript and Flash to get rich functionality such as a visual representation of the book, a designers, access to Web services, and drag and drop support.
Rob Sanheim sat down with Zed Shaw at RailsConf and had an hour long conversation with him that covered his thoughts on the Rails community, the role of the Enterprise, the state of Ajax, JRuby and Rubinius, documentation, tests, tooling, the role of patents in software, and a whole lot of opinion.
It is very interesting to listen to this after the explosion that happened when Zed lambasted the Rails community. When you listen to this interview, you see some of the seeds of the rant, but it is a lot more toned down, and there is some good stuff in there. It is easy to blog a crazy rant.... but when you are talking to someone you get a different side of the coin. This gives you that side, from a time when he wasn't as upset as he may have been when he sat at the computer to type up his post.
Derek Gaw gave an ignite talk tonight onAIR which showed off his Uncluttr project.
Derek works for Amazon, but this is outside of his company work. He is frustrated seeing 1.5MB of content being downloaded when you login, find a book, and then view the detail page. That is too much.
Uncluttr uses the Amazon Web Services and is written with Prototype and Rails.
