Montreal.rb October 2024 - Tame Complex Queries with Database Views

The Montreal.rb October 2024 talk "Tame Complex Queries with Database Views" had its video, slides, and code posted.

YouTube Video: 

https://youtu.be/gdrscLBNvDo

Presentation Slides: 

https://davidcornu.github.io/views-demo/

GitHub Code Repository: 

https://github.com/davidcornu/views-demo

Talk Description:

PostgreSQL views are a useful tool to make query logic reusable and maintainable. This talk will cover their pros and cons, a couple of real-world use cases, and how to use them in Rails apps using the Scenic gem.

Happy learning!

JavaScript is a disease! Ruby is the cure!

In a recent Ruby meetup, I called JavaScript a disease! It is true! Especially, when comparing JavaScript code to much better, more elegant, and more readable Ruby code! JavaScript looks like ugly smelly mold by comparison. Once you see it, you can never unsee it! That's why I wouldn't touch JavaScript with a ten foot pole if I can help it. I would use Frontend Ruby instead (e.g. Opal Ruby, WASM, or Ruby2JS). Opal Ruby can usually be setup in about 10 minutes in a Rails app (https://github.com/opal/opal-rails), and it yields smaller downloadables than WASM. I am not sure why anyone in 2024 would go through the Hell of JavaScript in their otherwise pristine Ruby on Rails codebase instead of actually entering Heaven by using Frontend Ruby! Opal Ruby has won a Fukuoka Ruby 2023 Award and supports Ruby 3.1 with the ability to use any pure Ruby gems in the Frontend by simply including them in Gemfile. That removes the need for a complicated JavaScript bundling beast like Webpack. In the past, I might have advocated for still using JavaScript in smaller apps, but the barrier of integrating modern Ruby into the Frontend of Rails applications has become so non-existent with Opal, there are no more excuses for using JavaScript in a Ruby on Rails codebase. 

Yahuda Katz mentioned in his keynote speech at RailsConf 2014 (https://youtu.be/9naDS3r4MbY?t=1195), which borrowed ideas from Steve Jobs, that by continuously building more floors for the lower levels of a building in the form of a framework and a community of open-source projects, we enable developers to start development at higher and higher levels than they would have been able to otherwise, thus helping them leapfrog earlier ways of development in ever increasing productivity! In 2024, Frontend Ruby (e.g. Opal) is the next floor level that enables Ruby Software Engineers to start at a higher level of development with much higher productivity and maintainability. I strongly believe that anyone who is not using Frontend Ruby in 2024 is at least half as productive as those who are using Frontend Ruby in their Rails development, regardless of whatever framework they are using. I don't care if someone is enamored by some "cool JavaScript framework xyz"; try to implement that framework in Ruby, and IT WILL BE EVER COOLER AND BETTER IN RUBY! Or, in certain instances, you will discover that Ruby is so much simpler than JavaScript, YOU DO NOT EVEN NEED the "cool" JavaScript frameworks as they are UNCOOL IN RUBYLAND! Glimmer DSL for Web is one Frontend Ruby Framework example that demonstrates the unique simplicity/readability of Ruby that is unmatched by cryptic/too-clever JavaScript code: https://github.com/AndyObtiva/glimmer-dsl-web

JavaScript is a disease! Ruby is the cure! Don't be part of the problem by using JavaScript in Ruby on Rails codebases! Be part of the solution by using the language we all love, Ruby, isomorphically in Ruby on Rails applications in 2024 and beyond! 

Ruby Rogues Podcast - Building Better Ruby Apps: Glimmer's Component Slots and More

I appeared in the Sep 25, 2024 episode of the Ruby Rogues podcast titled:

Building Better Ruby Apps: Glimmer's Component Slots and More - RUBY 653 - Ruby Rogues - Top End Devs

My RubyConf 2024 2-hour workshop "How To Build Basic Desktop Applications in Ruby" was mentioned in the podcast.

Web Podcast link:

https://topenddevs.com/podcasts/ruby-rogues/episodes/building-better-ruby-apps-glimmer-s-component-slots-and-more-ruby-653

Apple Podcast link:

https://podcasts.apple.com/us/podcast/building-better-ruby-apps-glimmers-component-slots/id1237406856?i=1000671137874

Amazon Music Podcast link:

https://music.amazon.ca/podcasts/e1608c49-b50a-4450-94a2-673ce74e6cc7/ruby-rogues

Glimmer DSL for Web:

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

Glimmer DSL for LibUI (Fukuoka Ruby 2022 Special Award Winning):

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

Glimmer (top-level engine used in all flavors of Glimmer):

https://github.com/AndyObtiva/glimmer

Laptop Instructions for RubyConf 2024 Workshop "How To Build Basic Desktop Applications in Ruby"

My RubyConf 2024 2-hour workshop "How To Build Basic Desktop Applications in Ruby" has been added to the RubyConf schedule. It requires attendees to follow setup instructions on their laptops before attending the workshop to hit the ground running at the event. 

The workshop will take place at "Salon A2" in the Hilton Chicago Downtown hotel (Chicago, Illinois, USA) on Day 2 (Thu, Nov 14, 2024) from 11:15am till 1:15pm. 

Full workshop material will be published on the day of the workshop at the GitHub repository below, which in the meantime includes setup instructions that must be followed on your laptop before attending the workshop (please bring your laptop to the workshop):

https://github.com/AndyObtiva/how-to-build-desktop-applications-in-ruby

After lunch, the workshop theme will continue in a Hack Day event at "Main Stage - Ballroom South" from 3:45pm till 5:45pm, in which #RubyConf attendees could continue learning and playing around with Ruby desktop exercises, build desktop applications individually or in collaboration with others, and/or ask me questions about desktop development in Ruby.

Lack of Support in the Software Engineering Community Violates The Software Engineering Code of Ethics

Some Software Engineers mention "not being interested" as an excuse not to help someone with something that could benefit customers or the Software Engineering community at large when the real reason is in fact covert discrimination against that person and lack of effort to treat them as an equal and equally respected member of their community. Know that Software Engineers have to abide by the Software Engineering Code of Ethics: 

https://www.computer.org/education/code-of-ethics

And, it includes the statements: 

• "Software engineers shall act consistently with the public interest."
• "Software engineers shall be fair to and supportive of their colleagues."

So, if someone gives you an excuse of "not being interested" to avoid helping you out with a public interest matter out of discrimination against you, know that they have conducted themselves in an unethical manner, and remind them of what they signed up for when they became Software Engineers, whether implicitly or explicitly.

This even extends to matters like Software Engineers not wanting to check out certain technologies/libraries that could greatly help the public interest just out of discrimination against the technology/library creators. It also covers matters of Software Engineers not wanting to learn and improve certain skills through frequent attendance of local user groups that can improve the practice of their profession.

After all, that is covered by the statement: 

"Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession."

I am including the short version of the Software Engineering Code of Ethics below for your convenience:

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC – Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

3. PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT – Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION – Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. COLLEAGUES – Software engineers shall be fair to and supportive of their colleagues.

8. SELF – Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

Ethical Disagreement Demands Sharing Reasons and Allowing Debate

When ethical Software Engineers disagree about something, they always share with others their reasons for disagreement because they care about others' well-being and want to provide them feedback to help them course-correct when they are wrong for the benefit of the community at large. Also, ethical Software Engineers always humbly open themselves up to debate to acknowledge the possibility of being wrong and to benefit from correction if needed. By sharing their reasons for disagreement and allowing others the room to debate, they objectively explore the topics of disagreement until they arrive at a mutual understanding with others whereby both parties either correct themselves gradually or reveal points that the other party was not aware of until they resolve all of the disagreement successfully.

As such, telling others the reasons for disagreement and staying humbly open for debate are two very important characteristics in ethical Software Engineers that are required for effective team work. 

Software Engineers who try to avoid providing their reasons for disagreement not only show a lack of care about improving the knowledge of the other party and community at large to improve collective work quality long term, but they are sometimes masking hidden discrimination against the person they are disagreeing with. Sometimes, they do not want to accept a correct version of the truth from someone else just because they do not personally like that person or actually hate that person, and do not want to treat them with equality or as equals to all members of society, yet want to maintain a higher ground above them. Silencing debates becomes then a tool for masking discrimination because if no debate takes place, the disagreeing Software Engineer who does so purely out of discriminatory reasons could never be found out. In other cases, getting unreasonably angry and silencing debates happens simply to avoid revealing lies that the Software Engineer believes and lives at the expense of everybody else, which they want to maintain to keep a lazy or incompetent work ethic while customers and other Software Engineers are paying for their laziness and incompetence. It is like someone who wants to continue to believe in Santa Claus at the expense of everyone else instead of hearing and accepting the truth, by requiring everyone else to work hard at maintaining the lie that Santa Claus exists in all their interactions even if that lie is basically hindering work quality significantly for customers. 

In summary, ethical Software Engineers always provide reasons for their disagreement while humbly opening themselves up for debate. Not providing an explanation for the reasons of disagreement and silencing debates are often immediate tell-tale signs of a non-equality-minded discriminator. If someone avoids telling you what they disagree about and do not want you to debate the disagreement any further, know that it is a red herring as they are not treating you with equality and objectivity, or are masking a lie that they want to live at the expense of others.

10x Developer Puzzle, Solved!!!

Here is a thought! The mythical 10x Developer is simply a developer that eliminates 9/10 of unnecessary over-engineered code, and then writes the remaining 1/10 of the code needed at the productivity rate of a 1x Developer!

Such a developer might come across as a 10x Developer to others when in fact, all they are is a 1x Developer that knows how to cut the fat of over-engineering out and avoid unnecessary overhyped libraries/languages/technologies to eliminate 9/10 of development waste and only do 1/10 of the work otherwise done. 

I believe I have just solved the 10x Developer puzzle for once and for all! The 10x Developer mystery has been demystified for good!!

P.S. Of course, there is no I in a team! What was mentioned can be followed by all members of a team. In the end, it is not about any individual in a team. It is about the team delivering the best work possible for customers.