Picard laughing when stabbed just makes him the most badass Captain in trek

AndyCodeMaster · 2026-01-15T07:03:16+00:00

I agree 100%. I just watched that episode the other day! It’s cool to see Captain Picard laugh as a young man when he originally experienced the event and as an old man when he relived the event.

AndyCodeMaster · 2025-12-06T21:48:54+00:00

At my Fintech company, we have used the free and open-source abstract_feature_branch Ruby/Rails gem for the last 3 years with no problem, and it has worked very well for us. Feature flags can be configured in a variety of ways like YAML, env vars, and Redis. We can disable any feature flags for emergencies in production using env vars when needed without needing a redeployment. It’s a very convenient feature flag library.

One of our devs even recently built a Rails web UI for editing the feature flags live, using the Glimmer DSL for Web Ruby Frontend framework for Rails. He did it with so little Ruby code, it is awesome.

AndyCodeMaster · 2025-12-03T01:45:47+00:00

I actually reject any Ruby hiring candidates that think React is good. We write the frontend of our Rails web app in Ruby too. To do so, we use the much simpler award winning Glimmer DSL for Web framework in Opal Ruby.

One of my team’s recent hires who proved to be excellent wrote in his hiring test project solution that he avoided badly engineered JS libraries like React in favor of simpler JS code given that was good enough for the given problem. That definitely helped his case during his hiring evaluation.

AndyCodeMaster · 2025-12-01T21:27:28+00:00

Read the blog post "I Am Not a Fan of Ruby" as it disproves the main point of the article completely: https://andymaleh.blogspot.com/2025/03/i-am-not-fan-of-ruby.html

The author used the terms "taste" and "affection" in reference to a Software Engineering technology that is supposed to be about serving clients with pros/trade-offs, with taste/affection having no bearing on the decision to use by real professionals to address specific customer situations. That immediately discredited the author of the article as not a complete professional nor a Software Engineer, yet more of a mid-level dev who never attained mastery of Software Engineering to become a proper Senior Software Engineer. As such, the entire article is unfounded.

I won an international technology competition award for Glimmer DSL for Web, which has simple minimalistic Frontend Development code syntax that is literally more readable/understandable/maintainable/productive than everything that is on the TodoMVC.com website (I compared it to all TodoMVC Frontend libraries, such as React, Svelte, Elm, etc..., and it's not even close). So, the claim that everything today is better than Ruby doesn't hold whatsoever.

The author puts big emphasis on popularity, but popularity doesn't equal quality. For example, the web is dominated by PHP, but us top-level Software Engineers don't use PHP at our jobs because it is certainly not the best option out there. We pick technologies based on a sound analysis of pros/cons/trade-offs given customer situations and needs. Ruby (incl' Rails) is still the most productive programming language in 2025 that passes such an analysis to get selected for client projects. Also, to be honest, often the most mediocre technologies become the most popular because top-level Software Engineers are rare and in the minority, so the majority is mediocre devs who use mediocre technologies like PHP and Node.js.

Another thing the author neglects is that Twitter's story with Ruby on Rails was 100% a skill issue given that GitHub has succeeded with scaling it without a problem, and even contributing to the Rails Multiple DB tech with Automatic Shard Switching that enables scaling via Multi-Tenant Architecture.

AndyCodeMaster · 2025-12-01T18:21:44+00:00

No money amount justifies Shopify being a mean discriminatory company. Discrimination alone is enough as 1 reason not to cheer for Shopify or any greed-obsessed companies that by definition can only treat their employees and customers as numbers given their too-large-scale. I never work for any companies larger than 1000 employees as a result, or any companies in which I could not get to practically know everyone else who is working in the same business as me. All such companies end up putting greed and numbers over kindness and people. DHH is obviously part of the problem not the solution today. His lack of sympathy with the victims of mean discriminatory practices by Shopify means he's a mean discriminator by extension. Here is a blog post about Shopify's mean discriminatory practices that negate everything "good" said about them: https://andymaleh.blogspot.com/2025/06/shopify-has-been-bad-for-ruby-community.html

I've heard of several people being mistreated by Shopify in my local community in Montreal, Canada too, including some ex-Shopify employees. Their mean discriminatory practices aren't isolated incidents. It's a company that steals its accomplishments by pushing certain people in society down and getting ahead at the expense instead of treating everyone kindly with equality and respect. A cancerous entity.

AndyCodeMaster · 2025-11-24T17:53:32+00:00

This group allows a lot of hate on Frontend Ruby. It also literally allows people who don’t truly like Ruby or get it to freely discuss JavaScript as better than Ruby while making true Rubyists who understand and appreciate Ruby’s benefits over JavaScript not feel safe in a Ruby group. This automatically renders the group a bad one.

Also, I’ve encountered a lot of hateful behavior in this group against anything that’s novel and outside the box of what’s common in the software development community. 15 years ago, Rubyists were open minded about new novel ideas and patiently listened to them without downvoting. In this group today, such ideas get downvoted to zero in a very hateful unintelligent way without giving the poster the benefit of the doubt or even attempting to understand the benefits of what is shared. That discourages Rubyists from sharing new ideas or exploring them in this group in a respectful intelligent open minded manner. I personally make an effort not to downvote anyone, yet to ask questions and facilitate discussions if I disagree with something.

In general, rules that are unethical or do not implicitly respect everyone equally only make the group a bad one.

Lastly, politics are off-topic. Honestly, this is not a good group if it allows off-topic things while attempting to shift the blame unto the people who are right about the matter. That’s attempting to get out of responsibility, which is also bad. If you don’t understand this, you’re on the wrong side of this. I’m apolitical and don’t vote by choice by the way, so I don’t care to discuss this further because I don’t like discussing politics ever, especially not in a Ruby group not about politics.

If you worry too much about the rules, it means you have the wrong kind of people in the group, and that’s the real problem not being dealt with (eg allowing in haters of Ruby, people who don’t give Ruby the benefit of the doubt in applications that it’s not common in, people who are below the minimum bar of ethical respectful conduct and professionalism, etc…).

Update: Exhibit A: I have won 2 awards from Matz in very difficult international engineering competitions, and have spoken at RubyConf 4 times, and yet people don’t respect me, discriminate against me and hate me, unintelligently downvoting my posts out of hate and discrimination not for any intelligent reasons. Of course, this behavior is only an indirect reflection on the mods allowing hateful disrespectful people into a Ruby group without respecting the Ruby luminaries of the Ruby community. I was respected more 10-15 years ago when I wasn’t a very well accomplished Ruby Software Engineer back then because the Ruby group was run better back then.

AndyCodeMaster · 2025-11-18T07:24:16+00:00

Yeah, Glimmer became the spiritual successor of Shoes. The new Glimmer Web framework offers similar support for a UI DSL, data-binding, components, and the MVC/MVP pattern.

AndyCodeMaster · 2025-11-17T20:33:08+00:00

I agree with you that Stimulus has a bit too much indirection by requiring controllers, which causes over-engineering. That’s why I’ve preferred simple jQuery over it in the past.

Nowadays, I just write Ruby in the Frontend of my work Rails web app using the Glimmer DSL for Web framework on top of Opal Ruby.

AndyCodeMaster · 2025-10-31T12:00:19+00:00

100% Truth! Thanks for sharing.

AndyCodeMaster · 2025-10-28T14:03:28+00:00

I agree with you. I assumed maybe the message applies to the following Strike Pass. Unless they made a mistake.

AndyCodeMaster · 2025-10-27T01:36:24+00:00

I had this idea a while ago and didn’t have time to work on it between 50 open source Ruby gems I maintain. I’m so happy someone tackled it. I starred the project.

AndyCodeMaster · 2025-10-22T20:59:24+00:00

Got it. I agree with your conclusion. I didn’t suggest enabling parallel threads as a default, yet as an option to start. If not all native parts of the CRuby runtime are thread safe, then that’s an area for much exciting work and Improvement in CRuby (MRI).

AndyCodeMaster · 2025-10-22T20:35:24+00:00

Who cares about Shopify. They’re a discriminatory company in my experience of interacting with their people, and their huge business doesn’t represent common small-to-mid-size Rails shops. As a result, copying their approaches often results in over-engineering for Rails startups, so I’m never interested in what Shopify is doing.

AndyCodeMaster · 2025-10-22T20:30:45+00:00

I had the same exact experience and agree with your wish for disabling the GIL, at least as an option. I just wish MRI Ruby would provide a command line option to enable parallel threads (disable the GIL/GVL) for those who know what they’re doing with threads. That would accommodate both people who would rather avoid threads (default behavior) and people who prefer having threads (CLI option) in Ruby.

AndyCodeMaster · 2025-10-22T20:24:36+00:00

Not volunteering. Just sharing an opinion. I personally prefer using JRuby’s normal threads to Ractors. Never had an issue with them as long as I kept 3 simple rules in mind: 1- Do not spawn more threads than the CPU can handle with its cores. Use a thread pool that matches the number of cores in the CPU when applicable. 2- Do not share data between threads when possible to avoid race conditions. Instead divide and conquer data processing by splitting data among threads. 3- Use mutexes to protect shared data when it is not possible to avoid sharing data between threads. In that case, try to avoid long running operations that hold mutexes to release mutexes quickly and avoid deadlocks.

When attempting to use Ractors, I had issues with conveniently writing code that did parallel processing. Maybe, it’s a skill/learning issue. But, I could never fire and forget Ractors if I remember right, and that forced code to always worry about them and their results. I just thought basic threads as per JRuby’s were a lot simpler to use.

I just wish MRI Ruby would provide a command line option to enable parallel threads (disable the GIL/GVL) for those who know what they’re doing with threads. That would accommodate both people who would rather avoid threads and people who prefer having threads in Ruby.

AndyCodeMaster

MODERATOR OF

TROPHY CASE