They really need to port this to Rails 3. At this point, any new app I'm building is Rails 3, and any old app I have, I'm reluctant to add something that will make upgrading harder.
Assuming there's some uptake on this version we'll almost certainly produce a Rails 3 port. New apps aren't actually a great target for recommendations since they don't have much data around and since there are still far more Rails 2 deployed than Rails 3 apps around it seemed like a better target for the first version.
It's interesting that you say that -- and I don't mean this to be contentious -- I've genuinely had the opposite impression. Unfortunately HN's a bad place to get a sense for such things since it tends to be way ahead of the curve. (i.e. things like Node and Scala appear far more mainstream reading HN than they are in practice.)
Most of the folks I know working on Rails 2 sites have only started taking Rails 3 seriously in the last month or two and don't seem to be in a hurry to upgrade.
It'd be interesting to see a curve of when major rails deployment cut over (if they do). I wonder if there's a tell-tale Rails 3 signature that could be used combined with e.g. an 80legs crawl?
Rails 3 is a very substantial effort to upgrade to. There are definitely actively-updated apps that are doing it more gradually (add no_xss, add bundler, convert in bits) but haven't made it to Rails 3 yet. I expect that's more the rule than the exception right now, in fact.
It's the same in that they both use our webservice, but the Shopify add on doesn't use this Rails plugin.
The Shopify add-on is actually fairly different from the usual webservices product since it's completely usable by non-developery sorts. We handle pulling the shop's data from Shopify and spitting out Javascript that displays the recommendations, have a settings panel that shop owners use and so on.
In comparison, this is basically just glue that get's things one layer abstraction further (relative to our Ruby bindings) from having to think about the web service.
So, they're both moving away from the generality of the bindings, which are a pretty faithful mapping of the capabilities of the API, to make simplifying assumptions to make the API easier to use. But they're so different that it's difficult to compare directly.
The Shopify app is a pretty normal web app. None of its users know that there's anything API-ish about it, nor do they care. You can set weights, but only for pre-specified things:
There are a bunch of features of the API that aren't exposed via the Rails plugin (even a couple that are used in the Shopify app) and it does, at present, assume that you're just latching onto a preexisting model.
That said, using the Rails plugin is kind of like using a C API from C++ -- you can drop down to the lower level of abstraction if you need to. So while the plugin is, say, a minimum viable plugin at the moment, you can still get the full flexibility of the bindings at will if you're willing to trade some simplicity.
Thanks for your patient responses. I'm so curious because all this goodness you guys are cooking up at DE makes me want to sell something, anything on the internets so that I can use your awesome product.
Totally agreed. This service looks awesome, but the plugin really needs to be ported. Rails 3 was released more than six months ago and we've already ported our apps.
