require, RMagick, and case sensitivity

(At least on Leopard with Ruby 1.8.6)

Ruby will try to reload rmagick if you get the case of rmagick different from the original require. And when that happens it all goes up the whop.

We were using attachment_fu’s image magick processor, then doing a require ‘rmagick’ seperately which resulted in tonnes of errors like this

/usr/local/lib/ruby/gems/1.8/gems/rmagick-1.15.10/lib/rmagick.rb:32:
  warning: already initialized constant PercentGeometry

Keep your case’s of require’s consistent. Even if this is file system dependent behaviour in mixed development environments you can imagine how weird problems could get!

HTML_QuickForm in …. Rails ?

Caution Thinking Out Aloud:

Okay the purists have just decided to kill me. Let the religious wars begin !

No seriously, everytime I do some coding in an old PHP app which is heavily dependent on HTML_QuickForm, I keep questioning how possible would it be to convert it across to Rails, and whether any other persons like myself would think all of their Christmases have come at once. Here’s my hopefully rational thought processes behind this. Rails is a fantastic CRUD machine. If you want to build single model forms with validations in them, absolutely beautiful. Nothing could feel more clean and make you as a developer go ‘thats sweet’. Fantastic.

Now try and do a model-less form, with validations, or combine multiple models within one form. Things like the presenter pattern get bandied about. Real world case example - a form to choose options for defining a report. Nothing that you want to put in a model as it’s not a represenation of a ‘thing’ (although some may argue it is).

I wonder and am sitting on the fence of, whether to try implementing quickform for rails. For those that haven’t been exposed to it, in a nutshell it’s a brilliant little php library that lets you create a representation of a form, with rules, pass the form into a renderer which dumps out the html on a page, but that’s not all, it assists you in processing the form on submission. So some code can look like this (not syntactically correct, but close enough), which does all of the hard work of writing out html, setting up client side js, and server side processing.

//page myform.php
 
$myform = new HtmlQuickForm('form_name', 'myform.php'); 
$abc = $myform->addElement('text', 'product_name', 'Product Name:'); 
$myform->addRule('product_name', 'required', 'You must enter a product name'); 
if ($myform->validate()) {
   //process form
   var_dump( $abc->getValue() ); 
} else {
   //setup form 
   $abc->setValue('123')
}
 
// then in any template which dumps out the rails code
$myForm->display();

It doesn’t seem like much, but put half a dozen or more options on the form, different processing rules, and suddenly it’s done a lot of the heavy lifting for you.

What would it take to add this to Rails ? How would (I personally) fit it in. It doesn’t really sit within either the model, view, or controller. The view should render the output, it doesn’t really fit within a model as it’s not a representation of a thing. It most closely sits in the controller, but you don’t really want to clutter the controller with your form models.
Here’s some thoughts

An initial idea, with everything defined in the controller, then dumped into the view by a @my_form.output

class FormController < Application 
  def do_form
    get_form
    if @myForm.posted 
       #do stuff
    else
       #populate stuff
    end
  end
 
protected
  def create_report
    @myform = RFormBuilder.new do |f|
       f.call_back_url = { :controller => 'form', :action => 'do_form' }
       f.name = 'myform'
    end
    @myform.add_text( :name => 'product_name', :label => 'Product Name', 
              :rule => { :required => :true, :msg => 'You must add this' } )
 
  end
 
end

OR

Maybe we add in a new folder in the main app

  /app/
      /controllers
      /models
      /views
      /forms
        myform.rb

And the treat myform.rb kinda like a model, but kinda not.

 
class MyForm < RFormBuilder
  defaults :name => 'my_form', :call_back_url => '/myform' 
  text_field :name => 'product_name', :label => 'Product Name', :required => :true
 
  #gets called when form is posted   
  def validate
    return true if field_product_type == 'abc'
  end 
end
 
 
# now in FormController 
 
 def do_form
    get_form
    @my_form = MyForm.new
    if @myForm.valid
       #do stuff
       render :text => @my_form.field_product_name
    else
       #populate stuff
    end
  end

What do you think ? Am I stark raving mad. Could this just work ? I think so and am willing to take up the challenge…

Rowan

Automated testing of websites via “real” users.

Of all the testing we can do, there’s nothing quite like firing up your browser and navigating to the website in question, logging in and doing stuff. All of the integration tests, port tests, contrived “I’m alive” tests etc can give you an *indication* that your website code is all well and good. However what you really want to test is “can I jump to it, do x y z action, and complete those actions without it bombing out”. We have a two options, we hire an army of minions who will do that for us every 15minutes on the dot OR we could do it automatically. How do we do this ?

Well there are a number of ways. One option I’m going to walk through is using the magic genius of Safari Watir, RSpec tests, ruby, a few gems, cron and any Mac you can lay your hands on. We set this up a while ago monitoring some of our sites and it’s great for finding out when something in your webstack has fallen over. For a < $1k investment it’s a no brainer for any web site.

Caveat - this ain’t going to test your flash/flex content - this is just for HTML based sites. Read on…

The satisfaction of Rails

More work on XChain. In some spare hours on the weekend I implemented the basic structure of price catalogues for products. I can’t tell you how long this took when previously doing it in PHP a few years back! (or even worse ASP a few years further back still). I’m sold on BDD, it was so quick to bang this out starting with the spec it first approach, mainly because all you need to do is ‘rake spec’, and bingo your code is tested…

As follows, note code is cut down a little, but you get the picture:

# A product itself does not contain any price information, it has many price's in a 'pricing' model, that is linked
# to price types, eg "Standard Distributor" "Standard Retail"
class Product < ActiveRecord::Base
  has_many :pricings
  has_many :price_types, :through => :pricings
  belongs_to :order_line
end
 
#The pricing table, not only links to a product and price_type, it also has a discount
#model associated with it..
class Pricing < ActiveRecord::Base
  set_table_name 'pricing'
  belongs_to :product
  belongs_to :price_type
  belongs_to :discount
end

XChain is now running on rSpec

Whilst I wait to sort out the UI issues I’m building up the specs’ for XChain. I’m using RSpec, so it’s a lot more ’self documenting’ about what you can expect the application to do. Starting on a fresh project, it’s immensely enjoyable to get into the spec -> code -> test -> repeat cycle. If you’re at all hesitant about getting into them feel free to go browse the source of my specs. I only spent a little time on it last night but already starting to see progress - a lot of the schema is getting cleaned up as a result of the specs. Here’s the doc out put so far (which is about a fraction of what the finished specs will look like !).

Order when creating a new order
- should be able to instantiate
- should default to draft status
- should be able to prefill an address
- should have a default price type matching customer price type
- should calculate return 0 dollars
- should throw an error that it doesn't have line items
- should be able to be edited
- should be able to have an order line added

Order when finding existing order
- should have id = 1
- should have a purchase order number
- should have 3 order lines
- should have a billing address
- should have a customer

To get the specs running.

Flex vs HTML vs Time

The old simple triangle of time vs features vs quality has reared it’s ugly head again. After one particularly unproductive weekend I’ve made the decision to place a hold on the Flex interface for XChain, in favour of a raw HTML interface, sprinkled with AJAX.

I personally hate the decision, being enamored with Flex, I don’t want to make it, but I look at the forward progress I’ve made in the past couple of weeks and it’s been more or less stationary. I’m not trying to deliver the ‘richest’ interface possible, I’m going to deliver a working application.

What impacts my client most, is that they can get their job done.

Using Rails with Flex to manage long running tasks

UPDATE Jul 2008 - The API for BackgroundRB has changed and docs improved significantly since this blog post. Read the latest API calls over here http://backgroundrb.rubyforge.org/rails/. Don’t reference the Rails code below if using latest BackgroundRB

As soon as you start doing anything with photos sooner or later someone says “It would be really nice to upload these in a zip file”, which then leads into a whole rabbit warren of issues, one of which you will inevitably come across is how to deal with a long running task on the server, in terms of a) getting it to actually complete and b) telling the user what’s going on. There are various hacks for doing these, like running a shell script and writing out tmp files all over the place. Just plain ugly.

Enter Backgroundrb, probably one of the greatest little inventions for Rails. It lets you kick off a background process, outside of the main rails app process, with the option to interact with the rails models or not. The beauty of this plugin is a little thing called MiddleMan, as the name implies it lets you interact with your background processes (Workers) from your Rails app.

XChain - it has a name, license, and home.

XchainThe open source Rails/Flex eCommerce application now has a name - XChain - pronounced cross-chain. I had some air travel time over the weekend and put it to good use coming up with a name, the basic premise being that the app should really be classified as a Supply Chain Management system as it deals with a lot more than simply taking peoples money for a product. (Order fulfillment, shipment tracking, eventually CRM and inventory management), and being a cross of two major technologies it seems to fit. Catchy enough and has meaning. Well I think so anyway, others might disagree - (that’s what the comments form at the bottom is for…), only downer is XChain.com is taken by some spammer, but I’ve snapped up .ca and other appropriate domains.

Open Source Rails & Flex eCommerce Application

[Announcement] Rowan Hick Consulting, Canada and Ron Hanley of Fastmount LTD, New Zealand are pleased to annouce that their new Rails/Flex/MySQL eCommerce application will be released to the community under an Open Source license. The application, is a successor to a PHP/MySQL based application developed by Rowan Hick and James McGlinn of Nerdsinc Ltd New Zealand.

After nearly 2 years in production, with the advent of Rails, Flex, and the rapidly growing business needs of Fastmount, the current application no longer meets the business needs of Fastmount. We made the decision early this year to re-write a new application and have been developing requirements for the application as well as evaluating technologies.

The application is a business to business eCommerce system. Allowing a marine manufacturing company in New Zealand to service it’s agents, distributors and customers world wide. The existing application facilitates order management from creation through to shipping tracking, along with customer management and some reporting elements.

Why are we open sourcing ?

Franken-php-rails-apache-stein

Every wondered about the possibility of running a rails app, and a php (or anything else for that matter) site together, on one virtual host, on apache. But why? the hordes screamed … DHH keels over … the PHP community says ahh just put it in CakePHP… and to you it feels just plain *wrong*.

However, there is always that odd need, every now and then, that you have to do it. So here’s how.

Continue Previous page Next page

About

Rowan is a Product Development Manager, specialising in architecting, developing and putting web applications into production - in particular Ruby on Rails based apps. He lives in Toronto, Canada but speaks in a funny accent as he's originally from New Zealand. He's been working in the software and web business for over a decade. This blog covers Web Application development and deployment in the real world, dealing with topics from business fundamentals to Ruby on Rails, Merb, PHP, Flex, MySQL, Apache and more.

Read more ...

 

 

View Rowan Hick's profile on LinkedIn

 

Subscribe to my RSS feed