Ruby Programmer Happiness Explained!

'Ruby Programmer Happiness' means 'happiness for having the ability to deliver useful business value to customers as productively and as simply as possible with the ability to maintain the code with very little effort for years to come'.

Some devs misunderstand 'Ruby Programmer Happiness' as a Technology that makes them happy only when in fact, the term assumes Ethical Software Engineers, meaning Programmers who derive their happiness from serving customers (who pay them) in the best way possible.

That is something to think about! 

Remember that all Software Engineers are paid to make Customers happy, so if they were to use a Technology that made the Programmers happy only, then they would fail at their job. 

Besides, I am sure there are many things that would provide much more happiness to Programmers than Ruby in general like playing video games, playing board games, playing sports, attending sports events, watching movies, bing-watching TV series, connecting with loved ones, etc...

But, Ruby is literally much more productive than other programming languages like JavaScript, Python, and Java at delivering business value to customers (assuming there are no special performance-optimization requirements), so using technologies other than Ruby causes frustration and unhappiness in Ethical Software Engineers. On the other hand, unethical programmers stubbornly stick to ineffective programming languages while writing 2x or 4x the code needed in Ruby in a more cryptic "clever" manner just because the other programming languages "make them happy" for personal reasons (like "feeling clever" or "belonging to a cool community") without any regard for how happy their customers who pay them are as a result of their work as compared to how they would be when using better technologies like Ruby. 

This disproves that happiness of the programmer using Ruby is what makes Ruby so great and proves that it is programmer happiness as a result of customer happiness in Ethical Software Engineers that is the real reason for 'Ruby Programmer Happiness'.

In conclusion, we do not use Ruby just to make programmers happy. We use Ruby to make customers happy, and being Ethical Software Engineers, we become happiest as we deliver the best work possible to customers (who pay us) with Ruby.

Imposter Syndrome vs True Imposters

I see too many posts on imposter syndrome and not enough posts on the other side of the spectrum, true imposters. You can’t trust an argument if it doesn’t cover both sides as otherwise it might be a covert scheme to get more unqualified imposters into the field of software engineering to steal the work and pay of truly qualified software engineers. Imposters often write shit code that hurts companies the most after the imposters have quit them to greener pastures, which is a common theme with them. They’re often unloyal and unreliable as they don’t stay in one place for long. Beware of imposters! They’re people who don’t have a 4-year degree in any field that relates to computers, engineering, or science, and who often don’t think for themselves, yet just mindlessly repeat what blog posters and open source project owners who work at large rich companies say on the Internet without questioning them with any proper pros/cons/tradeoffs analyses for their specific customer situations. 

To cover both sides of the argument as any proper argument should, imposter syndrome is different from being a true imposter because it happens in software engineers who are 100% qualified by having a 4-year university degree that related to computing, but are new to the software development market as professional workers, or are new to a position they have recently gained like engineering manager or CTO. Those software engineers are only suffering from lack of confidence in applying themselves to the field of software engineering as they feel out of place due to being new to their position. Once they have improved their practical skills enough (like by reading practical work software engineering books and building toy or open source projects), have accomplished enough successes at their job, and have humbly accepted coaching by more senior software engineers, they get over imposter syndrome and start feeling like they belong 100% to the field of software engineering. 

Be a Good Steward of Open-Source Software!

I had to ban a troll from my GitHub projects who never behaved like a good member of the open-source software community as he always just talked and talked without ever taking any useful actions, like reading documentation, following instructions, creating examples, writing documentation, contributing pull requests, or sharing code examples in issue reports, forgetting that open source projects are 100% free community contribution efforts and aren't paid closed-source software that entitles the user to anything.

Reminder of how good members of the open-source software community behave:

• They make an effort to read an open-source project's docs and try it out on their computer to answer their own questions before asking questions about an open source project.
• They build and share real examples of using an open-source project when reporting issues instead of just writing down very abstract words that might not relate to reality and might miss the fact that the project does provide solutions for the reported issues.
• They give back by writing documentation they feel is missing from an open source project and use that as an opportunity to become open source contributors to the open-source project.
• They give back by contributing simple issue fixes as pull requests to an open-source project, using that as an opportunity to become open source contributors to the open-source project.
• They interact with open-source project maintainers with an attitude of humility and respect of their effort and time.

Bad members of the open-source software community behave this way:

• They act entitled like they are more important than the creators of open-source projects (as opposed to equal to them) and think they are owed the privilege of paid service on 100% free and open source software projects, expecting 100% hand holding on everything, instead of being expected to be responsible strong software engineers who can figure things out for themselves by reading open-source code and minimalistic documentation. Also, they don't realize that they are being evaluated by open-source project creators on whether they are competent Software Engineers and respectable members of the open-source software community instead of being entitled devs that lose merit if they ask questions without putting in any of their own effort or demonstrating understanding of solid Software Engineering and open-source software principles.
• They do not spend at least 10-30 minutes reading documentation or trying out an open-source project before asking very trivial questions they could have answered for themselves with very little effort.
• They complain about missing documention instead of realizing this is 100% free open-source software, not paid closed-source software, and using missing documentation as an opportunity to gain the honor of becoming contributors to an open-source project.
• They report issues without writing any code examples and they ask questions with a very haughty rude entitled attitude as if they are more important than the open-source project creators when in fact, their entitled attitude loses them merit and drops their importance way below that of the maintainers who at least spent time and effort to contribute something to the worldwide open-source software community for free.
• They do not contribute pull requests for very trivial issues that they could have contributted fixs for themselves to intelligently gain the honor of becoming contributors for an open-source project.
• They do not contribute time beta-testing or using an open-source project in low-risk situations to help contribute feedback to very novel and innovative open-source ideas to show good faith in wanting to support innovation/excellence and help open-source software.

Good stewards of open-source software are the kind of Software Engineers that is considered the top of the line when hiring at Software Businsses. Be a good member of the open-source software community to help it come up with better ways of serving customers with open-source software while improving your resume and your hirability and job retention!

Glimmer DSL for Web Wins in Fukuoka Prefecture Future IT Initiative 2025 Competition

Glimmer DSL for Web (Ruby Web Frontend Framework) won an award in the Fukuoka Prefecture Future IT Initiative 2025 competition after I presented it to Yukihiro Matsumoto (the creator of Ruby) and other Fukuoka competition judges earlier this week on January 21, 2025! It's official! Matz approves of Glimmer DSL for Web!!!

GitHub Repository for Glimmer DSL for Web (Ruby Web Frontend Framework): 

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

Slides for Glimmer DSL for Web Fukuoka Prefecture Future IT Initiative 2025 Presentation (10-min):

https://docs.google.com/presentation/d/e/2PACX-1vQ8_DEsug8pIaHTKtVM1lye0I22gU-tatPT1B5WEwp6uRXkfmlQ9SSmdmCTHvXuPDb749wvPzBUmqRz/pub

Thanks to the maintainers of Opal Ruby (Fukuoka Ruby 2023 Award Winner) for making it possible to build something as amazing as Glimmer DSL for Web today! You guys totally rock!!!

Thanks to everyone who attended my first talk about Glimmer DSL for Web at the Montreal.rb Ruby Meetup on March 6, 2024 last year as you guys literally witnessed history in the making! This is similar to discovering Ruby in the early days of Rails in the mid-2000s, but on the Frontend instead of the Backend. A couple of weeks ago, I got approval by my managers at work to start using Glimmer DSL for Web in my work Rails web app and to explore it as a replacement for React.js. So far, the results have been absolutely amazing! Truly, I feel a 200% improvement in productivity, maintainability, simplicity, and code readability in Ruby Frontend code compared to using plain JavaScript or React.js. I look forward to the bright future of Ruby in Frontend Development of Rails web applications, as enabled by Glimmer DSL for Web, now a Fukuoka Award Winning project! 

First Endorsement of Glimmer DSL for Web

I am happy to announce that I received my first endorsement of Glimmer DSL for Web (Ruby-in-the-Browser Web Frontend Framework):

"I'd like to endorse Andy Maleh’s work (Glimmer DSL for Web). I got introduced to it at RubyConf 2024 and have been playing around with it pretty successfully. What I have found most interesting is that I have been writing inside of a rails app, where I have been running the same code for models and presenters inside of MRI rspec. That way I can write tests that verify behavior of the presenters and models and still see them run successfully in the browser. That allows me to have a very nice cycle of refactoring and being confident in my changes without even running it in browser. I just assume that the binding will work and it usually works perfectly." - Steve Tuckner

 

Pushed First Code Commits of Frontend Work Done with Opal Ruby + Glimmer DSL for Web to My Job's Rails Web App Repo

I'm happy to report that I officially pushed the first Opal Ruby + Glimmer DSL for Web code commits to my job's Rails repo in the Admin UI last week. It is just amazing how Glimmer components written in Ruby to replace React components are way simpler and smaller! It's not even close! My productivity definitely feels double at least while producing about half the code. This is so exciting! It reminds me of the early fun days of discovering Ruby, but on the Frontend! There is so much potential and so many possibilities. It is super exciting to discover new patterns and best practices. Ruby creates so much programmer happiness compared to JavaScript! I literally volunteered extra time after work last week to refactor/fine-tune some Frontend components in Opal Ruby because it is SO MUCH FUN!!!! React's JavaScript code looks like ugly over-engineered over-complicated dinosaur code nonsense by comparison, it feels like writing Glimmer Ruby code is like waking up from a bad spell. I literally was so stupid to use React or any JS tech in the past 10 years when Opal Ruby was available (by the way, it has won a Fukuoka Ruby 2023 award). I would have never overcome my stupidity if I acted like I'm too important or too insecure to admit stupidity or if I lied to myself about it just because "an important person" at "a large rich important corp" said "React.js is good" without questioning it with my own brain, which is why I'm admitting it now. Using Ruby in the Frontend feels like that's the way things should have been 10 years ago if Rails was more creative and didn't bail out on us, Rubyists, by adding Webpacker temporarily for a number of releases instead of adding Opal Ruby as a default. Thankfully, Glimmer DSL for Web comes to the rescue for Frontend Development in Rails web applications. I am literally operating on a whole other level with it over everyone in the Rails community who are using JavaScript right now!

By the way, as far as how I convinced my bosses to use Opal Ruby + Glimmer DSL for Web at work, I did the following:

• During off-work-hours (one weekend, mostly in one day), I built a work app POC (Proof Of Concept) of an Opal Ruby + Glimmer DSL for Web SPA (Single Page Application) by rewriting a sophisticated React page component that had a lot of interaction going on. I proved to myself first that Ruby code is so much simpler and better than JavaScript code.
• As a Senior Software Engineer, I scheduled a short 15-minute demo with my teammates and the CTO to demonstrate a new better way of developing Frontends for our Rails web application that could cut down 12 months of Frontend Development work a year into 6 months. That huge difference in productivity got their attention. I prepared well for the demo, including anticipating questions for the Q&A period. When I did the demo, I made sure to show the Frontend code improvements using Ruby right away and to keep the demo short, like no more than 15 minutes. I had about 15 more minutes of Q&A afterwards because everyone was so excited to ask questions that we lengthened the meeting, and I made sure to provide good answers and not to cop out or naively fall in the trap of accepting negative narratives. I also provided a phased plan for how to implement Opal Ruby + Glimmer DSL for Web gradually in the codebase to manage risk in a Lean/Agile iterative incremental way by starting usage in the internal-facing Admin UI, and then 6 months later, using in the public UI in low-risk features, and 6 months after that, using in the public UI in high-risk features, and 6 months after that, rewriting all React JavaScript code in Glimmer Ruby (the actual phased plan might end up having a shorter timeline for transitions than that, but I had to provide the least risky plan first).
• I scheduled another demo with the Director of Engineering after all my coworkers and the CTO told me they definitely thought Opal Ruby + Glimmer DSL for Web were interesting technologies. He asked me to prepare for him a comparison between the performance of Glimmer DSL for Web vs React. So, I used the POC that I built as a benchmark. It was to my huge delight that it ran ~33% faster in Glimmer Ruby than the React JavaScript version. After I gave the demo (including a performance sub-demo), the Director of Engineering was very impressed and told me he was OK with me integrating Opal Ruby + Glimmer DSL for Web in the week between the holidays and the start of the new year's work when employees get back from their planned vacations. That was last week.

By the way, my work app is not a vanilla Rails app as we are using Webpack using JS bundling for Rails, so I was able to surmount the challenge of integrating Opal with Webpack and finish the integration in about 1 day only. The deployed app loads pages instantly in our cloud Staging environment whether the page assets are JS files generated by Opal or Webpack, which is amazing! Ruby performance in the Frontend is absolutely good for our Rails web app even in a sophisticated SPA webpage.

I am very grateful to have such forward thinking management at my company to enable the use of new Ruby innovations like Glimmer DSL for Web.

Glimmer DSL for Web (open-source Ruby-in-the-Browser Web Frontend Framework) GitHub repo:

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

Glimmer DSL for Web Now Officially Supports Rails 7.1 & 7.2

Glimmer DSL for Web (Ruby-in-the-Browser Web Frontend Framework) version 0.6.4 has been released! It now officially supports Rails 7.1 & 7.2 (Rails 8 support is planned for the future).

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

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

Happy Glimmering!