Week 3 Day 4: B.C.E. (Bundle, Cover, and Embed)

Major activities of the day: We started out today with an assignment to create a "Person" class that takes a hash of attributes and can then spit them out when requested.  Most people listed all the allowed attributes and `attr_accessor`ed them.  Here was my way to do it:

class Person

  def initialize(attributes)
    attributes.each do |attribute, value|
      eval("@#{attribute} = value")
    end
  end

  def method_missing(method, *args)
    eval("@#{method}")
  end

end


This takes the initial hash and sets an instance variable named for the attribute to equal the value that is passed in.  method_missing then returns whatever is held by the object for the attribute requested.  If it was initialized with a "height" attribute of 6.0, the initialize method will assign a value of 6.0 to @height, and `person.height` will return @height, which is 6.0.  My way isn't necessarily better, it just depends on the situation.  If there is a specific set of attributes which are allowed, it's probably best to use attr_accessor.  My way would be best for an object that you actually want to have a non-predefined set of values (which I imagine is sort of rare).  But I did it because it was a chance to flex my metaprogramming muscles.  eval is another of the metaprogramming methods, and a really dangerous one.  (Avi recommends never using it; I guess I'll learn why at some point.)  It takes a string as an argument, and evaluates whatever's inside of it as though it was written as regular code on that line.  This is really scary because if the string contains as-yet-unknown content, there are lots of things that might happen.  Sticking eval into method_missing, like I did, is just asking for trouble.  In this case, however, I thought it makes sense, because I'm trying to create an object that just takes in and spits out attributes with any names.

But I digress. After 10AM, we learned about Bundler and the standard ways of structuring the directories and files for a project (setting up an environment file, putting your models in lib, executables in bin, etc.).  We also covered the use of Simplecov, a neat tool to check how completely your tests cover your code.  It seems to actually track what code is executed as the tests are run.  That's awesome.  We also got some more practice writing modules, and played with Sequel, which is a Ruby gem that handles database stuff.

The last thing we covered was ERB, or Embedded Ruby, which is a way to embed Ruby code inside of HTML templates to be able to generate static pages through your Ruby program.  I've been looking forward to this for a while.  At this point, we should have the ability to, through Ruby programs, take information and get it into a database, and use that information to generate a whole slew of static pages.  That's really powerful already.  It's really amazing when diverse skills - HTML, CSS, SQL/databases, and Ruby - start coming together, interacting with each other, to form a picture of how these skills can be used to generate content for users.

Tonight was our first NYC on Rails meetup of the semester.  We heard 4 students talk about different projects, including a webscraping Pokedex, a Battleship game, a Tic-Tac-Toe game, and a Random [restaurant] Order Generator.  It's amazing how people have used their newfound skills to be creative and learn even more!

Skills developed: Metaprogramming, Bundler, Simplecov and code coverage, ERB, Pokemon knowledge

QOTD: Well, actually, I can't remember any exact words, but there were some awesome Pokemon jokes at the meetup.  It was fun to relive that part of my childhood.  :)