Let’s learn and work together on Hanami at Baltic Ruby’s OSS Expo! 
Day two of Baltic Ruby 2025 will feature an OSS expo, where conference-goers can get together with representatives of a range of Ruby projects. I’ll be at the OSS expo and ready to help you with Hanami!
At the expo, you can:
- Make your first Hanami app
- Make your first contribution to Hanami itself
I can be there to support you in both.
Who am I? I’m Tim Riley, the lead of the Hanami, Dry and Rom projects. I’ve been driving the Hanami 2 development over the last 5+ years.
Who are you? You can be anyone at the conference! All are welcome! Regardless of your experience level, please come along and I can help you learn the Hanami ecosystem and put together your first contribution to the project.
This rest of this post will serve as your getting started guide to Hanami development, and a source of ideas for your contributions.
Getting started
Hanami projects are fairly typical Ruby projects. Here’s how you can get started for development:
- Clone the repo
- Run
bundle install - Run
bundle exec rake specto run the tests
That’s it! If there are any other specific requirements, these will be noted in each repo’s README.
Hanami consists of multiple repos. Your contribution will likely be in one of the following: hanami, cli, db, controller, router, view, assets, assets-js, rspec, webconsole.
Hanami also depends on gems in the dry-rb and rom-rb organisations.
Ideas
General
Update the README in new Hanami apps with helpful instructions
Right now the README in new Hanami apps is fairly bare-bones. It could come with some more useful instructions for getting started with Hanami. Let’s get them in place!
Some work on this was done in hanami/cli#273, though further improvements could still be made.
Tidy up all inspect outputs
Some of our framework-level objects have rather large (and confronting!) #inspect outputs. These can get in the way, especially when interacting with objects in the console or in our error pages. Let’s slim these down and get them to a place where they help rather than hinder our users. (Hint: Hanami::View#inspect’s output is particularly thicc).
Memoize actions and views in the container, measure performance impact
Right now our app and slice containers return new instances of these objects every time they are fetched. Instead, we could have the container set up these components using the memoize: true option, which would mean the same object is returned each time. We expect this may bring some good performance improvements! Let’s make this small adjustment, and then measure the impact.
Add built-in i18n support to Hanami
Right now we don’t offer this. But it would be very helpful! To add this, we can create a first-party provider that sets up i18n for our users, with configuration allowing for i18n yml files in conventional locations (within the app and within each slice). Along with this, we’d need a helper method for accessing i18n translations inside views.
As a flow on from this, it would also mean we could start to offer other view helpers that depend on i18n, like Rails’ number_to_human.
CLI
Create a hanami generate provider command
Users only occasionally need to create providers. Having a generator to do this will help them remember the right syntax to do so, and could provide some helpful tips via code comments in the generated file.
Rationalise the output of all the hanami db commands
Right now these provide differently formatted output lines depending on whether their operations are timed or not. This makes for a disjointed experience. It would be better for this output to be simplified and made consistent. We don’t need the timing information. We also need clearer details certain commands.
Improve output when avoiding file overwriting
Our CLI will not overwrite existing files, but the command output in this situation could be made clearer and more helpful.
Provide more helpful output when unknown options given to a command
Right now when you provide an incorrect argument, you’ll see output like this:
❯ be hanami generate relation posts --fnorp
ERROR: "hanami generate relation" was called with arguments "posts --fnorp"
This should be more useful. It should show the details of the command and the options that are actually available.
Allow for third party code extending existing CLI commands to register their own specific options on those commands
Gems can enhance existing registered hanami CLI commands using Hanami::CLI.after "some_command", but they cannot add new options to the command. We should allow this.
Bring some 
pizazz to the CLI experience
Right now the user experience of the hanami CLI experience is fairly basic. We want Hanami to be a framework that brings both power and delight, and the CLI is our front door. This is a great chance to make it nicer!
For example, our hanami new output is fairly basic. This is the very first thing people see when they try Hanami. Can we bring some “wow” factor here?
And in general, look for anywhere we might provide more sparkle to our CLI outout
Database
Make Deps work inside Repos
This is a nice and easy one-line fix! (Plus a new test)
Hanami::DB::Testing.database_url should apply to explicitly configured database URLs, not just ENV-detected URLs
Update rom-factory to support a configurable inflector
Right now, rom-factory’s inflector usage is hard-coded across multiple files (search for “inflector” to see). Instead, it should be possible to supply an inflector when creating/configuring the factory itself. This would allow a future Hanami integration to provide the Hanami app inflector.
Controller
Allow exception names represented as strings in Hanami::Action.handle_exception
See this issue: right now we require a proper Ruby exception class here, which means that users may need to require libraries that have nothing to do with actions, merely so they can rescue their exceptions. Using strings here would free users from having to have everything required at this point.
Zero-config cookie session configuration
Most users of Hanami web apps will need to set up cookie sessions. Requiring them to add their own config for this is a little bit of a hurdle, so it would be good if we could find a way for hanami to do this via some conventional ENV vars or similar.
View
Provide a nicer Hanami::View::TemplateNotFoundError message
This error message is OK right now, but we could make it even more helpful by suggesting as closely as possible which file the user should be creating.
Docs and guides
Update our building a web app guide to set up some CSS/JS
Right now this guide doesn’t step through creating CSS or JS, and instead just points to the frontend assets guide for the user to figure things out for themselves. It would be good if we could instead add some basic CSS and JS as part of the getting started guide itself.
Help us make some “app recipes!”
If you’re more interested in direct user enablement, then you could just get started building a Hanami app and helping create examples/documentation for users about using Hanami with various tools. For example:
- Sidekiq + Hanami
- Rodauth + Hanami
- Shrine + Hanami
- A full CRUD example app
- And so on…