00:00:09.780
Hello everyone! I'm super happy to be here. It's a real pleasure to talk to you today. We're going to discuss innovations in the Ruby ecosystem. My talk is titled 'Can We Still Innovate?'—a question I pondered last year. As you may know, I have been working on several libraries for quite a while, but it has been somewhat challenging at times. While observing our community, I noticed some great Ruby developers, my good friends, leaving Ruby. At that moment, I thought, "Well, maybe I should do the same." Coincidentally, however, I also noticed many positive developments in our community. The community is expanding, with more projects, people contributing, providing feedback, and helping with issues. This positivity energized me, and ultimately, I realized that everything is fine. So you don’t have to wait an hour to get an answer to this question: yes, we can still innovate.
00:01:25.470
A little about me: I'm a software developer working for a company called Mojo Tech, a software development and design agency located in Providence, Rhode Island. I also work on open source projects during my so-called spare time. The first project I want to highlight is Ruby Object Mapper, and the second one, which is a bit younger, is called Dry RB, which we established last year. I will use these projects as examples of some innovative ideas within the Ruby ecosystem.
00:02:40.380
First, I want to discuss what it actually means to innovate. Innovation involves making changes to something that is already established. Both aspects are challenging because changing software is inherently difficult, and altering established norms poses even more difficulties. We tend to become accustomed to specific solutions, knowing how to solve certain problems in particular ways, and we have our preferred tools that enhance our productivity, providing a sense of comfort in their use. The task of challenging these established norms and attempting to change them—essentially improving them—is quite difficult.
00:04:00.240
To provide some context, I want to reflect on what has happened in our community over the last ten-plus years. Between 2005 and 2010, there was a tremendously interesting period in our community's history. This era began with Rails, which was revolutionary. Rails was a technology that significantly innovated how people approached web application development. It improved productivity in writing software.
00:04:48.660
One key aspect of Rails that we often take for granted today is the principle of 'convention over configuration.' This concept has deeply influenced the entire community along with our mindset, shaping the way we use our software and raising our expectations for Ruby libraries and frameworks.
00:05:10.440
The first aspect of 'convention over configuration' is that it significantly increases productivity. When we start using a new tool, the fact that it just works out of the box means we don't have to spend much time on configuration or writing extensive code. However, after years of working in this manner, there has been an interesting impact on our mindset surrounding libraries and software development in general.
00:06:00.240
At some point, we realized that the term 'model' was ambiguous; nobody quite knew what it meant. Many developers associated 'model' primarily with Active Record. This led to several explorations and experiments to deal with complexity in our applications—this discussion ignited around 2006, identifying our enemy: complexity. It was clear that our applications were growing more complex, and we needed to address this issue.
00:07:12.150
Years passed, and throughout 2007 to 2009, we experimented with various approaches to managing complexity. Ideas such as Domain Driven Development and Data Context Interaction emerged. Discussions surrounding the data mapper pattern became pivotal, leading to efforts to separate data persistence from domain logic. This was the foundation for broader experimentation around simplifying data handling, setting the stage for more impactful innovations.
00:08:44.760
In 2008, both the Rails and MERP teams decided to collaborate to create a robust full-stack framework that followed the convention over configuration principle. The release of Rails 3 in 2010 represented a significant milestone in our ecosystem, incorporating many ideas from MERP, thereby improving modularity and performance. However, discussions about handling complexity within large Rails applications persisted. The ongoing complexity posed pressing concerns that needed strategic solutions.
00:10:34.410
Over the following years, various Ruby gems emerged, focusing on different aspects of application development and addressing the complexities associated with traditional patterns like Active Record. For instance, the introduction of MERP illustrated an innovative approach to building applications, showcasing features like faster Ruby frameworks and modular structure, which sparked further creativity in development practices.
00:12:21.250
As the Ruby community evolved, we recognized the importance of embracing innovation. This collective journey began shifting paradigms, allowing developers to explore unique solutions beyond conventional setups. The iterative process involved uncovering the value of new frameworks while maintaining an openness to experimentation and constant learning.
00:14:01.140
The rise of libraries like ROM and Dry RB exemplified this ongoing evolution. While traditional paradigms were questioned, the Ruby ecosystem donned new ventures, utilizing insights and experiences gained from earlier frameworks to forge paths that prioritize simplicity, performance, and distinct conceptual foundations.
00:15:38.710
The innovations in the Ruby ecosystem are numerous, and I have discussed various projects that I have been involved with. However, it's important to highlight that they are not the only advancements occurring. The beauty of our community is in its diversity and willingness to innovate. There are many interesting gems like Hanami and Trailblazer emerging, along with countless smaller libraries aiming to solve unique challenges in our development processes.
00:17:39.740
As I conclude, I'd like to emphasize that innovation is a continuous journey, remarkable in its unfolding. Engaging in discussions on programming abstractions, new ideas, and code development fascinates me. Staying curious and open to new methodologies allows us to perceive the evolving landscape of Ruby development in a brighter light.
00:18:50.640
With the remaining time, I'll take questions. I am eager to discuss any aspect of Ruby, programming techniques, or the innovative directions we can explore. Thank you for your time today!
00:20:03.330
In response to the audience question about innovation in the Ruby language itself, there are many changes I'd love to see. For instance, unifying the functionality of method objects and lambdas, addressing the long-standing proposal for a proc composition operator, and finally tackling mutability concerns in Ruby to allow for true immutability without performance drawbacks.
00:20:32.258
Furthermore, fostering the concept of first-class functions, similar to constructs in Scala, could greatly enhance Ruby's capability. I believe that such changes would add significant value to the language but require careful consideration and clear implementation strategies.
