Test Coverage
I Like My Params Like I Like My Coffee
Edit
#ruby-on-rails
#rails-upgrades
#error-handling
#test-coverage
Summarized using AI

I Like My Params Like I Like My Coffee

Tara Scherner De La Fuente • October 02, 2015 • Earth

In her talk "I Like My Params Like I Like My Coffee", Tara Scherner De La Fuente shares valuable insights into using strong parameters in Ruby on Rails, particularly for complex applications. The presentation explores the challenges faced when transitioning from Rails 3 to Rails 4, especially with intricate models and lengthy controllers. The talk emphasizes the importance of parameter management to secure applications against unauthorized data manipulation.

Key Points Discussed:
- Introduction to Strong Parameters: Tara provides a brief overview of the strong parameters concept, which aims to prevent users from inserting unwanted data into an application. She explains how to implement this by using methods like require and permit in controllers.
- Implementation Challenges: After significant modifications to models and controllers, Tara recounts her experiences applying strong parameters, highlighting difficulties encountered with complex nested attributes.
- Best Practices: She shares practical advice, such as using permit! for initially allowing all attributes when dealing with complicated models. This approach can ease the process before refining the allowed parameters.
- Common Pitfalls: Tara discusses common errors, including misuse of parameter management—strong parameters should not delete attributes and can lead to confusion about data presence.
- Testing: Insights are also shared on testing controllers and API endpoints, particularly about handling errors that arise when expected parameters are not passed correctly in requests. Tara advises always including valid attributes in test hashes to avoid confusion.
- Collaboration and Learning: Throughout the journey, collaboration with colleagues proved to be crucial; it not only led to solving substantial issues but also fostered continuous learning, particularly with the importance of the order of parameters.
- Final Thoughts: Tara concludes with key takeaways that include starting with broad permission for attributes, the necessity of refining parameter lists, and the importance of collaboration and order in setting parameters. Her journey emphasizes how junior engineers can bring enthusiasm to rigorous and tedious tasks.

This talk serves as a critical resource for developers encountering difficulties with strong parameters in Rails, providing both foundational knowledge and advanced tips for effective implementation.

I Like My Params Like I Like My Coffee
Tara Scherner De La Fuente • October 02, 2015 • Earth

Anyone moving to Rails 4 has seen the documented examples like this: params.require(:coffee).permit(:all, :the, :things). But if the codebase has multiple controllers (including a few over 1000 lines long), some api endpoints, nested attributes nesting inside attributes that are named things like additional_attributes_attributes, and robust test coverage that has likely caused forbidden attribute grief, then this talk about some of the little/not documented details of the parameters we call strong might be your cup of...coffee.

Help us caption & translate this video!

http://amara.org/v/HLd1/

Rocky Mountain Ruby 2015

00:00:24.339 Greetings and felicitations! My name is Tara Scherner De La Fuente. I have been a junior engineer at LivingSocial for one year as of last week. Thank you! I've been a professional engineer for one year, and I'm still short, but I've been short for much longer than I've been an engineer. You can find me on Twitter at @media_remedial. I would love for you to visit my blog, Goat User Stories, where I've been tweeting for a little while now. Earlier today, my girlfriend Hazel helped me post a Rocky Mountain Ruby story, so please check it out. In any case, my talk today is called "I Like My Params Like I Like My Coffee," which is strong, in case anybody was wondering. Although I had to change about 25 models and controllers in the application I work on, today I'm just going to talk about a few less documented tips I've gathered from working on one model and its thousand-plus line controller. Believe me, you wouldn't want to get into that code!
00:01:12.750 I'm also going to share a months-long mystery that prevented strong parameters from working effectively on that controller, and how the solution to that mystery turned out to be intricately tied to my coffee theme. This was not planned, as the mystery existed even when my talk was accepted, but it's been solved now, so stick around! Just a quick overview of strong parameters: we were using the strong parameters gem because we were on Rails 3.0 and eventually moved to Rails 3.2. With that gem installed, you’ll need to include a specific line in any model you want to apply strong parameters to. Then on the controller, this is the basic outline of what your new private method will use to implement these strong parameters.
00:02:01.320 Essentially, parameters that require your model are followed by `.permit` and whatever attributes you would like to allow. The idea of strong parameters is to prevent users from injecting inappropriate data into your application. It’s crucial to replace the params model bracket with your new method in any create or update actions. This is just a quick overview in case you’re unfamiliar with this concept. This is a screenshot of the coffee controller. It’s important to note that this is not the controller itself, but the attributes. All of the attributes listed here are directly on the coffee model, and starting from a certain point, you also have nested parameters that could span four or five slides if I were to show them all. You can imagine why it took a while to set all of these up.
00:03:40.620 Initially, to figure out which attributes needed to be included, I alphabetized all of them directly on the model and in the attributes section of the controller. It was a cumbersome process, but it allowed me to compare the raw parameters and make sure I had all the attributes correctly placed. I figured this would help future developers easily understand where to add or remove parameters. After I submitted that pull request, I had been applying strong parameters to other models and controllers for a couple of months. However, the implementation process did not go smoothly at all. One key takeaway I learned from this experience is to start by permitting all attributes when dealing with complex models and controllers. You can do this with a `permit!` method, which allows all your attributes and gets your code working everywhere else, regardless of whether the attribute list is correct.
00:04:29.580 After that, you can refine your attribute list. If you’re working on a thousand-plus line controller and it's an internal application, the risk might be low enough to take this approach. The next day, I managed to finally get strong parameters functioning on the coffee controller. It was a huge relief! I can’t believe it happened so quickly. Now here are some additional, lesser-known things I learned while working on that project. There are times when your private method lists strong parameters, including nested attributes, and you might still need to permit them separately within a method. In our case, this was the create method. Just like I used `permit!` on the private method, I also had to use it within the create method. This is something to watch out for as you may need to specify parameters again separately in a method.
00:06:40.070 Next, I learned a total newbie mistake: strong parameters are designed to prevent users from injecting code, but I mistakenly replaced all params brackets with my new method at the beginning of my learning curve. Strong parameters do not prevent the deletion of attributes—they simply don’t care about it. This misunderstanding caused us to think sometimes deleted attributes were still present; however, strong parameters don’t delete anything for you. As for some tests, we had API controllers and one other miscellaneous controller. When we were running certain updates, sometimes we felt we needed to pass in an empty hash for the object but would understandably receive a 400 error instead of a 204 no content response. It's vital to remember that with strong parameters, if you receive a 400 error, it's not necessarily an error; it's just that the expected parameters aren’t included in the request.
00:08:14.360 To avoid this, you should always include an actual attribute in your hash—you can’t just put any random value like ‘foo’ or ‘bar’. The tips I’ve learned so far are significant, but I did struggle with the coffee controller significantly during this process. I ran into many errors related to nested attributes, specifically with those attributes which included the phrase ‘additional attributes attributes.’ No joke! It was related to the depth of the parameters we were working with; it was challenging. I'd read the raw parameters and obsessesively reviewed the nesting, spending days comparing and ensuring everything was correctly placed. I was sure that the issue lay within the nesting, as it could easily complicate matters.
00:10:01.900 Some might wonder why I hadn’t utilized a certain gem that helps identify attribute discrepancies. The reason being, at that time, one of our lead software engineers was working on that gem. We discussed our experiences, and they confirmed that the gem was still being developed. I shared my terrifying raw parameters hash with him, and he adapted it to make his gem, which ended up being cleverly named after my strong emoji meme: ‘strong like bull.’ It has over 300 downloads now and seems to be beneficial for others. He also published an article on the topic on the LivingSocial tech blog that I highly recommend you check out, even if you’re not interested in the gem—it provides concise information regarding strong parameters and how they function. This brings me to another tip: to tackle the challenge of deeply nested parameters, I created a dedicated `params` file in our `lib` folder, straight-up constants with arrays of the parameters, ordered alphabetically. It allowed for easier management and readability.
00:12:38.965 After building all models and controllers, even with a `permit!` method on the coffee controller, I was then able to fix things quickly. I created a test that would specifically check for the run span error I kept encountering. The version that included the `permit!` would pass, while the version with my adjusted attributes that visually appeared correct would not work. Fortunately, in November at RubyConf, I finally got to collaborate with our lead engineer. He graciously offered to pair with me, and we worked on the project for two months, meeting every so often to make observations and steps forward. Our notes were often punctuated with frustrations, which culminated after several meetings when we finally noticed that the raw parameters differed versus the specifically designated attributes.
00:16:30.340 I recalled learning during a Ruby book club about the importance of order. I realized that we were overloading an active record method, which I hadn’t grasped initially. While I had my raw parameters compared against my alphabetized code base, Dan pointed out the differences that played a vital role in the success of strong parameters. After months of struggling, I pushed through the distinction of placing the time zone from its alphabetical position to right in the front of the list. After that minor adjustment, when we reran the tests, we received a ‘pass’ for the first time in ages! This was a fantastic breakthrough! So just to quickly recap: whitelisting all the attributes before listing them individually can help you focus on the necessary code changes required. Nested parameters might need to be permitted again within a method; and remember, there’s no deleting in strong parameters. Additionally, avoid using empty object hashes in tests or you risk running into those dreaded 400 errors. Finally, realize how crucial order is; successful pairing can lead to learning opportunities for all. Junior developers often possess an enthusiasm for tedious tasks, and they can be invaluable so put them to good use. Thank you for being my first tech audience; I really appreciate it!
Tara Scherner De La Fuente
@wisetara
Explore all talks recorded at Rocky Mountain Ruby 2015
+9