What do you get when the power of Ruby on Rails is combined with flexibility of Merb web framework? Rails 3 of course!

We have a very happy news: Rails 3 Beta is ready for testing. The improvements are numerous: ActiveRecord, ActionController, ActionView, and ActionMailer, ActiveSupport have all been redesigned. ActiveRecord got pimped with ActiveRelation scoped queries.

Some components have been refactored into their own: ActionDispatch, ActiveModel. Even better, all components can be used alone and you don’t have to require the entire Rails framework.

Rails is now not only Rack compatible, but subcomponents of Rails, like routing, are Rack middlewares.

Not to mention better dependency management system called Bundler, and improved performance especially on ActionView.

Read more detailed explanation on Yehuda Katz’s post:

http://www.engineyard.com/blog/2010/rails-3-beta-is-out-a-retrospective/

Will you upgrade to Rails 3?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

A Ruby on Rails web application I’ve been developing uses Dojo-based full AJAX frontend. I learned some new tricks during development, relearned old pitfalls, and found some mistakes that I’d like to share with you.

Our team decided to implement the webapp in a non-conventional approach, using Dojo Toolkit-based full AJAX frontend, without using any ActionView functionality. It turned that it went quite well, but there are some things that we weren’t aware of and now we know how to deal with it, and you will too.
Communication between backend and frontend is done using JSON REST API. Since there is pratically no view code in the server-side app, theoretically it would be more appropriate to use Sinatra instead of Rails. But we opted for Rails because of familiarity with all its eccentricasies and exoticism. It’s not so much about learning the Sinatra framework, but more on what if we need to hack things out? (which we have personally proven to be time consuming)

1. Make Good Use of Integration Tests

Since the app uses SOFEA-style (Service Oriented Front End Architecture), I thought backend tests aren’t so critical as it’s replaceable by the front end (which is separate) itself.

I was mostly wrong. Unit tests are still needed to test the backend implementation (with regard to database).

But to my surprise, integration tests are more important than ever, even more than functional tests.

Functional (controller) tests have limited use, I tend to skip it and it can even be misleading. Example: rendering string as JSON only outputs the string, but controller test won’t know that, while integration test detects that the returned JSON is incorrect. Let me illustrate with a more concrete example.

Wrong output:

@message = "Hello World"
render :json => @message

Correct output:

@message = "Hello World"
render :json => @message.to_sym

The first example returns just: Hello World, without quotes, which is an incorrect JSON. Since JSON is parsed, a simple string must be surrounded by quotes (and encoded), hence the to_sym ‘hack’.

2. Scaffolds Are Your Friend (or Leave Your Admin UI Alone for Now)

We thought we’d say good bye to ActionView. Well, we did, but not to scaffolds.

At first we focused on building the Admin UI, not so long before we realize we’re trying to do something Rails is good enough to do it for a few (milli)seconds: scaffolding.

Building the UI with Dojo, Dijit, and DojoX was fun. When you get to know JavaScript more, it’s not as scary as its reputation. And the resulting UI is awesome.

But we spent too much time building the Admin UI with Dojo. It’s not that the UI is hard or that we won’t need it, but we don’t need it now.

Schemas may evolve (migrate), as development progresses, and we couldn’t care less about how the Admin UI looks at this point.

Another plus for Rails scaffolds (whichever your preferred flavor) is it can directly reflect the database. Not true with Dojo-based one. You can rake db:migrate or change the model and voila, your Admin UI instantly has your changes.

3. Start Small

Two previous tips were more concrete, but this one is less of an action and more of… Less.

We tried to do more with more. We actually did less.

Especially during new development, you need as much instant gratification as possible.

Do less with more.

Do something that 80% works with only 20% effort. Or better, something that 60% works just by using 1% of your time.

I wrote specs too, the JSON specs, resource model, REST conventions. It looked pretty good… until I found out it’s not trivial to implement them in the server (and sometimes in the frontend).

Not that it’s not possible, but doing that will mean lots of additional logic in the controllers. Especially since Rails isn’t primarily geared to being a REST resource framework, but a server-side MVC web framework with REST support. Even worse, these logic are duplicated in all controllers, and while trying to refactor them out, it feels like I’m building a new framework of its own.

My workaround was simple: Code what the app is supposed to do.

Leave the snazzies, extras, and toppings for later.

And write tests.

Summing It Up

I’ve to say that I have been enjoying developing a SOFEA-style web application in Rails. Probably there is a better way, yet Rails is quite general-purpose: Rails doesn’t restrict us from doing what we wanted.

Writing backend tests is more important in SOFEA-style than traditional MVC webapps, because the frontend may not be fully developed and you need the tests to make sure the backend works.

Liberal use of Rails Scaffolds saves time. And start with the shortest code that works.

I want to know about your experiences too, please share it in the comments.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

  def help
    Helper.instance
  end

  class Helper
    include Singleton
    include ActionView::Helpers::TextHelper
  end

  def check_for_max_donkeys
    if Donkey.find_fit_donkeys.size ==
APP_SETTINGS['max_fit_donkeys']
      flash_error "The maximum of
#{help.pluralize(APP_SETTINGS['max_fit_donkeys'], 'donkey')} has
been reached."
      redirect_to_index
    end
  end

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

While using Ruby for your projects, you may need some references.

These are some references that might help you in using Ruby:

• Language

General Syntax Rules

• Comments start with a pound/sharp (#) character and go to EOL.
• Ruby programs are sequence of expressions.
• Each expression is delimited by semicolons(;) or newlines unless obviously incomplete (e.g. trailing ‘+’).
• Backslashes at the end of line does not terminate expression.

Reserved words

alias   and     BEGIN   begin   break   case    class   def     defined
do      else    elsif   END     end     ensure  false   for     if
in      module  next    nil     not     or      redo    rescue  retry
return  self    super   then    true    undef   unless  until   when
while   yield

Type

Basic types are numbers, strings, ranges, regexen, symbols, arrays, and hashes. Also included are files because they are used so often.

Variables

$global_variable
@@class_variable
@instance_variable
[OtherClass::]CONSTANT
local_variable

• Standard Library

Ruby comes with an extensive library of classes and modules. Some are built-in, and some are part of the standard library. You can distinguish the two by the fact that the built-in classes are in fact, built-in. There are no dot-rb files for them.

Built-in Library

Class Hierarchy:

Object

• Hash
• Symbol
• IO
  • File
• Continuation
• File::Stat
• Data
• NilClass
• Exception (see tree above)
• Array
• Proc
• String

Standard Library

The essentials:

• • benchmark.rb a simple benchmarking utility
  • cgi-lib.rb decode CGI data – simpler than cgi.rb
  • cgi.rb CGI interaction
  • date.rb date object (compatible)
  • debug.rb ruby debugger
  • delegate.rb delegate messages to other object
  • English.rb access global variables by english names
  • fileutils.rb file utility methods for copying, moving, removing, etc.

• Tools: ruby(Command Line Options, Environment Variables), irb, xmp, ruby-mode, Debugger, rdoc

• Mindshare, Idiom and Patterns (Object Design, Other Third-party Libraries)

For further details visit Ruby Quick Reference page at ZenSpider.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Ruby is a high level, object-oriented open source scripting language. It has excellent support for regular expressions as a language feature.

In Ruby, a regular expression is written in the form of /pattern/modifiers where “pattern” is the regular expression itself, and “modifiers” are a series of characters indicating various options. The “modifiers” part is optional. This syntax is borrowed from Perl.

Ruby supports the following modifiers:

• /i makes the regex match case insensitive.
• /m makes the dot match newlines. Ruby indeed uses /m, whereas Perl and many other programming languages use /s for “dot matches newlines”.
• /x tells Ruby to ignore whitespace between regex tokens.
• /o causes any #{…} substitutions in a particular regex literal to be performed just once, the first time it is evaluated. Otherwise, the substitutions will be performed every time the literal generates a Regexp object.

You can combine multiple modifiers by stringing them together as in /regex/is.

In Ruby, the caret and dollar always match before and after newlines. Ruby does not have a modifier to change this. Use \A and \Z to match at the start or the end of the string.

Since forward slashes delimit the regular expression, any forward slashes that appear in the regex need to be escaped. E.g. the regex 1/2 is written as /1\/2/ in Ruby.

Read more on: Regular-Expressions.info home page.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Advanced Rails offers you an in-depth look at techniques for dealing with databases, security, performance, web services and much more.

O’Reilly Media, Inc. published an intermediate-to-expert Rails book, authored by Brad Ediger:

Chapters in this book help you understand not only the tricks and techniques used within the Rails framework itself, but also how to make use of ideas borrowed from other programming paradigms. Advanced Rails pays particular attention to building applications that scale — whether “scale” means handling more users, or working with a bigger and more complex database.

You’ll find plenty of examples and code samples that explain:

• Aspects of Ruby that are often confusing or misunderstood
• Metaprogramming
• How to develop Rails plug-ins Different database management systems
• Advanced database features, including triggers, rules, and stored procedures
• How to connect to multiple databases
• When to use the Active Support library for generic, reusable functions Security principles for web application design, and security issues endemic to the Web When and when not to optimize performance
• Why version control and issue tracking systems are essential to any large or long-lived Rails project
• Advanced Rails also gives you a look at REST for developing web services, ways to incorporate and extend Rails, how to use internationalization, and many other topics.

Advanced Rails is an essential resource for improving your skills on Rails through advanced techniques.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Morph Labs is currently beta-testing their next-generation solution in application deployment, delivery, and management, the Morph Application Platform.

Acquiring hardware and configuring software to support web apps are things of the past. Morph Labs brings you the next-generation solution in application deployment, delivery, and management. Reduce your time to market and lower your startup costs no matter if you are an ISV, a developer or a business.

About Morph Labs

Morph Labs Inc. www.morphexchange.com is a Philippine-based Web 2.0 technology company focused on providing innovative technologies and applications to support Software as a Service (SaaS) globally.

Morph offers independent software vendors (ISVs), IT consulting organizations, application developers and entrepreneurs the quickest and simplest route to SaaS-enablement. Morph simplifies deployment and management of software as a service with an elastic Web 2.0 delivery and management solution — the Morph Application Platform.

Morph Application Platform, powered by Amazon EC2 grid computing technology, combines the elasticity in delivering and managing Web 2.0 applications and the simplicity of deploying software as a service (SaaS).

With no hardware to buy and no software to install and configure, Morph allows developers to easily grow or shrink their application environment on demand without disruption to the application. The Morph Application Platform is offered through a subscription to a Morph AppSpace, which is an instance of the Morph Application Platform.

Beyond delivery platforms and managed services, Morph will build simplified software applications (that run on our platform) that leverage open source technologies for small and medium businesses.

Morph’s first on-demand application is Morph helpME (released October 2007), provided via the software as a service model and runs on top of the Morph Application Platform. It’s an on-demand help and training system that enables sharing of knowledge while reducing overall cost and technical burden.

Morph helpME is a Ruby on Rails application running on the Morph Application Platform. It’s automatically formats, structures and creates menus, enabling faster deployment of new content.

If you are Ruby on Rails developers, bring your on-demand application to life with the Morph Application and leave the details to us!

Visit Morph home page to find out more!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I’d like to express a warm notice that AdaRuby.com might be down intermittently as we’ll be having major rearrangement and server upgrades of our hosting facilities in the coming days.

The upside is, when it’s done (and oh YES it will be done!), I’ll be providing you interesting information on the stuff that we’re doing, especially our experience regarding the hosting services that we have been using all this time.

Looking forward to hearing you share your experience as well!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Canadian Web Hosting provides shared, VPS, and dedicated web hosting for Canadian sites. They operate from a 1st Class Colocation facility located at Harbour Center in downtown Vancouver, BC, Canada. The advantage to international (i.e. non-Canadian) hosting services are obvious: they are much faster to access from Canada (with an added bonus that you pay in your native Canadian Dollars currency! Hence, if your customers and/or your business is based on Canada, hosting your Rails site with them might be a perfect fit.

The shared hosting plans offered by Canadian Web Hosting starts from the tight-budget CAD$3.95/mo (2 year prepayment). Ruby on Rails support is provided with the CA Pro plan which is only CAD$15.95/month (2 year prepayment), with 3500 GB bandwidth, and 300 GB space. All the “standard” web hosting stuff, like PHP 4/5, MySQL, are available, including support for advanced features such as PostgreSQL, SSH, ColdFusion MX 8 (seriously), ImageMagick, and more.

There’s no initial setup fee (hosting account setup is free!) and they provide 30-day money-back guarantee. So you can try their services and features without risking anything, really.

VPS plans are also available starting from an affordable CAD$25.95/month (2 year prepaid), that some of you demanding more control would prefer. They also provide Intel Dual Core and Quad-Core Xeon-powered dedicated servers (with Red Hat/CentOS operating system), which would be more cost-effective for those who have larger number of clients or require better stability and guaranteed resources.

This is a sponsored post.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

A common stumbling block for beginner Rails developers is learning the basics required to write plugins. This is made more complicated by the fact that Ruby is inherently dynamic and offers many techniques for code reuse.

Luckily, if you can write Rails applications you can write plugins by simply drawing on a handful of basic patterns.

Why write plugins?

Writing a plugin will:

• Help make sharing code more efficient, whether it’s between projects or within the same project
• Allow you to publish generic code to the community
• Save time and increase your confidence by testing once and reusing many times
• Share functionality in a robust manner, especially when using namespaces with ActiveRecord

Usage

Rails provides installation scripts through script/plugin install, and a generator for creating new plugins: script/generate plugin. These will work with URLs, saving time when trying out plugins. You can read more about installing and managing plugins at the Rails wiki.

Rubyisms

Any of the following tools and techniques provided by Ruby are used by plugins to extend functionality:

• Mixins: including or extending classes using modules
• Opening a class or module definition and adding or overriding methods
• Dynamic extension through callbacks and hooks: method_missing, Class#inherited, Module#const_missing, Module#included
• Dynamic extension through code generation: eval, class_eval, instance_eval

These techniques fall into two broad categories:

• Using modules and classes to extend existing classes, providing new features
• Using introspection to adapt generic code to specific cases

It’s important to consider exactly what should be extended when writing a plugin. If complex meta-programming to adapt your plugin to the host application is required, care should be taken to ensure concurrency will not produce unexpected results.

Hopefully this very short summary clears things a bit. Read more on Alex Young’s article.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.