Janko Marohnić

102 Followers
20 Following
55 Posts
Ruby off Rails developer ⋅ open source contributor ⋅ creator of Shrine and vim-test
GitHubhttps://github.com/janko
Bloghttps://janko.io
Blueskyhttps://bsky.app/profile/janko.io
YouTubehttps://www.youtube.com/@jankomarohnic

Release notes auto-generated from commits just aren't quality enough for me. Some examples are ViewComponent and GitHub CLI.

Releases are an opportunity to introduce new features & explain bugfixes, they shouldn't include internal changes. Not everything needs to be automatized.

I actually like being only mildly known in open source. I don't receive too many support requests, and I only really get nice people in my issue tracker 😌

When I start getting assholes, I'll know my project has become popular.

I'm more than happy to continue using dry-initializer, I can just see an advantage of removing a dependency if there is something that Rails offers out of the box.

For those that don't believe in service objects, just imagine non-AR models instead 😉

For advocates of the Rails way, what is your alternative to dry-initializer for service objects? I want positional & keyword arguments and lazy default value.

Active Model doesn't tick all the boxes for me, as it doesn't have positional arguments nor lazy default values.

Syntax errors generated by Prism are waay better than what Ruby's default parser generated before 🤘

I upgraded our Rails app from Vite 5 to 6 just by bumping up the package version 🤘

No configuration, no problems 😎

I'm barely able to keep up with the libraries that @37signals folks release, let alone learning another programming language 😅

Yesterday I was checking out hotwire-spark, was curious whether full page reloads were faster than Vite. It seems to be in the same ballpark.

I would be fine just aliasing the model, but then associations don't work correctly, I have to specify the fkey names. I recall there being other issues as well.

I'm really missing a feature for SQL DBs to create a read & write *alias* for a table. Views are only for reads.

How do you sanely rename Active Record models / tables without downtime?

For us it happens occasionally that the product team decides to rename a feature from the customers' perspective, and now we're stuck with the old name in the codebase for eternity.

I've been using a custom script that calls either `bundle open` or `gem open` depending on whether the specified gem is in the project or not.

Really useful for quickly diving into gem source code without thinking about my current working directory 😅