Notice: Undefined index: order_next_posts in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 194

Notice: Undefined index: post_link_target in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 195

Notice: Undefined index: posts_featured_size in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 196

5 Quick expert Ruby on Rails tips you need to know

Need to give your Ruby on Rails workflow a boost? Try out these quick tips to for a faster workflow

Need to give your Ruby on Rails workflow a boost? Try out these quick tips to for a faster workflow


01. Keep an eye on your models via the Schema

Back in the days of Rails 3, you could get a swift overview of your models and their attributes by checking the /app/models directory. But this is no more the case: as of Rails 4, much of the model logic has been refactored to elsewhere in the system.

To best keep an eye on the model development, you should have the /db/schema.rb permanently at hand: not only will this provide you with an insight into the application’s developing structure, you will also be able to keep an eye on your database relations at the same time. Database-driven development may be dead, but it’s not a bad idea to take a hint from your schema.rb when you might need to extract a class.
The schema.rb will update on-disk every migration, too: so there’s no need for you to reload the file. It’s a great on-going reference as to the current state of your model layer.

02. Rake routes

One of the most useful commands – particulary for debugging – is bin/rake routes. When you first encounter a new Rails project, or you are lost about how everything in your current Rails project fits together, running this will give you an immediate overview of the different URLs in your app, all the controllers and all the actions in your controller.

The prefix at the beginning of the table lets you know the prefix you need to add to the path view helper to get a URL for the route in your views – so if the prefix says edit_product, call edit_product_path(1) to get back the URL /products/1/edit

03. Use Scopes

Often when querying the database, you will find yourself needing to chain a number of ActiveRecord commands together to build up your query. However, not only can this look messy, it’s often hard to tell what you are trying to do with your query. Scopes enable us to instead write our queries inside of the model, tidying up our code and clearly labelling what we are trying to do, such as:

class Shirt < ActiveRecord::Base
scope :dry_clean_only, -> { joins(:washing_instructions).where(‘washing_instructions.dry_clean_only = ?’, true) }

This enables us to call Shirt.dry_clean_only to get rails to generate the query above in a cleaner way..

04. Even if you’re not planning on translating, Utilise Internationalisation

Rails is bundled with a powerful set of internationalisation tools. People often neglect this part of Rails, putting all of their language-specific code directly into their views on the assumption that they’re never going to translate their app. In reality, Rail’s internationalisation features are not just for when you need to serve your website in multiple languages. They also let you keep content-specific parts of your app in one place, making it easy to hand off content generation to non-technical members of your team.

05. Precompile assets

Chasing down a production asset bug in development? Well you can view production-type assets by precompiling the contents of your /app/assets directory to the /public/assets directory so you can snake around them in a text editor.

Put ‘RAILS_ENV=production bundle exec rake assets:precompile’ in the root of your project. Then navigate to /public/assets and your production-compiled assets will be there. Notice the long string after the asset name? That’s called a digest, and it differentiates between asset sets. When you update your app, it doesn’t ditch the old set of assets – they’re kept, and an updated group (along with an updated digest) is pushed to the /public folder.

Simultaneously, helper methods, eg javascript_include_tag, append the new digest to any files that they have referenced – updating your users’ asset files in one swoop. If you’re using Sprockets, the above command will also generate a .sprockets-manifest file, it gives your app explicit guidance as to which uncompiled asset matches which compiled one.