I’ve recently had the good fortune of working on a greenfield Rails app. The app is heavily dependent on times and recurring events (weekly). Naturally, I dragged in the timecop gem to handle freezing time, so my I could properly assert that certain events took place in the tests.

With the release of Rails 4.1, the time stubbing method travel_to was added. This new helper method forces the current time to whatever you specify, allowing you to make asserts against a historical time, or week in my case.

I recently wrote a book about integrating with Rails from a Ruby gem, which specifically touched on using a Railtie to extend ActiveRecord, ActionController and ActionView . While these are the 3 more popular Rails libraries, there’s plenty others that are configurable.

A recent issue in Sucker Punch caused me to go digging through the Rails source code. Ultimately, the to_prepare method on ActionDispatch::Reloader resolved the issue, but I surprised was to find very little documentation about it.

After several weeks of really early mornings, Build a Ruby Gem is finally live:

http://brandonhilkert.com/books/build-a-ruby-gem/

Thanks again for all the support and encouragement. I had a great time working on it and really look forward to hearing your feedback.

This is one of the final post leading up the the launch of the Build a Ruby Gem Ebook, which is now available for sale in 3 packages, including 14 chapters of code and over 2 hours of screencasts.

Rails engines range from simple plugins to powerful micro-applications. The discussions we’ve had so far about Railties are closely related to the function of a Rails engine. One interesting side note is that a Rails application is a Rails engine itself — so it’s easy to see how we can encapsulate just about any normal Rails functionality in an engine, to ultimately embed in a host application.

The Rails engine documentation is well written and touches on the many ways to include functionality. I won’t cover every detail of Rails engines in this chapter, just enough to get you started making use of them. It’s possible to make full applications (routes, controllers, models, migrations, etc.) using Rails engines. However, we’re going to focus on some of the simpler the elements of a Rails engine that allow us to integrate functionality where a Railtie won’t suffice. Just know, there is far more you can do with Rails engines than what we’ll cover here. The documentation link above provides examples of many of those use cases.

This is one of the final post leading up the the launch of the Build a Ruby Gem Ebook, which is now available for sale in 3 packages, including 14 chapters of code and over 2 hours of screencasts.

I spent the last couple of weeks with my head down focusing on producing the best content possible for the upcoming release of my Build a Ruby Gem ebook. I’m excited to finally show you what I’ve been working on.

The book will be available starting at Midnight (EDT) on Thursday, March 27th and can be purchased from my website.

This is one of the final post leading up the the launch of the Build a Ruby Gem Ebook, which is now available for sale in 3 packages, including 14 chapters of code and over 2 hours of screencasts.

The world isn’t black and white (as much as we’d like to believe it is). Just because our gem’s functionality may work for us, doesn’t mean it’ll work for everyone.

Fortunately, we can give users the ability to add custom configuration data, allowing them to adapt our code to their own use. In this post, we’ll adapt the mega_lotto gem to take a configuration block that modifies the number of integers returned from the #draw method output.

This is one of the final post leading up the the launch of the Build a Ruby Gem Ebook, which is now available for sale in 3 packages, including 14 chapters of code and over 2 hours of screencasts.

One of the simplest and most common application of background processing is sending emails outside of a web request. And while background processing is pretty common, most existing Ruby background processing libraries require an additional process to execute these jobs, resulting in increased infrastructure costs.

At the time, I was working on an application hosted on Heroku, and the cost of an additional dyno ($35/month) wasn’t justified. The background jobs did very little more than send emails out of band. To me, the traditional solutions seemed like overkill. And with this, the idea of sucker_punch was born…

This is one of the final post leading up the the launch of the Build a Ruby Gem Ebook, which is now available for sale in 3 packages, including 14 chapters of code and over 2 hours of screencasts.

Greetings from a now less snowy Eastern USA!

The past few weeks have seemed like one big snow storm. We haven’t had many days above freezing and spent very little time outside (voluntarily at least). I’m sure those living in colder climates are probably saying “cry me a river…” right now. On the bright side, our extended home stays have given me more time to write.

Last week, I was looking through my Twitter stream and came across a tweet that referenced ENV[“RAILS_CACHE_ID”]. I was unfamiliar with this environment variable and made a note to learn more.

Rails 4 has made a discernible effort to improve view rendering performance by what they’re calling russian doll caching. Prior to this, view caching was simple in syntax, but realistically more complicated when cached partials needed busting on subsequent releases.

This is one of the final post leading up the the launch of the Build a Ruby Gem Ebook, which is now available for sale in 3 packages, including 14 chapters of code and over 2 hours of screencasts.

This past weekend I added ~ 6,000 words to the existing content. I’m really excited to be nearing the end of the road. I’ve gotten some great feedback since I started and wanted to gather a bit more to finalize the chapter list.

Here’s the chapter list I’m working with so far: