bgror

The iPhone Helpers Plugin for Rails 3.x »

Created at: 14.10.2010 04:57, source: Rails Inside, tagged: plugins

Picking the name of a new library or plugin is stressful. You could go too informal and call your library something like authgasm (now authlogic) or too formal and call it "Dull Authentication Plugin for Enterprises 1.0." It's the geek equivalent of calling your kid Butterfly or Jane. Fair enough, but what if you just called your daughter Kid or Girl? That's the approach taken by the author of the snappily named rails-iphone-helpers.

rails-iphone-helpers is a Rails plugin that provides helper methods to produce iPhone-specific (or iOS, more precisely) HTML.

This library solves a simple problem, but few people have the patience or interest in memorizing the underlying code to set viewpoint sizes, scaling options, iOS icons, or iOS splash image settings. With rails-iphone-helpers, it all becomes structured and simple.. what more could you want from a plugin, really?

Tweet This Post

Remail: Send and Receive E-mail Through Google App Engine for Free »

Created at: 23.03.2010 18:31, source: Rails Inside, tagged: plugins Tools

Sending e-mail from Rails applications is a common activity, but not all application servers are running a reliable SMTP daemon.. and setting up a server to receive e-mails is a real pain. A common solution is to use GMail, but now there's a slicker RESTian alternative in the shape of Remail (or GitHub repo) by Alex MacCaw.

Remail is an attempt to bring RESTian practices to the world of sending and receiving e-mail from Rails applications. In this short "how to" guide, Alex demonstrates how to get it all up and running, but effectively it relies on deploying a "Remail engine" on to a free Google App Engine project (which you can create) and then sending and receiving your mails over a REST interface through the Google hosted app. The e-mail handiwork is then managed at Google's end.

Limitations? Google App Engine only lets you send 2000 e-mails a day on free accounts (this shouldn't be a big deal to most users, though) but with the reasonably priced paid-for accounts, millions of e-mails per day can be delivered reliably. The ability to receive e-mail also makes this a must-see.

Tweet This Post

Dragonfly: Image Handling For Champions »

Created at: 12.03.2010 01:39, source: Rails Inside, tagged: plugins

Dragonfly is a new(-ish!) ruby gem for handling images and other content in Ruby web apps (including Rails). “What – another one?!”.. I hear you exclaim. While using Dragonfly in Rails is similar to using, say, Paperclip, a significant difference is that images are generated on the fly, as opposed to when uploaded. This at first sounds like just a small detail, but it opens us up to a wide range of new possibilities..

First, thumbnail sizes are no longer specified in the model, but in the view. So when designs (i.e. image sizes) change, we simply make the change…in the view. Previously we’d change the model, then reprocess all of the already uploaded images. Furthermore, it is now trivial to have a custom avatar cropping for each user, or blog posts with different image sizes, etc. This would be difficult if thumbnails were created on upload.

Rack Off

Dragonfly isn't so much for Rails, but for anything using Rack. It can be used as a standalone Rack application, or inserted as middleware into any Rack stack, e.g. with Sinatra, Merb, etc. Using with Rails is designed to be super-easy though, so anyone used to using Paperclip and friends should find it fairly intuitive.

Custom and Excise

Custom data stores / processors / encoders / analysers, etc., can be created to suit your needs. It is designed to be as configurable as possible, while using sensible defaults for those who can’t be bothered with the details. Any type data can be served – not just images – though not all data suits the on-the-fly paradigm.

Cache and Carry

Dragonfly is meant to be used behind a cache-proxy such as Varnish, Squid or Rack::Cache, so that while the first request may take some time, subsequent requests should be super-quick!

Take a look at the bamboo blog post for an introduction, or else check out the code and the documentation

[post by] Mark Evans, a web developer at New Bamboo who writes Ruby and Javascript by day and spends the rest of the time running around like a headless chicken and playing the guitar.

Tweet This Post

Hobo 1.0 – A Rapid Rails Web App Builder – Released »

Created at: 01.03.2010 01:07, source: Rails Inside, tagged: plugins Tools

Hobo, an open source rapid web app builder for Ruby on Rails, has officially reached Version 1.0 after three years of focused development effort by the Hobo community and sponsorship support from Barquin International in Washington, DC. (Ed note: Hobo was first covered by Ruby Inside just over 3 years ago!)

As part of the celebration the Hobo team are releasing a bunch of new stuff for newcomers and the community to enjoy. As well as a shiny new logo, they're releasing two free ebooks designed to help Hobo developers quickly and easily make the most of the popular toolset — Rapid Rails with Hobo (an introductory book) and Hobo at Work (a more detailed guide)

The current version of Hobo has changed a lot since the early days of the beta, with a number of new features designed to make it super easy to create Rails applications. There's a sophisticated built-in migration generator with automatic index generation, an ultra polished model based UI out of the box and Hobo lifecycles to simplify multi-step processes such as social network friending and 'forgot password', plus a lot more under-the-hood improvements to the codebase and functionality.

Learn more at the official Hobo homepage or try building a Hobo app in just two minutes.

[post by] Tom Locke, the founder of the Hobo project and a Ruby on Rails coder for four years. He is the co-founder and CTO of Artisan Technology, a Ruby on Rails web development company.

Tweet This Post

Rails and Merb Merge: Rails Core (Part 4 of 6) »

Created at: 22.01.2010 22:00, source: Engine Yard Blog, tagged: Uncategorized activerecord plugins rails Rails 3

After working to make Rails faster and more modular, we took a look at the glue code holding Rails together: Railties. Railties started life as a relatively modest piece of code in the early days of Rails, but it eventually grew to encompass quite a few different areas. For instance, Rails 2.3 included quite a bit of code for managing plugins, and some additional code for managing gems. Adding in explicit support for engines meant yet more code.

In isolation, each of these pieces of code made a lot of sense as they were added, but as the pieces accumulated, plugin authors, and even Rails itself, had to often resort to contortions to get the job done. Our goal in Rails 3 was to solve these problems.

An Application Object

The first thing we addressed was that a Rails 2.3 application had pieces spread out in a number of places. For example, it stored the configuration on a global configuration object, stored the routes on a global router object, and booted up the server and console from this collection of global state. It also looked up plugins using PluginLocators and PluginLoaders. While all of this worked, we found it difficult to reason about and it was easy to trip over when implementing new features. We wanted to unify these pieces.

Second, we wanted to make it possible to run multiple applications in a single process. This meant we had to remove as much global state as possible. We will likely be continuing to work toward this goal over the next several releases, but the nice thing is that removing global state has already resulted in improvements in code quality and we have found that it makes code easier to understand.

If you take a look at a newly generated Rails 3 app, you now find a named application.

module YourApp
  class Application < Rails::Application
    # Settings in config/environments/* take precedence over those specified here.
    # Application configuration should go into files in config/initializers
    # -- all .rb files in that directory are automatically loaded.
 
    # Add additional load paths for your own custom dirs
    # config.load_paths += %W( #{config.root}/extras )
 
    # Only load the plugins named here, in the order given (default is alphabetical).
    # :all can be used as a placeholder for all plugins not explicitly named
    # config.plugins = [ :exception_notification, :ssl_requirement, :all ]
 
    # Activate observers that should always be running
    # config.active_record.observers = :cacher, :garbage_collector, :forum_observer
 
    # Set Time.zone default to the specified zone and make Active Record auto-convert to this zone.
    # Run "rake -D time" for a list of tasks for finding time zone names. Default is UTC.
    # config.time_zone = 'Central Time (US & Canada)'
 
    # The default locale is :en and all translations from config/locales/*.rb,yml are auto loaded.
    # config.i18n.load_path += Dir[Rails.root.join('my', 'locales', '*.{rb,yml}')]
    # config.i18n.default_locale = :de
 
    # Configure generators values. Many other options are available, be sure to check the documentation.
    # config.generators do |g|
    #   g.orm             :active_record
    #   g.template_engine :erb
    #   g.test_framework  :test_unit, :fixture => true
    # end
  end
end

This looks a whole lot like the initializer block in Rails 2.3, but the Application object, not a global configuration object, now has the configuration information. Similarly, routes.rb now begins YourApp::Application.routes.draw. The application object lives in the center of Railties in Rails 3, providing a core object that the rest of the frameworks can build on.

Improving Initialization

Rails 2.3 initialized a Rails application by calling a number of methods in sequence. Correct operation relied heavily on the order of those methods, and Rails ran some methods multiple times (apparently to hack around long-forgotten issues). As a next step towards getting a grip on Railties, we refactored the initializers so that Rails declared each initializer separately in a way that users could easily hook into.

This idea originated in Merb, where the framework defined each initializer as a separate class. Merb also provided a mechanism for declaring in the class body, that the framework should run a particular initializer before or after another one. By breaking the initializers up into reusable chunks, we provided a convenient API for extensions to hook in at whatever part of the process they wanted to.

In Rails 3, we have defined a slightly different API, inspired by the same ideas.

initializer :load_all_active_support do
  require "active_support/all" unless config.active_support.bare
end
 
# Set the <tt>$LOAD_PATH</tt> based on the value of
# Configuration#load_paths. Duplicates are removed.
initializer :set_load_path do
  config.paths.add_to_load_path
  $LOAD_PATH.uniq!
end

These first initializers in the Rails bootup process require active_support/all and set the load paths. Each initializer has a name, which allows other initializers (in plugins) to hook in at the appropriate time. Initializers also have access to the configuration object.

Making initializers their own isolated chunks definitely improves the code, and exposed a number of issues in the existing initializers. With initializers now living on the brand new application object, we then took a hard look at plugins.

Unifying Plugins

We wanted to unify plugins into one coherent system. Rails 2.3 supported several different kinds of plugins: vendor/plugins, gem plugins, vendor/plugins engines, and gem engines.

Rails 2.3 had a number of objects to find and load each kind of plugin, that resulted in a certain amount of magical behavior in each case. For instance, it automatically ran init.rb for plugins in vendor/plugins at the appropriate time. For Rails 3, we have created a new class, called Rails::Plugin, that can itself set configuration and have initializers. Rails 3 now merges in those initializers, giving plugins the ability to directly participate in the initialization process.

Each plugin in vendor/plugins automatically become a Rails::Plugin, but we also allow gems to explicitly create a subclass and add their own initialization. This makes plugins more powerful, giving them the ability to hook in at more precise parts of the process.

initializer :load_init_rb, :before => :load_application_initializers do |app|
  file   = "#{@path}/init.rb"
  config = app.config
  eval File.read(file), binding, file if File.file?(file)
end

Here, vendor/plugins defines an initializer called :load_init_rb, which runs before the application initializers. The block receives the application object, so it can take a look at the configuration, or other parts of the application in question.

Railties (Or, How Frameworks Became Plugins)

After making all of this progress, we revisited an earlier mission set out at the beginning of the merge: make all frameworks, like ActiveRecord and ActionController, behave like regular plugins. This would allow other plugins, like DataMapper, to use exactly the same APIs used by ActiveRecord. By definition, other projects could then replace all the functionality in ActiveRecord in a self-contained gem.

After moving each initializer into its own block, we noticed that a large number of the initializers were wrapped in if config.frameworks.include?(:active_record) and the like. If we fixed this, we could make good on our promise to make each framework a plugin. So now, instead of having Railties inspect the list of available frameworks and run appropriate initializers, the frameworks themselves add their own initializers, but only when loaded. When the user loads ActiveRecord, its plugin adds its initializers; when the user loads DataMapper, its plugin adds its initializers.

The monolithic Railties framework is now a set of individual Railties, each inheriting from a new class, Rails::Railtie. Railties has more power than simple plugins. For instance, a Railtie’s name also serves as its key in the configuration object. And a Railtie can also specify rake tasks. For instance, if the user chooses DataMapper instead of ActiveRecord, he only sees DataMapper’s rake tasks.

Because Railties merely specifies how Rails initializes them, requiring them has no side-effects. Taking a look at the ActiveRecord Railtie, you can see that the file first requires “rails” and “action_controller/railtie”, ensuring that Rails runs the ActionController initializers before the ActiveRecord ones. It also allows ActiveRecord to define initializers that run before or after ActionController initializers.

Exposing an API to allow ActiveRecord to run decoupled from Railties forced us to enable functionality for third parties. For instance, because Rails loads Railties before initialization, this allows third-party plugins to hook into the very earliest stages of the process. By making the keys on config more general, we now can have config.data_mapper as well as config.active_record. By moving rake tasks and generators to the frameworks, and triggering them through the Railtie, Rails guarantees that the user can remove all artifacts of these frameworks by installing an alternative plugin. It also means that any plugin can add these artifacts.

Most usefully, it moves everything about how Rails should initialize ActiveRecord in a different context, such as booting up an app, running rake tasks, or running generators, into a single location that we can more easily maintain and that others can more easily copy. We think this will result in people being able to easily write Rails extensions that behave similarly to builtin Rails frameworks.

In short, Rails frameworks are now plugins to Rails.