Hanami 2.3 beta1 is out! This is the one that includes Rack 3 support 🚀
https://hanamirb.org/blog/2025/10/03/announcing-hanami-230beta1/
If you have any questions, join the #Hanami Discord server: https://discord.gg/KFCxDmk3JQ
re:
> How developers sound to non-developers when you talk shop
Ohh yeah! the Rockwell retro encaburator, I featured that in my 2022⁺ #RubyConf talk while talking about #Monads in #ruby
Never again without a contract: dry-validation
https://www.rubyevents.org/talks/never-again-without-a-contract-dry-validation
where I also featured your work, Ryan :)
⁺ wow almost 3 year ago to the date.
#dryrb
The same as you shouldn't work without a contract, our systems should accept external inputs without one, a written, clear and enforceable one. Define the structure & expected payload being aware of their schema, structure & types. Using dry-schema or dry-validation this part is a matter of a few lines of codes covering most of the cases you may find with the cherry-on-top: error handling out-of-the-box and if this not enough with optional pattern matching for results.
Hanami 2.3 beta1 is out! This is the one that includes Rack 3 support 🚀
https://hanamirb.org/blog/2025/10/03/announcing-hanami-230beta1/
If you have any questions, join the #Hanami Discord server: https://discord.gg/KFCxDmk3JQ
Hey, Dry::Struct users... is this "Hash to attributes" thing considered a feature? I find it messy...
I can see the advantages, but I can clearly also see the cons, especially in terms of predictability and debugging...
Took me literally hours to chase a missing object return before I got the hang of this. #ruby #dryrb
Read about ProtoInteractor, a simple business object I created to use with Hanami. It combines:
* The parameter parsing functionality of Hanami Actions.
* Do notation from Dry-Monads.
* Result objects, also from Dry-Monads.
Feedback and corrections (especially) are welcome! Please let me know what you think!
https://rossney.net/articles/protointeractor-a-simple-business-object-for-hanami/
It's a relevant observation because this past week, I've been going hard on an open source side project that I'm hoping to release into the wild in the near future.
It's a #ruby gem for dry-types and dry-struct from #dryrb that gives you the ability to export all of your types and structs to #typescript
This is especially useful when you've got a Typescript frontend receiving responses from a Ruby backend! Being able to share types between the two sides will help keep things consistent and reduce having to maintain duplicate definitions of types.
I've still got a couple of issues to work out but it's getting close.
The two biggest issues I'm working on:
1. Ruby-land dependency resolution - in particular, following references to types from one module to another, and so on, to make sure that types that are referenced by a TS-expored type also get exported, or at the very least, flagged to the user.
2. Typescript-land dependency resolution - any types that depend on other types should have their dependencies exported first. For example, if you have a User type and a Users type which is an array of User, there's a dependency there and User needs to be exported first.
Slowly chipping away on this. I'm eager to get this out for a beta release.
@Sandbagger I'm glad you found that #ruby toy project interesting, the ogpreview was not meant for document #docker with #Rails, but mostly to demonstrate good practices such as Railway Oriented Programming in general and @dry_rb gems in particular.
Also, if you want to go a little bit deeper, you can check the repository for my talk in #RubyConf2022, where it was more about API input validations & in general and #modularity by accident:
Dry Transaction permite que você modele o fluxo de trabalho como uma série de operações independentes. A principal vantagem do Dry Transaction é que ele permite que você mantenha sua lógica de negócios livre de detalhes de implementação. ❤️
Vale apena conhecer. https://dry-rb.org/