RichardJordan

# My solution here was kinda meh. I should never do an interview
# before lunch. I stay up too late. I'm not awake yet.
#
# My original solution got lost in copy/paste, so I've tidied it up
# a bit here so you're not seeing all my flaws (though my solution
# worked and was built within the hour, while chatting, which is
# what counts). So this is sort of a tidy refactoring of my answer
# with maybe an extra 20-30 mins to clean it up added. The basic
# shape of the solution is the same though. I just moved around
# downcasing, and used select instead of .map.conmpact - that kind

RichardJordan

# This was a neat little question that fit into about a half our coderpad session. The question is below, with my solution below that:
#
# have a look at an example puzzle: https://upload.wikimedia.org/wikipedia/commons/thumb/3/31/Sudoku-by-L2G-20050714_solution.svg/250px-Sudoku-by-L2G-20050714_solution.svg.png
#
# There are 3 simple rules to solving a Sudoku puzzle.
#       1.  Each row in the puzzle is exactly 1 through 9. No duplicates.
#       2.  Each column in the puzzle is exactly 1 through 9.  No duplicates.
#       3.  Each 3x3 matrix in the puzzle is exactly 1 through 9. No duplicates.
#
# Part 1.

RichardJordan

# I liked this interview question. It fit nicely in about an hour, and I 
# think I'd consider re-using it. It isn't too gimmicky and it's not one 
# of those "did you do a CS degree" tests, which help nobody.
#
# Q: given a json input in the form of a set of jobs and subjobs:
#  
# '[
#   {"id":"1","name":"Designer","parent_id":null},
#   {"id":"2","name":"Engineer","parent_id":null},
#   {"id":"3","name":"Software Engineer","parent_id":"2"},

RichardJordan

module RJ
  module Utils
    module NullListener
      # allows for injection of a different class for null_listeners
      #
      attr_writer :null_listener_class

      private

      # make available a null_listener that uses the null object pattern

RichardJordan

module RJ
  module Utils
    module Commands
      module Notifications
        extend ActiveSupport::Concern

        module ClassMethods
          def observer(*observer_methods, of_event: :success)
            observer_methods.each do |observer|
              observers[of_event] ||= Set.new

RichardJordan

# This creates a nice chainable command pattern which is very powerful
# when pulling business logic out of controllers or models, and allows
# for observers and notifications to be easily added.

module RJ
  module Utils
    module Commands
      class Base
        include Errors
        include Notifications

RichardJordan

# 3. This would enable a really focused TransactionsController
# that just handled sending off a use_case to the handler and
# dealing with renders or redirects on the way back in.
# 
# In this example we have a context that is per action - but 
# maybe we just pass in a broad context of request params,
# any authorization/authentication object and self as a listener
# in to the use_cases handler as a context. This could be a
# method in application controller to clean this up even 
# further.

RichardJordan

# 2. In order to enable that previous example of a handler to 
# deal with all of the transactions use cases, for a transactions
# controller, we'd need a base class that looks something like this:

module UseCases
  class Base

    class << self
      def commands
        @commands ||= {}

RichardJordan

# 1. So, we are all factoring out of our controllers into Query
# Objects, Command Objects and Service Objects, to name a few, 
# right?
#
# But all of that knowledge about which commands to call and what
# objects to create still ends up as an additional responsibility
# burden on the controller class.
#
# What if we wanted something that was as simple as registering the
# commands for a set of controller use cases, with either a command

RichardJordan

My basic query object pattern is super simple building on what many people seem to do nowadays.

1. Never use method missing - always an explicitly defined interface.
2. expose #relation and #all
3. always return self to keep methods chainable

Example:

class CustomerQuery