I'm writing these four tips for programmers and managers who are starting to work professionally on projects using the Ruby on Rails development framework. These tips are helpful in fine tuning your understanding, and productivity on the apps you are working on. Bottom line, your team mates and project managers will be happy you have these things under control.
-
"Read the code"
Often, our expectations mislead us and the code that we or others have written produces different outcomes. The first reaction might be to ask other team members for help. The next time you hit this, first ask yourself, "Did you read the code?" Did you read it all? Did you go to the next file in the stack-trace? Did you dig into dependent gem's code? You see new methods or syntax you don't understand? Keep reading! The solution is in the code!
-
rake routes
Are you curious about a path in the app that you need to hook up client-side code to? The Rails stack along with rake has a slick command that breaks down all the paths that the app handles. Simply run: rake routes
Does the app have tons and tons of routes? Pipe the output through grep to search for the keyword you are looking for: rake routes | grep 'resource_name' -
Speed up your Rails Environment
The faster your environment, the faster you can deliver value on your projects. Rails apps grow, and loading dependencies takes time. Constantly look for ways work around these known obstacles and you will find you can quickly iterate on your rails app confidently. For many years I found myself waiting for test runs, console restarts, rake tasks, etc. I recently started using a tool (zeus) to eliminate these wait times. Make sure you and your team aren't wasting time.
-
Write integration and unit tests
Without evidence of a fully integrated system, you have no control of your app. This lack of control quickly will be seen in uncontrollable errors, costs, and expectations. Do your team a favor and demand any code commit for feature or bug fix go in with passing unit and integration tests. But we aren't just writing test code for clients, we're writing them for other programmers too! I currently prefer using rspec for unit tests and cucumber with capybara for integration specs where browser interaction is required.