<div dir="ltr">To address the question of hiring I say hire software engineers rather than Rails devs.<div><br></div><div><div>We've had a pretty positive experience with with on-boarding so far, but be aware you'll need to hire people with good heads for OO.</div>
<div><br></div><div>Just as there's programming with functions and functional programming, there's programming with objects (most Rails apps) and object orientated programming.</div><div><br></div><div>If your team know the distinctions I'm talking about then they'll be fine.</div>
</div><div><br></div><div>Also if you start with coupling your app to Rails you ain't never getting it back. Start decoupled and if it causes a problem with your new hires they can paste the code into a massive controller method (or maybe on the user model) and everyone will be right back in their comfort zones :)</div>
<div><br></div></div><div class="gmail_extra"><br clear="all"><div><br>Stephen Best<br>Ruby / Javascript developer, Ember.js evangelist.<br><br>+44 7745 790523<br><a href="http://linkd.in/stephenbest" target="_blank">linkd.in/stephenbest</a><br>
<a href="http://github.com/bestie" target="_blank">github.com/bestie</a><br>@thebestie</div>
<br><br><div class="gmail_quote">On 23 July 2013 23:12, Stephen Best <span dir="ltr"><<a href="mailto:bestie@gmail.com" target="_blank">bestie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I've been working on a green field SOA project with the team at Cambridge Healthcare recently and we've very much embraced the whole 'Hexagonal Architecture' paradigm, following the EBI / EBC (entity, boundary, interactor / controller) pattern mentioned by Uncle Bob is his "Architecture the Lost Years" talk.<div>
<br></div><div><a href="http://www.youtube.com/watch?v=WpkDN78P884" target="_blank">http://www.youtube.com/watch?v=WpkDN78P884</a><br><div><br></div><div>We started off with a hexagonal-ish Rails app, used devise and the service layer pattern and soon moved away from Rails and ported our app to Grape. The porting process was not a big problem.<br>
<div><br></div><div>The awesome stuff is:</div><div><br></div><div><div>* Adding / changing features is very easy.</div><div>* All our objects are very simple.</div><div>* Tests are lightening fast. Unit test run measured in ms. Full integration suite run through Faraday / Rack test takes <5s, including startup times.</div>
</div><div><br></div><div>The caveats are:</div><div><br></div><div>* It takes a little longer to get going.</div><div>* Those tough decisions about how to do things are frequent at the start, make sure have at least two experienced/obsessed engineers to pair on / argue about them.</div>
<div><br></div><div>Gerhard Lazu and myself are planning to present some of our ideas and code samples as soon as our apps have proven themselves in production.</div></div></div><div class="gmail_extra"><br><div>Stephen Best<br>
Ruby / Javascript developer, Ember.js evangelist.<br><br>+44 7745 790523<br><a href="http://linkd.in/stephenbest" target="_blank">linkd.in/stephenbest</a><br><a href="http://github.com/bestie" target="_blank">github.com/bestie</a><br>
@thebestie</div>
<br><br><div class="gmail_quote"><div><div class="h5">On 23 July 2013 21:25, Aanand Prasad <span dir="ltr"><<a href="mailto:aanand.prasad@gmail.com" target="_blank">aanand.prasad@gmail.com</a>></span> wrote:<br></div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5">
<div>This comes to mind as a practical application of some of the techniques we usually discuss at a higher level, though perhaps it's not all that radical:</div><div><br></div><div><a href="http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/" target="_blank">http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/</a></div>
<div><br></div><div>On the refactoring theme, there's also the Bowkett book, Unfuck a Monorail. Has anyone read that?</div><div><div><br><br><div class="gmail_quote"><p>On Tue, Jul 23, 2013 at 8:53 PM, Murray Steele <span dir="ltr"><<a href="mailto:murray.steele@gmail.com" target="_blank">murray.steele@gmail.com</a>></span> wrote:<br>
</p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">
On 23 July 2013 15:58, Roland Swingler <span dir="ltr"><<a href="mailto:roland.swingler@gmail.com" target="_blank">roland.swingler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>* What sort of developers will you be hiring? Junior & mid-level developers have a lot of resources in terms of books, community, other code examples, etc. to learn how to follow rails conventions really well. Going for the Objects on rails approach forces you into making many more, harder, decisions - what is the scope for these decisions to be made poorly? Appealing to authority, I seem to remember in the Domain Driven Design book, Eric Evans advising that you shouldn't try and apply DDD if the modelling skill in your team isn't high.</div>
</div></blockquote><div><br></div><div style="font-family:arial,sans-serif;font-size:13px">I think this is key. If you build a standard rails app you are in very real terms "on rails"; there's a single approach you can take to build the app and you don't really have to think much as there's so much What Has Gone Before wisdom out there. If you take the OO / Hexagonal approach pretty much everything you do is going to require A Decision About Something New. Like Roland, I don't think that's a bad thing, but I do worry that it means it's easier to make poor decisions.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">There's lots of people saying "Hey, you should totes do stuff this new way. Maintainability FTW!" but not a lot of "and here is how. WOO!". Maybe someone can prove me wrong though; do you know of any good, real-world, examples to look at?</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">[aside: Objects on rails is good but, as someone already said, it describes a toy app and it's hard to extrapolate upwards to the complexity we'd really face. The songkick tech blog series[0] about their approach to splitting an app into services is also good. I want more.]</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px"><div>It occurs to me that I have a bunch of tools to hand for refactoring single objects (extract method, identify and extract collaborators, etc). Handily these tools can be applied to the problem in my brain before I even start writing the code, so I can knock up something reasonable at first pass without the refactoring step.</div>
<div><br></div><div>What I don't really feel like I have a similar set of tools for doing this across a whole app. Unless, maybe I do? Is it just the same thing, applied macroscopically? Does it even make sense to think in terms of red-green-refactor across a whole app architecture?</div>
<div><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">Ideally I want someone who has done both:</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
a) starting a new app and doing it using pure OO / Hexagonal approaches</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">and</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">b) refactoring a standard rails monolith down into a more service-y many-apps architecture</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">to come an tell me (us) what it's like and which is easier. Also explain what pitfalls there are (for example I imagine one obvious one is chopping it into the wrong services too early), and what patterns there are for spotting obvious things.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Anyone?</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
Muz</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">[0]</span><span style="font-family:arial,sans-serif;font-size:13px"> </span><a href="http://devblog.songkick.com/2012/07/27/service-oriented-songkick/" style="font-family:arial,sans-serif;font-size:13px" target="_blank">http://devblog.songkick.com/2012/07/27/service-oriented-songkick/</a><span style="font-family:arial,sans-serif;font-size:13px"> - I think that's the first of 3 articles; I'm sure a Songkicker will let us know if I'm wrong ;)</span> </div>
</div></div></div></blockquote></div><br></div></div><br></div></div><div class="im">_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></div></blockquote></div><br></div></div>
</blockquote></div><br></div>