Showing posts with label Rails. Show all posts
Showing posts with label Rails. Show all posts

Tuesday, March 17, 2026

Glimmer DSL for Web 0.8.3 Preventing Components from Shadowing HTML Elements

Glimmer DSL for Web (Fukuoka Award Winning Ruby-in-the-Browser Frontend Framework for Rails) had a new release in version 0.8.3, which now raises an exception plus a correction hint if the user attempts to define a component or a component slot with a name that shadows an existing HTML element.

For example, suppose a developer defines a Glimmer Web Component class called `Input`, which would automatically generate the `input` keyword for use in the Ruby HTML DSL:

class Input

  include Glimmer::Web::Component   

  markup {

    h1 { "Hello!" }

  }

}

This would normally shadow the HTML input element, preventing the user from being able to use HTML input as in this code:

input(type: 'text', id: 'name', placeholder: 'John Doe')

Instead, input now can only be used according to the component definition (which currently defines zero attributes):

input

This renders <h1>Hello!</h1> as per the Glimmer Web Component definition above. Of course, this is a contrived example as normally, an input component would have some form of inputting behavior, but for the sake of this example, let's imagine that it just renders an h1.

In version 0.8.3, Glimmer DSL for Web now raises an exception if the developer attempts to shadow an existing HTML element:

Cannot define the Glimmer::Web::Component class "Input" because it shadows the HTML element "input"! Either rename the class (e.g. "MyAppInput") to avoid conflicting with an existing HTML element name or nest it within a namespace module/class (e.g. "MyApp::Input")!

So, the developer can happily rename the component:

class AcmeInput

  include Glimmer::Web::Component   

  markup {

    h1 { "Hello!" }

  }

}

Or, the developer can happily namespace the component:

module Acme

  class Input

    include Glimmer::Web::Component   

    markup {

      h1 { "Hello!" }

    }

  }

end

That way, the user can now continue to use standard HTML input in addition to the new input components:

div {

  acme_input # the renamed class version

  acme__input # the namespaced class version (double-underscores in place of ::)

  input(type: 'text', id: 'name', placeholder: 'John Doe') # standard HTML input

}

The same sort of safety harness has been implemented for Component Slots as well.

Glimmer on!!! 

Monday, March 16, 2026

Workshop Accepted: "Building Rails SPAs in Ruby using Glimmer DSL for Web" at Wroclove.rb 2026

My 3-hour workshop proposal "Building Rails SPAs in Ruby using Glimmer DSL for Web" was accepted at the Wroclove.rb 2026 Ruby Conference, which takes place April 17-19, 2026 in Wroclaw, Poland. 

Title:

Building Rails SPAs in Ruby using Glimmer DSL for Web

Description:

Glimmer DSL for Web is a Ruby-in-the-Browser Web Frontend Framework for Rails that won an award at the Fukuoka Prefecture Future IT Initiative 2025 competition after getting judged by Matz (the creator of Ruby) and other Fukuoka Prefecture competition judges. Since January of 2025, it has been in use at Eltropy Canada inside the Collection 2.0 Rails web app (a debt collection FinTech platform) as an upgrade from React.js, doubling productivity with much simpler Frontend Ruby code.

This is the missing piece of the Ruby puzzle that bridges the gap between basic Rails Hotwire apps and more sophisticated highly interactive Rails apps that need a lot of Frontend-local interactions that are NOT driven by the Backend via Hotwire. Frontend Ruby removes the need to use JavaScript in those situations and provides an exponential jump in productivity as it cuts down software time-to-release, development cost, and implementation code by half with the language we all love, Ruby, albeit producing much more readable and maintainable code than even the best JavaScript code out there. That saves 6 months of Frontend Development work a year, which is a huge saving that makes and breaks startups and provides a unique competitive advantage to mid/large companies.

In this workshop, attendees will learn how to build Rails SPAs (Single Page Applications) in Frontend Opal Ruby (Fukuoka Ruby 2023 Award Winning Ruby-to-JavaScript Transpiler) with Glimmer DSL for Web. The workshop will walk attendees through writing examples that solve bigger and bigger problems while covering Glimmer DSL for Web features, such as:

  • Ruby HTML DSL
  • Ruby CSS DSL (optional or to be used in a hybrid fashion with standard CSS/SCSS/Tailwind when Ruby logic is needed)
  • Glimmer Web Components
  • Component Slots
  • Component Custom Event Listeners
  • ERB embedding glimmer_component Rails helper
  • Element Property Unidirectional/Bidirectional Data-Binding
  • Element Content Data-Binding
  • Element Inline Style Data-Binding
  • Element Class Inclusion Data-Binding
  • html_to_glimmer/css_to_glimmer commands for converting legacy HTML/CSS code to Glimmer DSL Ruby code
  • HTTP REST API Web Requests
  • JavaScript library integration.
Bio:

Andy Maleh has won a Fukuoka Prefecture Future IT Initiative 2025 Award for his open-source gem Glimmer DSL for Web and a Fukuoka Ruby 2022 Special Award for his open-source gem Glimmer DSL for LibUI after his gems were judged by Matz, the creator of Ruby. He has spoken at RailsConf (2012/2014), RubyConf (2008/2022/2023/2024), MountainWest RubyConf 2011, MagicRuby 2011, and AgileConf 2008. Andy is currently a Senior Full Stack Engineer at Eltropy Canada. He has an M.S. in Software Engineering from DePaul University, Chicago, and a B.S. in Computer Science from McGill University, Montreal. In his free time, he drums in a rock band, snowboards, curls, plays Softball, and watches Red Sox/Canadiens/Alouettes/Warriors sports games.

Sunday, March 15, 2026

Glimmer DSL for Web 0.8.2 HTML Value-less Boolean Attributes

Glimmer DSL for Web (Fukuoka Award Winning Ruby-in-the-Browser Frontend Framework for Rails) had a new release in version 0.8.2, which now supports HTML Value-less Boolean Attributes, simplifying the Ruby HTML DSL when using HTML boolean attributes like 'required', 'autofocus', and 'disabled'. There is no need to pass them in a hash with value true anymore. They could now be just passed as Ruby Symbols in HTML element arguments, ahead of hash attributes.

For example, instead of writing this:

input(type: 'text', id: 'name-field', required: true, autofocus: true)

You can now write this instead:

input(:required, :autofocus, type: 'text', id: 'name-field')

That would generate the following HTML upon rendering a Glimmer component:

<input type="text" id="name-field" required autofocus>

Happy Glimmering!

P.S. Glimmer DSL for Web will be presented at the following conferences in 2026:

  • APRIL 17, 2026 3-hour Workshop: "Building Rails SPAs in Frontend Ruby with Glimmer DSL for Web" at the wroclove.rb 2026 Ruby Conference, in Wroclaw, Poland
  • MAY 30, 2026 Talk: "Frontend Ruby on Rails with Glimmer DSL for Web" at RubyConf Austria 2026, in Vienna, Austria

Thursday, December 25, 2025

Friday, December 19, 2025

Recommended Plan for Migrating from React.js To Opal Ruby & Glimmer DSL for Web

In a recent team retrospective meeting at my job, 5 team devs (all) voted for the future plan item "More use of Opal Ruby & Glimmer DSL for Web in the Rails Web App Frontend". 

We are following a gradual rollout plan for migrating our React.js Frontend to Opal Ruby & Glimmer DSL for Web inside our Fintech Ruby on Rails web application:

  • Step 1: Use Opal/Glimmer in new Admin UI features
  • Step 2: Use Opal/Glimmer in new Manager UI features
  • Step 3: Use Opal/Glimmer in new Customer UI features
  • Step 4: Rewrite all legacy React components with Glimmer DSL for Web (either whenever touching legacy React components to make fixes/changes or in an incremental planned fashion that can be spaced out over a period of time with other business priorities taking precedence)

The plan could be adjusted to have as many steps as your web application has user roles with their own groups of webpages that they use, expanding gradually from migrating the least used webpages (lowest risk) to migrating the most used webpages (highest risk).

Step 1 in the process, using Glimmer DSL for Web in the Admin UI, was a success! So, the aforementioned retrospective item was about progressing further into Step 2 in 2026.

Glimmer improved performance in one re-written React page by 33% while cutting its code overall by about ~50% (and the component code became 1/10 what it was given there is no state management code in Glimmer components). 

One other 32-line Glimmer component was reused on 7 Admin UI pages very effectively and its performance of rendering was instant (aka fast enough). 

Also, when a relatively new Software Engineer on the team used Glimmer DSL for Web for the first time, he was able to complete his work in less than a week with much less code than what React.js would have needed, and with much better readability and maintainability. I was really impressed by the work of that Software Engineer in Opal Ruby & Glimmer DSL for Web

Eventually, that same developer ended up building another Admin UI feature in Glimmer DSL for Web, and his code was pure poetry! Such small components that don't exceed 43 lines of code.

Part of the reason why Step 4 is recommended at the end of the migration plan is because it is much cheaper to maintain Glimmer Ruby code compared to React JavaScript code. Also, I noticed that I could rewrite a very complicated React.js component that probably took a week or multiple weeks to build in only about 1-2 days tops in Glimmer Ruby code, and the overall code gets cut by about half. In other words, it is faster and cheaper to rewrite React components in Glimmer than to maintain them as they are when making fixes and changes. We literally feel like we're flying in Glimmer compared to moving like a slug in React.

This is the true state of the art in Ruby on Rails Frontend Development in 2025 (not silly Inertia that thinks inside the box of JavaScript by enabling more of the same garbage code in React.js/inferior-JavaScript-frameworks).

The future of Frontend Development in Ruby on Rails is very bright!!! I can't wait for what 2026 will bring!

I'm finally ready for the post-DHH Rails era! Are you!?!

The other day I chatted with someone from 37Signals. He didn't even tell me "Congratulations" for winning the Fukuoka Prefecture Future IT Initiative 2025 award for Glimmer DSL for Web when I mentioned it as a Ruby accomplishment. I mean any normal person would say "Congrats", let alone Ruby devs who should find any Ruby accomplishments infinitely interesting. That was not nice whatsoever, and frankly very creepy and weird. 

This proves my point once again about the Ruby on Rails community not being nice anymore and having become corrupt from the top. Both 37Signals and Shopify have become garbage in recent years. DHH is a terrible leader. I supported him a lot in the last 10 years, defending Rails whenever possible, but given that I know now he hires trash at his company, which doesn't support my award-winning highly useful open-source projects or other highly useful tools like Opal out of a sense of community, I think I'm finally done with supporting DHH. I don't appreciate the unequal relationship in which I support DHH and Rails folks, but they don't support me back. I'm finally ready for the post-DHH Rails era!

I mean 2025 was such an ugly year for the Ruby on Rails community and DHH. It hosted the last RailsConf due to issues between RailsConf and DHH. It had a huge conflict between Mike Perham and DHH that removed Sidekiq's financial support for Ruby Central. Shopify showed its true colors when it did a hostile take over of Ruby Central's RubyGems and Bundler (which fortunately later got moved under the purview of the Ruby core committers team, including Matz, the creator of Ruby). Ruby Conferences rejected my Matz-award-winning open-source Ruby Frontend project that saves developers 6 months of Frontend work every year over JavaScript, and allowed JavaScript in instead, believe it or not! And, Ruby/Rails subreddit members demonstrated over and over again mean unintelligent behavior, false privilege entitlement without qualifications, and closed-mindedness/standing-in-the-way-of-progress by downvoting novel posts to zero without even discussing them while sharing very nasty comments that ignored wrongdoing and clearly took sides just for 100% tribal bias reasons instead of thinking of everyone as an equal accountable for equal standards while being equally fallible, thus required to apologize for any committed mistakes instead of sweeping them under the rug. These things prove 100% that the Ruby on Rails community isn't nice anymore as per MINASWAN (Matz Is Nice And So We Are Nice). That is no longer arguable.

Not being truly nice goes hand in hand with stupidity. Nicer people collaborate better with others, so they end up with better information exchange and better work overall. No wonder the Ruby community has gone down the drain in recent years given that discrimination and unniceness have been normalized. Don't be deceived by discriminatory niceness, which is given to some people only but not to everyone equally. Some think the community is still nice because they're treated nicely without paying attention and noticing that niceness is offered to them as preferential treatment that is masking the problem. 

I would say that it's definitely the Rails subcommunity of the Ruby community that has the very big problems of unniceness and discrimination. The Ruby community outside of Rails is a lot nicer as it doesn't include companies like 37Signals and Shopify, and has devs who use Ruby with GUI Desktop Development, Opal, and TUI Development. Unfortunately, this fact gets lost sometimes because the Rails subcommunity is the loudest in the Ruby community and it gives the Ruby community a bad name.

Wednesday, December 17, 2025

Frontend Ruby on Rails with Glimmer DSL for Web (accepted at RubyConf Austria 2026)

My talk "Frontend Ruby on Rails with Glimmer DSL for Web" has been accepted at RubyConf Austria 2026.

Title:

Frontend Ruby on Rails with Glimmer DSL for Web

Elevator Pitch [FOR JUDGES]:

Glimmer DSL for Web is a Ruby Frontend Framework for Rails that won a Fukuoka Prefecture Future IT Initiative 2025 award from Matz. It is the missing piece of the puzzle that finally enables devs to write the Frontend of Rails web apps in Ruby too. This talk will cover its features and demo samples.

Description [PUBLIC]:

Glimmer DSL for Web is an SPA (Single Page Application) Framework for Rails that runs in Opal Ruby and has won a Fukuoka Prefecture Future IT Initiative 2025 award from Matz, the creator of Ruby. It provides a paradigm shift and the next stage of evolution in Frontend Development beyond JS libraries like Angular/Ember/React/Vue/Svelte by cutting down 12 months of JS work into 6 months of Ruby work every year. It has a more intuitive development model than Hotwire that better adheres to Software Engineering principles, albeit Hotwire has its place, and Glimmer can be used once Stimulus controllers grow too large or the need arises for using a Frontend SPA Framework.

It is currently in use at Eltropy inside the Collections 2.0 Fintech Rails web app as a gradual upgrade from React.js. It was able to cut down some React components by 1/10 the code and overall Frontend code by about ~50%, albeit with significantly more readable and maintainable Ruby, the language we all love. As a result, Glimmer DSL for Web should become the biggest difference maker and game changer in Rails development productivity in 2026, completely eliminating the need for directly using inferior JS libraries like React because Opal Ruby supports indirectly using any library in the entire JS ecosystem from Ruby.

Glimmer DSL for Web provides a Ruby HTML DSL, a Ruby CSS DSL (optional or to be used in a hybrid fashion with standard CSS/SCSS/Tailwind when Ruby logic is needed), Glimmer Web Components, Component Slots, Component Custom Event Listeners, ERB embedding glimmer_component Rails helper, Element Property Unidirectional/Bidirectional Data-Binding, Element Content Data-Binding, Element Inline Style Data-Binding, Element Class Inclusion Data-Binding, html_to_glimmer/css_to_glimmer commands for converting legacy HTML/CSS code to Glimmer DSL Ruby code, HTTP REST API Web Requests, and JavaScript library integration.

Using an isomorphic one language approach for both the Frontend and Backend in Rails web apps not only achieves significant productivity and maintainability improvements, but also opens the door to new possibilities, like the ability to reuse Backend Ruby logic directly in the Frontend without making API calls to provide faster response times for users, extending the Rails’ One Person Framework approach by enabling Backend Ruby Software Engineers to handle Frontend work in the same language (cutting hiring costs down by half), and enabling future architectural improvements such as connecting Frontend Ruby Models to Backend Ruby Models by automatically generating Rails REST APIs, thus removing the need for developers to write Rails controllers manually anymore, which would then cut down work in the Backend in addition to cutting down work in the Frontend, providing unheard of productivity benefits in Rails in the future.

Bio [FOR JUDGES] (including why I am the best person to give the talk):

The reason I am the best person to speak about this subject is that I wrote the Glimmer DSL for Web open-source project (glimmer-dsl-web Ruby gem) starting around 2024 and won the international Fukuoka Prefecture Future IT Initiative 2025 award for it in January of 2025 from Matz and other Fukuoka judges. I have spoken at RubyConf (2008/2022/2023/2024), RailsConf (2012/2014), MountainWest RubyConf 2011, MagicRuby 2011, and AgileConf 2008. I am the organizer of the monthly Montreal.rb Ruby Meetup in Montreal, Canada. I have a Master’s Degree in Software Engineering from DePaul University, Chicago, USA and a Bachelor’s Degree in Computer Science from McGill University, Montreal, Canada. I have 23 years of Software Engineering professional experience and 20 years of Ruby/Rails experience.

Tuesday, December 02, 2025

The Embarrassing Ruby/Rails Subreddit Chronicles 2025-12-02

Welcome to another edition of the Embarrassing Ruby/Rails Subreddit Chronicles! A post was shared in the Rails subreddit about DHH claiming that money is a good reason to cheer for Shopify. I simply stated that no amount of money justifies mean discrimination, and I immediately got downvoted to 0. That proves yet again that there are devs in the Rails subreddit who are OK with mean discrimination if a certain amount of money is made and the subreddit mods are OK with mean discrimination by extension by allowing them into the group. 


Yet another embarrassment for the Ruby on Rails community as it officially admits the belief that mean discrimination is OK if a certain amount of money is gained, throwing MINASWAN out of the window instead of behaving in the ethical and nice Ruby way! This is the truth of the Ruby on Rails community in 2025!

Thursday, November 27, 2025

How did the Ruby community go from Great to Garbage?

Only 10 years ago, the Ruby community was great! It was a highly innovative and outside-the-box thinking community that explored ideas independently from the rest of the Software Engineering industry, often innovating novel open-source projects not possible in any languages other than Ruby. Also generally, I was treated with dignity and respect in the Ruby community, and it was the common default that Rubyists would support me in whatever new ideas I explored in Ruby open-source projects. 

So, how did the Ruby community go from great to garbage!?!!

- Many devs entered the Ruby community unethically just for the money or "cool" association factor, cheating clients by not offering them the best Software Engineering work possible in Ruby/Rails.

- Many Rubyists were pushovers that were easy to influence and manipulate by inferior non-Rubyists and fake or unethical Rubyists due to lazy complacency and lacking a backbone to say no when needed. Such Rubyists were often too afraid to address the big elephant in the room.

- The Ruby community has become mean by practicing covert discrimination and open discrimination against certain members of the community that are not deemed part of the "cool crowd" even if they had 100% merit, ethical conduct, great education, smart open-source projects, excellent accomplishments, and valid novel Ruby ideas. This kind of behavior started mostly at companies like Shopify when Shopify started becoming big and evil, and then eventually spread through the rest of the Ruby community. DHH and some members of 37Signals seem to more recently practice that sort of mean behavior and covert discrimination as well.

- Many Rubyists had a selfish attitude of "if this discrimination/hate/meanness doesn't affect me directly, then I don't really care about it even if it affects others! I just care about what I'm getting out of the community!", without caring to realize that some of what they are getting out of the community is coming from pushing some community members down, meaning stolen goods. I've even encountered Ruby/Rails subreddit mods and public speakers who didn't care whatsoever about the discrimination happening in the community by large Ruby shops like Shopify, just because they had friendships with some of the people at Shopify. They didn't even bother to investigate the discrimination or at least show sympathy and ask more about it. I mean if my friends practiced discrimination, they wouldn't be my friends anymore, and I would definitely investigate if they did practice discrimination. This just goes to show that some Ruby/Rails subreddit mods and public speakers are unethical awful people who are part of the problem, not the solution.

- Some leaders of the Ruby/Rails community like DHH simp to non-Rubyists like JavaScript devs while desperately seeking their approval, which doesn't make sense given that their technologies are inferior to Ruby. Instead, such bad leaders should be leading non-Rubyists towards better ways of Software Development using Ruby when Ruby offers the best possible potential solutions in certain areas of Software Development. It doesn't hurt to learn other technologies too, but when it's obvious a technology like JavaScript is inferior to Ruby, using JavaScript would not be using the best potential tool for the job, so it would be unintelligent to desperately seek the approval of its users instead of leading them towards better Software Development approaches in Ruby.

- Some Rubyists have a "my way or the highway" attitude and insist on using one "golden hammer" for all problems. Like, DHH believing everything must be handled by Hotwire and a Monolith instead of having the correct Software Engineering attitude of having many tools in the tool belt to address a spectrum of problems and using the right tool for the job depending on each client's situation and requirements. Devs who believe Hotwire solves everything are just as bad as devs who believe React solves everything. They're not any different or better as they close the door on any potential other innovations that could rival both solutions.

- Ruby/Rails subreddit mods tolerate hate, mistreatment, and unkind behavior towards well-accomplished Rubyists in the Ruby community who have much better ethics and much better accomplishments in the Ruby community than the unethical hateful devs who mistreat them. They also allow in devs who don't pass the minimum bar of respectful conduct for being hired at any respectable business, which makes no sense. Lastly, the subreddit mods practice discrimination against certain members of the Ruby community, treating them as if it doesn't matter at all whether they receive mistreatment, discrimination, or hate. That paints the mods as hypocrites and discredits all their words about stopping hate. If you discriminate in who you stop hate for, you are practicing discrimination and hate, and everything you say about stopping hate is a lie and doesn't have any weight anymore. 

- Some Rubyists betrayed the Ruby community by giving the false privilege of being considered Rubyists to unethical unqualified unintelligent devs who hate Ruby in certain parts of Software Development and don't pass the minimum bar of respectable conduct for hiring even though they don't really get Ruby and actually hate it in certain areas of Software Development while preferring extremely contradictory and dumb inferior technologies to it like React.js. They also betrayed customers who receive 1/2 or 1/4 of the business value they pay for due to Rubyists using React.js and other inferior technologies instead of using Ruby.

- Many Ruby/Rails conferences discriminate against certain topics in Ruby. For example, they reject all talks relating to Frontend Ruby no matter how qualified/upstanding the speaker is, how well-rehearsed the talk is when already given in local Ruby meetups, and how useful the technology is when already in use at a business. Also, some of their organizers are not upfront and humble about the fact they are less qualified in Ruby Software Engineering skills than the speakers they are judging, meaning they either shouldn't be in their position and allow someone better to judge talks or they should accept the expertise of more competent Ruby Software Engineers and accept their interesting novel talks without discrimination. What's most embarrassing is I have encountered some judges at Ruby conferences who were "hurt" by the fact that a Frontend Ruby technology is unseating React.js or some other JS/non-Ruby technology they are strongly attached to, demonstrating they are fake Rubyists and fake Software Engineers who don't put customers first along with the benefits they might receive from superior Ruby technologies, aren't committed to Ruby, and don't really get Ruby's benefits, yet are just shams/frauds that shouldn't be presiding over any conference. 

- Many Rubyists have lack of humility and honesty, especially regarding admitting lack of skills, lack of experience, and/or lack of qualifications in Ruby as to address that effectively. They bluff their way through the Software Engineering industry by mindlessly repeating "intelligent-sounding words" they heard from big names in the industry without truly understanding them, which might trick the untrained eye and gullible Rubyists, but is seen for what it is from a mile away by all competent Rubyists. Some Ruby/Rails subreddit members who have no degrees, no work accomplishments, no open-source projects, no conference presentations, and no ethical conduct act as if they're the gods of Ruby/Rails, which is very laughable.

- Many Rubyists don't respect the excellent accomplishments of more accomplished and/or more senior Software Engineers (sometimes out of unconscious or conscious discrimination). When a Rubyist doesn't respect excellence, that immediately tells everyone that they are NOT excellent. After all, excellent people always appreciate excellence in others, including excellent accomplishments.

- Many Rubyists lack skill in general Software Engineering principles and best practices, often doing Software Development in a Monkey-See-Monkey-Do fashion by following big names in the industry without thinking for themselves. And, they lack Software Engineering curiosity and interest in exploring Ruby in unexplored areas or learning more about outside-the-box novel Ruby open-source projects. More often than not, this is a side effect to not having any university degrees in computing, and instead having very shallow knowledge from reading a few books or going through an insufficient short bootcamp. 

- Many Rubyists do not match their words with actions and often make lame excuses instead of taking responsibility. Some will make a million excuses for not wanting to check out a new novel Ruby open-source project even if it only takes 10 minutes to an hour to check it out and the project won an award and is in successful use in production at a business. Sometimes, this happens out of unconscious or conscious discrimination. Either way, it's bad. It's known that anyone who makes excuses is incompetent by definition. No great accomplishments ever happened through excuses.

- Many Rubyists are unsupportive towards open-source project authors that implement highly novel outside-the-box disruptive ideas either due to closed-mindedness or due to being too attached to older less effective technologies, including ones in other languages, like React.js, instead of correctly being attached to serving customers in the best way possible above all else.


Thursday, October 09, 2025

The Embarrassing Ruby/Rails Subreddit Chronicles 2025-10-09

I have covered multiple times the mean discriminatory ways Ruby/Rails subreddit members treat some Rubyists, which started happening only in the last 10 years. Now, I will be regularly sharing examples of that for everyone to see to increase the level of awareness of the un-Ruby-community-like meanness, lack of sympathy, lying, and discrimination that Ruby/Rails subreddit members practice and moderators tolerate to the detriment of the Ruby on Rails community. Eventually, if the problem is not corrected, I will be talking about this problem at Ruby meetups and conferences to increase awareness of this big elephant in the room that isn't being addressed. It is basically a double standard that excludes some people like me from participating safely in the Ruby/Rails subreddits while the Subreddit members are nice to others they deem "in their clique" or "tribe". That's exactly what discrimination is, let alone, it's not nice as per the MINASWAN Ruby principle (Matz Is Nice And So We Are Nice). Also, the argument that nobody forced me to join those groups is akin to telling someone who went into a bar and got stabbed that nobody forced them to go into the bar instead of correctly sympathizing with them and reporting the bad behavior to the authorities, potentially closing the bar permanently if it doesn't reform in its treatment of clients who enter it.

Before sharing examples, here are some of my previous posts about the topic:

I am very confident secure person and have thick skin, so I can freely share the interactions without being anxious about others' opinions.

As a first example, 10 months ago, I shared an article about "How To Spot Covert Discrimination in the Ruby Community", and I got downvoted to 0 in both the Ruby subreddit and Rails subreddit (probably got a very large negative number in both subreddits as Reddit doesn't show the real number when it's negative anymore I believe).


We all know that downvoting an article that speaks against discrimination means all the downvoters are discriminators (assuming what is shared is truthful). Meaning, this downvoting unwittingly confirmed 100% that the Ruby/Rails downvoters are discriminators.

Even if there might be some disagreement with what is written, the nice Ruby way to express that is by refraining from downvoting and having a conversation in a sympathetic, serious, and patient way (that's how things happened 10 years ago and before). It is very weird that Ruby/Rails subreddit members don't act that way, but it is possible they are indirectly benefiting from the discrimination that is happening in the Ruby community as that discrimination frees up jobs for them that they are not most qualified for, which enables them to steal those jobs at the expense of pushing defenseless members of the Ruby community down with bullying and discrimination. But, how come no leaders in the Ruby community are commenting about this mean behavior when in fact it is not normal whatsoever?!! Could it be that they are indirectly benefiting financially somehow from this discrimination too by taming the competition of Ruby developers indirectly? 

As a second example, I will share a very recent interaction that demonstrates total lack of sympathy by a Ruby subreddit member with the fact that I got discriminated against by a certain Ruby shop. And, the subreddit member ended up embarrassing themselves further by defending embarrassing lack of support for a local Ruby community by a well-funded Ruby shop that claims to be a "big supporter of Ruby", which is obviously a lie if actions don't match their words or if they discriminate against some members in the Ruby community in their support. Of course, defending mediocrity indicates mediocrity in the defender, which is why they embarrassed themselves further with the defense, let alone they told everyone they have no manners and aren't nice members of the Ruby community. One more thing that is also embarrassing about the interaction is that I am sure the commenter fits the profile of the post above "Entitled/Incompetent/Mean Members of Ruby/Rails Subreddits", meaning it's an unqualified person with entitlement issues that make them act in a mean way as if they're a god instead of being humble and sympathetic.

If a normal person was told by somebody that some other person suffered from discrimination, they would assume a serious sympathetic attitude and ask what happened to see if they could help. Any other reaction, like making fun of the person or being sarcastic with them, immediately reveals that the listener isn't a normal loving person, yet a person who is mean, unloving, a discriminator by extension through endorsement of discrimination, and probably someone indirectly benefiting from the discrimination to defend it. Even if the reporter of the discrimination was wrong in misinterpreting some behavior as discrimination, the right reaction would be to at least show concern and ask questions or explain in a calm rational manner any misunderstandings without joking about a topic like discrimination. That Ruby subreddit member's reaction was totally unacceptable and inappropriate as part of the nice Ruby decorum.

Here is the interaction:



Here is the link shared in my Reddit comment to learn more about what it says: https://andymaleh.blogspot.com/2025/06/shopify-has-been-bad-for-ruby-community.html

The bottom line is that this person's interaction made the Ruby community worse not better overall. Offering sympathy or at least a listening ear to a person who suffered discrimination would have made the Ruby community better overall regardless of whether the discrimination took place or was a false perception that needed a patient gentle correction.

Not sympathizing with discrimination while affirming lack of support for members of the Ruby community means the commenter is by extension a mean discriminator who does not support the Ruby community nor kindly sympathizes with people who are mistreated, meaning a manner-less trash person. Also, by simple logical deduction, upvoting that comment indicates that all the upvoters are mean discriminators who do not support the Ruby community nor kindly sympathize with people who are mistreated equally, meaning manner-less trash people.

This demonstrates how ugly the Ruby on Rails community has become, especially with people in it enabling this kind of behavior and not doing the right things to discourage it, while conducting that with double standards, meaning they sometimes defend some members of the Ruby community from this sort of behavior, but also allow this behavior to go unchecked against other members of the community. Having double-standards is the very definition of discrimination.

I will start sharing more and more of those interactions to expose the unnice ways of Ruby/Rails subreddit members to the maintainers and contributors of Ruby, Rails, and other high-profile Ruby projects. It is important for everyone to become aware of this problem to eventually resolve it.



Saturday, September 27, 2025

It's Official! The Bullies Are Running The Ruby Community!

Update 2025-10-24: Since this article has been written, new development has happened that led to the Ruby core team officially taking over RubyGems and Bundler, so fortunately, the hostile takeover by Shopify has been corrected and Ruby devs won everywhere as a result!!!

After reading Joel Drapper's article "Shopify, pulling strings at Ruby Central, forces Bundler and RubyGems takeover" and Josef Simanek's article "Why I leave Ruby Central", there is no doubt left in the fact that Shopify is a mean opportunistic company and isn't good for the Ruby community. They intentionally compromised the neutrality of RubyGems and Bundler for their own commercial interests. Meaning, they don't have the best interests of the Ruby community and customers in mind aside from profit, yet only their own self interests that are ultimately about their own profit. That fully compromised RubyGems and Bundler as being non-profit neutral platforms not associated directly with any company's commercial interests.

Just like that, the false image of Shopify as a nice entity in the Ruby community is completely shattered and exposed for the illusion it always was! Shopify does in no way follow the Ruby MINASWAN attitude and practice (Matz Is Nice And So We Are Nice)!

I already blogged about how Shopify has been bad for the Ruby community in the article "Shopify Has Been Bad for the Ruby Community in the Last 10 Years". The events of last week support everything I wrote as true. I haven't received any apologies from Shopify about what I wrote even though it is all 100% true. Everybody makes mistakes, but good people humbly own up and apologize when they realize their mistakes whereas bad people neither humbly own up nor apologize for their mistakes. 

A wronged person would at least expect something like "Hey, sorry! We messed up! We don't do this anymore as we learned from our past mistakes (or we fired whoever did this). Let's have a chat to make sure we're good going forward!". Not receiving communication as basic as that means the company is truly evil. If I was working at Shopify right now and I read a story like this, I'd immediately dust up my resume to go find another job. After all, everyone who works at Shopify right now is working at the expense of pushing people like me down by Shopify's mean elitist discriminatory practices. It's like someone living at a house that was paid for by stealing from a percentage of people in their community. It's not right at all! 

That's part of the reason why I was surprised DHH recently joined Shopify's board of directors. That indicts him further as part of the problem, not the solution. I have observed that companies that have evil discriminatory practices like Shopify's are almost always 1000+ employee companies as they treat people like numbers by the definition of them being too large. After all, their size, which is mainly driven by the greed for too much profit, makes it impractical for everybody to know everybody and treat everybody like an equal, let alone they have fake problems caused mostly by their size, preventing them from being truly agile like small-to-mid-size companies. DHH's 37Signals is a small company that should have a much better culture, so it's surprising that he chose to join the board of directors of one of those big corrupt evil companies that are totally unlike his.

In summary, it's official! The bullies are running the Ruby Community today! And, it's been having terrible effects on the Ruby community as a whole, especially innovation in Ruby. I recently recorded a video of myself talking about how "Ruby on Rails Conferences Are Discriminatory, Unintelligent, and Hateful of Ruby in 2025". This is a direct result of the bullies running the Ruby community!!!

In fact, I have suffered quite a bit from this covert bullying in the Ruby community in previous jobs, and have written an article about "How To Spot Covert Discrimination in the Ruby Community".

I had a hard time talking about the bullying in the Ruby community in the past because I really needed to keep my job for financial reasons, and I didn't want to lose my job by talking about the discrimination I was facing at various companies I worked at as well as in the interview process of companies I was considering. Fortunately, I have a good job now, and I am not worried anymore about talking about all the discrimination I received from past companies in past jobs. 

If you have faced bullying in the Ruby community at a previous job, please speak up about it for the benefit of everyone who is oppressed by unethical Ruby companies. Don't do it just for yourself, but for the benefit of the tens, hundreds, or thousands of employees that are potentially being bullied at bad Ruby companies today. After all, speaking up about this problem is the only way to expose it and then eventually eliminate it and prevent it. I know it is very hard to speak up about this problem, but every voice that gets added in opposition of bullying helps prevent further bullying in the future.

Thursday, September 18, 2025

Ruby on Rails Conferences Are Discriminatory, Unintelligent, and Hateful of Ruby in 2025


I think I might have finally figured out why Ruby on Rails 2025 conferences rejected my talk proposals for my open-source project Glimmer DSL for Web that won a 2025 Fukuoka award from Matz (the creator of Ruby) even though the library provides a 100% innovative and useful tool, is used at my job, has no competition by any other open-source projects, is Matz-approved, and I am the most qualified person to give a talk that unique and interesting due to being the creator, a multi-time RailsConf/RubyConf speaker, and an award winner (meaning, the excuse of other talks winning over doesn't really apply here as they're all inferior if they don't cover a topic that is as innovative and aren't given by someone as qualified as I am due to winning an award by Matz).

I noticed in the past that some Ruby on Rails conference websites were built using React and kinda sucked because they didn't have bookmarkable URLs for when the user clicked on a talk to expand it and read it, preventing users from being able to share direct talk links with others. So, the devs presiding over the conferences were probably insulted by my talk saying that using Glimmer results in writing much less Frontend code as to be able to do 12 months of JS Frontend work in 6 months in much more readable Ruby because they've drank the React koolaid, are biased, and would hate to stop using React no matter how inferior it is to using a Ruby Frontend Framework. In other words, they're devs who are insecure, standing in the way of progress and innovation, attached to inferior technologies for emotional reasons not rational reasons, and hate Ruby, so would rather side with React's folks against real Rubyists to the point of discriminating against me by rejecting my 100% qualified and unique talk that had zero competition. 

Honestly, that auto-disqualifies those conferences from being ones that I'd like to speak at due to being run by unintelligent biased haters of Ruby who don't respect accomplishments like winning an international competition with an open-source project by the creator of the Ruby language himself, meaning they discourage innovation and encourage devs to either use outdated tech like JavaScript and React (Inertia is just inside-the-box unimaginative lipstick on a pig and Glimmer DSL for Web already bridges the gap to all JS libraries via Opal) or follow the hero worship anti-pattern by only allowing DHH to "innovate" with Turbo without anyone else in the community being accepted for their innovative idea contributions (a form of discrimination). So, it wasn't a loss for me not to present as I'd be embarrassed to speak at one of those inferior conferences like RailsConf that are now run by unintelligent haters of Ruby in 2025. In fact, I am already embarrassed I spoke at RailsConf twice in the past given how anti-innovation, unintelligent, and downright discriminatory RailsConf has become. But, it is a loss for attendees of those conferences to miss out on a tool that lets them cut down development time and code by half in the Frontend of Rails apps when Turbo isn't cutting it anymore, meaning the selfishness in being biased towards React and JavaScript against Ruby is literally robbing all devs and customers of months of saved costs and time in Frontend work. 

Obviously, the Ruby community has a cancer that has invaded it through fake Ruby shops that claim to like Ruby, but use React in the Frontend instead of Frontend Ruby (Frontend Ruby via Opal has been around for 10 years, so no Ruby shop has any excuses not to have adopted it as a standard even before I created my Frontend Framework, Glimmer DSL for Web, on top of it). A while ago, I saw a guy give a talk at a Ruby meetup about how much he liked using Ruby at his startup, but then he mentioned that his team used React in the Frontend, even though React's code and approach completely contradicts and goes against the Ruby way, resulting in very bad maintainability. When I told him and his team after the talk that they could use Ruby in the Frontend via Opal now, their eyes glazed over as if they didn't care for Ruby whatsoever, disproving 100% that they really liked Ruby and proving they were hypocrites that just used Ruby on Rails for the "cool association factor" (that's what they truly liked Ruby for), not for appreciating or understanding the benefits of Ruby. That's the story of 50% of Ruby shops in 2025. 

I have no choice but to conclude that those Rails conference rejections are 100% discrimination and exclusion given I am 100% qualified (I have spoken at the last 3 RubyConfs in a row), the topic is very important as it would save companies that do Frontend Development with JavaScript months of work every year, and no other speaker at all in any of those conferences has won a Fukuoka international technology competition award with a Ruby open-source project from Matz, meaning the excuse of "other talks won over" doesn't really apply unless there is discriminatory bias. I mean some of those conferences literally accepted JavaScript Frontend talks with Inertia and favored them over using Ruby even though  they are Ruby conferences believe it or not, and Ruby produces much more readable/maintainable/slim code than Inertia/React while cutting Frontend work by half and allowing the use of any JS library from Ruby (that's infinitely way more innovative than using Inertia), and yet those conferences claim to be "Ruby conferences" (obviously a lie nowadays)!!! 

While inferior tools like Inertia think inside-the-box, truly innovative tools like Glimmer DSL for Web in Rails-like fashion totally tear down the box and re-imagine Frontend Development in Ruby. Why did the once-forward-thinking Rails community become so backwards thinking about the Frontend Development story aside from Turbo in 2025? The talk that covered Inertia at RailsConf 2025 didn't even mention Opal Ruby as part of the Rails Frontend evolution at all, nor cover Ruby WASM and how it allows writing Frontend code in Ruby as an alternative to Opal. I personally covered both with a talk at my local Ruby meetup years ago now, proving I'm a more qualified speaker than the guy who mentioned Inertia in his Frontend talk at RailsConf 2025: https://www.youtube.com/watch?v=4AdcfbI6A4c . The RailsConf 2025 Frontend talk didn't highlight how Rails 6 broke its own Convention over Configuration principle by including a configuration heavy library like Webpack in Rails due to lack of intelligence in selecting Opal Ruby as a default instead. Had that happened, the Rails community would be 10 years ahead today, but it is in fact 10 years behind. Just because people aren't aware of that, that doesn't mean it's not true. Smart people think of what the highest potential that could have been achieved over the last 10 years had DHH didn't completely mess up and simp to the JS folks as a pushover instead of confidently sticking as a leader with the superior language he was already using in Rails, Ruby!

The Ruby on Rails community cancer of discrimination, bias, and hate of Ruby is very ugly in 2025. Conference organizers could put an end to the discrimination and incompetence by apologizing for their discriminatory treatment and guaranteeing a spot for me to speak at their conference next year if they want to make things right and prove that the Ruby community isn't run by discriminatory unintelligent biased haters of Ruby. Otherwise, RailsConf 2025 actually provided outdated, incomplete, and inaccurate information about the Frontend story in Rails that neglected a Fukuoka Prefecture Future IT Initiative 2025 Award Winning Ruby on Rails Frontend library (Glimmer DSL for Web), neglected Opal (won an award in 2023), and neglected Ruby WASM entirely! The Ruby on Rails community is worse for it, and more importantly, customers are paying double the fee for Rails Software Development and getting the Software in double the time as a result. RailsConf was a weak conference that degraded developers' skills. Still, everybody makes mistakes, but good people apologize when they are made aware of their mistakes, and they redeem themselves as a result. I do make mistakes and say sorry at work from time to time. I say sorry because if I don't, customers suffer like they're suffering today from terrible React/Inertia codebases. Devs not realizing that doesn't mean the codebases aren't terrible (the Dunning-Kruger effect) when the devs could have done half the work in half the time using Frontend Ruby and contributed to the betterment of Ruby in the Frontend as well. 

Honestly, saving 6 months of Frontend work a year via Frontend Ruby (vs doing 12 months of work in JavaScript) provides the biggest improvement to Rails shops in 2025, so this is actually the most important topic at any Ruby on Rails conference in 2025 as I am 100% sure that not a single other RailsConf 2025 talk provides that big a benefit to companies. 

Glimmer DSL for Web Component Attribute Listener & Component Attribute Data-Binding

Glimmer DSL for Web (Fukuoka Award Winning Frontend Framework for Ruby on Rails) versions 0.7.2 & 0.7.3 add new samples to demonstrate the newly added features of Component Attribute Listener and Component Attribute Data-Binding. So, not only could we listen to HTML element events like a select element's onchange event, but now, if you add any attribute to a component, it automatically supports having consumers listen to that attribute's updates by hooking into `on_attributename_update` by convention (this is the Rails Convention Over Configuration principle at play). Additionally, consumers could even automatically data-bind that attribute to a model attribute by using the typical Glimmer approach of <=> for bidirectional data-binding and <= for unidirectional data-binding.

Suppose we have an address type select box.

The address_type_select component code would be something like this:


Now, we can attach a listener to the selected_address_type component attribute without the developer of the component doing anything extra by writing this consumer code:

address_type_select(address_types: ['Home', 'Work', 'Other'], 
                    selected_address_type: 'Home') {
  on_selected_address_type_update do |selected_address_type|
    # Do something
  end
}

Alternatively, we could data-bind the component attribute to a model attribute:

address_type_select(address_types: ['Home', 'Work', 'Other']) {
  selected_address_type <=> [address_type_presenter, :selected_address_type]
}

That opens the door for building higher concepts with components and being able to listen to their attribute changes and data-bind them as if they are basic HTML elements.


New samples:

Happy Glimmering!

Friday, July 11, 2025

Glimmer Web Components (+ Championship Win & General Recipe for Success)

Before I get into the blog post's main subject, I'd like to mention that I recently won the 2024-2025 TGIF Curling League championship with my Curling team (Brooms Up) at the Royal Montreal Curling Club. I brought a championship trophy back home as a result. 

Team "Brooms Up" celebrating the championship win!

Andy Maleh (me) holding the TGIF League Curling Championship trophy (and a Hockey stick beer mug)!

Andy Maleh (me) tossing cheers with others at the Curling club!

It is interesting to note that I only learned the sport of Curling 2.5 years ago (though I've known it as a weird sport that shows up on TV for many years before). So, to win a league championship in Curling this soon (finishing as the 1st team in 14) is a testament to having been able to transfer my general recipe for success from Software Engineering into Sports! In fact, as a result of this recent success in Sports, I have spent the last 3 months learning a new sport that I have always loved, but never played much (I only did a couple of leagues in it over 20+ years) and never played well: Baseball. Hitting a ball in Baseball is known as the most difficult thing to do in sports! I have been very busy the last few months taking classes and participating in a summer league for the easy version of Baseball known as Softball. Yesterday, I caught my first fly out ever! A few weeks ago, I caught my first pop out ever! Before that, I was able to hit my first line drive ever! 

To summarize my "General Recipe for Success" (whether in Sports or Software Engineering):

  • Learn the basics from the experts by taking classes with them (including doing any assigned homework): In Sports, I simply took classes at a Curling club to learn Curling and classes at a Batting Cage / Softball / Baseball Store to get started with Softball. In Software Engineering, I did a 4-year Bachelor's degree in Computer Science and a 2-year Master's degree in Software Engineering.
  • Practice alone: In Curling, my alone practice happened by arriving early to games or booking practice sessions at the Curling club, and spending time practicing the Curling delivery stance and Curling shots. In Softball, my alone practice has been happening by arriving 45 minutes early to every game and spending that time practicing the batting stance and flow, batting with a batting tee, and throwing a Softball up vertically to practice catching pop ups at different locations. In Software Engineering, my alone practice happened by building open-source software projects while exploring interesting Software Engineering ideas that I wished existed, and by testing my learnings from my university education by building my own computer programs to satisfy some of my own needs (e.g. in college, I built a calculator that figured out when future level-ups would happen in an RPG video game based on experience points by looking at past level-ups).
  • Practice with others while humbly asking them for feedback and help: In Curling, I practiced with other people on my league Curling team by booking a Curling practice session together and having the team's "Skip" (best player on the team who plays the most difficult position) watch us and correct us while we tried various Curling shots and sweeping methods. In Softball, I practice with others by arriving early to games to play catch with others, practice fielding, and practice pitching and/or batting. I let experienced players watch my errors and correct them during practice, humbly accepting their feedback and deferring to their expertise. In Software Engineering, I practiced with others by collaborating with other people on open-source software projects, doing book clubs and experimenting with book learnings in code, and asking coworkers for feedback in code reviews while accepting correction and learning from it. In my early years as a Junior Software Developer, I asked experienced Developers to teach me practical principles in computer programming.
  • Watch the experts: In Curling, I watch every Curling competition on TV that I could think of (in Canada, it's the Grand Slam of Curling, which happens 5 times a year, the Brier's, which happens once a year, and the World Curling Championship) and I watch Curling games at my local Curling club played by other members. In Baseball, I watch every season's Major League Baseball games on TV (Let's Go Red Sox) and I sometimes watch Softball games in my Softball league that happen before my team's games or afterwards. In Software Engineering, I read open-source software code online and I read old legacy code written by experts at my company to learn from it. I also observe the features of various pieces of Software that I use, including paying attention to the usability and user experience.
  • Communicate and collaborate well with your team (including having retrospectives about team performance): As they say, Teamwork Makes the Dream Work! In Curling, our Skip (i.e. captain) gave us very clear instructions for what to do every game. Additionally, he discussed what went right and wrong after every game so that we would all learn from our mistakes and do better next time. In Softball, my team captain and 1st base / 3rd base coaches give us clear instructions of how to play every game. Moreover, after games are done, we have retrospectives about what went wrong and what could be improved by next game. In Software Engineering, my teams favour over-communication instead of stingy communication because saving a few seconds here and there could result in days, weeks, or months that are wasted due to miscommunication. Additionally, we hold regular retrospectives in which we discuss what went right and wrong since the last retrospective. And, we often hop into impromptu meetings when extra communication is needed to ensure better work on a problem.

Now, let's get into the main topic of the blog post. I would like to announce glimmer-web-component as a new Ruby gem that provides a collection of reusable Glimmer Web Components for Glimmer DSL for Web (Ruby on Rails Web Frontend Framework), which were extracted from real Rails web applications. Of course, they are fully customizable with component options and standard CSS/SCSS. 

Version 0.1.0 of the Ruby gem ships with the first Glimmer Web Component: Multi Checkbox Dropdown. It was extracted from my current work Rails web app at Eltropy Canada (formerly Lexop, which got acquired by Eltropy in 2025).

GitHub: https://github.com/AndyObtiva/glimmer-web-components 


Using the Multi Checkbox Dropdown is as easy as utilizing the Ruby keyword `multi_checkbox_dropdown` in the Ruby HTML DSL. At minimum, it takes a `values` keyword argument to figure out what options to display to the user.


Of course, to be able to do anything useful with the user selection, one would have to hook into the `on_change` listener, which takes a Ruby block that receives `selected_values`. 


But, it's even simpler to just rely on bidirectional data-binding. selected_values are automatically pre-populated from @some_presenter.status_filters and stored back on @some_presenter.status_filters upon user selection.


Finally, it is possible to customize the component with many options:


Below is the full list of options, which are defined in the `multi_checkbox_dropdown` Glimmer Web Component code:

Happy Glimmering!

Monday, June 23, 2025

Stupidity in the Ruby on Rails Community

Any environment that prevents people's freedom to call stupid people stupid is actually an environment that is full of stupid people who are all in denial about being stupid because they are living a lie if people cannot speak the truth.

Some people don't understand this. Calling someone stupid is only BAD if that person is NOT truthfully stupid. Calling someone stupid if they are TRUTHFULLY stupid is GOOD because it is pointing out a TRUTH that needs to be corrected so that the stupid person would stop being stupid and would start being smart for the benefit of clients and coworkers. In other words, calling stupid people STUPID is a LOVING act that aims to IMPROVE a situation. Preventing others from calling TRULY stupid people stupid is BAD and a HATEFUL act because it helps maintain a LIE and a NEGATIVE REALITY as a big elephant in the room that no one can discuss, thus enabling bad work performance for clients to persist forever. 

I thank people if they call me STUPID when I'm being TRUTHFULLY STUPID, and then I course-correct to improve my thinking, attitude, and behavior to be SMART. I don't push back. Only truly STUPID people who never become smart push back. Besides, if people who call me stupid are WRONG about me being stupid, I can ignore what they say because words have no power whatsoever if they're UNTRUE. Words only cut and hurt if they are TRUE and the person who received them is in DENIAL OF THE TRUTH. That's why I strive to ACCEPT THE TRUTH whenever possible, instead of living a lie, to ensure I am AS SMART AS POSSIBLE, which translates to better work performance for customers.

Of course, there are gentler ways of pointing out stupidity like by talking about a certain technology or solution not being the best solution to a problem, or by describing approaches as stupid, not people. But, when people keep ignoring that while pretending that whatever terrible popular technology they want to use is not stupid, that's when it becomes important to point out stupidity in a frank manner because people are literally insisting on stupidity and not being smart. That case makes it 100% OK to eventually call people stupid. For example, people in the Ruby community had more than 10 years (since the creation of Opal) to be able to figure out and unlock the benefits of Ruby in the Frontend, but they didn't. Gentler approaches of giving feedback obviously didn't work in those 10+ years as I've seen quite a few Opal talks in that time period, and yet they were ignored by the community, so now we can conclude many Ruby devs are truly stupid and we can point that out directly. They had their chance to be smart and they blew it. Now, it's better to point out the truth than to lie about it while customers continue to suffer from terrible productivity/maintainability in developing their software. 

My estimation is that about 75% of the Ruby community is stupid today. It's easy to tell just by looking at how may Ruby on Rails jobs include React (or some other non-Frontend-Ruby library) and by looking at how non-innovative RailsConf & RailsWorld talks were in 2024 as they didn't include a single talk about Frontend Ruby, which came across as extremely outdated, unimaginative, lame, and dumb. If you look at most Rails codebases today, they include a lot of garbage unreadable React code that totally contradicts the Ruby Way and Rails Way. Stimulus code isn't much better as it's still JavaScript. Of course, some people at the top of the Rails world like DHH, Shopify devs, Ruby/Rails Subreddit mods, and many Rails Podcasters have become extremely dumb too and indirectly encourage stupidity with their actions. It's sad, but true. Rails has become BIFI (By Idiots For Idiots) even though it had a promising start back in the day. That's mostly because the general Rails development model hasn't evolved much since Rails 3 due to not enough exploration of Frontend Ruby by the Rails team. 

The silver lining though is that more stupidity in the Ruby on Rails community means more free job security for the rest of us!!! Thank you stupid members of the Ruby on Rails community!!! Keep being stupid so the rest of us would easily thrive at your expense!!!

Wednesday, June 04, 2025

Shopify Has Been Bad for the Ruby Community in the Last 10 Years

Ever since I took over the Montreal.rb Ruby Meetup 3 years ago, Shopify, which has presence in Montreal (Quebec, Canada), hasn't volunteered a single Ruby/Rails talk nor bothered to contact me to just say Hi and check if I need sponsorship or anything to demonstrate they care about the local Ruby community. Other companies with far less resources have reached out to me to offer talks or sponsorship though, so Shopify has zero excuses here. Shopify lost a lot of merit points because of this. 

During the last RubyConf in 2024 (at which I presented), everyone at the conference was friendly towards me except a small group of Shopify people who I met at a social event on the 3rd day. After I said hello, and was introducing myself, one of them interrupted me to claim he knew me, but then didn’t show any interest in talking or getting to learn how I’m doing or how my RubyConf talk went (everybody else at the conference cared to ask me about that). He looked at the other Shopify folks as if they didn't want me talking to them, so I left thinking it was such a weird interaction. It's one thing if they were busy or had to catch a plane, and they informed me of that in a friendly manner, but the way they treated me as not an equal human being who can be talked to like everyone else at the conference was very discriminatory, and only Shopify folks did that. Nobody else at the entire conference treated me that way. I’ve met people from other famous Ruby shops like GitHub, 37Signals, and Cisco Meraki, and none of them acted that way at all. By the way, a shout out to Cisco Meraki's folks for being the friendliest Rubyists at RubyConf, not just in 2024, but in 2023 as well (at which I presented too)! The irony is Shopify folks act as if they're "above everyone" instead of equal to everyone else, and by acting like that, they end up beneath everyone in merit. 

Around 2013, I actually applied for a job at Shopify when they expanded to Montreal. Given that I had learned Rails from its birthplace, Chicago, and had worked for Groupon, which was larger than Shopify at the time, I thought it would be easy for me to pass the interview as I had passed tough technical interviews with other Rails companies without a problem around that time. The weird thing is during the interview, the Shopify point of contact didn't ask me any technical questions (I mean first interviews are supposed to be technical usually). He met me briefly at a coffeeshop while talking in a way as if he didn't want to be there, and then had me go up to their office to meet other developers on the team I was being interviewed for. I tried to get to know their developers in a friendly manner (the same way I got to know many devs in Chicago when I worked there as a Rails Agile consultant for 6 years before joining Groupon), but suddenly in the middle of my conversation with them, the tech lead asked me very rudely to stop wasting their time. Wait, what! I'm there for an interview, not to waste anyone's time. And, I have the right to interview them just as much as they have the right to interview me. Perhaps, they're the kind of bad company that thinks rushing work produces better work than actually taking the time to discuss things intelligently, I don't know. Or, perhaps, their staff members are all demented and unethical. The next thing I know is I was put in a room with their HR person, so I started excitedly talking about my Rails tech accomplishments, which were very unique (including presenting at RailsConf a year before), but for a very weird reason, he had this extreme apathetic face with lack of interest to hear about my Chicago Rails accomplishments even though I came from a better place in Rails than Montreal. I mean I am pretty sure I had better Rails tech experience than some of their employees at the time. The whole interview was super weird. After two weeks passed without hearing back from them, I called them up, and their HR guy claimed I wasn't that good and that they found a better person. Wait, what! You guys never tested my Rails tech skills! I was a Rails consultant in Chicago who helped coach many people on Ruby on Rails development! I learned Rails at its birthplace! I presented at RailsConf in addition to RubyConf! I am sure that was 100% discrimination against me. There is no other way to explain it. I mean, eventually, I won 2 Fukuoka awards from Matz, the creator of Ruby himself, and spoke 6 times at RailsConf/RubyConf, which confirms 100% that I am not only highly qualified, but also more qualified to work at Shopify than many of their employees who don't have half my accomplishments, let alone I am friendlier than their staff and don't behave in an elite/aloof way. So, again, there is no way I'd get rejected for a job there except because of discrimination. Discrimination is unacceptable. In my opinion, any company that even discriminates against one person on earth must be shut down by the government immediately until their bad practices are cleaned up completely. I actually wrote about the topic of discrimination in the Ruby community in this blog post

I have met ex-Shopify folks that seemed a lot more normal and friendly than current Shopify employees, confirming how there is darkness in Shopify that makes people adopt this mean elitest aloof attitude. It seems after people escape that weird unethical dark environment, they become well-adjusted better people. Some of the people that left Shopify told me that they left it because of weird or disrespectful interactions/practices happening there that drove them away.

Shopify betrayed the Ruby community by not investing their endless resources in building a Ruby based desktop code editor/IDE that would have advanced the Desktop Development story in Ruby, yet lazily defaulting to VSCode even though Ruby as a language could provide a much more productive and maintainable editor building experience than JavaScript. Shopify also betrayed Frontend Ruby options by lazily defaulting to React in the Frontend instead of investing their endless resources into Frontend Ruby, which would have provided leaps and bounds in productivity for everyone in the Ruby on Rails community by comparison. Shopify's actions demonstrate that they don’t really believe in Ruby as they don’t put money where their mouth is regarding Ruby in general outside of standard Rails. 

Additionally, Shopify spent a lot of resources optimizing Ruby when in fact Ruby might have not been the right tool for the job in places where performance optimization was needed as Ruby was already fast enough for its appropriate uses at countless other companies. Shopify could have invested in Crystal and improved integration between Ruby & Crystal in ways that made it a no brainer to upgrade Ruby code to Crystal code with types whenever performance optimization is needed given Crystal's code is so close to Ruby's (though some other open-source efforts helped make a flavour of that possible eventually).

Contrary to popular belief and general appearances, the Ruby community has actually degraded, not improved, since Shopify became big about 10 years ago. Gullible devs don't see that, but intelligent devs can see it as clear as day. Before then, Rubyists were very nice (MINASWAN), open-minded, and comfortable with novel unproven open-source projects, supporting countless innovative ideas in the Ruby community while keeping a friendly open dialog about the quirkiness of unproven ideas until proven. Nowadays, probably due to influence by bad examples of behavior that Shopify has inadvertently set for others to copy, Rubyists on Ruby/Rails subreddits meanly downvote any novel open-source ideas that are outside-the-box while openly preferring non-Ruby technologies to Ruby (e.g. React), and Rubyists in the real world often ignore interesting open-source projects without discussing why. I could totally understand it if Rubyists are pushing back because there are valid reasons for why an open-source project isn't a good idea. But, being aloof without being helpful comes across as just ignorant and mean anti-MINASWAN behavior that discourages and kills outside-the-box open-source ideas instead of encouraging them. Especially in cases where Ruby code does provide an astonishing improvement in productivity compared to alternatives in JavaScript or other languages.

In conclusion, Shopify is part of the problem not the solution in the Ruby community, contributing to the Ruby community becoming mean and anti-MINASWAN as reflected by the behaviour of Shopify people towards me. Companies with far less resources than Shopify have contributed talks to the Montreal.rb Ruby Meetup after it was rebooted by me and another organizer post-Covid-lockdowns, which is quite embarrassing to Shopify. In summary, the Ruby community was way better, friendlier, and more open-minded toward innovation before Shopify became a big thing. 

By the way, everybody makes mistakes. The difference between bad people and good people is that when bad people make mistakes, they don't own up nor apologize for them. When good people make mistakes, no matter how big, they are always humble enough to own up to error, apologize, and resolve to correct their mistakes. I don't mind it if I stand corrected by having Shopify folks reach out to me to show they care, tell me they think of me as equal to everyone else, agree I deserve to be treated nicely by everyone there, apologize for past unnice behaviour, propose Ruby talks for the Montreal.rb Ruby Meetup, inform me they are willing to support Ruby in Desktop Development and Frontend Development, and confirm they care about upholding MINASWAN in the Ruby community. I’d gladly apologize and remove my posts about them if that happens. Alas, if it doesn't happen, as they say, not making a move is a move. Just like in timed chess, not making a move can result in losing the game, the same thing would happen in real life if Shopify doesn't react at all as that would ding their merit very badly and confirm that I am right all along.

Tuesday, April 22, 2025

Montreal.rb April 2025 Domain Driven Design in Ruby on Rails

The video, slides, and repo for the Montreal.rb April 2025 talk "Domain Driven Design in Ruby on Rails" have been published!

YouTube Video:

https://www.youtube.com/watch?v=JlJLz2dJlhQ&list=PLRAf4zt5oEjc2mqmEN9m_O0JovQCXxvxt&index=17 

Presentation Slides: 

https://docs.google.com/presentation/d/e/2PACX-1vT91M7Aw715dVfewkEn_kcDBjDIBJPN7eB6PH0lEkH41EUFGiL5GANj2rFxIGPU68s4Lm-O8Ch5WHZv/pub?start=false&loop=false&delayms=60000&slide=id.p1

GitHub Repo:

https://docs.google.com/presentation/d/e/2PACX-1vT91M7Aw715dVfewkEn_kcDBjDIBJPN7eB6PH0lEkH41EUFGiL5GANj2rFxIGPU68s4Lm-O8Ch5WHZv/pub?start=false&loop=false&delayms=60000&slide=id.p1

Talk Description:

Software development is not just about translating business requirements into a static software design. It is about ensuring that in the long run, the system can evolve with the business needs and facilitate communication between business people and developers around the business domain in order to quickly and accurately add or modify features. This requires superb knowledge crunching and domain modeling skills.

Domain Driven Design is an approach that Eric Evans popularized in the mid 2000s to address these concerns. It is a process that centers design of software around the business domain.

This presentation will cover several of the topics and ideas in the Domain Driven Design approach (but not all topics of the book):

  • Domain Modeling
  • The Ubiquitous Language
  • Model Driven Design

Additionally, there will be a few code examples to illustrate some of the Domain Driven Design ideas as applied in a Ruby on Rails application.

Friday, March 28, 2025

2025 Reminder That DHH Is a Total Idiot!

Just a reminder that DHH is a total idiot for not adding any Frontend Ruby tech to the Rails stack in recent years. For the last 10 years, he's pretended to be "forward thinking" and "innovative", but has been closed-minded and standing in the way of progress. He is not what he used to be when he was open-minded in the minded-2000s and helped merge Merb with Rails. Nowadays, he is clearly biased towards JavaScript against Ruby to the detriment of the Ruby community. He claims he is "embracing" JavaScript for "pragmatic reasons", which might sound good on paper and might be something I'd normally agree with, but in fact is hurting the Ruby community significantly as illustrated by the attached JS code examples that many Ruby on Rails devs write nowadays as a result of DHH's closed-mindedness and stupidity. His claim for embracing JavaScript would only be true if there weren't huge differences between JavaScript and Ruby, alas there are enormous differences between the two languages. As such, DHH is an idiot and will always be called idiot unless he humbly corrects his ways and apologizes for destroying the Ruby on Rails community by enabling devs to write code like the attached code in the last 10 years. The blood of such crappy code is on DHH's hands! Only bigger idiots would support DHH's idiotic position. They're all enemies of progress and innovation in the Ruby on Rails community. We all know Hotwire isn't enough, and the Stimulus bit is the part that many devs replace with React.js eventually or from the get-go because it doesn't solve everything effectively and conveniently. By the way, I do not necessarily propose that everyone needs Frontend Ruby as Hotwire could be sufficient for more basic Rails projects, but 100% of devs who use JS libraries like React/Angular/Ember/Vue/Svelte have zero excuses not using Frontend Ruby instead to cut their work by half with much better possibilities facilitated only by the Ruby programming language. The fact that DHH doesn't get that demonstrates how much out of depth and out of touch he's become in Ruby over the last 10 years.