Thursday, October 31, 2024

Montreal.rb May 2024 - Hotwire Turbo in Rails: Drive, Frames and Streams

The video of the Montreal.rb May 2024 talk "Hotwire Turbo in Rails: Drive, Frames and Streams" by Helmer Davila has been finally posted on YouTube:

https://www.youtube.com/watch?v=rmsBVsZUHzI&list=PLRAf4zt5oEjc2mqmEN9m_O0JovQCXxvxt&index=13

Talk Description:

In this talk, we will be exploring Hotwire Turbo in Rails, focusing specifically on Drive, Frames, and Streams. We will dive deep into how Hotwire Turbo enhances the speed and performance of Rails applications, providing users with a smoother and more interactive experience. We will also shed light on the concepts of Drive, Frames, and Streams, discussing their roles and how they contribute to the overall functionality of a Rails application. Whether you're a seasoned Rails developer or just getting started, this talk will offer valuable insights into optimizing your applications with Hotwire Turbo.

Speaker Bio:

Helmer Davila is a Senior Software Developer with over nine years of experience in Full Stack Web Development and a bachelor's degree in Computer Science. His comprehensive experience, gained from full-time and freelance roles, has equipped him with a deep understanding of various market frameworks, with Rails and Laravel being his favorites. He also co-founded a food delivery startup in Peru. His hobbies include biking, traveling, writing, and learning new languages like Italian and Portuguese.

Happy learning!

Saturday, October 19, 2024

Glimmer DSL for Web Component Custom Event Listeners / Component Slots / Default Slot

Glimmer DSL for Web (Ruby-in-the-Browser Web Frontend Framework) recently added support for Component Custom Event Listeners, Component Slots, and Default Slot in the 0.5.x & 0.6.x version releases. The new samples Hello, Component Slots!, Hello, Component Listeners!, and Hello, Component Listeners (Default Slot)! have been added as well and can be played around with in an online hosted Rails Sample Selector web app (the app takes a while to load because of cheap hosting, but once it loads, it is fast in the Frontend).

Component Slots is a feature that enables consumers of a component (e.g. address form) to contribute visual elements in one or multiple slots within the component (e.g. address form header and footer), thus facilitating extension of components following the Open/Closed Principle. The consumer code would just open a block matching the component slot name inside the content block of the consumed component.

Hello, Component Slots! is a new sample that demonstrates Component Slots. Notice how the 2 address forms are augmented with a header and footer inserted within their content.




Component Custom Event Listeners is a feature that enables component consumers to add listeners for custom events that are specific to certain components. Those events can be declared at the top of a component class via the `events :event1, :event2, ...` method. For example, an accordion component can support `on_accordion_section_expanded` and `on_accordion_section_collapsed` custom event listeners (via `events :events :accordion_section_expanded, :accordion_section_collapsed`), which consumers could hook into via `on_eventxyz` blocks in order to do some work when those events fire.

Hello, Components Listeners! is a new sample that demonstrates Component Custom Event Listeners with an `accordion` component that has expandable/collapsable sections. Each AccordionSection supports on_expanded and on_collapsed event listeners, and the full Accordion supports on_accordion_section_expanded and on_accordion_section_collapsed event listeners.


Default Slot: If a Software Engineer knows that a specific component slot will be the one used the most for a certain component (e.g. a slot for inserting content into an accordion), they can designate it as the default slot. That way, by simply adding content inside the content block of a consumed component, it will get added automatically to the default slot.

Hello, Component Listeners (Default Slot)! leverages this feature to simplify the consumer code for the AccordionSection component section_content slot in the Hello, Component Listeners! sample.


Monday, October 14, 2024

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!

Friday, October 11, 2024

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! 

Monday, September 23, 2024

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.


Monday, September 16, 2024

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.