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.
I just finished implementing this (albeit way more crudely (runs on CRONs & Rake tasks) and most likely less accurately) for a client. After I was done I was like "hey, this could totally be its own app." One day later...
Services like this significantly reduce the barrier to entry for complicated web apps. I've been mulling over an idea for a while now but it would tricky to implement. With the discovery of Directed Edge and a few other services it's now a minor technical hurdle. I can shift my thinking away from how to build the technology and onto how to execute the idea well, something that hasn't had nearly enough thought yet. I think services like this making innovation much easier.
Has anyone used the underlying recommendation service (or another similar service)? This definitely seems like it could be a huge time saver for a number of sites, but it's hard to tell from the site what people's impressions of the recommendation quality is.
Althought interesting product, it just makes me believe that many people are using ORMs simply because they don't have SQL under their belt.
The query they describe as 'monstrosity' is actually easy, understandable & typical stuff to do on the relational db. When I was taught CS stuff, you consciously chose relational db just because you could do things like that. If you didn't plan it, you wouldn't use such db in the first place.
My point is, why to popularize the approach that you should run away from SQL as much as possible and not tune it to your needs? Because that's what authors propose. SQL is not XX-century obsolescence and is not hard to learn. I always thought people, as me, are using ORMs to utilize some convenient coding pattern, not to be hopefully in a safe distance from all that SQL thingy. Am I so naive?
>My point is, why to popularize the approach that you should run away from SQL as much as possible and not tune it to your needs?
It's a business decision. More developers will use their product if it's easier to integrate. ActiveRecord acts_as_blank plugins are fairly simple to write and even easier to use.
Angry VC: Well why aren't more people using Directed Edge?
DE CEO: We could have built this plugin but we want more people to be fluent in raw SQL. It's better for the craft of CS.
I understand where you're coming from, but the benefit of using an ORM should be quite obvious in this case.
Also, I found that the more I understood about SQL, the more pleasant it was to use ActiveRecord. Sometimes its "magic" can be a pain, but when it works, it really works well. I can't help but smile when I think of all the time it's saved me.
OK I can see a business plan in it and I can't blame people for choosing one way of earning money over another.
Still this is quite sign of the times we live in. If someone's putting most of his service from the pieces hosted elsewhere, what it will be? I can say that it'll be probably sloooow ;)
Anyway I share your sentiment towards ORMs, with a little difference that I prefer data mapper (as a pattern) over active record (as a pattern). Active record locks you in the ghetto where the only primary source of the schema information are your artificially crafted ORM-dependent tables, where in data mapper the database itself can give this information to you via reflection of the "real" tables. This is priceless when dealing not only with legacy databases but also with effects of ad-hoc operational fixes, which in turn can save your production sometimes. Data mapper has got also object identities right.
Holy crap, recommendation as a service. I had this idea 3 months ago, any chance of me getting a royalty?
I was going to suggest having a free 'developer' account, but then I saw it in small writing at the bottom of the page.
I'm in - this is freaking awesome!
