<div dir="ltr">Hi Tom and all,<br><div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On 23 July 2013 14:26, Tom Cartwright <span dir="ltr"><<a href="mailto:tecartwright@gmail.com" target="_blank">tecartwright@gmail.com</a>></span> wrote:<br>

</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div><div>I am about to start a new rails project. I have read objects-on-rails and watched the Hexagonal rails talk and the techniques make a lot of sense. "Great!" thought I, I can build this new app with lots of those patterns</div>

</div></blockquote><div><br></div></div><div>I've actually just finished working on a project where I attempted to do this, and the results were overall very good, with a couple of caveats.</div><div><br></div><div>In general, I was able to ship features faster, with better test coverage, and therefore more confidence that the app was doing what was expected. Another nice side effect was that the fact that my views had no logic *at all* in them, I could introduce a designer / front-end-dev to everything he needed to work directly in erb templates within about 5 minutes, ensuring that we were both more productive and that it was virtually impossible for him to unintentionally break anything.</div>

<div><br></div><div>However, one thing that I noticed, is that there is a slower 'ramp-up' to this speed of development than with the traditional rails way. This wasn't such a problem with this project, as the delivery schedule was fairly amenable to that, but the first couple of features I shipped took a comparatively long time, although this was more than mitigated by the gains I made later.</div>

<div><br></div><div>You may also find that your design precludes the use of some plugins to perform common tasks - carrierwave for file uploads and rinku for pagination both fit very well within this style of development, and you can use devise for auth without compromising your design as it doesn't touch much of your codebase, but I couldn't find a solution for either authz or building a page navigation tree that didn't introduce a lot of unnecessary coupling and general ugliness, so I ended up rolling my own. YMMV here though, obviously.</div>

<div><br></div><div>Finally, to do this effectively, you need to refactor ruthlessly and continuously. This certainly adds an overhead (which in my experience was more than mitigated by increase in development speed), but it's key to driving a sane design for your app. The 'Hexagonal Rails' way isn't a silver bullet, just as the trad Rails way isn't, but it provides a *much* more effective starting point to drive out a decent design.</div>
<div class="im">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>they had concerns about moving away from the rails conventions as it would take time to get developers up to speed with the techniques.</div>

</div></blockquote><div><br></div></div><div>...and here's the main rub, for me - After I finished working on this project, it was handed off to another developer, who's continued to add features in the standard 'rails' style, rather than following the design I'd so lovingly developed! This was mostly a communication problem on my part, and I suspect I could have convinced him to try out the hexagonal style if I'd been there to oversee some of the transition, and explain the 'whys' of some of my design choices, but yeah. In your case, it sounds like you'll be able to work alongside other developers working on the application, so will be able to do this no problem. However, I think it's crucial that your other devs are at least receptive to the *idea* of doing things in an OO style, and understand the benefits. If this is the case, they'll be able to pick up the 'how' no problem.</div>
<div class="im">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
One reason (and I can definitely see their point here) is that intentions can get obfuscated when using lots of loosely coupled objects and this can lead to confusion. </div></div></blockquote><div><br></div></div><div>Interestingly, I totally disagree with this. I find lots of tiny classes interacting with each other in cohesive, well defined ways to be far easier to  grok than large classes with lots of imperative spaghetti. Maybe that's just me though!</div>
<div class="im">
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div>One way to strike a balance would be to develop the app in the canonical fashion and then use these techniques as and when. E.g. Use the publish subscribe pattern when controllers/models start to get bloated. However, by that point it could be a bit too late and I might be reluctant to make changes that major. My integration tests would catch most stuff, but I will have to be confident that they will catch all the edge cases.</div>

</div></blockquote><div><br></div></div><div>This is also a great approach, and one that I've used with success on 'legacy' projects. The key things here are to have acceptance tests for *everything* that conceivably break when refactoring a given area (ideally 100% coverage of the whole app), and to not get too attached to your existing implementation. There's also some easy OO wins you can apply here -for instance presenters/decorators/view models/whatever you want to call them are a very easy pattern to introduce to existing 'rails-y' code, and provide a lot of benefit in terms of reduced coupling and increased cohesion for the effort. The main thing (as is also true with 'greenfield' projects) though is to refactor continuously and ruthlessly. Ultimitely the architecture of your app will be something you derive yourself, 'rails' or 'hexagonal / oop' are just starting points, and a set of principles to guide you.</div>

<div> </div><div>I can't open-source the work I've talked about above as it's for clients, but I'd be happy to show you some of it in person if you'd be interested in examples (although I am planning to write a blog post with some examples at some point, and possibly abstract out some of it into plugins that I can open up, this might take me a little while!)</div>

<div><br></div><div>Cheers,</div><div><br></div><div>Tim</div><div><br></div></div></div></div>
</div><br></div>