00:00:16.430
It’s a pleasure to come back to Ruby Day. I have a strong connection with this conference because I am Italian. Ruby Day feels like Christmas to me.
00:00:22.070
It’s a time when I see familiar faces that I haven’t seen for a year. We come here, hug each other, cheer, and then another year passes.
00:00:29.630
Thank you, Crisp, for bringing this Christmas spirit once again this year. I lost my control here due to a technical problem, but we will overcome it.
00:00:35.210
The last time I was here was not last year, but a few years ago. Hanami was still called Lotus for those who didn’t know.
00:00:49.460
We have a lot to discuss today, including a look at the future. But before we dive in, let me introduce myself. My name is Luca Guidi, and I am the author of Hanami, which is an open-source project.
00:01:04.640
Specifically, it’s a web framework for Ruby. I work remotely from Rome, Italy, for a company called DNSimple.
00:01:11.810
We provide domain registrations, DNS, SSL Certificates, and everything can be automated through an API written with Hanami. Hanami has been battle-tested with this API.
00:01:17.509
If you are looking to build your infrastructure automation, I encourage you to check it out. I have stickers and t-shirts, so make sure to say hi.
00:01:23.869
We will discuss everything related to Ruby and Hanami.
00:01:31.069
Quickly, a digression about Hanami 1.0: Lotus was eventually renamed due to copyright issues.
00:01:38.679
There was a strong demand for 1.0 because people wanted to know if Hanami was stable and production-ready. It was being used by several companies for a long time.
00:01:49.729
I understand the concern because Hanami, being an open-source project, involved a substantial amount of investment.
00:01:55.910
People wanted to know if the design was stable enough for companies to invest in.
00:02:02.590
I want to send a strong signal to the community: enough testing. This is no longer an experiment.
00:02:08.599
This is something we are using to build projects where money is involved, and you can do the same.
00:02:15.590
I released 1.0, but I wasn't 100% satisfied with the design, which is a natural part of creative work.
00:02:21.020
Filmmakers and writers often postpone release dates until their products are perfect, but perfection never truly materializes.
00:02:26.150
We have a multitude of ideas, but only a few are worth implementing in software.
00:02:32.070
I faced a chicken-and-egg problem. I wanted Hanami to organically evolve as a software project but needed to take a decisive step.
00:02:38.490
Releasing 1.0 was the best decision because I needed to stop and move on to the next chapter of this project.
00:02:45.420
Taking that step was also advantageous because, working with just a few people on the team, our vision was narrow.
00:02:51.480
With 1.0 and substantial community feedback, we leveraged collective intelligence to uncover insights about our software.
00:02:57.510
It's a paradox that sharing improves the outcome. We have all experienced this in open source.
00:03:02.850
Thanks to feedback, we saw a 30% growth in our adoption rate last year.
00:03:09.090
With all this feedback, we decided to maintain the strengths of 1.0 while reshaping the software.
00:03:16.860
Today, I want to outline the principles behind Hanami 2.0.
00:03:22.530
We are still refining the code structure, but I want the community to understand our intentions.
00:03:28.170
Seeing the software directly may lead to questions that I hope to answer today.
00:03:34.770
Here is a high-level perspective of what Hanami 2.0 will look like. We aim to keep the same features but reshape them.
00:03:43.560
Hanami is sufficient for building web applications; it’s simply a matter of restructuring how components are arranged.
00:03:49.560
Some existing principles, like strong OOP and stability of use, will remain unchanged.
00:03:56.400
These principles are fundamental to the development process.
00:04:02.850
We only want to add more value to our framework.
00:04:07.360
The first principle is simplification, which comes from community feedback. Hanami 1.0 was optimized for productivity.
00:04:15.400
It includes an impressive CLI tool with code generators and test integration.
00:04:22.630
However, we observed a ‘what you see is what you get’ approach.
00:04:28.120
For instance, by typing `hanami new Instagram`, a multitude of settings is generated.
00:04:35.919
This means you won’t have to guess anything about the project structure. Everything will be explicit and documented.
00:04:41.680
Inside a Hanami application, it can host multiple apps within the same Ruby process.
00:04:49.460
For example, you could have a standalone web application, an admin panel, and an API.
00:04:56.589
We believe in a monolith-first approach; there is nothing quicker for your product in the first few years.
00:05:04.520
Deploying everything in the same codebase is more efficient.
00:05:11.280
Microservices are intriguing, but there's little incentive to invest in them initially.
00:05:17.670
There are also strong boundaries inside each application, which I want to clarify.
00:05:25.560
Each application within Hanami has its own customizable settings.
00:05:30.770
This includes settings like sessions, cookies, assets, and content security policies.
00:05:41.680
In our music Instagram example, we will have three applications, each maintaining its configuration.
00:05:49.110
While I initially thought this behavior would help, it turned out to be overwhelming for newcomers.
00:05:56.400
Developers tried to parse every setting generated, leading to confusion.
00:06:03.800
The principle of simplification for Hanami 2.0 will unify all settings in one place.
00:06:10.410
We aim for a more streamlined approach with a minimal amount of generated code.
00:06:16.410
You’ll only set the necessary configurations, making it easier for newcomers.
00:06:23.070
We aim to reduce verbosity and improve performance within Hanami 2.0.
00:06:30.690
Previously in 1.0, we had multiple routers for standalone apps, which was inefficient.
00:06:38.970
In Hanami 2.0, we will simplify this by merging everything into a single router.
00:06:44.310
The second principle focuses on blending functional programming with OOP.
00:06:51.130
This can be challenging to grasp, but I will clarify.
00:06:58.220
We have seen a rise in functional programming languages like Elixir, influencing many Ruby developers.
00:07:06.270
While we are here at Ruby Day, we want to leverage Ruby but also draw inspiration from functional programming.
00:07:12.760
Ruby is a multi-paradigm language, and we can use its features to build better code.
00:07:21.170
The first concept I want to mention is pipelines.
00:07:27.760
Traditionally, we think in terms of MVC applications, but let’s rethink this structure.
00:07:34.510
MVC leaves developers alone to manage the most complex parts—our models.
00:07:41.910
Models include all business logic, database interactions, and validations.
00:07:49.630
The role of a web framework is to direct you on how to structure your features.
00:07:57.430
If we consider Instagram, it comprises various features such as sign in/out and picture uploads.
00:08:05.020
Rethinking each feature as a pipeline of steps allows for a clearer understanding of the application.
00:08:12.780
Each step in this pipeline has a single responsibility.
00:08:18.450
Each step takes an input, processes it, and returns an output, functioning as a small algorithm.
00:08:25.520
This approach can lead to a more manageable and elegant design.
00:08:31.480
By implementing each step as a single-purpose object, we adhere to the single-responsibility principle.
00:08:39.110
This beautiful connection between functional programming and OOP leads to better structured applications.
00:08:45.360
These features, when built as a pipeline, can be composed to create more complex functionalities.
00:08:52.640
The equivalent in functional programming would be small, single-purpose functions.
00:08:59.740
Each function performs a specific task, and together, they can accomplish more complex operations.
00:09:06.080
Next, let’s talk about how these components should communicate.
00:09:13.870
Like LEGO bricks, they should be compatible and communicate effectively.
00:09:20.040
Taking inspiration from UNIX, we see how simple tools can be combined to create complex applications.
00:09:26.700
In the Ruby community, we’ve successfully integrated web frameworks and servers, enhancing connectivity.
00:09:33.230
The beauty lies in the simplicity of our approach, allowing seamless communication.
00:09:40.440
Now let's cover callable objects.
00:09:47.190
A callable object performs tasks through a single exposed method.
00:09:54.090
If we refer back to our upload file example, we see a straightforward object accomplishing a specific task.
00:10:00.580
This makes it easy to understand and reuse, meeting our goals of clarity.
00:10:07.909
Additionally, dependency injection becomes vital for managing your application's structure.
00:10:15.440
Effective dependency management simplifies your code and enhances its maintainability.
00:10:22.370
For clarity in code reading, rely on the initializer to understand dependencies rather than guessing.
00:10:31.220
Using dependency injection aids in testing your code.
00:10:36.740
Maintainability is essential; a good design is one that can be easily understood and extended.
00:10:43.150
To achieve this, we need our objects to be deterministic, meaning the same input yields the same output.
00:10:50.280
This predictability is key to avoiding bugs in your applications.
00:10:56.830
Avoiding shared mutable states aids in producing more reliable software.
00:11:03.040
Likewise, immutability simplifies coding patterns and enhances performance.
00:11:10.240
Using immutability allows us to maintain the integrity of data throughout our applications.
00:11:16.940
In Hanami 2.0, components will be immutable to minimize complications.
00:11:23.100
The result is a streamlined interaction between the database and each incoming request.
00:11:29.380
Ultimately, using these principles minimizes the complexity associated with Ruby garbage collection.
00:11:36.780
Lastly, I want to emphasize that our community-driven approach is essential.
00:11:43.880
Software is created by people, for people, and we must remain open to community feedback.
00:11:50.460
Collaboration fosters stronger ecosystems. We’re teaming up with ROM and Dry.
00:11:57.490
Our shared goal is to unify our projects, eliminating redundancy.
00:12:05.110
We will integrate these projects to build Hanami 2.0 effectively.
00:12:11.240
The timeline for our goals is projected by the end of the year.
00:12:18.720
The essential part is our collaboration, leading to a stronger Ruby ecosystem.
00:12:25.580
Our focus is on fostering a culture of sharing and integrating our experiences.
00:12:32.070
To conclude, when 2.0 will be released is still unclear, but we’re making progress.
00:12:39.090
I believe the future of Ruby is bright, and we’re entering an exciting era.
00:12:47.530
The possibilities that these developments can bring to your daily work are incredible.
00:12:54.250
Thank you.