DEV Community

Cover image for Debugging tips I learned while working with Sinatra
Syd
Syd

Posted on • Updated on

Debugging tips I learned while working with Sinatra

“Don’t let 2021... be 2020 part two for you.” ~ Tobe Nwigue, Wake Up Everybody, music video

2121 has been started with a bang, and it is not showing any progress of slowing down. I'm actually editing my entire blog and changing its direction because of how crazy my life and this my Sinatra project became. I intended to explain how to add some simple Bootstrap CSS to your Sinatra web app. Instead, I'm going to give some quick debugging tips I learned on the fly after a frustrating week and a half of coding...

Problem #1 - Scope
The plan:

I planned to build a web app to allow users to create a star-studded lineup of their favorite artists for an all-star version of a show.

The failure:

The project was becoming too complicated, and I found myself adding more and more items. Playing with relationships and join tables for days. After wasting nearly all my development time, I realized I was building a project more suited for the next phase of my course.

Debugging Tip:
Pay attention to the ask! When dealing with open-ended projects, try to complete the given requirements first, the Minimal Viable Product/Project, then get fancy. I stated I wasted hours when honestly I just spent hours elsewhere than where they should have been and missed the project's original point. I hadn't even completed any of the requirements after nearly four days of coding and debugging.

Problem #2 - Patch - Override
The Plan:
After simplifying my project, I started writing out all my CRUD routes (Create, Read, Update, Delete/Destroy). Since I was using Rake and was also instructed to use Patch to update rather than a Put in my RESTful routes, I needed to use an Override method so rake would know what to do with the Patch. Dope! This is as simple as adding:

use Rack::MethodOverride
Enter fullscreen mode Exit fullscreen mode

to the config.ru file before the Run command.

and

    <form action="/some/<%=@some.id%>" method="post">
    <input id="hidden" type="hidden" name="_method" value="patch">
Enter fullscreen mode Exit fullscreen mode

to the start of the form in the HTML/ERB file. (For a delete, replace patch with delete.)
and

patch '/pets/:id' do
    something action here
end
Enter fullscreen mode Exit fullscreen mode

to the controller file.

Everything should work!

The Failure:
NOPE! Not for me! My Get routes were working. My post to create new items worked just fine on other routes. I can access the edit page. I can edit the fields. I click submit, and nothing happens. It was as if the page was dead. I reworked my Patch route to death, thinking it was something with the params; maybe it was the update method. Finally, I talked with my tech lead, and after repeating the same debugging methods and a few more, we decided to try this...

Debugging Tip:
On the same route the patch or delete, try a regular old post to a binding.pry...assuming you were lucky enough to require it ahead of time. Don't forget about binding.pry!
Remember our form starts like this:

    <form action="/some/<%=@some.id%>" method="post">
    <input id="hidden" type="hidden" name="_method" value="patch">
Enter fullscreen mode Exit fullscreen mode

So in my controller, I create this route:

post '/some/:id' do
   binding.pry
end
Enter fullscreen mode Exit fullscreen mode

With my localhost and app still running Shotgun, I reloaded my edit page and clicked the Submit button. Sure enough, something happened. I hit the binding pry in my terminal. So the Post method is working for the page, yet the Patch override was not.

Back to the config.ru!!!

This is what my config actually looked like at the time:
Alt Text

Everything is there. I have all the parts. Then it happened: line positioning!!! The controllers were above the override. The Patch override was not being seen as the controller did not know about the override methods. Once I moved the Override method to the top of this list, my Patch worked beautifully.

Happy Working Code:
Alt Text

This debugging tip is a three for one.
A) Take a Step Back - sometimes the problem isn't the "most obvious".
B) Use Your Tools - Many people were coders ahead of us. They hit these walls before. They broke through them and built awesome tools for us to use to make sure we don't struggle as much either. Use them!
C) Back to Basics - When in doubt, rely on your coding basics.

Top comments (0)