Posts Tagged ‘rails’

Passenger (mod_rails) updates

August 15th, 2010

When updating Passenger:

sudo gem update passenger
passenger-install-apache2-module

The second command is important as it compiles the apache 2 module (caught me out for a whiles, hence this post). Ensure that the module is properly added to your config file. (e.g. /etc/apache2/apache2.conf) by confirming its pointing to the new directory for the updated version of the gem! An example is given in the blurb one the apache2 module is compiled:

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.15/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.15
PassengerRuby /usr/bin/ruby1.8

Git repositories with Slicehost

December 1st, 2009

No doubt I am really happy with my Slicehost VPS, it has been so hassle free!  The best part about Slicehost is all the amazing articles they provide to help you get going with your slice.

I’ve setup my slice to host my private git repositories, particularly since I wanted to use them with Rails and Capistrano.  This article provide to be just what I needed:

http://articles.slicehost.com/2009/5/13/capistrano-series-setting-up-git

The article even shows you how to secure the shell that the git user has to avoid anyone SSHing into your box with their ID.  However, it doesn’t tell you what to do when you want to create another repository as you cannot switch to the git user while ever it is using the git-shell as opposed to a normal shell.  The trick is you need to switch with the root user as only they are allowed to provide an alternative shell.  Here are the commands once you have logged into your slice with a user that is able to sudo:

$ sudo su --shell /bin/bash git
$ cd /home/git
$ mkdir project2
$ cd project2
$ git --bare init
$ exit

Now your repository is good to go and you can follow the steps from “Making your first commit” section.

Making your Rails app work on Java

September 26th, 2009

So you’ve written a Rails app and you want to show it off to your boss at work because you know that it will impress them. Problem is that your company only uses Java and won’t consider it for their production environment if it can’t be deployed under a JVM. Let’s go:

  1. Install JRuby http://jruby.org
  2. Install the required gems for Ruby on Rails to work with JRuby
  3. jgem install mongrel activerecord-jdbcsqlite3-adapter rails
  4. Install the gems particular to your application
  5. jruby -S rake gems:install
  6. Update your database.xml file, prefixing your adapter with jdbc
  7. development:
      adapter: jdbcsqlite3
      database: db/development.sqlite3
      pool: 5
      timeout: 5000
  8. Start your JVM
  9. jruby script/server
  10. Demonstrate
  11. Sit back and wait for promotion

Some notes on whats going on above:

Setting up scheduled jobs with Rails

June 8th, 2009

I’ve seen lots of different approaches to scheduling jobs with Rails, including a great run down by Ryan Bates’ Rails Casts Episode 129, however the most elegant solution I’ve seen so far is what was outlined in Episode 164 using the cool Whenever gem and good ol’ Cron.

Within a couple of hours I had a weekly scheduled job running all nicely managed entirely through my Rails application code base. The incorporation into Capistrano makes it killer. The only thing that caught me out was that my script/runner file was not set as executable when capistrano was deploying it, therefore runner commands failed to execute through Cron with a “permission denied” error.

Found that all I needed to do was set it to executable within svn:

svn propset svn:executable on script/runner

All good!

Ok, ok, I get it, jQuery is cool!

December 4th, 2008

I’d been hearing about jQuery for quite a whiles now but resisted the temptation to dive in. The Rails community in particular is quite abuzz with it and I’d heard the creator of it interviewed on Geoffrey Grosenbach’s Ruby on Rails Podcast.

Still I resisted, surely prototype and scriptaculous were the way to go, after all they’ve been shipping with Rails since forever and Rail’s has many functions that tightly integrate with them, especially its RJS view support.

Then I started to hear people becoming quite critical of RJS, in particular raising concerns over its abstraction of javascript and invasive approach to the DOM.

I continued on my merry way, working on my pet project, pulling out a lot of RJS support that I had previously but still using it where it made sense.

Then I started looking into potentially introduce an Accordion User Interface widget and thats when the wheels started to fall off for the prototype and scriptaculous cart that I was pushing.

I found an accordion extension for p & s and started playing around with it. It seemed to work fine on the demo site, but it looked horrible when I integrated it into mine. I discovered that it was built against prototype 1.5 whereas I was using 1.6.

It was at this point that that I decided that I’ve got myself a problem. jQuery had an accordion widget, I’d seen it demonstrated at a recent workshop at the WebDirections South conference in September and it looked pretty good. Time to bite the bullet.

I checked out Ryan Bate’s Railscast on jQuery to get a quick overview and see how to get it up and running quickly in Rails. Then I spent an hour checking out the jQuery website and getting familiar with the examples and API. All looking very impressive. Pretty quickly the concepts started to come through. It really struck me that the selector approach is incredible powerful and it made striving for unobtrusive Javascript easy, just like CSS is unobtrusive presentation.

Within a couple of hours my Rails app was devoid of all RJS, prototype and scriptaculous. jQuery was introduced and all my obtrusive Javascript removed!

Now it feels like I have a world of options available to spruce up my user interface too! The plugin repository is incredibly large, something which p & s are sorely missing.

The amount of inertia behind jQuery is quite impressive and in my opinion this is what counts. The fact that Rails developers are openly advocating it spells the end for prototype & scriptaculous too. Alas, they were great libraries but its time to move on, the mob has spoken.

Dependency injection for Rails

September 23rd, 2008

I’d been looking around for how to do Dependency Injection (Inversion of Control) in my Rails App. I don’t need anything particularly fancy, just the ability for classes (controllers in particular) to have different service implementations injected into them depending on the environment that they’re in. Something which I take for granted in the Java world with Spring’s IoC container.

Now I know that Ruby is a vastly different language than Java and that means that somethings that make sense in the Java world (i.e. Dependency Injection) just may not add up at all in the Ruby world. But I still think that a simple IoC container in my Rails app is required. It helps with unit/mock testing and in particular, it helps when working in an enterprise environment.

I found what appears to be quite a famous article about DI with Rails using Needle here:

http://www.jamisbuck.org/ruby/rails-injected.html

Although it does appear to be thorough (if a little old now), I still felt that I could get what I needed without as much complexity, so this is what I did in my Rails app…

I created a simple service locator module that classes include to access services:

lib/ioc/service_locator.rb
module IOC
  module ServiceLocator
    def self.included(base)
      base.class_eval do
        extend ClassMethods
        include IOC::ServiceLocator::InstanceMethods
      end
    end

    module ClassMethods
      def has_dependency(*names)
        names.each {|n| class_variable_set("@@#{n}", Registry.instance.get_service(n)) }
      end
    end
  end
end

A registry for all the services to be cataloged in:

lib/ioc/registry.rb
module IOC
  class Registry
    include Singleton

    def initialize
      @registry = {}
    end

    def self.register(name, instance)
      self.instance.register(name, instance)
    end

    def register(name, instance)
      @registry[name] = instance
    end

    def self.register_if_not_defined(name, instance)
      self.instance.register_if_not_defined(name, instance)
    end

    def register_if_not_defined(name, instance)
      register(name, instance) unless has_service(name)
    end

    def self.get_service(name)
      self.instance.get_service(name)
    end

    def get_service(name)
      @registry[name]
    end

    def self.has_service(name)
      self.instance.has_service(name)
    end

    def has_service(name)
      !@registry[name].nil?
    end
  end
end

Now my controllers can include the ServiceLocator module and nominate dependencies which can then be accessed as class variables, in this case the

workflow_service
class WorktrackerController < ApplicationController
  include IOC::ServiceLocator
  has_dependency :workflow_service 

  def wip
    @wip = @@workflow_service.get_work_in_progress
  end
end

Wiring this up, I add the base registry components at the bottom of:

config/environment.rb
...
# Default IOC configuration - overridden by environments
# Each environment needs to call the config.to_prepare first for the
# Dispatcher class to be loaded!
Dispatcher.callbacks[:prepare].insert(0, lambda do
  IOC::Registry.register(:workflow_service, Service::FakeWorkflowService.new)
end)

The registry’s entries can then be overridden by the particular environment, ie:

config/environment/development.rb
...
config.to_prepare do
    IOC::Registry.register(:workflow_service,
      Service::WebserviceWorkflowService.new('http://tiger:8888/proxy/service/WorkflowInquiry'))
end

So there you go, its simple and it works.