Most of my clients get their hosting from a shared server hosting package, where the server is shared amongst multiple people. This is great, as it lowers the cost of hosting tremendously, but also the number of features the server comes with is reduced. Most shared server hosting providers allow FTP.

Sadly Capistrano requires one to have SSH access to the server. Thus Capistrano, isn't a feasible tool to use. Unable to find a substitute, I developed my own called git-deploy.

git-deploy will interact with git to only update relevant files on the server via FTP or SSH.

For example, if you only updated on file in your source code, you only need to upload one file, and not the whole directory. This makes uploading, more time and bandwidth efficient. Especially for time, as the script can be run from the command line, so you don't need to launch your upload program, select which files to upload, drag and drog, and wait. A lot of time can be saved.

This is done by storing a file called REVISION on the server, which we can compare with on the local machine.

I am personally using it now on this website, and other production sites.

I am planning to create a Ruby Gem out of the plugin, but unfortunately the name git-deploy was taken. I am still looking for a new name, so if you have a suggestion, just drop me a comment.

git-deploy is licensed under an MIT License, so feel free to use, change, and build on top of my code.

To find out more about git-deploy, and how to set it up visit its GitHub page.

Happy Deploying!

Related posts

• SessionlessBots (0)
• Ruby on Rails git pre-commit hook (0)
• Improving SSH Connections (1)
• FirebugLogger Released (0)
• Will Ruby Not be the Next Big Programming language"? (0)

Lucky me. I found one, and a pretty great one.

Introducing Workflow, your alternate Finite State Machine for Ruby on Rails.

acts_as_state_machine vs Workflow

At its core acts_as_state_machine and Workflow function exactly the same way. Feature wise Workflow wins out as it makes it easier to manage the callbacks. Workflow is more up to date, and I personally prefer its syntax a lot better than acts_as_state_machine.

Workflow's syntax looks a lot more like a Domain Specific Language.

Installing Workflow

Installing Workflow as a Ruby on Rails Plugin

Workflow can be installed either via Ruby Gems or a Ruby on Rails plugin.

As a Ruby on Rails plugin, go to the root folder of your Rails application and execute:

./script/plugin install \
     git://github.com/geekq/workflow.git

Note: You may need Git installed

Installing Workflow via Ruby Gems

Likewise as a Ruby Gem, Workflow can be easily installed. As your root user execute:

gem install workflow

We will need to update your config/environments.rb, and in the Rails::Initializer.run block we will need to add in config.gem 'workflow'.

Your config/environments.rb may look like so:

Rails::Initializer.run do |config|
  ...
  config.gem 'workflow'
  ..
end

Using Workflow

Lets have a look at a sample code, featuring a Person.

class Person < ActiveRecord::Base
  include Workflow
  workflow do
    state :sleeping do
      event :shower, :transitions_to => :showering
      event :work, :transitions_to => :working
    end

    state :showering do
      event :sleep, :transitions_to => :sleeping
      event :work, :transitions_to => :working
      event :date, :transitions_to => :dating do |romantic_interest|
        successful = self.flirt(romantic_interest)
        halt unless successful
      end
    end

    state :working do
      event :shower, :transitions_to => :showering
    end

    state :dating do
      event :shower, :transitions_to => :showering
      event :sleep, :transitions_to => :showering
      event :work, :transitions_to => :showering
    end
  end
end

Note: Workflow makes the assumption that the state of your model is saved in a field called workflow_state.

In line 2 we have to specifically include include Workflow into our model. From there we begin describing the workflow by opening up a workflow block. Inside we define what states the model is going to contain, and what events can be fired to transition the model from one state to another.

The initial state of a model is the first state defined, in this case it is the sleeping state. States are defined in a state block as seen on lines 4, 9, 17, and 23. We have four states here: sleeping, working, showering, dating. Possible events a state may fire are contained within the state block as an event method. These events describe which state they would transition to if they were fired.

Methods are created every time you define a state or event. The method created when you define is a state tests wether or not the state is within a particular state, ie person.sleeping?. The methods created when you define an event is the event itself, ie person.sleep!.

There is also an additional method current_state, where you can investigate the current state of the object.

Given our example model above, these methods were created for our model:

Events

Events help you to transition from one state to another. So suppose your person is sleeping, and you want him to shower, well we'll just call shower!.

person.current_state # "sleeping"
person.shower!
person.current_state # "showering"

Note: When firing an event, Workflow calls ActiveRecord::Base.update_attribute. This means that only your record's state will be saved in the database, any other changes to the record are not. You still have to call ActiveRecord::Base.save. It also doesn't call any validations. Validations will be handled by your guards, which will be discussed later. Calling an event from a new unsaved record, will save the record into the database.

Event Arguments

You can even have your events accept arguments, this can be see on line 12, in the :date block.

    state :showering do
      event :sleep, :transitions_to => :sleeping
      event :work, :transitions_to => :working
      event :date, :transitions_to => :dating do |romantic_interest|
        successful = self.flirt(romantic_interest)
        halt unless successful
      end
    end

Note: The scope of the block is within the instance. Treat it as any other method. self refers to the instance itself. flirt is a method defined in the instance. You would have to define the flirt method yourself.

Lets have a look at an example:

person.current_state # showering

romantic_interest = Person.new
person.date! romantic_interest
person.current_state # dating

With events being able to accept arguments, this gives us a wider range of flexibility on handling and organizing the flow of your model. But they can get more powerful with callbacks.

Callbacks

A state also includes two callbacks. One for entering the state, and one for exiting the state.

Like the event blocks, the callback blocks also accept arguments.

You can define a state's callback like so:

state :sleeping do
  event :shower, :transitions_to => :showering
  event :work, :transitions_to => :working

  on_entry do |prior_state, triggering_event, *event_args|
    # code
  end

  on_exit do |new_state, triggering_event, *event_args|
    # code
  end
end

• The on_entry callback is called when a person enters the sleeping state.
• The on_exit callback is called when a person exits the sleeping state.

You can also define your callbacks outside of the state block and in your model itself as methods:

state :sleeping do
  event :shower, :transitions_to => :showering
  event :work, :transitions_to => :working
end

def on_sleeping_entry(prior_state, triggering_event, *event_args)
  # code
end

def on_sleeping_exit(new_state, triggering_event, *event_args)
  # code
end

Note: Notice the naming convention of the method name? To use this method, the callback is called on_ + state name + _entry, and on_ + state name + _entry.

The arguments for the block and method are optional. Therefore for clarity, you may just enter:

state :sleeping do
  event :shower, :transitions_to => :showering
  event :work, :transitions_to => :working

  on_entry do
    # code
  end

def on_sleeping_exit(new_state, triggering_event, *event_args)
  # code
end

Global Callback

This gets tedious if you want to monitor the transitions of every state change. Don't worry, Workflow can handle that.

Workflow comes with an on_transition callback which is placed inside the workflow block:

workflow do
  on_transition do |from, to, triggering_event, *event_args|
    puts "from #{from} to #{to} via #{triggering_event}"
  end
end

Callback Order

With all these callbacks, it gets a bit confusing. Here are Workflow's callbacks in context of ActiveRecord's callbacks:

• Workflow's in event
• Workflow's on_transition
• Workflow's on_exit
• ActiveRecord::Base.before_save
• ActiveRecord::Base.save
• ActiveRecord::Base.after_save
• Workflow's on_entry

Guarding States: halt!

Using Workflow your model's validations do not work when an event is fired. In fact, only the model's workflow_state is saved when an event is fired, and not any other data.

In Workflow we can setup a guard, or a halt. This will prevent the transition from ever occurring, and provide us with the safety of having our models validated.

Guards can only be used inside the event block itself. For example:

    state :showering do
      event :date, :transitions_to => :dating do |romantic_interest|
        successful = self.flirt(romantic_interest)
        halt unless successful
      end
    end

Assuming that the flirting with the romantic interest was unsuccessful, the person would still be in the the showering state. All thanks to the halt on line 15.

This would run as follows:

person.current_state # showering

romantic_interest = Person.new
person.date! romantic_interest
person.current_state # showering

Instead of just a halt, you can make it more destructive by calling halt! (with an exclamation mark) instead, which will throw the Workflow::TransitionHalted Exception instead.

Conclusion

As you can see Workflow is quite feature rich, and provides more flexibility than acts_as_state_machine. I would recommend using this over acts_as_state_machine any day. So why don't you experiment with it, and have some fun?

Related posts

• Finder for Workflow States (0)
• Ruby on Rails Finite State Machine Plugin: acts_as_state_machine (9)
• Why I Support Free Culture (0)
• SWFUpload on Rails (0)
• Ruby on Rails git pre-commit hook (0)

named_scope

I need to locate all the models that are of a certain state, and thanks to named_scope. This can be done quite easily. Except when we have a lot of states I'd rather not write a named_scope for each individual state. For example:

class Order < ActiveRecord::Base
  named_scope :completed, :conditions => { :workflow_state => 'completed' }
end

It would be encumbersome to write this multiple times. I'd rather have a named_scope created for each state. This is my quick hack.

class Order < ActiveRecord::Base
  include Workflow
  workflow do
    state :new do
      ...
    end

    ...
  end

  (self.workflow_spec.states.keys - [:new]).each do |state|
    named_scope state, :conditions => { :workflow_state => state.to_s }
  end
end

After the workflow code you place you write:

  (self.workflow_spec.states.keys - [:new]).each do |state|
    named_scope state, :conditions => { :workflow_state => state.to_s }
  end

This iterates through each of our workflow states, and creates a named_scope for each one based on the name of the state. So you can easily do Order.completed and find all completed Orders.

Note: I had to remove :new (on line 12) from the array of keys as it would cause problems with my code. This is caused from overwriting the new method. You can solve this by probably putting a prefix for the named_scope name.

I know it can be extracted to use alias_method_chain and modify the Workflow sourcecode, but I enjoy my hack.

Related posts

• Ruby on Rails Finite State Machine Plugin: Workflow (0)
• Ruby on Rails Finite State Machine Plugin: acts_as_state_machine (9)
• Fixtures Without Rails (0)
• Why I Support Free Culture (0)
• SWFUpload on Rails (0)

Note: This has been tested with SWFUpload v2.2.0.1 and Ruby on Rails v2.3.4

Note: This is used together with restful-authentication.

SWFUpload is a Flash uploader, that enhances the experience of uploading. Some examples include the ability to select multiple files at once, and queue them up for upload. For more features, visit the SWFUpload website. This is a great tool if your website requires you to upload multiple files.

But there are documented issues SWFUpload and using it with Ruby on Rails.

By default, when using SWFUpload with Ruby on Rails, SWFUpload works great. Everything works as documented, well at least as far as I can tell. By default I mean:

• You are not using authentication (for example login)
• If you are using authentication, but uploading to a page that doesn't require login

Problems with SWFUpload and Ruby on Rails

SWFUpload breaks on Ruby on Rails when you using authentication, and when you have to upload to a page that requires login. The result of doing so is that Rails will think your user is not currently logged in, and will deny the upload request possibly by redirecting the request to the login page. This bug is caused Flash not being able to use the same session as your web browser.

Now when you Google, you will notice multiple methods of solving this problem. Notably a fix to rack and the middleware. Now I don't want to hack my rack, or middleware. Plus I found all the documentation rather confusing.

swfupload.cookies.js

Instead what I wanted to focus on, was in the tarball for SWFUpload. Inside I noticed a file called swfupload.cookies.js. The file describes itself as:

Cookie Plug-in

This plug in automatically gets all the cookies for this site and adds them to the post_params.
Cookies are loaded only on initialization. The refreshCookies function can be called to update the post_params.
The cookies will override any other post params with the same name.

When you include swfupload.cookies.js into your application, your params will include the keys and values from your cookies. For example, if you had a cookie called "auth_token", with a value of "d2f423cd5559645eb8e75230b9ce2648d59a7ad8", it would appear in your params as params[:auth_token] = 'd2f423cd5559645eb8e75230b9ce2648d59a7ad8'.

This was the perfect tool I needed.

Getting SWFUpload to work with Rails

Note: Once again, this tutorial is for use with restful-authentication. We will assume that your User model is called "User", and your Session controller is called "SessionsController". We will also assume that the swfupload files are in /public/javascripts

Using swfupload.cookies.js

In your Rails app, include swfupload.cookies.js. I decided to put it after my swfupload.js.

  <%= javascript_include_tag 'swfupload.js' %>
  <%= javascript_include_tag 'swfupload.cookies.js' %>

Modify Your Sessions Controller

If you open up your Sessions controller ( /app/controllers/sessions_controller ) you will see a create method. This is where your User is authenticated, and their session established.

  def create
    logout_keeping_session!
    user = User.authenticate(params[:login], params[:password])
    if user
      # Protects against session fixation attacks, causes request forgery
      # protection if user resubmits an earlier form using back
      # button. Uncomment if you understand the tradeoffs.
      # reset_session
      self.current_user = user
      new_cookie_flag = (params[:remember_me] == '1')
      handle_remember_cookie! new_cookie_flag
      flash[:notice] = 'Logged in successfully'
    else
      note_failed_signin
      @login       = params[:login]
      @remember_me = params[:remember_me]
    end
    redirect_back_or_default('/')
  end

Now we need to change lines 10-11.
From:

      new_cookie_flag = (params[:remember_me] == '1')
      handle_remember_cookie! new_cookie_flag

To:

      handle_remember_cookie! true

Yes, we are going to make the User remember the cookie every time he logs in.

Modifying lib/authenticated_system.rb

Now for all this to work we need to edit lib/authenticated_system.rb.

Look for the current_user.

    def current_user
      @current_user ||= (login_from_session || login_from_basic_auth || login_from_cookie) unless @current_user == false
    end

Now we are going to add a new method call to that, and change the method current_user to:

    def current_user
      @current_user ||= (login_from_session || login_from_basic_auth || login_from_cookie || login_from_params) unless @current_user == false
    end

Now we create a new method called login_from_params.

    # Created specifically for swfupload, as the cookie can't be passed via flash, and is instead passed via a post param
    def login_from_params
      binder = params[:auth_token] && User.find_by_remember_token(params[:auth_token])
      if user && user.remember_token?
        self.current_user = binder
      end
    end

This is where the magic happens. The user will be logged in based on their :auth_token.

Testing

Make sure you log out the user, and login again as we have to create the cookie.

Conclusion

There you have it! A working SWFUpload with Rails. Enjoy.

Related posts

• Why I Support Free Culture (0)
• Ruby on Rails git pre-commit hook (0)
• Ruby on Rails Finite State Machine Plugin: Workflow (0)
• Ruby on Rails Finite State Machine Plugin: acts_as_state_machine (9)
• Ruby and Open Classes (0)

Now iPay88 provides examples in ASP, ASP.Net, JavaScript, and PHP, but not in Ruby. So I thought I would go ahead and provide one:

require 'digest/sha1'
require 'base64'

def ipay88_signature(string)
  Base64.encode64(Digest::SHA1.hexdigest(string).scan(/../).collect { |a| a.hex.chr }.join).chomp
end

Related posts

• Will Ruby Not be the Next Big Programming language"? (0)
• Why I Support Free Culture (0)
• What Version of Ruby Am I Using? (0)
• Unexpected behavior of Ruby’s Range.min Range.max (1)
• Unexpected behavior of Ruby's Range.min Range.max (0)