[LRUG] Does Rails have an image problem?

Thu Aug 27 05:36:16 PDT 2020

Sorry to revive an old thread, but I just spotted this in the new Bootstrap 5 announcement post (https://blog.getbootstrap.com/2020/06/16/bootstrap-5-alpha/ <https://blog.getbootstrap.com/2020/06/16/bootstrap-5-alpha/>) and thought it was relevant:

Since when is requiring Ruby to be installed a ‘major issue’! 

> On 19 Aug 2020, at 14:45, Edmond Lepedus <ed.lepedus at googlemail.com> wrote:
> 
>> Sounds like you have a culture problem, not a technology one.
>> 
>> I’m far from a JS fan but I can’t believe Node land is much less productive and less likely to adoptive the kinds of good dev practice Rails foregrounded way back when? 
>> 
>> I’d probably join their camp but push for better practices 🤷‍♂️ 
> Matt, you’re right, we do have a culture problem. My hope is that in switching to rails, we would more easily break old habits and absorb the culture of quality that the rails community has championed.
> 
>> Sounds like the team has a lot of existing expertise in curly-brace languages.  Honestly, you might be the odd one out here, as it can take a while to get comfortable and productive in a new language, and if you're the only one who's already there, switching languages might cost your team quite a lot in terms of forward momentum.  Also, as you've pointed out, introducing yet another language is... unlikely to mitigate your onboarding problems over the next 2-3 years (a likely timeframe for rewriting :allthethings:).
>> 
>> I'd also be concerned that if your existing systems are brittle, getting everyone to switch languages *might* just result in having even more systems that are brittle, some of which happen to be half-rewritten in Ruby.  (It's easy to write unmaintainable code in any language.)  The time and energy they'd invest in learning a new language *could* be time and energy better spent leveling up testing and refactoring skills in the languages they already know.  In particular, it might be better to focus on some of the skills and practices highlighted in this talk:  https://youtu.be/UOOuW5tqT8M <https://youtu.be/UOOuW5tqT8M>.  The same author [full disclosure: a friend of mine] also has a screencast series that will be my first stop once I finally get around to seriously learning JS:  http://www.letscodejavascript.com/ <http://www.letscodejavascript.com/>
>> 
>> All that said... y'all's agreement to "adopt BDD going forward" might provide a reasonable way to introduce Ruby as part of the Cucumber stack.  (Or not; I'm aware that there is a JS implementation, but haven't checked it out.)  Either way... at risk of looking like a self-promoting jerk, you might appreciate some of my hard-earned advice on how to not make huge messes using Cucumber.  (Slides: https://www.slideshare.net/geeksam/cucumbers-have-layers-rubyconf-2014 <https://www.slideshare.net/geeksam/cucumbers-have-layers-rubyconf-2014>; video: http://confreaks.tv/videos/rubyconf2015-cucumbers-have-layers-a-love-story <http://confreaks.tv/videos/rubyconf2015-cucumbers-have-layers-a-love-story>)
> 
> Sam, thanks for your measured and insightful reply. I’m not going to push too hard on switching to Rails. Instead, I will focus my energies on ensuring that our adoption of BDD is a success, regardless of tech stack.
> 
> BTW, I really enjoyed your talk about testing in layers. Amongst other things, it helped me make sense of the development flow when using both acceptance testing and unit testing. I wasn’t quite sure whether I would have both test suites on an autorun loop, or whether to switch between them. It sounds like you tend to have the unit tests on autorun and manually run the acceptance tests pre-commit/as needed.
> 
> 
>> On 18 Aug 2020, at 17:36, Sam Livingston-Gray <geeksam at gmail.com <mailto:geeksam at gmail.com>> wrote:
>> 
>> Sounds like the team has a lot of existing expertise in curly-brace languages.  Honestly, you might be the odd one out here, as it can take a while to get comfortable and productive in a new language, and if you're the only one who's already there, switching languages might cost your team quite a lot in terms of forward momentum.  Also, as you've pointed out, introducing yet another language is... unlikely to mitigate your onboarding problems over the next 2-3 years (a likely timeframe for rewriting :allthethings:).
>> 
>> I'd also be concerned that if your existing systems are brittle, getting everyone to switch languages *might* just result in having even more systems that are brittle, some of which happen to be half-rewritten in Ruby.  (It's easy to write unmaintainable code in any language.)  The time and energy they'd invest in learning a new language *could* be time and energy better spent leveling up testing and refactoring skills in the languages they already know.  In particular, it might be better to focus on some of the skills and practices highlighted in this talk:  https://youtu.be/UOOuW5tqT8M <https://youtu.be/UOOuW5tqT8M>.  The same author [full disclosure: a friend of mine] also has a screencast series that will be my first stop once I finally get around to seriously learning JS:  http://www.letscodejavascript.com/ <http://www.letscodejavascript.com/>
>> 
>> All that said... y'all's agreement to "adopt BDD going forward" might provide a reasonable way to introduce Ruby as part of the Cucumber stack.  (Or not; I'm aware that there is a JS implementation, but haven't checked it out.)  Either way... at risk of looking like a self-promoting jerk, you might appreciate some of my hard-earned advice on how to not make huge messes using Cucumber.  (Slides: https://www.slideshare.net/geeksam/cucumbers-have-layers-rubyconf-2014 <https://www.slideshare.net/geeksam/cucumbers-have-layers-rubyconf-2014>; video: http://confreaks.tv/videos/rubyconf2015-cucumbers-have-layers-a-love-story <http://confreaks.tv/videos/rubyconf2015-cucumbers-have-layers-a-love-story>)
>> 
>> 
>> On Tue, Aug 18, 2020 at 2:58 AM Edmond Lepedus <ed.lepedus at googlemail.com <mailto:ed.lepedus at googlemail.com>> wrote:
>> Thanks for all your replies. Some really interesting points there. The ones that resonated the most with me were
>> - ask them to sell me on NodeJS 
>> - figure out what the other devs care about
>> - ask why so many large, successful companies are built on Rails
>> 
>> I also really enjoyed reading the post about when Rails is not the right choice, and re-reading the Rails Doctrine, which is also one of the major draws of Rails. I have shared both with the team.
>> 
>> In terms of providing additional context, I have recently joined a small web team in a larger games company. Our focus is to deliver added value services eg forums, leaderboards, achievements etc for our players. Although I’m only a few months in the role, the company has been a client of mine for many years, and I was involved in delivering the original MVP system before there was even a dedicated team for it. Back then, the project had been started in Java + Angular, but due to hiring difficulties, I was brought in to get it over the line. I made the point even then that Rails would be a much better choice, but there simply wasn’t time to start over. Since then, the frontend has been rewritten in React, and although we still have the old Java backend, new services have been built in NodeJS (Express + Sequelize). Now we are building a new profile service, which will likely grow and eventually take over the last bits of functionality from the Java API so it can be retired. Our team has complete autonomy when making tech choices, so it’s ‘just’ the other devs I have to convince.
>> 
>> The main challenges our team faces are
>> - limited dev resource
>> - brittle systems, partly due to lack of automated testing (we have committed to adopting BDD going forward)
>> - issues hiring and onboarding due to having a mishmash of stacks, largely homegrown systems and virtually no documentation for any of them
>> 
>> I believe Rails will help with all of the above by improving productivity, providing handrails for our adoption of automated testing, and providing a robust, well-known and well-documented foundation for our services.
>> 
>> I think the main concerns are the initial productivity drop while everyone gets up to speed, the ‘loss’ of mindshare invested in NodeJS, and potentially making our onboarding even more difficult in the short term as we will have Java, Node, Rails & React.
>> 
>>> On 17 Aug 2020, at 18:06, Ed James <ed.james.spam at gmail.com <mailto:ed.james.spam at gmail.com>> wrote:
>>> 
>>> Interesting topic.
>>> 
>>> Ed > it’s not entirely clear from your original message who exactly it is that you’re selling Rails to - is it the dev/tech team or the business? 
>>> 
>>> In my experience selling Rails to the business has always been the much easier sell, with the only reassurance required being the availability (and cost!) of developers. However, trying to sell Rails to a team of developers is likely to be extremely difficult in most cases. 
>>> 
>>> It’s probably also worth thinking about whether it’s difficult because "Rails is Rails", or whether it’s difficult because "Rails is different-to-what-is-already-being-used”. Any tech team worth its salt will know that moving to any other tech stack is a big commitment which will likely have an early adjustment period of bewilderment and steep learning curves, resulting in reluctance/resistance to change.
>>> 
>>> Hope that helps.
>>> 
>>> 
>>> 	Ed James 
>>> I will respect your spam <mailto:ed.james.spam at gmail.com>
>>> 
>>>> On 17 Aug 2020, at 16:29, Edmond Lepedus <ed.lepedus at googlemail.com <mailto:ed.lepedus at googlemail.com>> wrote:
>>>> 
>>>> Hi LRUG,
>>>> 
>>>> Once again I’ve recommended Rails for a project, and once again, I’ve found it a really hard sell, and I suspect the decision will be to use NodeJS instead. It seems that outside of the Rails community, most devs have a pretty poor opinion or just lack of visibility into the awesomeness of Rails. I’ve been asked questions like “Isn’t Rails abandonware now?”, been pointed to StackOverflow’s developer survey (https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-other-frameworks-libraries-and-tools-loved3 <https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-other-frameworks-libraries-and-tools-loved3>) as ‘evidence’ for NodeJS’s superiority and been told that “the majority of Rails consultants make their money on migrating people to other platforms”. This is not a new thing. I’ve been recommending Rails for web projects for nearly 7 years, both as an employee and as a consultant, with zero success. And before you think it’s just my credibility, I’ve not had any issues when recommending, WordPress, NextJS, Kubernetes, Ansible etc. It’s just Rails.
>>>> 
>>>> My current team would benefit hugely from Rails. It would do wonders for everything from code quality and productivity to documentation and our ability to hire and onboard new developers, but I fear that we will once again default to NodeJS and miss out on most of those benefits. 
>>>> 
>>>> The weird thing is that we use and love systems written in Rails, such as GitLab, and have enthusiastically committed to migrating our forums to Discourse, but the halo effect from those projects doesn’t seem to be affecting perceptions of Rails itself.
>>>> 
>>>> How do you sell Rails in a compelling way?
>>>> 
>>>> Thanks,
>>>> Ed
>>>> _______________________________________________
>>>> Chat mailing list
>>>> Chat at lists.lrug.org <mailto:Chat at lists.lrug.org>
>>>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org <http://lists.lrug.org/pipermail/chat-lrug.org>
>>>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org <http://lists.lrug.org/options.cgi/chat-lrug.org>
>>>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org <http://lists.lrug.org/listinfo.cgi/chat-lrug.org>
>>> 
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.lrug.org <mailto:Chat at lists.lrug.org>
>>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org <http://lists.lrug.org/pipermail/chat-lrug.org>
>>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org <http://lists.lrug.org/options.cgi/chat-lrug.org>
>>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org <http://lists.lrug.org/listinfo.cgi/chat-lrug.org>
>> 
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org <mailto:Chat at lists.lrug.org>
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org <http://lists.lrug.org/pipermail/chat-lrug.org>
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org <http://lists.lrug.org/options.cgi/chat-lrug.org>
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org <http://lists.lrug.org/listinfo.cgi/chat-lrug.org>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org <mailto:Chat at lists.lrug.org>
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20200827/4b5ecf61/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2020-08-27 at 13.33.41.png
Type: image/png
Size: 219277 bytes
Desc: not available
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20200827/4b5ecf61/attachment-0001.png>