Glimmer DSL for Web 0.10.1 Auto-Conversion of Date/Time Element Values + New Sample

Glimmer DSL for Web 0.10.1 Release Video: https://youtu.be/Tk8mjOzhd5I

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

RubyGem: https://rubygems.org/gems/glimmer-dsl-web

Happy Glimmering!

One of The Dumbest Questions Asked on Ruby/Rails Subreddits

One of the dumbest questions I see asked on the Ruby/Rails subreddits is "Are Ruby & Rails still worth learning today?" (plus other variations, such as "Are Ruby and Rails still relevant today?" and "Are Ruby and Rails dead?"). Are you stupid!?!! Obviously, if you ask such a question inside an online community of devs who make a living with these technologies, they are going to answer "yes" (to the first version of the question)! But, more importantly, any Software Engineer worth his or her salt would be able to answer such a question for themselves by doing their own research, spending an hour or a few minutes at least trying out the new technology they are asking about, and building a list of pros/cons/trade-offs to compare the technology to others. Lastly, if you rely on the words of others instead of your own ability to reason in Software Engineering, then you are letting others think for you instead of thinking for yourself, meaning you are surrendering your competitive advantage and weeding yourself out of the competitive pool, so it would be a bad idea to hire you regardless of what skills you have in Software Development. This is how idiots end up using a terrible garbage library like React.js in an otherwise pristine elegant Ruby on Rails web app codebase. Honestly, if you're too lazy as to answer that question for yourself while idiotically posing the question to a group of devs where the majority would answer "yes" to learning Ruby/Rails, then you won't be considered or get hired at any of the good jobs I've worked at. Initiative and analysis skills matter a lot in Software Engineering job candidates and nothing says there is zero initiative and no analysis skills than lazily asking a question that a Software Engineer should be able to answer for themselves. 

XO Ruby joins RubyConf/RailsWorld as Another Exclusive Discriminatory Unexcellent Conference

So, I got contacted by the organizer of the XO Ruby conference (aka Travelling Ruby), Pascal Laliberté, on meetup.com because I organize the Montreal.rb Ruby Meetup and am a Montreal-based Expert Ruby Software Engineer. He said XO Ruby is coming to Montreal and asked me for help with it. We end up meeting in a video conference call. 

To help out, I indicated that I asked my company to consider sponsoring the conference. Furthermore, I volunteered to give a talk as a Montreal-local Ruby Expert (given I have won 2 awards by Matz and have spoken 4 times at RubyConf and 2 times at RailsConf, plus 2 times this year at Ruby conferences in Europe, including this talk that I shared with him); I offered to ask my company's former CTO (who is still with us in a different position) to give a "Founder" topic talk (one of the topics of the conference) about how to be a Tech Founder for a Ruby on Rails project (our previous Montreal-based Fintech company is a huge success story as we got bought by a larger Silicon Valley Fintech 1.5 years ago that is a leader in the Credit Union AI/Agent Conversational Software space); and I offered to recommend other potential Ruby speakers from Montreal. 

After everything I volunteered to help with, Pascal strangely seemed to push back against me giving a Ruby talk at the Montreal-based XO Ruby even though there are empty slots left and I am literally one of the biggest representers of Ruby in the Montreal Tech community today (not many Ruby Software Engineers from Montreal present at RubyConf like I have in 2022/2023/2024, and no one from Montreal as far as I know has won awards by Matz, the creator of Ruby). I've also put in many many hours and days into keeping the Montreal.rb Ruby Meetup going, including giving extra presentations myself whenever needed, and that's in addition to the many many hours and days I've put into Ruby Open-Source Projects. Honestly, if an interviewee at a job interview I am conducting had reacted with that sort of apathy after hearing my accomplishments, they'd be cut immediately from the interview process due to being apathetic instead of passionate, and due to not appreciating excellence, as only unexcellent people don't appreciate excellence. Truly excellent people always appreciate excellence and excellent accomplishments, while maintaining an attitude of curiosity about them.

I asked him how many talk slots are left in the conference. He said there are about 9 slots and about 4-5 are left, including empty slots for the "Open-Source Projects" topic. Then, he started trying to explain that he wanted a very technical Ruby talk (it's a weird note given Glimmer DSL for Web is one of the most technically interesting and innovative Ruby projects ever with its ultralight, expressive, and minimalistic DSLs). So, I told him I've given talks at many Ruby/Rails conferences and meetups on a variety of topics, including Domain Driven Design, Design Patterns, Object Oriented Design, Desktop Development, Frontend Development, and DSL Engine Meta-Programming, plus I have literally won an award from Matz, the creator of Ruby, last year for my Open-Source Project, Glimmer DSL for Web (in addition to winning another award a few years ago for Glimmer DSL for LibUI), so I can easily give a strong Ruby technical presentation. The weirdest and creepiest thing is Pascal's face was so apathetic when I was recounting all my Ruby accomplishments as if they don't matter. That's not the reaction of a strong ethical Software Engineer who cares about the fact that past Ruby accomplishments have benefited many customers and continue to benefit customers directly or indirectly today. 

Then, Pascal said he could not guarantee a slot for me despite having empty slots, believe it or not, without providing any valid reasons! I told him given that I am 100% qualified to give a talk at the conference, this is discrimination! After all, if I wasn't qualified, or even had some competition, I could understand not being guaranteed a slot. But, I am the only one in the Montreal community who has won awards from Matz, my new innovative open-source project has no competition, and no Software Engineers in Montreal have represented Ruby as much as I have in recent years through continued effort in fostering the local Ruby community with running the Montreal.rb Ruby Meetup. Meaning, this is 100% discrimination. 

To give a point of comparison, I was literally hired instantly at my current company a number of years ago (when we were still a small startup before acquisition) because my boss appreciated all my Ruby accomplishments and knew that I had a large enough body of work in the Ruby community (many RubyConf/RailsConf talks and Ruby open-source projects) that demonstrated my Ruby skills beyond the shadow of a doubt and warranted instant acceptance of me. My boss back then who was the CTO at the time is a Super-Duper Ultra Strong Software Engineer/Architect/CTO by the way, so he knew what he was doing. 

Any normal competent ethical strong Software Engineer would have been absolutely excited to have me talk at their Ruby conference (like the organizers of wroclove.rb and RubyConf Austria), especially that I have won an award from Matz himself, the creator of Ruby. They would have been 100% curious to learn what the award-winning project is all about and would have wanted me to share that knowledge with others in the Ruby community for the benefit of customers (not for selfish reasons). 

I responded to Pascal further by telling him that his conference practices discrimination and is an unexcellent garbage conference that is way below my standards for how a Ruby conference should be (it should be non-discriminatory and appreciative of excellence that wins awards from the creator of Ruby).  So, I don't want to participate in it anymore nor help it. The fact that the conference doesn't immediately accept a talk by someone who won awards from the creator of the programming language that is the reason for the conference existing means it is a trash conference. It can't possibly be sharing top-level Ruby excellent knowledge, yet lower-level mediocre knowledge. I told him I was ending the video conference call because discrimination is not acceptable anywhere in Canada. It's funny how this creepy unethical guy was trying to act as if he's "more important" than me when in fact he probably doesn't have half my accomplishments. This reminds me of this blog post about entitled people in the Ruby community, which applies to him as well.

The crazy thing is he tried to interject and say things about "my behavior" towards the end of the video call when in fact his behavior was already bad through discrimination and lack of appreciation for excellence, so if his behavior is already bad, he is in no position to judge anyone else's "behavior"! My behavior is exemplary in the Montreal Ruby community over many years.

One other thing worthy of note that relates to discrimination is that at one point, Pascal tried to focus the conversation on the pronunciation of my last name, which felt uncomfortable and felt as if he was trying to pigeon hole me into whatever "country of origin" my heritage belongs to instead of just treating me as a 100% equal Canadian (as I am a 100% Canadian after all). I have just completed my employer's yearly training for workplace prevention of abuse, harassment, and discrimination. And, such behavior came up in the training as "discrimination based on the country of origin". When he asked about how my last name is pronounced, I told him my last name is just pronounced like it's written in English, with the end being silent, similarly to the pronunciation of the word "melee" (meaning a skirmish). To be honest, over the years, I have received that sort of discrimination from a number of people in Canada. It's disappointing that some people in my country, Canada, discriminate against others based on their country of origin, sometimes in very subtle ways with plausible deniability (this was blogged about as covert discrimination). I had less experience of that discrimination when I lived in the USA in the past during the first 10 years of my career. It's ironic that the international stereotype of Canadians is that they are nice people, but in actuality, some of them (not all) apply "niceness" with a double standard (which is not nice), treating people in their in-group nicely and treating others in their out-group not nicely at all. That's something I have experienced by some of the people who work for Shopify in the past (this blog post by Paul Battley and this blog post by André Arko confirm my experience of Shopify being mean). Fortunately, I work with very nice people at my company's Montreal branch and I have a very nice French Canadian girlfriend too.

Another thing worthy of note is that this XO Ruby conference is associated with Jim Remsik who runs Falgrant. In a past RubyConf that I presented at, at which I met Jim Remsik, I literally saw swag/stickers by Flagrant that included the F word, which were very unprofessional and disrespectful. Professional Software Engineers who don't make it a habit to drop F bombs at work would not use that sort of language in business marketing material as that immediately reduces a company like Flagrant into a trash company that spreads unethical trash with every interaction they have with others. I removed Jim Remsik from my LinkedIn in the past after I noticed that just as I removed Pascal Laliberté from my LinkedIn today after our video call.

I have mentioned this before; from the perspective of discriminators who have an unconscious or conscious in-group/out-group bias, it doesn't matter if someone from the out-group has launched rockets to the moon successfully with excellent effort, as they would still get treated as if they are unequal unimportant people and as if their accomplishments don't matter (in spite of having practically benefited many customers directly or indirectly with their accomplishments). 

In conclusion, to avoid enabling discrimination and unexcellence in the Ruby community, avoid attending, sponsoring, and presenting at XO Ruby. Also, know that it is a mediocre garbage conference that is way below the high quality standards of Ruby Experts like me for excellence and ethics. 

P.S. Of course, as with my other blog posts, to prove that I'm on the right side of things, I acknowledge that nobody is perfect and everyone makes mistakes. Meaning, I am always open to the idea of forgiving people if they redeem themselves. So, if Pascal was to apologize about his discrimination/lack-of-appreciation-for-excellence and allow the most active Expert Ruby Software Engineer in Montreal to present at a Montreal Ruby conference, I'd be happy to retract this blog post. Otherwise, if I am wrong about something and it was kindly, patiently, and respectfully explained to me with genuine loving intentions, I'd be happy to reverse my position too. 

Ruby Memes 2026-07-30: One Bad Monkey Spoils The Bunch

One Bad Monkey Spoils The Bunch! 🤣🤣🤣🤣🤣

This Ruby meme is a variation on the common expression "One Bad Apple Spoils The Bunch" that is noting how introducing inferior devs into a Software Engineering team ends up reducing the entire team's skill and intelligence to the least common denominator skill and intelligence of the weakest links, thus corrupting the whole team the same way a bad apple gradually ruins a bunch of healthy apples when placed with them. 

It's so true when it comes to Ruby on Rails development teams that suddenly make the bad decision of hiring a React.js dev for Frontend work one day even though React.js contradicts the Ruby Way and Rails Way and JavaScript is inferior to Ruby!!! The Ruby on Rails Software Engineers that were once smart suddenly become React.js code monkeys and start forgetting all the best practices and principles of Ruby on Rails due to getting used to React.js breaking them with its inferior over-engineered ways. So indeed, one bad monkey ends up spoiling the bunch!

That's why I strive very hard to avoid hiring even one bad dev on my team as I notice immediate degradation in everyone's work quality as soon as one bad dev enters a team, so we keep a tight ship on my team instead.

The Embarrassing Ruby/Rails Community Chronicles 2026-07-28

"The Embarrassing Ruby/Rails Subreddit Chronicles" becomes "The Embarrassing Ruby/Rails Community Chronicles" as it expands to cover embarrassing interactions by bad Ruby/Rails devs all across social media and the real world, exposing rudeness, meanness, discrimination, and unexcellence/unintelligence in the Ruby/Rails worldwide community. The goal of course is to call that out to discourage in favor of true Rubyist MINASWAN attitudes and behaviors instead (Matz Is Nice And So We Are Nice).

While going through the yearly Bystander Intervention training for my job, I stumbled upon "Persistent unwanted personal questions" as a form of verbal abuse. 

I have to confess I recently experienced that at a Ruby tech event. A bad Ruby dev (the kind you'd find on the Ruby/Rails subreddits) kept rudely asking me what my salary was after I told him I won awards by Matz (the creator of Ruby) for my open-source projects. Any normal Rubyist would have asked me about my open-source projects instead, just out of normal Software Engineering curiosity to learn better ways of serving customers with Ruby. Instead, he kept prying very hard about my salary and was unwilling to accept the fact that it's rude to ask people he doesn't know for their salary. 

After I gave him multiple examples of how previous companies I worked at had policies against people asking about salaries because knowing the answer could cause envy and create bad relationships, citing a real story of that happening at one of my previous jobs when someone's salary leaked, he pivotted towards asking me if "I felt uncomfortable answering". He kept insisting on me answering that new question instead going forward. The person was already coming across by that point as a very awful rude unprofessional person due to literally attempting to make me feel uncomfortable with incessent questioning.

He sounded like he desperately wanted to "win the conversation/situation" in any way possible (of me having won awards he hasn't won, instead of being humble/happy for me) by trying to make me "look bad" as someone who is "weak" due to being "uncomfortable". That revealed to me what his original intention and ulterior motive was behind asking for my salary: He just wanted to make me "look bad" as I'm sure he was going to tell me my salary was too low no matter what answer I would have provided, as a trap, to insult me and render me "unimportant" even if I've won awards by Matz. As if the awards were about me "being important" or "making more money" as opposed to ensuring I serve customers with the best quality work possible (which is what awards really encourage from the perspective of truly ethical excellent people who don't prioritize greed or pride over customer service). 

What a ridiculous interaction that was! I finally answered him by saying "it's not about me being uncomfortable. It's just a bad practice/etiquette to ask for someone's salary, especially if you don't know them well, and I won't endorse/enable that practice by answering the question even if I were comfortable with answering it."

The dude confessed to me eventually that he doesn't work in Ruby anymore because he lost a political battle at work, so he is now using Python even though Ruby is more effective than Python at building his work application. What a loser! That's exactly the kind of pushover rude loser my team would never hire and would screen for during the interviewing phase of hiring. We don't want devs who lose political battles for what technology decisions are best for serving customers. I have won many many such political battles at my company over the years, and it was because I'm no pushover. A bad dev being unethical/rude goes hand in hand with other bad attributes like being a pushover, which is why we never hire such devs in the first place.

RubyConf Austria 2026 Talk Video: Frontend Ruby on Rails with Glimmer DSL for Web — Andy Maleh

My RubyConf Austria 2026 talk has been published on YouTube! What if your frontend was just... Ruby?

https://www.youtube.com/watch?v=qTukq5AcSK0

You can find the talk slides over here:

https://andymaleh.blogspot.com/2026/06/rubyconf-austria-2026-frontend-ruby-on.html

A Supporter Sympathizes with My Discrimination by RubyConf 2026

I am thankful to the Software Engineer who shared a very supportive comment regarding my experience of discrimination by RubyConf 2026. 

RubyConf 2026 Is Not a Safe Environment for Everyone

RubyConf 2026 is not a safe environment for everyone. They have an in-group and an out-group. If you're in the in-group, they will treat you well and accept talk proposals by you even if you don't have top-level skills in Software Engineering. If you're in the out-group, it doesn't matter if you launch rockets to the moon successfully on your own or win the approval of Matz himself, you will be excluded and discriminated against: 

https://andymaleh.blogspot.com/2026/06/rubyconf-has-joined-railsconfrailsworld.html

If that weren't true, then RubyConf's folks would not be afraid to address the issue of feeling discriminated against for the benefit of keeping their reputation clean. Alas, like all discriminators out there, they cower and hide instead of addressing the issue because the discrimination is 100% real. A discriminator usually discriminates because they don't see everyone as equal or because they're frauds and don't have the energy to treat everyone equally, so if discrimination is brought up to them, they won't take it seriously. 

Respectful treatment means to treat someone well and fairly for what they have accomplished and what they offer. I realize I could buy a ticket to the conference, but rejecting a talk by me that won the approval of Matz, the creator of the Ruby programming language that is the reason for the conference existing means I have earned the right to talk about the subject that I won an award from Matz for. Otherwise, I am being robbed and discriminated against. This is no different from how the MLB (Major League Baseball) used to mistreat Afro Americans and relegate them to playing in the Negro league instead of the Major League. Telling someone who can perform at the major league level they are unaccepted as a player there, but could attend if they want is most definitely discrimination 100%. 

By the way, under other circumstances, if I had no project to talk about, I would be 100% OK with attending RubyConf instead of presenting as I would normally want to support other speakers and learn from them. But, in 2026, the issue is if they rejected a talk by someone who won an award from Matz at a near impossible international competition to win, it means they probably rejected a lot of top-quality talks and accepted many subpar mediocre quality talks. I don't want to go to a conference in which I become mediocre by attending mediocre talks. Excellence and unexcellence are infectious. The next thing I know after hanging out with unexcellent speakers at RubyConf 2026 is I'll become unexcellent and subpar like them. This is no different from entire mediocre communities like the React.js comunity and others where the blind are leading the blind into a pit, but everyone is celebrating the popularity of mediocre ideas and technologies (meaning they only perceive themselves as being smart, but objectively, they're all performing suboptimally for customers and don't provide the best smartest work). No thanks!!!

RubyConf 2026 is a cesspool of discirmination and exclusion:

https://andymaleh.blogspot.com/2026/07/reminder-that-rubyconf-2026-is-cesspool.html

One might think that RubyConf's folks are too busy to look into the discrimination claim. But in fact, I contacted them about the perceived discrimination about a month ago. They had all the time of the world to look into the discrimination and lack of appreciation of excellence (an equally serious matter). Also, if they claim to be "excellent", "inclusive" and "diverse", then looking into discrimination and lack of appreciation of excllence would be the top priority of RubyConf, alas they're a mediocre discriminatory conference in 2026 that doesn't put excellence and lack of discrimination at the top of their priorities, just like any dictator at a third world country would act. They're no different. It's a fraud of a conference in 2026.

The fact that it doesn't bother them to have these blog posts published as to want to contact me and settle the issue of discrimination against me proves they are discriminators 100% because discriminators aren't bothered by having discrimination reported to them, but real non-discriminators put ethics and good equal treatment of everyone first above everything else.

I have talked extensively about covert discrimination in the Ruby community in the past, including microdiscrimination / personal discrimination (meaning discrimination against a single person, which makes the discrimination escape protections available for minority groups). Ignoring someone without attempting to resolve things amicably definitely falls under covert discrimination:

https://andymaleh.blogspot.com/2024/12/how-to-spot-covert-discrimination-in.html

Reminder that RubyConf 2026 is a Cesspool of Discrimination and Exclusion

Just a reminder that RubyConf has become a Cesspool of Discrimination and Exclusion. In 2026, it doesn't matter how well accomplished a Ruby Software Engineer is in the Ruby community as even if they win awards by the creator of Ruby himself, if they propose a topic that is taboo with the organizers of RubyConf, they are excluded and discriminated against, without even providing a valid reason for the exclusion. It's one thing if there was an intelligent rational reason. It's another when the organizers just run away in cowardice from addressing the discrimination, which is an act of discrimination/exclusion as ignoring someone is a form of exclusion too. 

The bottom line of RubyConf is that if you are one of the "favored ones" that RubyConf give preferential treatment to, then even if you haven't won any awards from the creator of Ruby or lack complete mastery in Software Engineering, due to discrimination, you are given more importance over someone with more skills and experience. 

That means RubyConf mostly has subpar and suboptimal talks. Intelligent well-accomplished master Software Engineers can't trust that they would receive top-level talks at RubyConf anymore in 2026. 

Basically, RubyConf discriminates against people by seeing them in multiple groups (unlike normal non-discriminatory conferences that always recognize and reward excellence):

• Excluded ones: those people can build a rocket that reaches the moon and win awards from the creator of Ruby, but their efforts are not appreciated by RubyConf or respected as to give them a speaking platform if they propose a topic that is deemed too novel, outside the box, or taboo by RubyConf (like Frontend Ruby Development)
• "Favored ones": those people are liked not always for top-merit or rational reasons, but often for emotional reasons too, a form of discrimination by not seeing everyone as equal, yet deeming some people as above others even without having the best or top-level accomplishments.

Meaning, the "favored ones" will be allowed to "have fun" at the conference and think it is "diverse and inclusive" when in fact it's all a lie. They do it with a double standard offering that to some people only, but not offering well-deserved respect to everyone who earned it, and without even being loving enough as to explain why a talk about an open source project that won an award by Matz himself at a very difficult international competition is getting rejected at the conference as to help the person follow a "better path" in their career if they're truly wrong.

Part of the reason why this is a big problem is because the project they excluded offers an amazingly simple Ruby solution to a very complicated and divisive problem in the Ruby on Rails community. Then again, perhaps it is knocking JavaScript around too much for the liking of fake Rubyists who work at RubyConf and that's the true reason why they "didn't find the project interesting" when in fact Matz the creator of Ruby who's smarter and more accomplished/important than all of them didn't just find it interesting, but was willing to give it an award at a difficult international competition along with other smart judges. 

By attending RubyConf, you're supporting this kind of discrimination and exclusion, plus lack of appreciation of excellence, which means RubyConf is unexcellent and is mostly sharing dumb "yet popular" talks with the public. If anyone has any shred of ethics, self respect, or excellence, they would boycott RubyConf and contact them about this grand discrimination offense committed by them. 

Funny, I told my girlfriend about this a while ago, and she recently asked me if any of the RubyConf folks reached out to me to apologize or explain themselves, expecting that normal people would do that. I told her no, they're just unethical discriminatory cowards (their guys aren't real men) who don't care to explain this or apologize about it. Though, I personally am always open to forgiving someone if they are willing to apologize or explain what I might have done wrong to deserve this. Any other reaction shows apathy and more discrimination (ignoring someone is exclusion, so another form of discrimination). 

In a way, I am very happy I won an award from Matz in 2025 because it exposed the Ruby community for all the discrimination it has against certain people/topics in the community, which even reached RubyConf eventually.

Ruby Memes 2026-06-26: The Ruby Clown

The brief version:

The explained version:

Ruby Memes 2026-06-12: The "Cool" Reactionary

 

RubyConf has joined RailsConf & RailsWorld as another exclusive discriminatory unexcellent conference

RubyConf has joined RailsConf & RailsWorld as another exclusive discriminatory unexcellent conference by discriminating against any speakers who submit talks that cover Frontend Ruby technologies or dethrone React/JavaScript in any way. In 2025, I won an award for a highly innovative and outside-the-box Ruby open-source project at an international Japanese tech competition that Matz, the creator of Ruby himself, presided on in addition to other judges. My project really impressed Matz, who is the reason for all the Ruby-related conferences existing in the first place, but in spite of that, both RailsConf and RailsWorld rejected my talk about my award-winning open-source project in 2025 despite the Ruby on Rails community sorely needing a Frontend Ruby solution that would fill a gap not handled by Hotwire; that is true Frontend Development in Ruby (to build frontend-local apps like a UML Diagrammer for example). Given that I am the most qualified person to talk about Frontend Development in Ruby on Rails using real Ruby in the Browser, and no other Frontend technologies rival my project in either productivity or simplicity/maintainability, the rejections came across as discrimination/exclusion and mediocrity/closed-mindedness/lack of appreciation for excellence. After all, if you reject an open-source project that won an award by Matz, your action is sending everyone the discouraging message that it doesn't matter how hard Software Engineers work to produce a unique innovation; they will stil be rejected because of discrimination and lack of appreciation for excellence if it comes from outside the core group behind Rails and some of their sponsors/friends. The reason this is also discrimination is because I was not rejected due to being unqualified (as I won an award after all) or due to the project not providing great value to the Ruby on Rails community (it impressed Matz) as the project saves Ruby on Rails Software Engineers who previously used JavaScript libraries like React.js/Angular/Vue/Svelte 6 months of Frontend work every year by switching to Frontend Ruby. I don't know many talks at RubyConf in general that can offer the same benefit. And, I am sure that nobody working for either RailsConf or RailsWorld has won a similar award to mine at the same international Japanese tech competition that was judged by Matz (and I have done it one other time previously too in fact). 

Fortunately, this year, my award-winning open-source project got accepted at RubyConf Austria 2026 (30-minute talk) and wroclove.rb 2026 (3-hour workshop). Those conferences are much better run than RailsConf and RailsWorld in welcoming innovation and being inclusive! wroclove.rb 2026 literally says on their website that they "want to confront ideas", in contrast to RailsConf and RailsWorld running away from ideas that don't come from the Rails core devs and some of their sponsors/friends (a form of discrimination). RubyConf Austria & wroclove.rb don't discriminate against Frontend Ruby projects and aren't offended by a talk that dethrones React/JavaScript, especially if already approved by Matz, the creator of Ruby. They welcome the excellence and hard work that went into creating my award-winning open-source Ruby project and winning an award from Matz. In other words, they encourage the Ruby community to be excellent and follow my example in innovation and thinking outside the box. In fact, I met Chad Fowler at RubyConf Austria 2026, and he attended my talk, then told me "good job" afterwards. For those who don't know, Chad Fowler founded RubyConf back in 2001. 

So, I submitted my award-winning open-source project's talk to RubyConf in 2026 thinking they might be less averse to Frontend Ruby, especially if the speaker won an award from Matz, given RubyConf is typically more open-minded about Ruby innovations outside of core Rails. Well, I got rejected despite being accepted by Matz, the creator of the language that conference was founded upon. I asked by email for the reasons for the rejection and for feedback to help improve myself in case they want me to do better before getting accepted (though to be frank, I won an award from the creator of Ruby himself, and there isn't anything that can top that). They never responded. 

I want to clarify that I have supported RubyConf in the past by giving talks/workshops at it and by donating my speaker stipends/hotel-pay (over $1000 or $2000 for all the conferences I spoke at) back to RubyCentral for the benefit of the Ruby community as a whole with everyone in it. So, it's not much to ask for a response as to why I encountered behavior that came across as discrimination when I have gone above and beyond in the past in supporting RubyConf and RubyCentral.

Eventually, I remembered that I have 2 RubyConf/RubyCentral people as LinkedIn connections, Jason Swett and Freedom Dumlao, so I contacted them asking the same question. I also pointed out to them that I am a former RubyConf speaker who donated his speaking stipends from the last 3 RubyConfs back to RubyCentral for the benefit of the Ruby community at large (that's over $1000). So, being treated with respect and non-discrimination is the least I could expect from RubyCentral.

Jason Swett chose the coward's plea and just never responded, which is how true discriminators handle discrimination when it's raised to them. The reason this incriminates him 100% is because if he truly wasn't involved in discrimination, he would have at least responded by saying he sympathizes with me perceiving discrimination and by indicating he is shocked that a project that won an award from Matz (when many other RubyConf talk projects didn't win any awards from Matz) got rejected at RubyConf. Honestly, Jason reminds me of employees that my employers fired in the past. Lack of presence and visibility is usually the sign of an unreliable employee who is never there for others. So, I advise against hiring Jason Swett (unless he responds to me and clears up my experienced discrimination).

Freedom Dumlao didn't respond to my first message, but at least responded to my 2nd follow-up message. He gets some points for that. Otherwise, his response was very weird and defensive. He claimed with a very unfriendly tone that I didn't know him even though him and I met at RubyConf 2024 and sat at the same eating table multiple times while having conversations that eventually led to connecting on LinkedIn. In fact, it sounded like he was trying to get out of responsibility by claiming I did not know him enough (a very unnice unfriendly thing to say from a Rubyist) even though the world is a meritocracy anyways, meaning people are known through their actions in day to day interactions, whether ethical or unethical. The way he said that came across as immature and irresponsible, not the way someone at RubyCentral should be talking. After all, a responsible person would have not focused on that, yet focused on my experience of discrimination and how strange it is that a project that was approved by Matz in a very difficult international competition and got a "good job" remark from Chad Fowler (the founder of RubyConf) got rejected at RubyConf, which would indicate RubyConf's staff are unqualified and do not appreciate excellence, in addition to having discriminatory biases, like the bias against Frontend Ruby and biases for React/JavaScript that cause offense if they are dethroned (shameful at a Ruby conference that is supposed to make Software Engineers feel safe about loving Ruby more than other languages). None of them have won similar awards from Matz, most likely in fact. A person in Freedom's position should have been sincerely concerned and should have noticed the problem and then promised a solution without making any excuses, just like how excellent organizations behave. Given that he didn't respond that way, even if I didn't know him, his reaction told me and everyone everything about him that we need to know about who he really is. He showed that he's part of the problem not the solution.

Regarding my donations to RubyCentral that exceed $1000, Freedom tried to deny the value of my donation by saying he donated more to RubyCentral, believe it or not! What a creepy disrespectful way to talk to someone who gave you money for free without being required to. Invalidating a donation is NOT a way to encourage people to continue donating, yet sends the message that donations are discouraged because in the end, they won't matter anyways as "someone else donated more than you". That was the most unhinged unprofessional encounter I've had from someone who is supposed to be a professional! Honestly, it doesn't matter how much he donated. My donations still have the same value in helping RubyCentral and the Ruby community regardless. Other people's donations definitely don't invalidate mine. 

Freedom also proceeded to claim that there was "no discrimination" because all their talks are reviewed anonymously. EXCEPT, my talk was NOT reviewed anonymously, because it mentions a public project on GitHub (which shows the author as soon as one visits it) and a public award (with the winner's name) that the project won from Matz at a public competition. 

I responded to inform him that my proposal submission wasn't anonymous as that was impossible with the talk being about a GitHub project and having won an award. And, I informed him that my donation is definitely NOT invalidated because he donated more. Freedom then chose the coward's plea and didn't respond. I advise against hiring Freedom Dumlao for any jobs or services as a result. He's the kind of selfish irresponsible excuse maker who is only about protecting his own hide while not caring about encouraging and maintaining excellence in a community, nor respecting people who donate to the community without being required to.

You see what I'm dealing with here!? Total trash! These are the kind of people running RubyCentral today! No matter it encountered issues last year with the Mike Perham vs DHH debacle, in addition to stopping RailsConf. The Ruby community is being run by total clowns who are discriminatory, unethical, and unprofessional!

I have ZERO interest in attending RubyConf 2026 as a result. After all, if they rejected a talk by one of the best open-source Ruby projects to come out in 2025 as to win an award by Matz, the creator of Ruby himself, then they probably rejected many other project talks that are top  quality because of the discriminatory biases and lack of qualification of RubyConf staff in 2026. For all we care, we got the dumbest, but most popular, talks in RubyConf 2026, but smart Software Engineers know that popularity is NOT quality. After all, PHP/WordPress is more popular than Rails, but definitely inferior in productivity and maintainability, which is why Ruby on Rails devs don't use those technologies in general. 

In conclusion, RubyConf in 2026 has become an exclusive discriminatory unexcellent conference, which is where people go to become dumber and/or meaner. 

If I had been working for RubyCentral, I would have provided guaranteed speaker slots for winners of the yearly Fukuoka international tech competition that Matz presides on to encourage excellence and innovation in the Ruby community, and I would have provided guaranteed speaker slots or tracks for owners of long-term "pillar" open-source projects in the Ruby community (e.g. Sidekiq, JRuby, Opal, etc...) to respect and support long-term open-source contributors of the Ruby community.

I have covered the topic of covert discrimination in the Ruby community before. What I encountered at the hands of the RubyConf folks is classic covert discrimination. Spread the word to help stop discrimination and unexcellence in the Ruby community! In the meantime, I'll make sure to only attend and speak at Ruby conferences that don't have unprofessional unexcellent discriminatory staff.

P.S. To prove that I'm reasonable and on the right side of this, I will acknowledge that nobody is perfect and everyone makes mistakes. What distinguishes good people from bad people though is that good people will admit their errors and apologize for their mistakes when they are pointed out to them whereas bad people will act aloof and commit more discrimination/exclusion by ignoring you when that happens. If any of the problematic people mentioned in the article change their mind and decide to respond like real men (not by hiding like cowards) to resolve my concerns about discrimination/exclusion/unexcellence for the benefit of the cheated Ruby community that missed out on all the Matz-loved value provided by an award-winning open-source Ruby project that impressed Matz, then I'll delete this blog post. 

Presentation Slides for RubyConf Austria 2026 Talk "Frontend Ruby on Rails with Glimmer DSL for Web"

My talk “Frontend Ruby on Rails with Glimmer DSL for Web” went well at RubyConf Austria 2026. Especially given that after the talk, Chad Fowler (the starter of RubyConf and famous book author of The Passionate Programmer, among other books) told me “good job”, and Obie Fernandez (a famous entrepreneur and book author of The Rails Way, among other books) told me he will try Glimmer DSL for Web because he doesn’t like React.js. 

Presentation Slides for “Frontend Ruby on Rails with Glimmer DSL for Web”:

https://bit.ly/glimmer-rubyconf-at-2026

I ran a poll at the beginning of my talk, and everyone agreed that they love Ruby and that Ruby is superior to JavaScript, plus the majority indicated that they’d like to write less JavaScript and more Ruby during their Rails web development work. Several attendees told me my talk was great after the talk. 

Charles Nutter had me help him with his JRuby workshop afterwards by showcasing my other Glimmer project, Glimmer DSL for SWT, which runs on JRuby. In about 1 minute, I scaffolded a Hello World desktop app from scratch and then packaged it as a native executable on the Mac. Attendees were impressed. So, I’ve participated in presenting 2 events at this conference. 

I am very grateful for having such a great experience at RubyConf Austria 2026 overall, especially given that it uniquely included several classical/neoclassical/jazz concerts in between talks that entertained us and relaxed us. Chad Fowler concluded the conference with a beautiful Jazz piano and sax performance. Shout out to Hans Schnedlitz, Muhamed Isabegovic, and Zuzanna Kusznir (plus everyone who helped out) for organizing and hosting such a special Ruby conference!!!

Ruby Memes 2026-05-03: The Popularist

The Popularist (see the meme below first) ceases to question things, stops thinking for themself, and throws all their principles out of the window as soon as a bad technology becomes popular, due to The Popularist lacking the courage and backbone needed to say no when many devs head in the wrong direction.

Do you know Software Engineers who behave like "The Popularist", making it impossible to trust them with guarding the quality of your team's software? Popularity isn't quality after all. For example, many more devs use PHP, and yet Ruby on Rails devs choose their stack as a higher quality solution for productivity and maintainability. Intelligence and quality are scarce, so in fact, popularity is an indictment, as it means something is low quality enough to be used by the least common denominator majority who are not as intelligent as the top 10%. By the way in case it isn't obvious, React.js is NOT a good technology (learn more by clicking this link). 

Competent vs Incompetent Ruby Devs When Encountering React

Incompetent Ruby devs when encountering React:

- This language is used by Facebook, so it must be great (regardless of the fact that Facebook always suffers from tons of bugs and is an unethical company that has spied on its own users)!

- React is used by many rich large companies, so it must be a very good technology (regardless of the fact that often, rich large companies are unagile, unethical, and can afford bad technologies and bad practices).

- I met "very cool devs" at a tech event who told me they use React, so the technology must be "cool"!!! (when in fact customers don't pay devs for "cool", yet for business value, so getting distracted by "cool" things gets in the way of doing the best job possible)

- React gives me "joy" (regardless of customers losing joy with its use when features take longer to build while ending up with weird bugs due to terrible React code) by making me look so "clever" whenever I successfully write very complicated code using React (meaning React is overcomplicated).

- React is very popular, so it can't be a bad technology! (when in fact, excellence is unpopular, so popularity isn't quality, yet an indictment)

- React's creator sounds like a very smart man, so I can safely follow him (blindly without questioning or thinking for oneself, let alone the fact that he's uneducated, he desperately lies to justify use of React when it does not present the most agile or sensible approach, and is wrong about many things). 

- React is very fast, so it must be the best technology out there (regardless of how unmaintainable/unproductive its code is and how React's premature optimization isn't even useful at all for 99% of business use cases)

Competent Ruby devs when encountering React:

- React runs in JavaScript, a confusing programming language that is inferior to languages like Ruby and Python.

- React is regressing to older styles of programming from the 70's with functional programming, so it is very outdated with JS lipstick on a pig.

- React mixes multiple languages in the same file in JSX files, causing cognitive dissonance that creates mental friction, which slows down productivity.

- Hooks and Effects drop down thinking to lower levels of thinking that distance developers from the business domain and customer concerns, losing them half the battle from the get go.

- React's premature optimization is unnecessary in 99%+ of our business use cases, complicating development with inferior paradigms while being useless/hurtful of satisfying customer needs.

- React's maintainability is so terrible, it kills productivity and hurts teamwork and collaboration very badly (making devs deliver in double the time or longer and with double the cost or more).

- React's style of programming encourages the anti-pattern of devs writing "clever code" instead of code that is readable/maintainable by others without an unnecessary learning curve.

- Ruby provides infinitely simpler ways of Frontend Development than React's, like via the Fukuoka-award-winning Glimmer DSL for Web, which runs on the Opal JavaScript-to-Ruby transpiler. Code doesn't lie. Frontend Ruby is much simpler and more readable than Frontend JavaScript. The matter isn't really open for debate.

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

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.

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

Frontend Ruby with Glimmer DSL for Web - Ruby on Rio - 2025-06-06 Meetup

A video has been uploaded of the Ruby on Rio 2025-06-06 talk I gave: "Frontend Ruby with Glimmer DSL for Web". It covers Glimmer DSL for Web, the Frontend Ruby on Rails gem that won a Fukuoka Prefecture Future IT Initiative 2025 award by Matz, the creator of Ruby.

YouTube link: https://www.youtube.com/watch?v=LY6ulYICuzE

Otherwise, I am happy to report that my talk proposal "Frontend Ruby on Rails with Glimmer DSL for Web" has been accepted at RubyConf Austria 2026.

Merry Christmas!

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!