Coding Test

gistfile1.md

Coding Test

Here is few quick Ruby and JavaScript questions for you. You can reply in-line below and/or with Gists.

1.) Can you explain Rack and some of its benefits? Have you ever written and Rack applications any if so for what purpose?

Rack is the middleware sitting between web server and Rails(or any Rack compatible Ruby framework) apps. It provides a set of standerd interfaces to the common HTTP related objects and operations. Some of the benefits of Rack:

• Standardised interaction between web servers and ruby, making Ruby framework construction or web server's ruby capitibility implentmentation a lot easier.
• It provides a way(Rack Middlewares) to easily implement comment low level HTTP functionality such as analytics, logging, or authentication. One example would be the gem Warden which provides Rack level authentication support.
• It gaves App developers access to the low level "plumbing" of HTTP requests/responses which makes augmenting the request/response a lot easier.

One Example of my experiences with Rack: I was tasked with an I18n app that takes a path in url(i.e. en) as the locale. When the path is not specified, it checks the header for the browser language setting. I made a small middleware similar to this one but with some modifications to suit the clients need. This can be implemented at rails level, but moving it to rack level free's the app from checking/redirecting for locales.

2.) Can you give me a quick code review of https://github.com/mdeering/attribute_normalizer I have no "code ego" so state any opinions you might have. I'm looking for engineers that can challenge me.

Here's my two cents:

1. It's a awesome gem. I've been using white space killers for quite sometime and this is much better interms of functionality.
2. I really like the use of strategy pattern, it's easier to test and the class is SOLID.
3. I wasn't sure about the use of value.is_a(String) checks but meantime I don't have better suggestions. I guess this is an exception to the conventional wisdom the dynamic language should avoid type checking.
4. I would encourge the user of the gem to implement custom strategies(in it's own class) instead of inline blocks. it would reduce the complexity normalize_attributes method, and the benefit to the user is they have a easier to test normalizer class rather than an inline logic within their model.
5. I would give the user the option to include the normalizer rather than include in ActiveRecord::Base. So I can pick and choose to include in the model that have this need.
6. Very interesting organization of the specs. I like it that it provides sort of realworld example on usage and as well as the expected behaviour. On the other side, I think this makes many tests duplicated in multiple places. I don't think this is a big issue given the small size of the tests the additional maintenance effort is managable.

3.) Can you send me quick Gist of some Ruby for how you would get this to work without using any gems.

Time.now + 5.days - 3.minutes

# Usually I don't like to Monkey patch things but it's too convenient for this question.
class Fixnum
  def seconds
    self
  end
  
  def minutes
    60 * seconds
  end
  
  def hours
    60 * minutes
  end
  
  def days
    24 * hours
  end
end

4.) JQuery: What is the difference between the way these click events are being captured and why or when would you use one over the other. Assume that each executed at the same time after dom load.

// 4a $('#content a.clickable').on('click', function(event) { console.log(event); });

// 4b $('#content').on('click', 'a.clickable', function(event) { console.log(event); });

// 4c $('#content a.clickable').click(function(event) { console.log(event); });

I think the difference between click() and .on() is that .on() can be used to bind event listeners to dynamically loaded elements. Also .clicl() creates one handler for one binding and .on() creates one handler for all bindings. For example if I want to bind one function to multiple buttons on the same page, .on() would be a lot memory effeicent. For this reason I always prefer to use .on() accross the board for consistensy.

The difference between a and b I think is that a binds directly to a.clickable where b binds to #content which delegate the handler to a.clickable.

5.) What would replacing the console.log in each of the above event captures with the following do? a. return false

it stops the event from bubbling up and suppresses the default behaviour. in JQuery I think it's the same as event.preventDefault() + event.stopPropagation(), but unlike the other two this also concluded the function call immediately.

b. event.preventDefault();

This will prevent the default behavior to happen. i.e. prevent the form to be submitted when click on a submit button.

c. event.stopPropagation();

This will stop the event from propagating/bubbling up.

d. return this

I think in this case both default behaviour will be triggered and event is bubbled up.