class RacersController < ApplicationController
  def race
    @racer = Racer.first
    @was_in_if_block, @was_outside_if_block = false, false
 
    respond_to do |format|
      if @racer.name == 'john'
        format.json do
          render :json => @racer
          @was_in_if_block = true
          return true
        end
      end
 
      @was_outside_if_block = true
      format.json { render :json => @racer.name = "foobar" }
      format.html { @racer }
    end
  end
end

The Problem

Can you identify any issues lurking within this code?

Assuming that the responses is a json response and that @racer.name  is indeed 'john',
the if condition should execute which would lead one to believe that @was_in_if_block would evaluate to true followed by the the rest of the code not to execute.

However, if this code was spec'ed out(which indeed it is, to simulate the issue, https://github.com/alisyed/RailsAnomalies) we would have observed that @was_outside_if_block was being assigned true as well. In other words the return isn't working as expected.

The underlying reason

Lets delve into Rails code!

The respond_to method invokes the important retrieve_collector_from_mimes(mimes, &block) which first evaluates the particular type of mime_types the controller action can respond to at a controller level configuration for example:

respond_to :json, :except => [ :edit ]

as well as inspecting the block passed to the respond_to method. The collector for the particular request is attempted to be found.

Assuming that the the request is JSON for our case, the collector for our particular request will initially be assigned the format.json block in the if condition(It is important to note that the code inside the actual format blocks will not be executed yet) and since another format.json block exists, our collector will later on be assigned that block. This is carried out by the block.call(collector) statement.

def respond_to(*mimes, &block)
  raise ArgumentError, "respond_to takes either types or a block, never both" if mimes.any? && block_given?
 
  if collector = retrieve_collector_from_mimes(mimes, &block)
    response = collector.response
    response ? response.call : default_render({})
  end
end
 
# File actionpack/lib/action_controller/metal/mime_responds.rb, line 267
def retrieve_collector_from_mimes(mimes=nil, &block) #:nodoc:
  mimes ||= collect_mimes_from_class_level
  collector = Collector.new(mimes)
  block.call(collector) if block_given?
  format = collector.negotiate_format(request)
 
  if format
    self.content_type ||= format.to_s
    lookup_context.formats = [format.to_sym]
    lookup_context.rendered_format = lookup_context.formats.first
    collector
  else
    head :not_acceptable
    nil
  end
end

As the code in the format.json block isn't executed yet, @was_in_if_block will still have a value false, and the @was_outside_if_block will be assigned a value of true.

The format.json block will then execute, which is the last line of the respond_to method.

Warning: The code I'm about to mention below isn't a good practise. As far as I am aware, Ghost does not currently support adding custom HandleBar helpers but plan on doing so soon.

I wanted to change the behavior of my blog so as to display the blog cover only on the home page and not on pages where pagination is being used(/page/2/). After a quick look at the helpers present on Ghost's documentation I couldn't find a suitable solution.

I started to read up on the code of Ghost. From the looks of it there are plans to add support for apps however that functionality does not exist yet. Here is the quick and dirty solution I came up with.

I added the following code in the  core/server/helpers/index.js file

coreHelpers.ifOnHomePage = function (options) {
  if ((config.paths.urlFor(this, false) === "/")) {
    return options.fn(this);
  }
  return options.inverse(this);
}

followed by registering it at the end of the same file

registerThemeHelper('ifOnHomePage', coreHelpers.ifOnHomePage);

After adding the code in, the handlebars helper can now be used.

  {{#ifOnHomePage}}
    <h1>I work!</h1>
  {{/ifOnHomePage}}

DATE_COL = 10
2.upto(10) do |i|
  ...
  excel_file = Excelx.new("#{Rails.root}/temp/final_cand/khi_counsel_list.xlsx")
  date_ar = excel_file.cell(i, DATE_COL).to_formatted_s(:long)
end

After a quick google, I found out that the float being returned was the number of days that have elapsed since (Dec 30, 1899). As to why this is the case, I have no clue and didn't look it up.

I went ahead and modified my code to the following after which everything started working fine.

date_ar = (DateTime.new(1899,12,30) + excel_file.cell(i, DATE_COL).days).to_date.to_formatted_s(:long)

ActiveRecord objects keep a track of whether any of their attributes values have changed via the ActiveModel::Dirty module.

# Loading an object to memory
user = User.find 29
# changed? lets us know whether any modifications were made to the object
u.changed? # => false
# After Modifying the users name, we can see that changed? now returns a true
u.name = 'Frank'
u.changed? # => true
# changed can be used to let us know which attributes have been modified
u.changed  # ["name"]
# #{attribute_name}_was can be used to obtain the former value
u.name_was # "Joliene"
# #{attribute_name}_change returns an array consisting of the old and new values
u.name_change # ["Joliene", "Frank"]

Next time, when temporarily assigning variables the values of object attributes before modifying them, remember that this functionality is already provided by Rails in an elegant way.

= render partial: 'product_line', collection: product_lines_with_brand(@result, brand)

In my view I was rendering the partial above. For styling reasons I required that after ever second time the partial is called, I should be adding a clearing div.

After spending some time to try to find a good solution, I stumbled upon something really neat that Rails provides by default. Every partial rendered upon a collection has a counter associated with it. In the case of the partial above, the name of the counter would be product_line_counter. Basically the name of the partial with _counter being appended to the end of it.

So all I had to do was append the following snippet of code at the very end of the partial

- if product_line_counter.odd?
  .clear

In order to have cleaner code, this issue can be addressed in multiple ways. Two of which(for a monolithic architecture) are using:

Modules

A common practice is to extract a set of related methods from the model and move them to a separate module. These modules then serve as mixins to the actual model.

class User < ActiveRecord::Base
  include Billing
  include RegistrationMethods
  include Subscription
  include Socials
  ...
  ...
end

The issue that I feel exists with this approach is that inferencing where a certain method is coming from tends to be quite unintuitive. The actual developer who made the modules might have no issues, however, scenarios will always exist where the rest of the dev-team will need to execute a grep command to figure out where a method is being defined.

Classes Ftw!

A better approach would be to break down the functionality into smaller classes that have  actual meaning.

class Subscription
  def initialize(user)
    @user = user
  end

  def subscribe!
    ...
  end

  def unsubscribe!
  end
end

By breaking down the functionality and collecting them into logical entities(OOP) you gain the following advantages.

No More Grep Driven Development. Reading the code becomes very intuitive. I know exactly where to look in my code base to figure out the code.

The interfaces are very clean and well-defined.

Classes can be completely independent from Rails. TDD becomes uber fast as we do not need to require the evil spec_helper(i.e. Rails).(Thank you Gary of DAS for this. You've helped me a lot. )

Ending Notes

It is important to note that I'm in no way saying that modules are completely useless. Though I do feel that they are overused and that Object Oriented Design is often times overlooked while working in the Rails environment.

A = 'I am A'
module Foo
  B = 'I am B'
  puts Module.nesting.inspect
  class Bar
    C = 'I am C'
    puts Module.nesting.inspect
    module World
      D = 'I am D'
      puts Module.nesting.inspect
      puts ::A
      puts ::Foo::Bar::C
    end
  end
end
    
p A
p Foo::B
p Foo::Bar::C
p Foo::Bar::World::D

While not in the scope a particular variable, the :: operator can be used to specify which scope this variable belongs to. So If we're currently outside module Foo, Foo::Bar::World::D can be used to access constant D.

The statements with a :: right at the very start are used to set the current scope to root level. This can be observed in module world where ::A is being used to access the constant defined outside of module Foo.

The code above generates the following output.

[Foo]
[Foo::Bar, Foo]
[Foo::Bar::World, Foo::Bar, Foo]
I am A
I am C
"I am A"
"I am B"
"I am C"
"I am D"

Oh and the nesting method is used to see the current level of nesting.