Occasionally you’ll write a Capybara test which produces an unintended outcome. You’ll run and tweak the test a few times, but it continues to inexplicably fail. One easy way to debug the problem involves viewing the page as the test sees it. To do so just output the
page.body, as demonstrated below:
scenario 'Clients should not see the subscribe button', js: true do visit company_path(trial_owner.company) puts page.body expect(page).not_to have_css '.stripe-button-el' end
The fantastic Devise gem’s default
users table is pretty sparse, containing only two user-related items: an e-mail address and password. Chances are you will want to ask for additional identifying data, such as the user’s name, city, or date-of-birth. Fortunately you can easily add columns and integrate them into the Devise-managed workflow. Let’s work through an example in which we’ll add the user’s name to the
users table and account management form.
The Rails team has always been careful to take precautions that help to prevent malicious attackers from compromising an application’s data. One of the most visible historical protections involved using the
attr_accessible method within a model to identify which model attributes could be passed into methods like
update_attributes for mass assignment. For instance when using Rails 3 if you only wanted to allow the
city attributes to be updatable via mass assignment you would define
attr_accessible like so:
class Location < ActiveRecord::Base attr_accessible :name, :street, :city ... end
By giving the developer control over which parameters were whitelisted for such purposes, the presumption was that data could be better protected by eliminating the possibility an attacker could modify a sensitive attribute by injecting it into a form body. This worked great but had a significant drawback, because
attr_accessible is an all-or-nothing proposition. The developer couldn’t for instance change the model requirements when working within an administration console, because
attr_accessible could only be defined once. This changed with Rails 4, thanks to a new approach for managing mass assignment behavior. Known as strong parameters, the task of defining which parameters are available for mass assignment has been moved out of the model and into the controllers, allowing developers to define mass assignment behavior according to action.
As a longtime Rails developer, I love Heroku. It’s cost-effective, offers an incredibly simple deployment process, is extremely stable and easily scalable, and is built atop much of the very same software that I use every day. Most importantly, it allows me to focus on building great applications rather than the seemingly endless administrative minutiae often required when using other hosting providers. Yet once you’ve taken the absurdly simple step of deploying your application to a Heroku server, in my experience figuring out how to most effectively carry out various administrative tasks can be a bit frustrating.
The frustration doesn’t stem from a lack of documentation; Heroku offers a comprehensive set of guides through the Heroku Dev Center. However I’ve always thought fellow developers would appreciate a learning resource that introduces key topics in a sequence coinciding with the discovery process typically followed by a new Heroku user. Being the type of person who likes to write such resources, I figured it was a fine time to put such a guide together.
You can learn more about the book, including the table of contents, and subscribe to receive occasional notifications about the book (in addition to a nice discount whent the book publishes), by heading over to my official website.
This post is short but useful. Most of the Rails applications I work on these days involve a substantial user model complete with Devise integration. These applications maintain a friendly demeanor by referring to the logged-in user by their first or complete (first and last) name, meaning the
User model includes attributes such as
last_name. If you are regularly referring to a particular model attribute, you can save a few keystrokes by taking advantage of Ruby’s
to_s method. In doing so, you can output the desired object attributes simply by referring to the object rather than bother with expressly identifying the attribute. An example will nicely illustrate the benefit:
Whether your application is focused on TODO list management or fantasy football, users will appreciate the ability to sort and reorder various lists of items to their liking. Logically the desired ordering will need to be persisted so the user doesn’t have to bother with reordering items upon each return to your website. But what is the most effective way to perform list sorting and reordering when working with an ActiveRecord model? How might you for instance move a record “up” a list while also ensuring the record is is replacing is properly moved “down”? What is the best approach for retrieving an item deemed to be “higher” up the list than another? How about the “lower” item? What do terms such as “higher” and “lower” even mean? In this post I’ll introduce you to a great gem called ActsAsList that largely removes the complexities of dealing with lists of items in these manners and more.
Sites like ArcadeNomad would be a lot less interesting without the features that can help users find classic arcade games close to their current location. These location-based features are possible determining which arcades are situated within a certain radius of the user’s current latitudinal and longitudinal coordinates. As you might imagine, implementing such a feature is fairly complicated, involving several steps:
- Whenever a new arcade is inserted into the database, geocode the address and store the coordinates alongside other arcade-related attributes.
- When a user visits the site, determine the user’s latitudinal and longitudinal coordinates based on the IP address.
- Use the Haversine formula to identify the arcades residing within a certain radius of the user.
All three of these steps are pretty involved, and not something I’d want to implement alone. Fortunately we can use a great gem and one of several third-party services to handle much of the heavy lifting for us. The gem is called Geocoder, and it was created by Alex Reisner. In this section I’ll show you how to integrate Geocoder into your Rails project and use it to plug into the Google Geocoding and FreeGeoIP to geocode street addresses and IP addresses, respectively.
Over time, traditional taxonomies have been gradually replaced by metadata-driven approaches to web content categorization on the basis that structured categorization hierarchies are often too inflexible, hindering users’ ability to efficiently find content due to a limited selection vocabulary. A metadata-based approach removes such restrictions because information can be classified under a much larger and more descriptive set of keywords (often referred to as tags) that more holistically define what a user might expect to take away as a result of accessing that content.
To really understand the difference between these two approaches, consider how ArcadeNomad might categorize the arcade games using these two approaches. Using the traditional taxonomical approach the game Asteroids might only be found by navigating through a series of hierarchical categories such as
Space and then
Shooter whereas using the flat, tag-based approach a much more rich set of classification keywords might give users the ability to immediately locate A steroids using one of many possible descriptors (see the below figure).
One of the great advantages of working with various clients is the opportunity to learn from different implementational approaches. Currently I’m helping a client out with a particularly well-architected Rails application, one which uses several gems that I’d been unfamiliar with prior to this project. One gem in particular has really captured my attention, as it can dramatically reduce the amount of boilerplate code you’d otherwise have to write when building RESTful controllers. That gem is decent_exposure and it was created by the Rails experts at Hashrocket.
Easy Active Record for Rails Developers readers learn the many ins and outs of building database-driven Ruby on Rails applications by loosely following along with the development of a location-based web application geared towards retro arcade aficionados. The companion project is called ArcadeNomad, and among the many features it demonstrates is Devise integration. ArcadeNomad visitors can optionally create an account, login, logout, recover a lost password, change a password, and update account attributes.
ArcadeNomad’s Devise integration is pretty vanilla, although I did override the default Devise templates in order to stylize the forms using Bootstrap. For instance, you’ll notice the sign in form looks quite a bit more attractive than the default version provided by Devise.
Additionally, I wanted to demonstrate the ability to gather additional profile attributes beyond those Devise gathers by default (only the user’s e-mail address and password), and so have taken the steps necessary to override the profile management form in order to additionally gather the user’s name (see below screenshot). Of course, additional details could also be gathered, such as the user’s city, state, or date-of-birth.