The technology behind it is really quite remarkable. Netphase’s proprietary solution takes into account the available inventory of the seller, who typically will be an average user with products in their possession that they wish to resell. It prevents shopping cart conflicts, yet also considers how long a prospective buyer is allowed to keep an item in his cart before the item is returned back to the active inventory for others to purchase. Bottom line is that it strives to strike the difficult balance of allowing a seller to have inventory tied up by only those wanting to purchase, and also of allowing a buyer with an item in her cart to shop with confidence, knowing that when she checks out, the item is in fact hers.

Other features of WeSell protect both the buyer and seller by way of a built-in transaction escrow system. It is fully secure, deployed in the infinitely scalable Amazon EC2 Cloud, and of course, it runs on Ruby on Rails.

About Homeschool Apple

The Homeschool Apple mission is to be an oasis for homeschoolers on the internet. HSA seeks to provide a one-stop place where homeschoolers can sell their used, new, self-published or downloadable curriculum, connect with others, and share their talents with the world. While far from complete, Homeschool Apple is well on its way, with the most unique homeschool store on the Web and a rock-solid platform on which to build. The site is currently in public Beta, and homeschoolers are encouraged to sign up for their FREE account now. Pass the word to your friends, won’t you?

Many companies who have invested a lot of time and money in Java technology could still benefit greatly from Ruby on Rails by using it to build new sites that make use of their backend Java based services.

Here’s an example of an RSpec test that uses a Java DAO, provided by Spring to access a database with JPA / Hibernate.

it "should retrieve an Account by ID" do
  load_data "dao/accounts.xml"
  dao = spring.getBean 'accountDao'
  acct = dao.find "5000"
  acct.should_not be_nil
  acct.getName.should == "Alpha"
end

It’s surprisingly easy to use a Spring context here by adding the following method to my spec_helper:

import 'org.springframework.context.support.ClassPathXmlApplicationContext'
import 'org.springframework.core.io.ClassPathResource'
 
def spring(context_file="beans.xml")
  java.lang.Thread.current_thread.context_class_loader =
      JRuby.runtime.getJRubyClassLoader
  @ctx ||= ClassPathXmlApplicationContext.new context_file
end

Using that helper I am able to access any component managed by Spring. As designed, Spring will wire up any required dependencies, provide a pooled database connection, and handle any other configuration necessary so that the bean returned is ready to use.

My test also uses DBUnit to load an XML fixture. It can do that by adding this method to spec_helper:

import 'org.dbunit.database.DatabaseConnection'
import 'org.dbunit.dataset.xml.FlatXmlDataSet'
import 'org.dbunit.operation.DatabaseOperation'
 
def load_data(data_file)
  begin
    @dataSource ||= spring.getBean 'dataSource'
    @conn ||= DatabaseConnection.new @dataSource.getConnection
    @dataset ||=
        FlatXmlDataSet.new(ClassPathResource.new(data_file).getInputStream)
    DatabaseOperation::CLEAN_INSERT.execute(@conn, @dataset)
  rescue
    print "load_data error: ", $!, "\n"
  end
end

DBUnit provides a useful way to load data fixtures into a test database. The reason I’m using DBUnit instead of the more common YAML format used in Rails apps, is so that I can make use of the fixtures already available in the Java project.

Here’s what my DBUnit fixture looks like:

This combination of technologies seems like a pretty powerful combination to me, especially for those companies who are entrenched in Java and are looking for a way to improve their productivity.

I’m interested to know who else is using this type of setup. Leave a comment and describe your experience.

First, we got some participation from David Eisinger to help improve testing and some other critical features. Thanks, David! Recently though, we added some new functionality we had lying around in an old plugin called acts_as_amazonable.

The new functionality allows you to load Amazon product attributes into a new or existing model object on your system. You can define which fields are loaded, and which attributes in your model they map to. We are using this functionality on a new double-secret project that we are working on, and it is great. In that project, we are letting our users type in an ISBN code, and we pre-populate a form with all of the Amazon data we want for that product, saving the user from a lot of typing. We also pick up the images, so they don’t even have to load an image to sell their item. Pretty cool!

Here’s how you use aaap’s new functionality:

require 'acts_as_amazon_product'
 
 class LocalBook < ActiveRecord::Base
   acts_as_amazon_product(
     :asin => 'isbn', :name => 'title',
     :access_key => '0123456', :associate_tag => 'assoc-20',
     :auto_load_fields => {
         :title => 'title',
         :isbn => 'asin',
         :publisher_name => 'manufacturer',
         :author => 'author'}
   )
 end

The keys in the auto_load_fields hash are the fields in your object, and the values are their Amazon equivalents. In the true Rails convention over configuration spirit, we have included some of the most popular auto load fields as defaults. If your object contains the following attributes, they will automatically be loaded with their Amazon equivalents:

:auto_load_fields => {
     :title => 'title',
     :isbn => 'asin',
     :publisher_name => 'manufacturer',
     :author => 'author',
     :binding => 'binding',
     :list_price => 'listprice/amount',
     :pages => 'numberofpages',
     :description => 'content',
     :small_image_url => 'smallimage/url',
     :medium_image_url => 'mediumimage/url',
     :large_image_url => 'largeimage/url',
     :detail_url => 'detailpageurl'
}

Don’t worry if your object does not have some or most of these fields; Acts as Amazon Product is smart enough to check to see if the method exists before attempting to load up the Amazon value.

Now, if by some coincidence you have some fields in your local object that have the same name as our auto_load defaults, you can choose to specifically ignore those fields using, you guessed it, :ignore_fields. :ignore_fields is a simple array of fields in your object that you do NOT want to be replaced with the Amazon equivalent. You would specify them like this:

acts_as_amazon_product(
    :asin => 'isbn', :name => 'title',
    :access_key => '0123456', :associate_tag => 'assoc-20',
    :ignore_fields => [:small_image_url, :medium_image_url]
  )

In this instance, the object in question would load Amazon info for any of the default fields that the object has, with the exception of the small_image_url and medium_image_url values.

To load the Amazon values into your object for local storage, you may call the following methods:

load_from_amazon(title_or_asin, by_title = false)
load_from_amazon!(title_or_asin, by_title = false)

The two methods do exactly the same thing, except the first simply returns a new, unsaved object with its Amazon-like fields loaded with their appropriate Amazon values. The second version (load_from_amazon!) goes one step further and saves the object for good measure.

You may pass either an isbn (asin) or a title in. If you are passing a title, you need to specify that you are passing a title by also passing true as the second parameter so we will perform an item_search rather than an item_lookup. Note that passing a title is risky business, since currently the code will take the first result returned and load that into your object. So unless your title is unique, I would recommend sticking with the isbn (asin) value.

Since that is the default, all you need to do would be something like this:

@local_book = LocalBook.load_from_amazon('1590598415')

If your object was similar to the LocalBook object in our example, for instance, you would not need to specify the auto_load_fields in the acts_as call at all. The title, isbn, publisher_name and author methods would automatically be called once you call load_from_amazon, and their values populated appropriately.

It is important to note that if you call load_from_amazon with an invalid asin, you will simply get back an empty object.

Now, calling load_from_amazon still allows you to take advantage of the other Acts as Amazon features, like the dynamic loading of Amazon attributes on the fly by using the various amazon.foo methods as it always has.

def nested_error_messages_for(object)
  if ([Symbol, String].member? object.class)
    object = instance_variable_get("@#{object}")
  end
  unless object.nil? || object.errors.count.zero?
    error_messages = object.errors.to_a.uniq.map do |key, value|
      object2 = object.send(key)
      if object2.is_a?(Array)
        object2.collect {|obj| 
          content_tag(:li, nested_error_messages_for(obj)) 
        }
      elsif object2.is_a?(ActiveRecord::Base)
        content_tag(:li, nested_error_messages_for(object2))
      elsif value.match(/^\^/)
        content_tag(:li, value[1..value.length])
      else
        content_tag(:li, 
           "#{key.underscore.split('_').join(' ').humanize} #{value}")
      end
    end
    content_tag(:div,
      content_tag(:div, 
        "#{object.class} has errors", :class => 'error_field') +
      content_tag(:ul, error_messages), :class => 'error_block')
    else
      ''
    end
end

To use it, just replace your current call to error_messages_for with nested_error_messages_for. There’s nothing extra that needs to be done in the controller as with some recipes. You’ll also want to make it look good with some CSS.

I’m pretty sure there’s more that could be done with this, but thought I’d present it here first and try to get some feedback before turning it into a gem. Let me know how it works for you.

User.count(:conditions => ['created_at > ?', 30.days.ago])

Here’s a simple extension I made to ActiveRecord to DRY it up:

module ActiveRecord
  class Base
      def self.count_since(time_ago)
        count(:conditions => ['created_at > ?', time_ago])
      end
  end
end

Put that snippet in a file in your lib directory. I called mine rails_extensions.rb. Then add require ‘rails_extensions’ to the bottom of your environment.rb file.

Now you can just do:

User.count_since(30.days.ago)

That’s a little cleaner, don’t you think?