What Is $LOAD_PATH (also known as $:)

I have come across $LOAD_PATH many times and have always skipped over it, never quite understanding what it meant. Well, that is, until recently. The project that I am working on forced me to take a closer look. And once I did, like most things, it really wasn’t that difficult at all.

The first thing to understand is what it refers to. Quite simply $LOAD_PATH is what Ruby uses to determine which directories to look in when you use require in your code. In other words, $LOAD_PATH contains nothing more than lots of directories. Easy, huh?

The second thing you should know is how to reference it. You can refer to $LOAD_PATH in two ways. The first way is to simply call it by its name, $LOAD_PATH.

The second way is to use the predefined variable, $:

Both mean the exact same thing.

Finally to see it in action, here is an example of adding a directory to $LOAD_PATH

$: << File.expand_path('../', __FILE__)

RESTful Rails

Recently I decided to add a new download file feature to the Rails Girls Ideas app. It seemed like a straightforward task. But, upon opening the routes.rb file, I realised I there was more to this decision than I first thought. I had to decide on the type of route…should I create a member route or a resource route?

What is a Member Route

A member route simply adds an additional action to the enclosing resource.

The example below adds a new file action to the existing ideas controller (ideas_controller.rb). In this case the file relates to a single idea. The url to access it would be something like /ideas/1/file

# routes.rb

resourses :ideas do
  member do
    get :file

# ideas_controller.rb

class IdeasController < ApplicationController
  def file
   # download code here

However I started to think about what else I might need to do with the files: What if I want to add some more methods? What if I want to rename the file, or tag the file? What if I want to add a method to delete the file? And if I add all this new functionality, does it still belong in the ideas_controller?

Why a Resource Route

In order to keep controllers from becoming bloated, you can put the new action into its own controller. Then if the situation arises where you want to extend the functionality of the controller and add methods such as upload/download/rename/tag/delete actions you are already in the right place.

# routes.rb

resources :ideas do
  resource :file, only: [:show]

# creating the new method in its own controller

class FilesController < ApplicationController do
  def show
    #download method

The url to access it is still something like /ideas/1/file. The only difference lies in the fact that file is now an entity all of it’s own and, as such, has it’s own controller.

Remember when in doubt type rake routes at the command line to find your way. It will show you the http verbs, the controller and corresponding action and also the url helpers

I should point out that using a resource route is considered more RESTful than a member route. However understanding the difference is the key, as it will guide you in making an informed decision 🙂

Testing Explained

At Rails Girls we like to talk about tests. In fact, pretty much all Rails developers like to talk about tests! Why is this? Well, we understand how important they are to making your code as robust and error-free as possible. But we also understand how confusing they can be..there seems to be so many different types of tests. We believe most things in Ruby on Rails are only confusing because they haven’t been explained properly. In this post we are going to very simply explain tests. Once you understand what they are, the syntax isn’t really that hard..trust us!

Unit Tests

These tests are generally very quick and precise. They test at the method level and they generally test one single thing. An example might be testing that a specific data attribute has a valid value. A good rule of thumb is that whenever you add any new feature you write a unit test for it.

Integration Tests

These start one layer up from our unit tests and they test the underlying services. They are fantastic at telling you when something is broken, however they are not as precise as unit tests in telling us exactly what is broken. A perfect example of an Integration Test would be the testing of a valid and invalid login or perhaps connectivity to your database. The idea here is to flag when something is wrong rather than the low level of detail that unit tests can give us.

User Interface Tests

These tests are our end to end tests. They test the whole system and how it connects together with the UI. And in that sense they are fab. It can be tempting to think all testing should be UI tests but this is not the case. UI tests are very slow and therefore considered expensive. They can also be flaky which means that if something changes on the UI, even if it is just a new field, it could ‘break’ your tests. Don’t get us wrong, they are necessary and they have many benefits but use them sparingly.

Now we know we have covered a lot in one post but we will chip away at each type of test over time. So if you take just one thing from this post let it be this: when it comes to testing your app try to cover as much as possible with unit tests 🙂

Sorcha & Rachelle