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.continue reading →
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.continue reading →
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.continue reading →
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
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.
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.continue reading →
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.continue reading →