peel 0.1.0

data/dev_journal/Day_2.md

@@ -0,0 +1,59 @@
+# Day 2
+
+## Picking Up
+
+It seems silly that it has taken me so long to realize that the goal isn't to create an Active Record object, it's to create an interface for dynamically adding Active Record behavior to a class.
+
+I'm not sure I worded that well, so let me try to break it down, for my own sake.
+
+In our class, `Book`, we shouldn't define a class-level method called `.find()`. Instead, this should be dynamically added to the ancestry chain, so that when we call `Book.find()`, and it doesn't exist inside `Book`, Ruby knows to look up the hierarchy to find where that method is defined. 
+
+Likewise for the instance methods, like `#update()`. Instead of "hardcoding" that method inside of the `Book` class, we'll want to establish an interface that will allow Ruby to delegate to where that method is defined.
+
+With that said, the challenge of defining these methods, (`.find()`, `#update()`, etc.) continues. How do we define them in an abstract way so that the their behavior is adjusted during runtime? What interface do we make available to classes who wish to add this behavior?
+
+## Behaviors
+
+**Construct an instance of the Active Record from an SQL result set row.**
+
+We want to define a class...
+
+```ruby
+class Book
+end
+```
+
+Where we can call a method like `.find(1)`...
+
+```ruby
+Book.find(1)
+```
+
+Which will in turn make a call to `SQLite3` and execute a `SELECT` query...
+
+```ruby
+SQLite3::Database.new("books_app")
+	.execute("SELECT * FROM books WHERE id = 1;")
+```
+
+And return to us a `Book` instance that contains the data from the result set row, as attributes on the object.
+
+```ruby
+# => #<Book:0x007fa903965e98 @author="Metz, Sandi", @id=1, @isbn="9780321721334", @title="Practical Object Oriented Design in Ruby">
+```
+
+___
+
+The bulk of the work in this flow lies in the `SQLite3` execute method. This method has a lot of knowledge:
+
+1. `SQLite3::Database.new()` means it depends on the `SQLite3` library and knows how to get a new instance of a database object.
+2. `"books_app"` is the name of the database.
+3. `execute()` is the name of the method on the SQLite database instance that executes an SQL query.
+4. `"SELECT * FROM ... WHERE ..."` is the SQL query string to be run.
+5. `books` is the name of the database table.
+6. `id` is that name of the column.
+7. `1` is the id we're querying for.
+
+Managing how all of that knowledge gets to our persistence layer is a vital part of this problem.
+
+Another piece of the problem is how `Book` ends up with a `.find()` class method and how our persistence layer knows how to construct a new `Book` instance, once it's retrieved that data from the database.

data/dev_journal/Day_3.md

@@ -0,0 +1,138 @@
+# Day 3
+
+## SQL Injection Vulnerability
+
+```diff
+class Book
+...
+        
+  def update(title: nil, author: nil, isbn: nil)
+    title = title || @title
+    author = author || @author
+    isbn = isbn || @isbn
+    
+-    SQLite3::Database.new("books.db").execute <<-SQL
+-      UPDATE books  
+-      SET title = '#{title}', author = '#{author}', isbn = '#{isbn}'
+-      WHERE id = #{@id};
+-SQL
++    SQLite3::Database.new("books.db").execute(
++      "UPDATE books  
++      SET title = ?, author = ?, isbn = ?
++      WHERE id = ?;",
++      [title, author, isbn, @id]
++    )
+    Book.new(id: @id, title: title, author: author, isbn: isbn)
+  end
+
+...
+end
+```
+
+Small update of the `Book#update()` method.  The original version of this method used string interpolation in order to set the values for `title`, `author`, `isbn`, and `id`. 
+
+I did this because, the query is just a string and I needed that string to be "filled out" at runtime, dynamically. However, this has serious security implications. This is a  **prime** example of how easy it is to introduce an [SQL injection vulnerability](https://www.owasp.org/index.php/SQL_Injection). 
+
+> A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application.
+
+###  The Attack
+
+Our innocent code gets a book from the database, using the `Book#find()` method:
+
+```ruby
+book = Book.find(1)
+#=> #<Book:0x007fc3c00f9160 @author="Metz, Sandi", @id=1, @isbn="0115501237044", @title="Practical Object-Oriented Design in Ruby">
+```
+
+When we want to update our book, we call `book.update()`, with the parameters we want to update. In this case, we update the title:
+
+```ruby
+book.update(title: "POODR")
+#=> #<Book:0x007fc34ee1160 @author="Metz, Sandi", @id=1, @isbn="0115501237044", @title="POODR">
+```
+
+This is the expected behavior.
+
+Next, to visualize what an attack looks like, lets remind ourselves of the method signature and SQL query:
+
+```ruby
+def update(title: nil, author: nil, isbn: nil)
+    ...
+	"UPDATE books  
+	SET title = '#{title}', author = '#{author}', isbn = '#{isbn}'
+	WHERE id = #{@id};"
+	...
+end
+```
+
+Let's consider what would happen to our query if we called the `.update()` method like this:
+
+```ruby
+book.update(title: "PWNED' WHERE id = 2/*")
+```
+
+If we called our method like that, our query would look like this:
+
+```sqlite
+UPDATE books 
+SET title = 'PWNED' WHERE id = 2/*, author = 'Metz, Sandi', isbn = '0115501237044' 
+WHERE id = 1;
+```
+
+Notice that SQLite will consider everything after `/*` to be a comment, so if we strip that away, we're left with:
+
+```sqlite
+UPDATE books
+SET title = 'PWNED'
+WHERE id = 2;
+```
+
+What happened? Even though we were working with an Active Record object for a book row where `id = 1`, our interpolated string allowed us to effectively _change_ the original query in order to update a different row in our database, `WHERE id = 2` in our case. 
+
+We can see the effect of our SQL injection by querying for the book with and `id = 2`
+
+```ruby
+Book.find(2)
+#=> #<Book:0x007fc3c20dd120 @author="Martin, Robert C.", @id=2, @isbn="0187123641198", @title="PWNED">
+```
+
+This is not the intended use of our client code, but once it's out there, we can't protect against this kind of attack. Imagine if we were updating a user password instead of a book title!
+
+### The Fix
+
+The fix is to use _parameterized queries_. 
+
+> The use of prepared statements with variable binding (aka parameterized queries) is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied. 
+>
+> [OWASP](https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29)
+
+The `SQLite3` gem makes using these types of statements, really easy. We replace the interpolated code with a `?`, and provide a list of arguments that will be used to fill in those blanks, later:
+
+```ruby
+def update(title: nil, author: nil, isbn: nil)
+  ...
+  SQLite3::Database.new("books.db").execute(
+    "UPDATE books SET title = ?, author = ?, isbn = ? WHERE id = ?",
+      [title, author, isbn, @id]
+  )
+  ...
+end
+```
+
+In our case, it's as simple as passing in a second argument to `#execute()`. Let's looks at that function definition:
+
+```ruby
+def execute(sql, bind_vars = [], *args, &block)
+```
+
+You can read more about [Binding Variables in SQLite](https://sqlite.org/c3ref/bind_blob.html), but essentially, the abstraction in the `SQLite3` gem does exactly what you imagine: replace each, `?`, with the corresponding value in the  `bind_var` array, based on order.
+
+If we try to do the same SQL injection now, we end up with this:
+
+```ruby
+book.update(title: "PWNED' WHERE id = 2/*")
+#<Book:0x007fc3c22ff638 @author="Metz, Sandi", @id=1, @isbn="0115501237044", @title="PWNED' WHERE id = 2/*">
+```
+
+Instead of effecting any other rows in our database, the prepared statement escaped any characters which could otherwise be interpreted as SQL syntax.
+

data/dev_journal/Day_4.md

@@ -0,0 +1,195 @@
+# Day 4
+
+## Adding Functionality to Client Classes
+
+The first step in tackling this problem is to add functionality to a model class. If we have a class `Book`, we want to add a class method `Book.find` , and some instance methods `book#title`, `book#author`, and `book#isbn`, without needed to explicitly write them, like we did in the original spike.
+
+#### A Note on Mix-Ins & Inheritance
+
+When you want to create a model with `ActiveRecord`, you have to inherit from the `Base` module:
+
+```ruby
+class Book < ActiveRecord::Base; end
+```
+
+There are endless debates about composition v. inheritance, and, from my perspective, they all mostly lean towards composition, but what about using mix-ins versus using string inheritance?
+
+In Ruby, inheriting and including a module _both_ add a new entity in the method look-up path:
+
+**Inheritance** 
+
+```ruby
+class Foo; end
+class Bar < Foo; end
+Bar.ancestors
+#=> [Bar, Foo, Object, Kernel, BasicObject]
+```
+
+**Module Inclusion**
+
+```ruby
+module Foo; end
+class Bar
+ include Foo
+end
+Bar.ancestors
+#=> [Bar, Foo, Object, Kernel, BasicObject]
+```
+
+Which is what we want. When we think of the task at hand, we want to insert an object that defines `.find()` for a object we want to make an Active Record object.
+
+For our intents and purposes, either solution will do, and perhaps the same could be said for the folks working on `ActiveRecord`. There are a few considerations to be made when deciding however; here's a quote from [Well Grounded Rubyist, 2nd Ed.](https://www.manning.com/books/the-well-grounded-rubyist-second-edition)
+
+> - _Modules don't have instances._ It follows that entities or things are generally best modeled in classes, and characteristics or properties of entities or things are best encapsulated in modules... class names tend to be nouns, whereas module names are often adjectives...
+> - _A class can have only one superclass, but it can mix in as many modules as it wants._ If you're using inheritance, give priority to creating a sensible superclass/subclass relationship. Don't use up a class's one and only superclass relationship to endow the class with what might turn out to be just one of several sets of characteristics.
+
+With that said, I want to think of making client classes "model-able," rather than making client classes "a model." This pulls us towards using a module and including it, rather than using inheritance, _a la_ `ActiveRecord`.
+
+#### A Note about Include & Extend
+
+There are a few different ways to add behavior from a module into our classes. For our purposes, we'll focus on `include` and `extend`.
+
+As mentioned above, `include` will add an entity in the method look-up path. So for our `book#title`, `book#author`, and `book#isbn`, this sounds like the kind of functionality we want. The users of our ORM shouldn't have to define these methods, they should be provided to them. If the method is missing from there class, we can define them in our module and place it next in line.
+
+`extend` on the other hand, defines a singleton class and places the method definitions from our module there. This is the same as if the users of our ORM defined class methods in their class. This is a good candidate for `Book.find`, which, again, we'll define and place in singleton class of the client's class.
+
+>  Often, you will want to use a module to import instance methods on a class, but at the same time to define class methods. Normally, you would have to use two different modules, one with `include` to import instance methods, and another one with `extend` to define class methods.
+>
+> — [Léonard Hetsch](https://medium.com/@leo_hetsch/ruby-modules-include-vs-prepend-vs-extend-f09837a5b073)
+
+The idiomatic way of doing this like so:
+
+```ruby
+module Foo
+  def self.included(base)
+    base.extend(ClassMethods)
+  end
+    
+  module ClassMethods
+    def bar
+      "It works!"
+    end
+  end
+end
+
+class MyClass
+  include Foo
+end
+```
+
+The hook `.included()` gets called whenever a module is included into a class, and it's passed the class that included it. The above code adds the method `.bar` to class `MyClass`'s singleton class, `#MyClass`:
+
+```ruby
+MyClass.bar
+#=> "It works!"
+```
+
+## Bits & Bobs
+
+Now we have all the bits & bobs to get started. We know we want to define `Book.find`, `book#title`, `book#author`, and `book#isbn`, but we'll also want to define a constructor `Book.new`, which Ruby has us do by defining the instance method `book#initialize`.
+
+The workflow will go like this: we'll define a method in our client class, *e.g*. in `Book`, and then abstract those method out into modules.
+
+## Onward to the Database
+
+First, well want a way to read our database columns in order to know what accessor methods we need to build. In SQLite, we can use `PRAGMA`
+
+> The PRAGMA statement is an SQL extension specific to SQLite and used to modify the operation of the SQLite library or to query the SQLite library for internal (non-table) data.
+
+This works with the `sqlite3` gem like this:
+
+```ruby
+SQLite3::Database.new("books_app")
+  .execute("PRAGMA table_info(books)")
+#=> [[0, "id", "INTEGER", 0, nil, 1], [1, "title", "VARCHAR(255)", 0, nil, 0], [2, "author", "VARCHAR(50)", 0, nil, 0], [3, "isbn", "VARCHAR(13)", 0, nil, 0]]
+```
+
+Each array has the following values:
+
+```ruby
+["cid", "name", "type", "notnull", "dflt_value", "pk"]
+```
+
+Because we want the "name" of each column, we can extract them like this:
+
+```ruby
+SQLite3::Database.new("books_app")
+  .execute("PRAGMA table_info(books)")
+  .map { |column| column[1].to_sym }
+#=> [:id, :title, :author, :isbn]
+```
+
+Notice the call to `.to_sym` which turns each of the strings into Ruby symbols. This makes them a bit easy to work with later on.
+
+Notice in our use of the `sqlite3` gem, there are two pieces of information that tightly couple this to our implementation: the database name, `books_app`, and the table name `books`.
+
+**Note**: we're going to ignore the hardcoded database name, for now, and only address the table name.
+
+Our solution is going to be to define an instance variable with the table name, and use that to build our query.
+
+```ruby
+class Book
+  @table_name = "books"
+  class << self
+    def columns
+      SQLite3::Database.new("books_app")
+        .execute("PRAGMA table_info(#{@table_name})")
+        .map { |column| column[1].to_sym }
+    end
+  end
+end
+```
+
+`Book.columns` is a class method, because the columns will be the same for all instances of class `Book`. We could pass the table name into `.columns`, but likewise, the table name will be the same for all instances. However, we want to extract this into a module, and the table name will vary depending on the class that `include`s it. There are at least two ways to solve this problem.
+
+`ActiveRecord` solves this by implicitly linking classes and tables based on the name of the class, _i.e._, a class of `Book` would be linked to a table `books`, and a class `User` would be linked to a table, `users`. Similar to the Broken Record project, I believe there's value in *explicitness*, so instead of inferring a table name, we'll pass it into our module and store it there as an instance variable.
+
+```ruby
+module Modelable
+  def self.included(base)
+    base.extend(ClassMethods)
+  end
+    
+  module ClassMethods
+    def link_to(table_name)
+      @table_name = table_name.to_s
+    end
+    ...
+  end
+end
+```
+
+This allows us to do the following from our `Book` class:
+
+```ruby
+class Book
+  include Modelable
+  link_to(:books)
+  ...
+end
+```
+
+There is still an instance variable called `@table_name`, but we've assigned it using a method. That instance variable is available both to our `Book` class, as well as in the `Modelable` module, so we can now move the `#columns` class method into our module.
+
+```ruby
+module Modelable
+  def self.included(base)
+    base.extend(ClassMethods)
+  end
+    
+  module ClassMethods
+    def link_to(table_name)
+      @table_name = table_name.to_s
+    end
+      
+    def columns
+      SQLite3::Database.new("books_app")
+        .execute("PRAGMA table_info(#{@table_name})")
+        .map { |column| column[1].to_sym }
+    end
+  end
+end
+```
+
+**Note**: Here were see string interpolation in an SQL query again, and we discussed how that produces a security vulnerability. Unfortunately, SQLite doesn't allow you to bind variables in PRAGMA queries. We could find the column names another way, using a query that _does_ allow us to use bound parameters, or we could even sanitize `@table_name` ourselves. For now, we'll make a note of it and place it in the icebox where stories go to die.
+

data/dev_journal/Day_5..md

@@ -0,0 +1,366 @@
+# Day 5
+
+## Modelable
+
+Yesterday, we left off with module, `Modelable`, that, when included, adds two class methods, `.link_to()`, and `.columns()`. 
+
+```ruby
+module Modelable
+  def self.included(base)
+    base.extend(ClassMethods)
+  end
+    
+  module ClassMethods
+    def link_to(table_name)
+      @table_name = table_name.to_s
+    end
+      
+    def columns
+      SQLite3::Database.new("books_app")
+		.execute("PRAGMA table_info(#{@table_name})")
+		.map { |column| column[1].to_sym }
+    end
+  end
+end
+```
+
+We use this module like this:
+
+```ruby
+class Book
+  include Modelable
+  link_to(:books)
+end
+
+Book.columns
+#=> [:id, :title, :author, :isbn]
+```
+
+Notice, that if we don't call the `.link_to()` method, we would get an error:
+
+```ruby
+class Book
+  include Modelable
+end
+
+Book.columns
+#=> SQLite3::SQLException: near ")": syntax error
+```
+
+Because we haven't defined the `@table_name` class instance variable, so the query is being interpolated with `nil` instead of a string. 
+
+**Note**: If `nil` were just an empty string, we would get back an empty list, rather than an exception. This is design choice to take into consideration. Perhaps if we were test driving this, this is the kind of behavior we would account for in our design.
+
+Now that we have our list of column names, we want to create accessor methods for each of the columns. We can do this by creating instance variables for each column and then creating getter and setter methods that retrieve and set the instances variables, respectively. 
+
+### Metaprogramming
+
+```ruby
+class Book
+  columns.each do |column|
+    define_method("#{column}") { instance_variable_get("@#{column}")}
+    define_method("#{column}=") { |value| instance_variable_set("@#{column}", value)}
+  end
+end
+```
+
+Ruby gives us access to metaprogramming, which I like to think of as just programming with meta-data. In this specific example, we use the `#define_method()` method, which does exactly like what is sounds like.
+
+We pass into `#define_method()` the name of the method, and a block containing the body of the method. The two calls to `define_method()`, above, create a getter and a setter for each column. The body of the first retrieves and instance variable using `#instance_variable_get()`, and the second sets an instance variable using `#instance_variable_set()`. 
+
+An important thing to note here is that `#instance_variable_get()` will return `nil` if that instance variable hasn't been defined. So our getter method will either return a value that was set using the setter's `#instance_variable_set()`, or it will return `nil`. 
+
+**Note about `nil`**: It's important to realize the downfalls of using `nil` throughout a codebase in this way. `nil` represents both a _state_, (nothing has been set), as well as _data_, (the value of `foo` *is* `nil`, or `null`, as represented in the database). This conflation around `nil` is a topic I find really interesting, and has been tackled in functional languages with sum types; like Haskell's `Maybe` and Elixir's `Option`.
+
+These calls to `#define_method()` are just plopped into the `Book` class, but we can just as easily move them to the `Modelable::ClassMethods` module and call them from our `.link_to` method:
+
+```ruby
+module Modelable
+  def self.included(base)
+    base.extend(ClassMethods)
+  end
+    
+  module ClassMethods
+    def link_to(table_name)
+      @table_name = table_name.to_s
+      create_accessors
+    end
+  
+    def create_accessors
+      columns.each do |column|
+        define_method("#{column}") { instance_variable_get("@#{column}")}
+        define_method("#{column}=") { |value| instance_variable_set("@#{column}", value)}
+      end
+    end
+      
+    def columns
+      SQLite3::Database.new("books_app")
+		.execute("PRAGMA table_info(#{@table_name})")
+		.map { |column| column[1].to_sym }
+    end
+  end
+end
+```
+
+Now, whenever a client class calls `.link_to()`, or module will retrieve the names of the column for the given table, and automatically generate getters/setters for each of them:
+
+```ruby
+class Book
+  include Modelable
+  link_to(:books)
+end
+
+book = Book.new
+book.title
+#=> nil
+book.author
+#=> nil
+```
+
+### Find
+
+After creating some infrastructure in the client class, we've gotten a good pattern here with our modules. When we want to add a class instance method, we add it to the `Modelable::ClassMethods` module, when we want to add an instance method, we place in `Modelable` module. 
+
+If we think about our interface for `.find()`, we know we want to be able to call it on the class, e.g., `Book.find(1)`. And, we want that class instance method to return a new instance of `Book`, with all of the instances variables set to the values in the respective columns. 
+
+First, we'll tackle the retrieval of information from the database:
+
+```ruby
+def find(id)
+  SQLite3::Database.new("books_app")
+    .execute("SELECT * FROM #{table_name} WHERE id = ? LIMIT 1", id)
+end
+```
+
+_Note: we have a similar issue as before with the string interpolation..._
+
+Here we're selecting all the rows from the `books` for all rows that have an `id` that match the `id` we pass into the method. `SQLite3`'s `Database#execute()` method allows us to pass in bound arguments as an array as the second argument. Here, it also allows us to pass in just one variable as a single parameter.
+
+By default, `SQLite3` returns the results in an array of arrays:
+
+```ruby
+[[2, "Practical Object-Oriented Design in Ruby", "Metz, Sandi", "0311237841549"]]
+```
+
+We can use this, with our `columns` array to create a key-value pair, but `SQLite3` also gives us access to a `Database#execute2()` method, which is exactly the same as `Database#execute()`, except that is returns the column names in an array, as well as the resulting values from the query:
+
+```ruby
+[
+  ["id", "title", "author", "isbn"], 
+  [2, "Practical Object-Oriented Design in Ruby", "Metz, Sandi", "0311237841549"]
+]
+```
+
+This allows us to run one query, instead of two, to get the column names. Now we can `zip` the two arrays, and convert it into a hash:
+
+```ruby
+def find(id)
+  result = SQLite3::Database.new("books_app")
+    .execute2("SELECT * FROM #{table_name} WHERE id = ? LIMIT 1", id)
+  result[0].zip(result[1]).to_h
+end
+
+Book.find(2)
+#=> {"id"=>2, "title"=>"Practical Object-Oriented Design in Ruby", "author"=>"Metz, Sandi", "isbn"=>"0311237841549"}
+```
+
+The last thing we'll want to take in account is if our query returns an empty result. If that is the case, we'll return an empty hash:
+
+```ruby
+def find(id)
+  result = SQLite3::Database.new("books_app")
+    .execute2("SELECT * FROM #{table_name} WHERE id = ? LIMIT 1", id)
+  
+  if result.empty?
+    {}
+  else
+    result[0].zip(result[1]).to_h
+  end
+end
+
+Book.find(1337)
+#=> {}
+```
+
+Like before, we can write this function in the `Modelable::ClassMethods` module, an it will be available to our client class, `Book`.
+
+### Construction
+
+Now that we have our hash, we're just a stone throw's away from having a new instance of `Book`. If we tried to pass our hash into `Book.new`, we'd get the following error:
+
+```ruby
+Book.new(Book.find(2))
+ArgumentError: wrong number of arguments (given 1, expected 0)
+```
+
+That's because we haven't defined a constructor for `Book` that accepts a hash.
+
+We could start out with something like this:
+
+```ruby
+class Book
+  def initialize(**args)
+    @id = args.fetch(:id, nil)
+    @title = args.fetch(:title, nil)
+    @author = args.fetch(:author, nil)
+    @isbn = args.fetch(:isbn, nil)
+  end
+end
+```
+
+Now, if we pass in our hash, we get a new instance with the correct values!
+
+```ruby
+Book.new(Book.find(2))
+#<Book:0x007f8b8fafe6b0 @author="Metz, Sandi", @id=2, @isbn="0311237841549", @title="Practical Object-Oriented Design in Ruby">
+```
+
+However, we want to abstract that our generalized `.find()` method can return an instance of _any_ class.
+
+Instead of hardcoding instance variables, we can use the same `#instance_variable_set()` method we used earlier. We'll iterate over the hash, and for each key/column we'll create an instance variable and set it to the value/row data:
+
+```ruby
+def initialize(**args)
+  args.each do |attribute, value|
+    instance_variable_set("@#{attribute.to_s}, value)
+  end
+end
+```
+
+Notice the `@` symbol, without it, our instance variables wouldn't have the conventional `@` in front of it.
+
+Now, we can initialize our `Book` with a hash, and it will assign instance variables for each of the key-value pairs!
+
+```ruby
+Book.new(Book.find(2))
+#<Book:0x007f8b8fafe6b0 @author="Metz, Sandi", @id=2, @isbn="0311237841549", @title="Practical Object-Oriented Design in Ruby">
+```
+
+We can also initialize our `Book` manually, like before:
+
+```ruby
+Book.new(title: "POODR")
+#<Book:0x0078e21fafe6b0 @title="POODR">
+```
+
+However, we can also initialize _any_ instance variables we pass in:
+
+```ruby
+Book.new(foo: "bar")
+#<Book:0x0078e21fafe6b0 @foo="bar">
+```
+
+To solve this, we can limit the instance variables based on the columns in the database, if we pass in a key that doesn't match a column, we will raise an `ArgumentError`:
+
+```ruby
+def initialize(**args)
+  args.each do |attribute, value|
+    if self.class.columns.include?(attribute)
+      instance_variable_set("@#{attribute.to_s}", value)
+    else
+      raise ArgumentError, "Unknown keyword: #{attribute}"
+    end
+  end
+end
+```
+
+### Tying it All Together
+
+The last step is to move this constructor into the `Modelable` module. We do not want to move it into the `Modelable::ClassMethods` module, even though we're defining the `.new` class method...
+
+In ruby, when we define the _instance_ method, `#initialize()`, ruby will automagically call it after we call the _class_ method, `.new`.
+
+The final step is to add a call to `.new` with the result of the call `.find()`.
+
+Our entire module looks like this:
+
+ ```ruby
+module Modelable
+  def initialize(**args)
+    args.each do |attribute, value|
+      if self.class.columns.include?(attribute)
+        instance_variable_set("@#{attribute.to_s}", value)
+      else
+        raise ArgumentError, "Unknown keyword: #{attribute}"
+      end
+    end
+  end
+
+  def self.included(base)
+    base.extend(ClassMethods)
+  end
+    
+  module ClassMethods
+    def link_to(table_name)
+      @table_name = table_name.to_s
+      create_accessors
+    end
+  
+    def create_accessors
+      columns.each do |column|
+        define_method("#{column}") { instance_variable_get("@#{column}")}
+        define_method("#{column}=") { |value| instance_variable_set("@#{column}", value)}
+      end
+    end
+      
+    def find(id)
+      result = SQLite3::Database.new("books_app")
+      .execute2("SELECT * FROM #{table_name} WHERE id = ? LIMIT 1", id)
+  
+      if result.empty?
+        {}
+      else
+        result_hash = result[0].zip(result[1]).to_h
+        new(result_hash)
+      end
+    end
+      
+    def columns
+      SQLite3::Database.new("books_app")
+		.execute("PRAGMA table_info(#{@table_name})")
+		.map { |column| column[1].to_sym }
+    end
+  end
+end
+ ```
+
+### Grande Finale
+
+We can now create Active Record objects with our module:
+
+```ruby
+class Book
+  include Modelable
+  link_to(:books)
+end
+
+book = Book.find(1)
+#=> {"id"=>1, "title"=>"Practical Object-Oriented Design in Ruby", "author"=>"Metz, Sandi", "isbn"=>"0311237841549"}
+
+book.title
+#=> "Practical Object-Oriented Design in Ruby"
+```
+
+## Next Steps
+
+There are quite a number of directions to go in with our new `Modelable` module, here are few key ones that interest me:
+
+1. Abstracting the Database 
+
+   We're relying directly on the `SQLite3` gem, which couples our implementation directly to SQLite. Even further, our implementation hardcodes the database `book_app`. Wrapping this library, abstracting a `Repository` object, and/or using a `Configuration` object, are all possible next steps. Moving towards database agnosticism is an even better move towards Rails' `ActiveRecord` 
+
+2. Tests
+
+   We didn't write any tests for `Modelable`, and that's because we couldn't see where we were going before we got there. Now is a good time to write some tests and drive this out again, or at least writing some integration tests that describe the current behavior.
+
+3. Extend to Other Active Record Methods
+
+   We've implemented `.find()`, and have established a good abstraction patter in our module. It should be fairly straight forward to implement other common methods like `#save()`, `.all`, `#update()`, `#destroy`, etc. Soon, more patterns are sure to surface and lead to further abstractions of the module. This, of course, could really benefit from TDD!
+
+4. Remove String Interpolation from SQL Queries
+
+   See [Day_3](./Day_3.md)
+
+5. Replace `nil` with `Null` Objects?
+
+   Above, we talked about the downfalls of using `nil` to take on many meanings throughout the code base. Ruby is notorious for this, but often times the Null Object Pattern can step in and provide our `nil`s with more context. Perhaps this could be usefully employed to solve our `nil` problem.