> Anybody here got direct experience of it and the pain points/successes it brings to the party?
It's all pretty new stuff, so my main liking is that it makes sense to me and gives me another boost in the complexity I can deal with -- I need all the help I can get! :) But I'm currently migrating a very old Rails app to a very new one, and the bits that are broken apart like a hexagonal app are a joy to transfer over -- drag & drop the files and specs! But all the bits that use Rails conventions feel like pulling teeth -- everything is mixed up with everything else, and so everything is impacted by every small and large change to Rails conventions. (With regards to everything being mixed up with everything else, one of the biggest culprits there is ActiveRecord! I'm finding going back to having different modules handle fetching, updating, and presenting information (even if they're only limiting wrappers) is much easier to maintain cleanly.) > Got any good write-ups anywhere on Rails implementations of hexagonal that demonstrates that? Not really, sorry, but if you have namespaced classes and modules under lib/ (for example) that handle as much of your business logic as possible, and you explicitly require them whenever you need them, then you're already taking responsibility for them. This means you can test them *really* quickly, and also that you can tell at a glance what is in play in any given bit of code, rather than just a sort of fuzzy, rails-y 'everything'. I find myself, generally and on more complex projects, being bitten by Rails magic more often than helped out by it. But that could just be me. It often is. :) On 22 January 2013 12:50, Will Jessop <[email protected]> wrote: > On 22 January 2013 12:22, Paul Robinson <[email protected]> wrote: > > On 22 Jan 2013, at 11:24, doug livesey <[email protected]> wrote: > >> I don't think that 'un-rails-like' is necessarily a bad thing, to be > honest. > > > > It depends on your "religion". If you think that the power of rapid > Rails development is embodied by the mantra "convention over > configuration", then you are losing a lot of that power when you stop > following the conventions. > > > > If you spend a lot of time configuring things to get a Rails app > working, you have to realise you're using Rails incorrectly. > > IMO this is valid for setting up a rails app, not so much for writing > an app in it. Sure, RESTy MVC is going to work well with some of your > app, but most apps beyond trivial ones are going to stray from the > paradigm in some way. I think the key is to work out where to do so. > SOA'ing everything is probably as wrong as keeping everything on the > Rails track (ha!). > > >> Your pain points there sound rather like getting past the point of > Rails conventions and needing a new paradigm, which you've recognised. > > > > Maybe. I'm not sure that we need a new paradigm. An MVC framework > written in Ruby with a persistent SQL storage back-end with Models taking > on some sort of ORM responsibility is what Rails is brilliant at, and > that's what I think we need here. > > That's what I use in the app I'm writing right now, except for the bit > (a controller) that communicates over a TCP socket to a job server to > run synchronous tasks on other machines. That's not Railsy at all, but > most of the app is. > > > It's possible we could look at other options - I scratch my chin > thinking about node.js a lot at the moment as we're heavily event-driven as > an architecture - but I am not convinced we need to involve new paradigms > here out of necessity. > > If you're already using Ruby (and you *really* need an evented server, > most people don't) you should consider EventMachine, unless you really > need JS there's no reason I can see to choose Node. You can always > integrate an evented system into your existing setup, no need to rip > everything out and start again. > > Will. > > -- > Will Jessop > System Administrator > 37signals > > -- > You received this message because you are subscribed to the Google Groups > "NWRUG" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/nwrug-members?hl=en. > > -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en.
