What is Rubinius ?

Evan Phoenix's Rubinius project is an effort to implement Ruby using as much Ruby code as possible. It is not, as professed, "Ruby in Ruby" anymore. Rubinius started out as a 100% Ruby implementation of Ruby that bootstrapped and ran on top of MatzRuby. Over time, though the "Ruby in Ruby" moniker has stuck, Rubinius has become more or less half C and half Ruby. It boasts a stackless bytecode-based VM (compare with Ruby 1.9, which does use the C stack), a "better" generational, compacting garbage collector, and a good bit more Ruby code in the core libraries, making several of the core methods easier to understand, maintain, and implement in the first place.

The promise of Rubinius is pretty large. If it can be made compatible, and made to run fast, it might represent a better Ruby VM than YARV. Because a fair portion of Rubinius is actually implemented in Ruby, being able to run Ruby code fast would mean all code runs faster. And the improved GC would solve some of the scaling issues Ruby 1.8 and Ruby 1.9 will face.

Rubinius also brings some other innovations. The one most likely to see general visibility is Rubinius's Multiple-VM API. JRuby has supported MVM from the beginning, since a JRuby runtime is "just another Java object". But Evan has built simple MVM support in Rubinius and put a pretty nice API on it. That API is the one we're currently looking at improving and making standard for user-land MVM in JRuby and Ruby 1.9. Rubinius has also shown that taking a somewhat more Smalltalk-like approach to Ruby implementation is feasible.

Rails on Virtual Machine

There was a short note today, that the Rubinius development team has successfully run Rails on their virtual machine. Although isn’t anywhere new production ready yet, it is a significant step forward in getting a faster Rails.

I covered some of the alternate Ruby implementations previously.

Congratulations to the team!

Rails Development Tips part-2

• Use database indexes to speed up queries. Rails only indexes primary keys, so you’ll have to find the spots that need more attention.
• Profile your code. The ruby-prof gem and plugin helped me make an application three times faster with only minimal changes to the code.
• Minimize graphic-related dependencies. If your application only needs to make a few thumbnails, don’t waste memory by importing large graphics libraries. Look at mini-magick or image_science for lightweight thumbnailing.
• Avoid excessive repeated rendering of small partials.
• Use CSS instead of inline tags to apply selective styling.
• Don’t use ActiveRecord’s serialize option to store large objects in database fields.
• Use attr_protected :fieldname in models to keep database fields from being manipulated from forms (or from any calls to Model.update_attributes(params[:model])).
• Use Ruby classes and inheritance to refactor repeated controller code.
• Use unobtrusive Javascripting techniques to separate behavior from markup.
• Package self-sufficient classes and modules as plugins or RubyGems.
• Cache frequently accessed data and rendered content where possible.
• Write custom Test::Unit assertions or rSpec matchers to help with debugging test suite errors.
• Rotate the Rails and Mongrel logfiles using the logrotate daemon on Linux.
• Build a reliable backup system.
• Automate deployment and maintenance with Capistrano or Vlad.
• Keep method bodies short. If a method is more than 10 lines long, it’s time to break it down and refactor.
• Run flog to determine overly complex methods and clases.
• Don’t use too many conditionals. Take advantage of case statements and Ruby objects to filter instead of multiply-nested if statements.
• Don’t be too clever. Ruby has great metaprogramming features, but they are easy to overuse (such as eval and method_missing).
• Become familiar with the most popular plugins. Instead of re-implementing the wheel, save yourself some time by using well tested, popular plugins

source :http://nubyonrails.com/articles/massive-list-of-rails-development-tips

Rails Development Tips or Hints part 1

• Store sessions in the database (or at least not on disk, which is the default).
• Use a custom configuration file for passwords and API keys instead of storing them in your Subversion repository. I use YAML and mirror the style of database.yml.
• Use constants where needed. Instead of repeating strings like the address of your customer service reply email, set it once in a constant (in environment.rb or the appropriate environment file) and use that throughout your application.
• Keep time in UTC. A no brainer, and easy to do.
• Don’t loop through ActiveRecord models inside other models. Use eager loading if you need to work with multiple associated models. Better yet, write a custom SQL query and let the database do the work for you.
• Beware of binary fields. By default, all fields are returned with queries, including the full contents of any binary fields. Use :select to pull out only the fields you need.
• Write tables to cache data for reports that span months and years. It’s much faster than re-generating a year’s worth of reports every time a page is loaded.
• Create a table with a list of country names. By default, Rails uses strings for selects and lists of countries, which doesn’t work well for reporting or database consistency between models.
• Avoid bloated controllers. Instead of piling actions into a controller, limit yourself to 10 actions per controller, then rethink your design.
• Keep your controllers and views skinny. In general, most of your code should be in your models, not your controllers or views.
• Don’t store objects in the session. Use integers or short strings if necessary, then pull the appropriate object out of the database for the duration of a single request.
• Avoid heavy response processing. Can you mark a record as needing to be processed, then use a cron job or a messaging server to do the long-running work? BackgroundRB is also an option. (I use this technique for filtering SPAM comments on this blog).
• Use ar_mailer to queue bulk emails instead of sending them during the Rails response cycle.
• Monitor your servers with the exception_notification plugin, munin, monit, or other tools.
• Don’t cut costs on hardware. You’ll quickly lose the money you thought you were saving if your developers have to spend even one day a month on unexpected server maintenance due to poor backups or cheap hardware.
• Test-drive your development.