[LRUG] Does Rails have an image problem?

Tue Sep 1 06:00:19 PDT 2020

This is probably because people writing documentation may not be that
technical so having a working ruby instance is some overhead + hugo having
a binary install for most platforms. Installing ruby isn't a major issue
for a dev, but it does have its challenges for non-devs. The extra speed of
site generation of Hugo is probably a bigger benefit when you consider the
size of the bootstrap documentation.

On Thu, 27 Aug 2020 at 15:38, Edmond Lepedus <ed.lepedus at googlemail.com>
wrote:

> 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/) 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.  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/
>
> 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;
> video:
> 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> 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.  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/
>
> 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;
> video:
> 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>
> 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> 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 <ed.james.spam at gmail.com>
>>
>> On 17 Aug 2020, at 16:29, Edmond Lepedus <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) 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
>> 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
>>
>>
>> _______________________________________________
>> Chat mailing list
>> 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
>>
>>
>> _______________________________________________
>> Chat mailing list
>> 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
>>
> _______________________________________________
> Chat mailing list
> 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
>
>
>
> _______________________________________________
> Chat mailing list
> 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
>

-- 
------------------------
Andrew Premdas
blog.andrew.premdas.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20200901/d73032e6/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/20200901/d73032e6/attachment-0001.png>