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!

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!!!

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.

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, 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.

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).

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, 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 and 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.

How To Compliment an Open-Source Software Project

The best compliment of an open-source project is using it, even if only in a proof of concept or a toy project.

When I started the first desktop version of the Glimmer project back in 2006, I had multiple coworkers support me by not only trying the project out, but also making contributions to the project via pair-programming.

If somebody ever compliments your open-source project without using it, it means they didn't compliment it at all, yet just lied. 

Beware of fake "open-source supporters". They actually weigh you down by pretending to support you with words alone without actually supporting you with actions. Meaning, they're all talk and no walk. I try to intentionally alienate such people from my open-source projects all the time. They're total trash!!! Not real supporters of open-source software. 

If someone compliments one of your open-source projects, put them on the spot by asking them if they used it. If they didn't, it means they only offered a cheap compliment, so tell them not to compliment your project until they've used it, or else they would be lying because if they didn't even try the project out for themselves, the compliment isn't sincere.

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.

Addressing Selfish Lame Excuses for Anti-MINASWAN Behavior

When mentioning the problem of Ruby/Rails subreddit members behaving in anti-MINASWAN ways (anti Matz Is Nice And So We Are Nice), some devs give ignorant selfish lame excuses like "Nobody forced you to join those groups!". This is exactly like saying to someone who got poisoned at a restaurant "Nobody forced you to go to that restaurant!", selfishly allowing other people to get poisoned there daily and even die regularly without caring to report the problem and resolve it for the benefit of everyone. Newsflash! If a restaurant does not meet health standards, it must not be open! You cannot allow people there to profit at the expense of other people who visit the restaurant without offering them healthy food and respectful treatment.

The idea of "Nobody forced you to go there" is misapplied here. It does apply if someone is complaining that "Ruby on Rails libraries do not seem to offer the performance characteristics of C/C++". In that case, those devs can go and join a C/C++ subreddit or the subreddits of other more performant statically typed programming languages instead, assuming they received fully respectful non-discriminatory treatment. But, the idea of "Nobody forced you to go there" does NOT apply when basic things like respect and niceness aren't provided equally to everyone, which is a literal form of discrimination! 

In fact, Reddit mods are total hypocrites because they do claim to provide a "safe environment" except they ironically do it with a double-standard discriminatory way by allowing some people who are mean, lazy, and literal haters of Ruby to "feel safe" while making others who are nice, hard-working, and passionate about using Ruby feel unsafe. 

Many Ruby on Rails devs are passive with regards to addressing this covert discrimination because they are indirect benefactors of it. When I hear of discrimination, I don't stay silent. I show concern. I listen. I ask if there is a way to help. In fact, there are Ruby on Rails devs that do those things with a double-standard by ironically discriminating against whoever they lend support to for "discrimination" instead of being against all discrimination for everyone equally. 

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.