#rails
All journal entries tagged with ‘#rails’
Related Journal Entries
John and I joined Elise on the Ruby on Rails Podcast to talk about taking over Fireside and what it’s like to to acquire an app and ramp up on things to get to work making changes and upgrading infrastructure slowly but surely.
A very nice and concise summary of all the lesser-known and under-appreciated benefits of using partials in Rails. There are a lot of alternatives to partials these days, but they’re so nicely integrated with models, views, and layouts, I still lean heavily towards using partials and leveraging caching to reduce performance impacts.
The only thing I’d add is that any class can work seamlessly with partials as long as it has defined a to_partial_path method. With that, we’re not limited to rendering only ActiveRecord models with an implicitly associated partial.
As someone who has spent far too much time thinking about managing configuration and secrets in Rails applications, this post from Joy of Rails is solid.
Learn how to use “Rails config x” and add your own configuration options to your Rails app with built-in methods, ActiveSupport::OrderedOptions, and practical use cases.
Rails provides a plethora of great tools for managing configurable values, environment variables, credentials/secrets, and even per-environment variations. Like generators, while Rails uses them plenty internally, all of these tools are equally available and accessible for our own custom configuration bits.
It’s not always clear how to make the most of partials and helpers in Rails and know when to put what code where. Regardless of the methods, we all still want to organize the elements that help bridge the front-end and back-end with readable and maintainable code.
The ActiveRecord::AssociatedObject gem is a great tool to help organize logic that fits nicely into an encapsulated concept but only ever needs to interact with one type of object.
Long-form prose can only go so far, and even perfect prose isn’t easy to reference after reading it. So with Frictionless Generators, I wanted to think about how people would be building generators after reading the book. I ended up creating a set of cheat sheets for after-the-fact help and reminders.
What are the differences between Rails::Generators::Base and Rails::Generators::NamedBase? When would we want to use one over the other and why?
Creating a generator is one thing, but creating a generator that actually gets used is another. We’ll look at some of the ways we can make sure we’re building generators that the whole team uses.
When creating templates for custom generators, whitespace matters, so it’s helpful to know and understand the tools and tactics available to help us get it right. We can use whitespace-eliminating delimiters from ERb, generator helper methods, and built-in indentation helpers.
The steady improvements to both Ruby and Rails combined with an amazing and supportive community have me deeply excited about the future of both.
It’s one thing to develop the skills to know how to build custom Rails generators, but it’s another to recognize the wide array of scenarios that lend themselves to saving time with custom generators of any size. Small generators collectively represent much of our time-saving opportunity.
Rails custom generators may not be the most well-known superpower in Rails, but they should definitely be on the list due to their ability to save time and reduce tedium. So I wrote a book to help us make the most of them.
Have you ever been working on a Rails application, needed to use a configuration value within your code and then couldn’t remember whether it’s a setting, secret, credential, or environment variable? If you haven’t, this won’t be interesting, but if you’re like me, it might be worth reading on.
I’m very bullish on the potential of feature flags, but I’d be remiss not acknowledging that they also introduce potential issues that require caution. I even got tripped up with a small oversight, but these are the kinds of mistakes that help reinforce that some basic guardrails can help. Fortunately, that’s precisely what we’ve been working on.
Lots of solid improvements to Rails coming down the pipe. While there are some larger improvements, the little improvements help make several common patterns less tedious. The authenticate_by method provides protection against common timing attacks. The generates_token_for declaration streamlines the process of managing single-use tokens. And has_secure_password can now automatically verify the current password when performing updates by providing a password_challenge attribute on updates.
I’ve been working part time with John, Brandon, and Steve on Flipper Cloud the last few months, and then we decided to make it a full-time thing. We’ve been working on a ton of stuff to make feature flags more powerful and less painless to manage, and cutting 1.0 and offering a free plan for Cloud is just the first step.
A good overview of autoloading in both Ruby and Rails that goes into just enough detail to help it all make sense without getting bogged down in the deeper inner workings. It’s definitely one of those features that easy to take for granted until trying to build something in a language or framework that doesn’t offer autoloading.
If you’ve ever wondered about the differences between Classic autoloading and Zeitwerk, the second part does a great job explaining the differences.
This is a really interesting exploration of an idea for a more concise ERb alternative by Kasper Timm Hansen. HAML and Slim have never felt appealing to me because they feel like they blur the lines between markup and back-end code, but a less-verbose approach to ERb sounds fantastic.
ERB tags
andfeel so noisy, having to add%>a Ruby line feels as if I’d had to write;to end my Ruby lines. So what if we had a simpler syntax that can figure out how to auto-close for us.
Even if it never goes anywhere or sees wide adoption, just seeing this kind of exploration and experimentation with fun ideas to make the Ruby ecosystem even more pleasant is exciting and encouraging.
A good post by Matt Brictson showing the resilient approach for broadly handling exceptions in rails apps using rescue_responses instead of handling cases one-by-one closer to where they happen. And as an added bonus, Rails will correctly render either the static error page or an appropriate JSON response depending on the request.
Creating your first custom Rails Generator can feel counter-productive at first, but with a little knowledge and experience, they can become a powerful tool to help you and your team save time.