Overall I think the focus with clean syntax/DSLs in Ruby projects with pervasive metaprogramming is one of the reasons the code is so hard to maintain.
Overall I think the focus with clean syntax/DSLs
in Ruby projects with pervasive metaprogramming
is one of the reasons the code is so hard to maintain.
However, in general, I wholeheartedly agree with your statement. Sometimes Ruby frameworks get way too cute with the metaprogramming.
:-)
I wrote a wrapper that handles/maintains multiple hanami apps and makes plugin usage easy with multiple projects I use them in. Everything gets deployable with capistrano. I run a few sites with more or less complex features and quite happy with it.
Will see how the migration goes...
Grats to 2.0 and kudos to the hanami guys! Great software.
Oh, yes, of course. But I am only willing to work for 6-7 hours a day, 5 days a week and my employer pays for them all. Working outside that... nah, no need.
If your app uses Hanami and Zeitwerk, for example, breaking changes in Zeitwerk may REQUIRE you to update Zeitwerk before you can upgrade Hanami. Or, if dry-rb hasn't adopted the new version of Zeitwerk, you may be stuck on an old version of Zeitwerk, unable to update it. Depending on the nature of the breaking changes, working through this stuff could be a lot of work for a mature app.
Maybe the maintainers are nice and release patch versions for older major releases. I don't know. What I do know is that either way, there is likely to be a lot of maintenance burden somewhere unless these libraries have high stability guarantees.
I don't understand the Rubyist obsession with having a whole bunch of magic stuff just "happen" in your code. Magic is fine if the scope is narrow and well-defined. Ruby magic is often _entire app magic_, which means that it is hard to approach (because you need to understand how it works in many contexts). If that magic ever changes, there are a lot more places where it can break stuff.
What would your successor prefer when they take over: Bob's ad-hoc framework built from the ground up where they don't know how anything works, or some app implemented on top of a framework they've used in 10 other jobs?
While I agree that using frameworks like rails/django/hanami/react has an upfront cost, it's so hard to justify doing your own thing if your usecase is fits within what they offer.
The obsession with magic is actually more an obsession on developer speed and ease because that is the biggest cost and driver of software. The magic also promotes following well tested patterns.
You seem to be advocating a dependency free path where the developer builds everything from scratch. Totally a valid approach but at the cost of development speed and ease. It also results loss of the collective knowledge of a community.
I love Rails but have used Sinatra and Padrino in the past. The knowledge you get using these frameworks can sometimes be brought back to your Rails apps to improve some things.
I hope I can have some time in the near future to use Hanami in a real world project.
Congratulations to the team.
0. https://dry-rb.org/gems/dry-rails
I'm sad that the trailblazer stack went so commercial as to be FOSS-hostile and unusable.
I found that some doc are removed from README to a 3rd party website which seems odd to me
But interactions are a plague. People start chaining interactions and very soon you have a maze of these things, with all the domain logic lost inside of these procedures and almost no POROs in sight.
Most of these complaints are, of course, not inherently the fault of these commands/operations/interactions, but they make it so easy to create these monstrosities that I have to put some of the blame on them.
SlackNotifier.notify("Welcome email sent to #{email_address}")
end
If you want Hanami to be an IoC framework, why still allow direct SlackNotifier to be injected to the action layer here ? I guess, lib/ folder should be loaded into Deps instead (Deps["slack_notifier"] ?
No good production code allows such things to accidentially happen, so to me, it's the error from framework. What's the point of using a framework if it couldn't help me do silly things then ?
They seem to be the other two "micro frameworks" (with Rails obviously being the primary Ruby framework).
When it comes to differences - Sinatra is not as feature rich and it's got a less powerful plugin system. Roda has a completely different router using so called Routing Tree, which Hanami doesn't have (it's got something more akin to what Rails has) but it's also highly extendible through plugins, so there is similarity there. A huge difference is that Hanami ships with a very powerful code loading system that supports automatic dependency injection mechanism.
"Hanami is a modern web framework for Ruby."