$(document).ready function in combination with CSS style scoping to limit the functionality.
In light of RailsConf last month, I spent some time thinking about my experience learning Ruby and Rails back in 2009. The conference included quite a few seasoned veterans, but like any popular technology, there was also plenty of people that either just started learning Rails, or are considering doing so in the near future.
Turning the clocks back to when you knew much less about something is hard. But putting yourself back in that position can offer valuable insight to the opportunities available and how they might be improved in the future.continue reading →
In my last article, I presented some code that wrapped up accessing a customer’s Stripe data and added a caching layer on top. I wanted to take some time to dig in to that code and see how we can make it better.
Decorators give us a tool to add additional functionality to a class while still keeping the public API consistent. From the perspective of the client, this is a win-win! Not only do they get the added behavior, but they don’t need to call different methods to do so.continue reading →
With so many services available these days, it’s almost impossible to find or build an application that doesn’t rely on a third-party service. Most developers that have dealt with billing systems within the past few years have likely heard of Stripe. Stripe is, by far, the most developer-friendly billing service I’ve implemented.
While Stripe does provide a number of features and plugins that make updating a credit card or signing up for a service simple, there are occasions when data needs to be fetched from Stripe in real-time. For these cases, it’s great to be able to fetch and cache this data before-hand, and only expire if you know there’s been a change.continue reading →
Most applications have ancillary data that’s required to support the main function of the application — think drop-downs with states for shipping or credit card type.continue reading →
For the past 2 years, I’ve committed myself to specific goals for the year to come. Most people call them New Year’s Resolutions. Heck, I probably even referred to them as “resolutions” too. But the more I thought about it, the more it dawned on me that a “resolution” felt more like a fix for something — something that didn’t go well in the previous year. Think weight loss (everyone makes this resolution at least once in their life) or a dedication to be more focused.continue reading →
I recently wrote some code to interface with Stripe’s webhooks. After looking at the code and tests, I decided I needed to do something to make it easier to test all pricing tiers— something I wasn’t able to easily do from the start.
Dependency injection was a necessary piece of that puzzle. I’ve always been curious about the various forms of dependency injection and the effects each would have on the code. Below I explore 2 options (constructor injection and setter injection).continue reading →
What’s the first thing you look at when you see the source code of a Rails project?
For me, it’s the
Gemfile. Think about it…there’s very few other files that contain so much information. It describes the building blocks of the application. And at times, you can even see specific features of the application.
If you’ve used
validates in a Rails Active Record model, you know they work great – at least until the first bit of complexity arises. At that point, they can quickly morph in to a ball of conditional spaghetti convoluting the initial reason the validation was added in the first place.
I recently had an experience using
has_secure_password where I wanted control the length of the user-supplied password. Adding a length validation to the password accessor invalidated existing records, so I was in a bit of a bind. In the end, I sub-classed the Active Record model to create a unique model made specifically for that context. This allowed me to inherit the core functionality from the model and sprinkle on existing validations for specific use cases. This was a new tactic for me and I’m still not sure how I feel about it. I like the fact that it removed complexity from the
User model. This, in hopes, will keep the minimize the likelihood of it becoming a God object.