Rebuild or Refactor

[kellyjandrews]

Would love to get everyones opinion - should we start from the beginning, or refactor what we have? Seems like a lot of issue keep popping up, and this is compatible with Ruby 1.9.3 - might be nice to support the latest Ruby version.

Any suggestions?

[kkohrt]

Unless there is a person or group of people near 100% dedicated to ExactTarget work, it seems to me that starting with a working model and refactoring it without breaking it is a more reliable approach that will produce more benefits sooner. The API is extensive and starting from scratch would be a considerable undertaking.

So along those lines, @jmcnevin and I have refactored this gem to make its components a little more distinct (at least in my head :) and so that it works with more recent RoR (currently running with Ruby 2.1.0 and Rails 4.1.8)

https://github.com/novu/FuelSDK-Ruby

We have additional code in our corporate repo that makes Subscribers and DataExtensions actual objects that have behaviors similar to ActiveRecord, but I have not had time to extract them as plain old Ruuby objects. It has been on my list, and I'd love to have help with that. If anyone is interested, I could get the code out there as is (polluted with some Rails code and also a User object at the moment) and you could give it a look.

[kellyjandrews]

So removing any hurdles, rebuilding would be the better approach? Perhaps redactor this to separate concerns better, and ongoing rebuild to get to v2?

I'm one of the Dev advocates for the marketing cloud and trying to prioritize some projects.

[kkohrt]

@kellyjandrews thanks for reaching out. I'm not sure a complete rewrite is needed. I'd be concerned about breaking existing code that is using the FuelSDK if that happened. Instead, Some things I would put on my wish list are:

(1) Make the server side code more robust--we hit access limits all the time keeping our user data up to date in real-time, and had to resort to updating many things using the asynchronous FTP batch update on like a 4 hour schedule, which really takes deterministic processing out of the developers hands: there is no way to programmatically catch, report, and possibly remediate error conditions in the data. Badgeville, by way of comparison, almost never hits a throughput limit for us; and only ever complains because we have two event processors sending it data in parallel. (2) more detailed error responses from the API (3) w.r.t FuelSDK, maybe split the data synchronization and the email send functionality into two gems (though one may depend upon the other).

[michaelstalker]

Take a look at what @barberj has done with his fork of the repo. It may be worth trying to merge his work with this repo. I think the design of the two repos has diverged, but it may be a good step in updating the current repository.

It would be nice to have only one repository that is both canonical and supported.