Summarized using AI

Hanami 2.0

Luca Guidi • April 11, 2019 • Verona, Italy • Talk

In this video titled 'Hanami 2.0,' Luca Guidi discusses the evolution and upcoming features of the Hanami web framework, previously known as Lotus, at the Ruby Day 2019 conference. The talk highlights how feedback from the community has been instrumental in shaping Hanami 2.0 into a more streamlined and efficient tool for Ruby developers. Guidi reflects on the journey of Hanami from its first release to its anticipated improvements, emphasizing the importance of community collaboration in open-source projects.

Key Points Discussed:

  • Introduction to Hanami:

    • Hanami is a web framework for Ruby, designed for productivity and efficiency in web development.
    • Guidi works remotely for DNSimple and advocates for using Hanami in automation projects.
  • Transition from Lotus to Hanami:

    • The framework was renamed due to copyright issues, and its stability has been tested in production environments.
    • Community feedback led to a significant adoption rate increase of 30% in the past year.
  • Principles of Hanami 2.0:

    • Simplification:
    • Hanami 2.0 focuses on reinforcing a ‘what you see is what you get’ approach, providing clear project structures and configurations.
    • The goal is to ease the onboarding process for new developers by minimizing complexity in settings.
    • Blend of Functional Programming with OOP:
    • Encourages rethinking the structure of applications from MVC to pipelines, promoting a better understanding of application features.
    • Highlights the importance of single-responsibility components for improved clarity and reusability in code.
  • Communication and Structure of Components:

    • Components should be compatible and able to communicate effectively, drawing parallels to UNIX philosophy.
    • Guidelines on the use of callable objects and dependency injection to enhance code simplicity and maintainability.
  • Community-driven Approach:

    • Continual community engagement will streamline development and unify projects within the Ruby ecosystem, particularly collaborations with ROM and Dry.
    • The timeline for Hanami 2.0’s release is uncertain, but the commitment to progress is clear.

Conclusion:

  • Guidi expresses optimism about the future of Ruby and the potential positive impacts of Hanami 2.0 on developers' daily work. He emphasizes that collaboration, simplification, and feedback are vital for crafting a successful framework that meets community needs.

Hanami 2.0
Luca Guidi • April 11, 2019 • Verona, Italy • Talk

Hanami is being reinvented. We learned from experience, and community feedback, how to build a much more simplified, fast, and productive framework. This is a preview of how Hanami 2.0 will work.

rubyday 2019

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.
Explore all talks recorded at rubyday 2019