BenCurtis.com

RailsConf was a blast—I’m so glad I was able to go… thanks to my employer for paying my way. Giving a presentation was very exciting, and the great feedback I got is appreciated. It was fun to meet Tobi of Shopify and ‘talk shop’ a bit. :) I also got to meet the first person who purchased my Rails e-commerce book, and that was cool (he even gave me some great feedback on material to include in the next release of the book). It was so much fun that I can see the appeal of being a professional speaker, except for the travel that that would require.

I have put up my slides from my presentation, but I don’t know how useful they will be without actually hearing the presentation, since most of the content was in what I said, not in the slides.

Most of the other presentations were fantastic—there were only one or two where I felt like my time would have been better spent elsewhere. The people I met were also fantastic. It is such a pleasure to be a part of this community. I would say the trip was definitely worth it, even if would have had to pay my own way.

While preparing for my presentation at RailsConf I decided to write an e-book on the same topic: creating an e-commerce site using Ruby on Rails. The result is The Money Train, a collection of tips for those who are interested in building their own shopping cart application using Ruby on Rails. The book is not a complete, step-by-step guide on building a storefront, but it does provide useful information for those at the beginning of the project from someone who has been there and done that.

Like the Beta Books from the Pragmatic Programmers or the Rough Cuts series from O’Reilly, I’m releasing this book before it is finished to help get this information out there sooner, and to give those who buy this early version a chance to guide the direction of the book with their feedback. I’ve provided some samples of the book so you can get a taste of what’s in it before you buy.

I hope you enjoy it, and if you’ll be at RailsConf be sure to stop by and let me know what you think!

Update:
I forgot to mention this when I first made this post, but I want to thank Ben Wiseley for giving me the idea to write the book and helping me by reviewing it. I haven’t had a chance to incorporate his suggestions yet, so don’t blame him if you don’t like the book. :)

I’m working my presentation for RailsConf and wanted to make a fancy chart using Gruff. I hadn’t gotten around to installing RMagick on my MBP yet, so I was curious to see how it would go…

Well, it was incredibly easy, since I had previously used DarwinPorts to install Ruby:

That’s it. :)

Just this morning the Rails Plugin Directory rolled over 200 plugins! I think that is, in fact, more plugins than I can shake a stick at.

One feature request that has come up recently while working on my e-commerce project was to support multiple storefronts from the same codebase and database, but have different product selections depending on which storefront you were browsing. So, if you browsed mygreatstore.com, you would see all the products from the database, but if you browsed specialvendor.mygreatstore.com, you would only see products from specialvendor. That is, of course, if specialvendor had requested that only a sub-set of products be displayed. If that’s not the case, then all the products should be available, just as if you had browsed to the main site.

So, I decided to set up a many-to-many relationship between Store and Product, with a before_filter to load the Store by subdomain. If no store matching the requested sub-domain is found, then the default store is used. Aside from the (optional) list of available products, the Store model also has things like the theme to use for the layout, customer support contact email address, and so on.

Finding the products for the store isn’t as simple as checking the Store object for a value, though. Every method that returns products needs to be restricted to the list of products for the store, if such a list is present. Enter the Scoped Access plugin. This plugin is a gem, and makes this kind of thing as easy as pie.

First, I set up a before_filter to load my store:
[ruby] before_filter :load_store

def load_store @store = Store.find_by_domain(request.subdomains.first) || Store.find(1) end [/ruby]

Then I use the Scoped Access plugin to set up a scope for calls to Product if there is a list of products associated with the store:
[ruby] around_filter ScopedAccess::Filter.new(Product, :store_products)

def store_products return {} unless @store.products.any? { :find => { :conditions => [“store_id = ?”, @store.id], :include => :stores } } end [/ruby]

Bam! Just like that, all Product finds get scoped to only find products from the current store, if the store has a product list. If the store doesn’t have a product list, no scope is applied, and all the products in the database are available. It doesn’t get much easier than that!