Unlimited Tech Debt Work

I love that at my job, our managers are 100% on board with doing as much tech debt work as needed. That's what enables my team to stay productive month in month out. It's very sad when company politics prevent tech debt work from happening and employees end up getting forced to accept the unproductive status quo because "that's the way it is". That's why good work relationships are of paramount importance. They enable us to bypass politics entirely to focus on getting work done in the most effective way possible for customers.

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:

• Hello, Component Attribute Listeners! 
• Hello, Component Attribute Data-Binding!

Happy Glimmering!

Discrimination Experienced at Tech Companies

I have experienced something like this at Ruby shops before. My girlfriend keeps getting mistreated at her job where she works as a Scrum Master. Some devs on her team miss her meetings and ignore her deadlines, and then instead of apologizing for their bad work ethic, they lie and bully my girlfriend by pretending they're the "victims" and she's the "oppressor", which makes zero sense given that she's like the nicest person and incapable of being mean towards anyone. 

Worse yet, instead of the manager bringing the other devs and my girlfriend into a room to have them speak their sides of the conflict and hash out their differences respectfully (as done at normal ethical companies), or at least investigating if the claims by the devs about my girlfriend are even true at all (they're not), he decided to blindly trust the claims without giving equality to all sides (meaning he is taking sides with one side instead of staying unbiased and letting both sides be equally trustworthy or equally have to prove their claim). Afterwards, he decided to split the team into 2 teams with the excuse that "there is no cultural fit between some people on the team, so it's better to split them into 2 different teams". That's ridiculous as it completely ignores the bad work ethic of the lying developers (like not attending meetings and not hitting deadlines) and ignores the fact that my girlfriend is a certified Scrum Master and a very friendly team player. She would be a great fit in any tech culture given that she is a qualified team player. On the other hand, the other devs are very individualistic and don't care about the team or teamwork whatsoever. So now, they are using "culture fit" as a way to discriminate against my girlfriend and defend bad coworkers who are literally missing meetings without being held responsible while bullying my girlfriend and treating her with discrimination. They don't see themselves as equals to her, yet as being on a higher platform from which they don't need to follow the same standards my girlfriend follows like attending meetings and respecting deadlines. 

I actually cover these exact kinds of discrimination in my writeup on covert discrimination (like having double standards and using "culture fit" as an excuse to discriminate): https://andymaleh.blogspot.com/2024/12/how-to-spot-covert-discrimination-in.html

Stop covert discrimination from happening at work places by spreading awareness via sharing this article and the one linked above. 

In my experience, 100% of companies that have 1000 employees or more (the kind of company my girlfriend works for) practice some sort of discrimination while treating employees as numbers, with some treated as part of the "elite" and others treated as second class citizens regardless of their technical qualifications and merit. That's why a number of years ago, I stopped accepting high paying jobs at 1000+ employee companies even if I am fully qualified for them technically because I discovered that they are all essentially discriminatory environments that prioritize greed/pride over servitude to customers and coworkers (any company that makes more than a certain large amount of money cares more about greed than providing 100% equal service to everyone without discrimination). I am much happier working for small and mid-size companies where such discrimination doesn't take place while working in a much more agile fashion than any 1000+ employee company could.

Devs Who Use React Hate & Abuse Customers

Devs who use React abuse customers by finishing 6 months worth of work in 12 months due to using an inferior technology. They literally hate their customers as they use React primarily for the "cool" "association factor" and "wow" "buzz factor", not because they are looking to lovingly deliver the best solution to customers while setting aside their own personal emotions/preferences. 

As such, beware of anyone defending them as they are defending criminal behavior that robs and cheats customers, rendering those people criminals by extension. 

The proof is in the pudding. You can ask any React dev if they would be willing to use an alternative technology that enables them to write half the code to finish work in half the time with double the maintainability, and they will say no without even evaluating the alternative technology. That's because they use React to please themselves not customers. 

In my opinion, any social media platforms that defend React oughta be held liable for criminal behavior in a court of law and either shut down or penalized until they completely stop defending React devs and allow true western free speech to expose the truth.

Under-applying YAGNI Results in Terrible Codebases and Not Taking Good Advantage of OOP

It's amazing how few devs understand the YAGNI Software Engineering principle (Ya Ain't Gonna Need It!). This is as true in the Ruby community as it is in other Software Engineering communities. Devs either over-engineer everything with very complicated "Services" or under-engineer everything by using a Functional Programming language or style of development, resulting in a very terrible expensive-and-difficult-to-maintain codebase. Very few Software Engineers are adept at applying YAGNI, understand how to balance division of responsibilities between objects in Object Oriented Programming, and understand that every approach in Software Engineering is valid depending on the problem at hand.

Writing everything in a single script is sometimes good enough. Otherwise, dividing the script into a few Models might be the next good enough approach. If the Models grow too large, then perhaps extracting a Service or few is the next good enough approach, but that doesn't mean devs should be applying that approach everywhere all the time. That's where most devs fail as they try to generalize whatever approach they think is "best" everywhere all the time, and end up resulting in a terrible codebase to work with.

Balance between different approaches is key and being comfortable with imperfection is perhaps the most underrated skill in Software Engineering as it is the skill that ensures properly applying the YAGNI principle whenever needed. Under-applying YAGNI results in terrible codebases and not taking good advantage of OOP when helpful.

One of the most common anti-patterns caused by lack of application of YAGNI is a developer complaining about different parts of a technology and throwing the baby with the bathwater by never using a technology again because it did not solve everything all the time. 

Usually, when I hear a Software Engineer talk with such generalizations, I recognize right away I am talking to an amateur not a real expert in Software Engineering. Software Engineering amateurs usually are always bouncing from one approach to another while seeking the golden hammer that would solve all their problems all the time. One day that is GraphQL, the next day, it is Server Side Rendering, and after that, perhaps Rust, and on and on and on. They never learn to write good code with any approach because they are always seeking a silver bullet while complaining about different parts of a technology because of expecting them to solve everything all the time. 

Like, they might complain about Rails for being "too simplistic with its MVC pattern". So, then they jump on Elixir or Rust and expect it to solve all the problems of the world by throwing the Rails baby with the bathwater. Hello!!! You were never supposed to only apply MVC in Rails, yet just use it as a starting point while augmenting it with proper Object Oriented Design, including application of Design Patterns and Domain Driven Design! 

Those same devs end up eventually ditching Elixir or Rust, and then jumping on the next hype bandwagon, like Next.js or Clojure, etc... Every codebase they build ends up being a complete piece of unmaintainable garbage, and they use that as an excuse to jump unto the next piece of hype. 

Beware of such devs as all they do is scam customers with the illusion of skill while they lack the true deep Software Engineering skills of applying YAGNI and knowing how to use the right tool for the job.

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!