Howdy, and happy Monday.
I’m Garrett. I’ve been designing and developing software on the web for a couple of decades with a focus on information architecture, HTML, CSS, accessibility, Ruby, and Rails.
Featured
We’re making some updates to Flipper’s pricing in order to move from seat-based pricing to fixed-price monthly and yearly plans, but we didn’t want to force any customers onto the new plans, so we planned and designed first-class support for multiple types of billing indefinitely.
Recently
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.
We’re close to rolling out updated pricing for Flipper Cloud, and it goes against most of the advice we heard from other SaaS teams. We’re moving forward anyways because it feels like the right thing to do for our context.
When we started billing for Flipper Cloud, we did what everyone else in the space was doing – per seat pricing. $20 per seat each month felt like plenty. As time has passed this choice has increasingly bothered me. The past few months I’ve been thinking about what type of billing I like.
Instead of strategizing about maximizing revenue, we focused on finding an approach that would maximize customer satisfaction while leaving room for reasonable profit. We could be entirely wrong, but there’s really only one way to find out.
We’re making some updates to Flipper’s pricing in order to move from seat-based pricing to fixed-price monthly and yearly plans, but we didn’t want to force any customers onto the new plans, so we planned and designed first-class support for multiple types of billing indefinitely.
I haven’t yet tried this tactic, but I really like the idea. Instead of requesting answers, we request a sort of virtual debate to help us strengthen our own thinking as we try to write it down.
Let’s turn the tables and have ChatGPT prompt us. Tell AI to ask you questions about what you’re writing. Push yourself to express in clear terms what you really want to say.
Of course, there’s still the fact that AI uses an inordinate amount of power, but this is one of those applications that feels like it has real potential if the power usage can ever get under control. It’s like a rubber duck for your thoughts.
Web forms and inputs support a variety of additional attributes that can provide hints to the browser and improve the user experience of filling out forms online. With the tiniest bit of extra effort, we can make sure our forms help rather than hinder.
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.