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).

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.

Last month marks the 6 month anniversary of the release of Build a Ruby Gem. Thinking back to this time last year, I would’ve never guessed that I would launch a product to the tune of $16k+ sales in 6 months. Thanks to the help of expert teachers, I was able to quickly get over my fear of marketing and put my technical knowledge to good use.

The weeks leading up to the launch seem like a blur now. At the time, I had a perfectly crafted schedule of marketing material and approaches that, as far as I can tell, were the difference between no sales and quite a few.

It’s been awhile since my last post — almost 2 months to be specific. A trip to Portugal, getting sick and a minor run-in with a table saw made it challenging to post anything for the last couple weeks. But I’d be lying if I said I was itching to write.

During that time, I didn’t have anything screaming to be talked about. I have a long list of “decent post” topics, but none of them got me particularly excited. Until today…

It’s generally known that leaving any kind of logic in a Rails view is bad news, both for debugging and your own sanity. Rails views can be cumbersome to test and leave a lot to be desired when it comes to debugging.

It’s been 3 months since the release of Build a Ruby Gem and I’ve gotten tremendous feedback since the launch.

I’ve love to share some news and an opportunity to win a FREE copy of the book. If you’ve already purchased the book, don’t worry, we’ll find a way to make it worth it for you.

Contuining my love affair with Minitest and fixtures, I wanted to dive in to something deeper this time. Switching tools takes time to get used to and managing passwords was one of the bigger headaches I encountered.

I previously wrote about how I handle environment configuration in Rails. Along with solutions like the dotenv gem, it relies on entirely on environment variables.

One of the highlighted features of Rails 4.1 was the config/secrets.yml file. By default, this file contains the secret_key_base and defers to the ENV variable of the same name in the production environment. Even though secret_key_base isn’t typically referenced explicitly in an application, I was curious if I could use the config/secrets.yml file in place of previously documented configuration solution.

I’ve been fortunate to spend the last month as the sole developer of greenfield Rails 4.1 app. As someone who’s spent quite a bit of time maintaining existing code, the freedom to establish patterns and choose tools is a highly welcomed change. One of the choices I made was to use Minitest and Rails fixtures.

The short is…it’s been great! So great that I’m having trouble imagining myself using anything else going forward.