I recently started a new internship at Buzzstarter working with a team of experienced developers. One of the benefits of this internship is to view how good code is written. My first two weeks involved viewing their application’s source code and using similar techniques to build an introduction project.

A specific instance of seeing good code was when I saw a class method called enum.

  def self.enum(options)
    options.each do |attr, values|
      values_method = attr.to_s.pluralize

      class_eval <<-RUBY, __FILE__, __LINE__ + 1
        def self.#{values_method}
          #{values}
        end

        def #{attr}
          self.class.#{values_method}[read_attribute(:#{attr})]
        end

        def #{attr}=(value)
          idx = self.class.#{values_method}.index(value.to_sym)
          raise 'Enum not found' unless idx

          write_attribute(:#{attr}, idx)
        end
      RUBY
    end
  end

The method uses a bit of meta-programming, or at least that’s what I think this is doing, to write attributes to the database. The difference is that the values being written to the database are integer values instead of strings. As it was explained to me, this is a feature MySQL has, but PostgreSQL does not have. This allows for both reading and writing attributes to be quicker. You would then use the the enum method like so.

enum current_status: [:off, :on]

The enum method creates a getter and setter using the attribute current_status with the value being the index of the value within the values array passed in.

There are too many instances already where I’ve read some code and was left smiling about the new technique I just learnt. Not only does viewing the application’s source code show me how good code is written, but making the introduction project has me writing better code.

I am fortunate that I have one of the engineers reviewing my code via code reviews. During these code reviews, Radil, would comment on the specific lines with what I needed to change. I would make the necessary changes until I can create a branch with the feature working, then I would create another pull request. There are about ten parts to the project, but I am still only on the third part. I can already tell there is much more for me to learn.

I was installing TinyMCE so I could have a WYSIWYG editor on a textarea within ActiveAdmin when I got the following error.

No route matches [GET] "/assets/tinymce/themes/advanced/theme.js"

I found the similar issue on the tinymce-rails gem’s docs. Losing TINY mce in dev when switching from 3.5.8 to 4.0.2 in Dev

The issue was caused by a change in TinyMCE’s theme. Apparently TinyMCE 4 replaced the ‘advanced’ theme with the ‘modern’ theme. Sure enough when I edited my active_admin.js.coffee CoffeeScript file to:

#= require active_admin/base
#= require tinymce
$(document).ready ->
  tinyMCE.init
    mode: "textareas"
    theme: "modern"
    editor_selector: "tinymce_editor"
  return

That solved the issue I was having. I followed along with this answer on StackOverflow to install tinyMCE to rails.

Has and Belongs to Many Example Repo

Railscast 047 Two Many-to-Many prompted me to ask this. He showed an has_many_and_belongs_to and an has_many :through example. From what the episode, Ryan Bates seems to generally like has_many :through better because it adds flexibility. What are some of the reasons behind this conclusion?

Differences

The Rails Guides on Associations has a section about this.

For has_and_belongs_to_many the relationship is built through a join table using only two models. A has_many :through relationship creates a third model that belongs_to the two models in the relationship. The circumstances you would want a has_many :through association would be:

if you need validations, callbacks, or extra attributes on the join model.

A case where you might want to have a has_many :through associations would be if you have a feature of ‘following’ within the app. Each user has followers and following users. One relationship could be established, but both do not necessarily have to be established. In the case of followers and following users, you would actually need two relationship tables in the database. ActiveRecord provides the ability to ‘reverse’ a relationship based on what the foreign key is.

There could be a relationships table with follower_id and followed_id. To find a user’s followed users, then you would set the foreign key to the follower_id. To find a user’s followers, then you would set the foreign key to the followed_id and rename this relationship to something like reverse_relationship within the model.