Month: November 2015

Know how to CRUD

While there are some similarities to Rails, there a few differences to keep in mind when performing CRUD operations in Ember. Let’s compare creating, updating and deleting a user in both frameworks.

Creating a new User instance:

In Rails:  app/controllers/users_controller.rb:

Screen Shot 2015-11-24 at 8.26.16 PM

In Ember:  # app/routes/users/new.js:

Screen Shot 2015-11-24 at 8.27.47 PM

In both cases, we create a new instance of a User, but do not persist it. Persisting records to the database (or API) has some differences. In Rails we add a create action, create a new instance based on parameters that were passed, and then call save on it.

In Ember, we only need to add an action to our users/new route that saves the User record we’re currently working with.

In Rails: # app/controllers/users_controller.rb:

Screen Shot 2015-11-24 at 8.32.32 PM

In Ember: #app/routes/users/new.js:

Screen Shot 2015-11-24 at 8.34.11 PM

Updating user attributes:

user.setProperties({ firstName: ‘Tatsiana’, lastName: ‘Borshch’ });

One key difference between Rails update_attributes and Ember setProperties is that update_attributes will automatically persist the record to the database, while setProperties  will update the record immediately on the client but not attempt to save it. We can verify this by checking the isDirty property, which is equivalent to the changed? method in Rails. To actually save the record in Ember, we need to call save. Ember will make a PUT request to the API to persist the changes.

Deleting a user:

To delete a record in Rails the destroy method is used. In Ember, the equivalent function is destroyRecord, which marks a record as deleted and immediately calls save on it. In case the destroy fails, it is a good idea to use catch along with reload to refresh the state of the model from the server.

Screen Shot 2015-11-24 at 8.51.40 PM

Ember models also have a function called deleteRecord. Like destroyRecord, the record will be marked as deleted. The difference is that save will not be called afterwards.

Must have Development Gems to install on every project!

    Have you wasted a few hours debugging some condition only to find a query or function something was returning nil? Spent time optimizing queries only to forget to do eager loading? Scrolled through your development log past 100s of lines for requests for images, css and javascript that you don’t really need to refer? We have all been there and these gems solve exactly these problems. Once you learn how to use them you’ll find that you can accomplish what sometimes takes hours in minutes.

      One of the largest portions of time that you will spend developing an application is on debugging and optimizing. As the rails application becomes bigger with more moving parts, debugging it becomes slower and finding parts that are causing your application to be slow become fewer in between.

Awesome Print

Rails objects can get pretty dense and hard to read when inspecting in the console. Awesome print solves this problem by prettifying the output. Read on to see by what I mean.

Lets run the command User.first in the rails console. This is something most of us do on a day to day basis in the rails console.

Screen Shot 2015-11-04 at 11.17.30 PM

As you can see on the Terminal above, the output is kind of hard to read although the object is not that complex. Awesome print takes that output it and makes it much easier to read. Lets install the gem and see how it changes.

Use gem “awesome_print”, require:“ap”. Make sure to include do bundle install and restart the rails console. It will not work without it.

We run the same command, however this time we just run the command by adding ap to the beginning of the commend. So it becomes ap User.first. Basically, what you are doing is passing to the ap method the object that you want it to print.

Screen Shot 2015-11-04 at 11.15.59 PM

Screen Shot 2015-11-04 at 11.14.46 PM

Screen Shot 2015-11-04 at 11.24.47 PM

Screen Shot 2015-11-05 at 12.55.53 PM

Rails Panel

Rails panels adds a number of useful features to the Google Chrome inspector. To use this you will need to install the  meta_request gem and also install the Chrome extension by going here.

Rails panel is something I keep switched on pretty much all the time if I’m doing any backend work. It gives you all the metrics and information required without actually having to go into the Rails console.

The first columns gives you the HTTP Response Status, the Controller and Action that your route hit, the HTTP Verb (PUT/POST/GET), request format (HTML, JSON, XML) and the response time. These metrics by itself would have been quite valuable.  

I find the ActiveRecord tab to be extremely useful as it gives you the raw SQL queries being executed and the executing time for that query. It also gives you the number of queries that were used for that request which is great for optimizing the app. Apart from that, clicking on the controller name automatically opens your editor and takes you to that line of code!

The next tab is the Rendering which gives a breakdown of all the views being rendered. This is useful for finding which partials are taking the longest to render. Click on the view name automatically opens it in your editor.

Quiet Assets

Do your rails server log look like this? Filled with asset requests that you don’t really need to see, making you scroll endlessly to find the last request? My biggest annoyance would be that while scrolling I would more often than not miss the relevant request.

Quiet Assets as it names suggests removes all the asset requests from your rails console so you can see just the relevant request data. Installation is as simple as dropping gem 'quiet_assets', group: :development into your gemfile and bundling. You should see something to the screenshot below.