[LRUG] Does Rails have an image problem?

Fri Sep 4 10:51:13 PDT 2020

as everyone else has said: it's another semi-complex dependency *if* you're
not a Ruby developer or developing Ruby software. Sorting out versions,
environments, and gems just to publish documentation isn't necessarily a
valuable use of a documenter's time. (Python and Javascript have, frankly,
similar problems, not to mention their own idiosyncracies).

Bear in mind also that they're comparing it to Hugo, which emphatically has
no dependencies other than the Hugo binary, which is prebuilt - you don't
need to have a Go environment to use it. For a lot of teams and toolchains,
that's a big win in terms of consistent delivery.

On Thu, Aug 27, 2020 at 3:28 PM 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
>

-- 
Tom Armitage
http://infovore.org
07813 060578
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20200904/5cbd3591/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/20200904/5cbd3591/attachment-0001.png>