<font color="#000000"><font><font face="arial,helvetica,sans-serif">Some sound principles which never failed me:</font></font></font><div><font face="arial, helvetica, sans-serif"><br></font></div><div>
<div>1. Choose a solution from your own experience, appropriate for the team that you're leading</div><div><br></div><div>Teams vary wildly, what works for team A will not work for team B. If unsure, favour the known, tried and tested over the more academic solutions.</div>
<div><br></div><div>2. Write apps with change in mind</div>
<div><br></div><div>POODR explains this very well, I couldn't put it any better <a href="http://www.poodr.info/" target="_blank">http://www.poodr.info/</a></div><div><br></div><div>Whether it's a conventional Rails or pure JS app, strive for simple & clean code.</div>
<div><br></div><div>3. Simple and straightforward always wins</div>
<div><br>
</div><div>If Rails is the simple and straightforward solution for you, go with it. As Roland mentioned, Rails works very well for conventional CRUD. Even bigger apps, with enough Rails experience, can be pulled off, just think alphagov.</div>
<div><br></div><div>4. Innovate as/when you can afford it </div><div><br></div><div>You should try new things for fun, not when you have a deadline or when important things depend on it. Experiments can go either way, plan for failure. Sometimes, the old and boring way is the best way <a href="http://zef.me/4235/pick-your-battles" target="_blank">http://zef.me/4235/pick-your-battles</a></div>
<div><br></div><div>5. Defer decisions</div><div><br></div><div>This requires more experience, but the point is to defer everything that you can. Rails is a decision, so is a real database <a href="http://www.youtube.com/watch?v=WpkDN78P884#t=49m48s" target="_blank">Keynote: Architecture the Lost Years by Robert Martin</a></div>
<div><div><br></div><div>As Stephen mentioned, we've been running EBI in production for a few months now, we're holding out for the degradation part. Every approach starts to degrade sooner or later, without that experience under our belt the talk that we're thinking of giving would be incomplete.</div>
<div><br></div><div>My reasons for going pure Ruby are based on all the negative experiences that I've had with monorails stuck at specific versions (mostly Rails 2.x) and bloated with hundreds of gems. I've always associated them with having an anaconda as a pet.</div>
<div><br></div><div>Over time, all successful apps grow to become standalone DSLs. As long as you don't weld them to a framework, you will be much better off in the long run. Yes, it does require experience to realize when you're coupling, but experience is just learning from past mistakes. Trying to prevent mistakes acts like airbrakes to learning and growing.<span></span></div>
<div><br></div><div>As for the conclusion, <a href="http://www.youtube.com/watch?v=Rzu6zeLSWq8" target="_blank">Apple (unreleased) Think Different ad - Narrated by Steve Jobs (1997)</a></div><div><br><hr style="font-family:arial,helvetica,sans-serif">
<font color="#3333ff"><font face="arial, helvetica, sans-serif"><a href="http://twitter.com/#!/gerhardlazu" target="_blank">Twitter</a> <a href="https://github.com/gerhard" target="_blank">Github</a> </font><a href="http://gerhardlazu.com/" style="font-family:arial,helvetica,sans-serif" target="_blank">Blog</a></font></div>
<br><br><div class="gmail_quote">On Tue, Jul 23, 2013 at 2:26 PM, Tom Cartwright <span dir="ltr"><<a href="javascript:_e({}, 'cvml', 'tecartwright@gmail.com');" target="_blank">tecartwright@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Afternoon all,<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 (service layers, decorators, publish/subscribe (announcer/listener) pattern, logic living in a classes with a single responsibility etc). Everything will be easier to test and easier to change and develop. Winner.</div>
<div>However, when I asked a colleague what they thought of these techniques, 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>
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. Given lots of developers will be working on the app, onboard time is something I need to consider.</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><br></div><div>So my question is: Should you strike a balance? If so, how do you strike a good balance? What has been your experience of introducing these techniques bit-by-bit?</div><div>Thanks in advance for your brain thoughts.</div>
<span><font color="#888888">
<div><br></div><div>Tom</div><div><br></div>-- <br><div dir="ltr"><font face="arial, helvetica, sans-serif">Tom Cartwright</font><div><font face="arial, helvetica, sans-serif"><a href="http://tecartwright@gmail.com/" style="line-height:18px;white-space:pre-wrap;text-decoration:initial" target="_blank">tecartwright@gmail.com</a><span style="line-height:18px;color:rgb(71,71,71);white-space:pre-wrap">
<a href="http://www.tomcartwright.net" target="_blank">Portfolio</a> </span><font color="#474747"><span style="line-height:18px;white-space:pre-wrap">· </span></font><span style="line-height:18px;color:rgb(71,71,71);white-space:pre-wrap"><a href="http://github.com/tomcartwrightuk" target="_blank">GitHub</a></span></font></div>
</div>
</font></span></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="javascript:_e({}, 'cvml', '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></blockquote></div><br></div></div>
<br><br>-- <br><br><hr style="font-family:arial,helvetica,sans-serif"><font color="#3333ff"><font face="arial, helvetica, sans-serif"><a href="http://twitter.com/#!/gerhardlazu" target="_blank">Twitter</a> <a href="https://github.com/gerhard" target="_blank">Github</a> </font><a href="http://gerhardlazu.com/" style="font-family:arial,helvetica,sans-serif" target="_blank">Blog</a></font><br>