Week 4 Day 4: RPS and MVC, find out what it means to me, and all I'm askin', is for a little RSpec!

Major activities of the day: Morning lecture about MVC, routes, and other basics of putting together a web app, afternoon lab to put together a rock-paper-scissors (RPS) game in Sinatra, review of that lab, and homework to get some more practice with routes, as well as testing Sinatra with RSpec using rack/test.

Skills developed: Understanding MVC and RESTful architecture, somewhat more developed Sinatra apps, and working with RSpec in the context of Sinatra apps.

Week 4 Day 3: Singing the Sweet Songs of Sinatra

Major activities of the day: We started off today with a quick assignment to make sure we understand how a status code is returned by a server.  The morning lecture covered ActiveRecord associations, dealing with all the ways ActiveRecord methods can be used to generate, save, and access objects.  We followed this up with a lab where we had to run migrations and create models for artists, songs, and genres, where each song had an artist and a genre, and the artists and genres were associated with each other through the songs.

In the afternoon, we were introduced to Sinatra, and put together a simple message-posting app.  The lecture clarified how Sinatra builds on the standard Rack framework to let you create simple websites quickly and easily.

Fun note: I found an even better way today of doing my person object.  It already exists in Ruby!  It's called an OpenStruct, and it's really cool.  Here's the code:

require 'ostruct'

person = OpenStruct.new

And you're done!  The documentation is online at http://www.ruby-doc.org/stdlib/libdoc/ostruct/rdoc/OpenStruct.html

Skills developed: ActiveRecord associations, Sinatra

Week 4 Day 2: I Am But Thy Humble Server

Major activities of the day: We started out today with a lab debugging a program with some intentionally inserted bugs (lack of require statements, a missing bracket, an improperly parsed hash, etc.)  It was a great way to get a taste of taking over a code base, having to analyze it and understand what's doing what, then zero in on the problems and debug.

We broke for blog posts (as usual), and then went immediately to work on a lab to learn how to use Rack, a simple server for constructing web apps.  It drills through a stack of middleware, then works its way back up, finally producing content which is sent back to the user.  We practiced adding middleware and creating a stack that returns a specific result, which is dependent on accessing the env (environment) argument which is passed in when each piece of middleware is called.

After lunch, we had another lecture discussing how the internet works.  The highlight was a demo with actors (i.e. student volunteers) pretending to be a client, a DNS, and a set of servers with different information.

Finally, we worked through another lab about Rack middleware, generating middleware and using it through the Config.ru file.

Skills developed: Debugging other people's code, Rack

QOTD: "Anyone who has lost track of time when using a computer knows the propensity to dream, the urge to make dreams come true and the tendency to miss lunch." - Tim Berners-Lee

Week 4 Day 1: Active Listening and ActiveRecord

Major Activities of the Day: Lecture. We were introduced to Rake in the morning, did a lab putting together some Rake tasks, and then at 10AM moved into the classroom for lecture. We got out at 5PM.

Well, to be fair, it wasn't without any breaks. We stopped for lunch, got a 45-minute sanity break around 2:45, and had a 7-minute break towards the end. But it was a marathon of sitting in a room with the lights off and a projector. I got really sleepy.

So what happened during lecture, exactly? First, we went over the lab from the weekend. Not surprisingly, as it was a difficult lab, it took a really long time. Hours and hours. But it was a good opportunity to watch TDD in action; this lab had some vague instructions and no tests, so he had to write the tests, make them pass, and then refactor. We watched methods broken down into simpler methods and code DRYed up.

When that was finally finished, we moved on to Rake and ActiveRecord. We got a glimpse of the awesome power of ActiveRecord, and I'm excited to use it in the future, saving myself all the frustration of the last few days' work with databases.

Finally, we got an assignment to play around with ActiveRecord. I discovered that if you take a YAML file and load it into Ruby, it generates objects, but the objects have never passed through the initialize method. So in order to get objects that have been initialized properly, you have to do this: `Class_name.create(object.as_json)`, which will initialize and save a new instance with the object's properties.

Remember my fancy method_missing from W3D4? Well, I discovered a better way to write it!  Here it is, with slightly different functionality (I'll explain, don't worry!):

def method_missing(method_name, *args)
  attribute = "@#{method_name.to_s}"
  if attribute.end_with?("=")
    instance_variable_set(attribute[0..-2], args[0])
  else
    instance_variable_get(attribute)
  end
end

And that's it!  This method creates an instance variable setter and getter for anything you want!  And unlike before, it doesn't use "eval", which is a supremely dangerous method (because it can let users have direct access to your system - bad idea!).  Here's me playing around with it in IRB:

2.0.0-p353 :001 > class Person

2.0.0-p353 :002?>   def method_missing(method_name, *args)

2.0.0-p353 :003?>       attribute = "@#{method_name.to_s}"

2.0.0-p353 :004?>       if attribute.end_with?("=")

2.0.0-p353 :005?>           instance_variable_set(attribute[0..-2], args[0])

2.0.0-p353 :006?>         else

2.0.0-p353 :007 >             instance_variable_get(attribute)

2.0.0-p353 :008?>         end

2.0.0-p353 :009?>     end

2.0.0-p353 :010?>   end

 => nil 

2.0.0-p353 :011 > person = Person.new

 => #<Person:0x000001011587e8> 

2.0.0-p353 :012 > person.height = '5\'11"'

 => "5'11\"" 

2.0.0-p353 :013 > puts person.height

5'11"

 => nil 

2.0.0-p353 :014 > person.happy? = true

SyntaxError: (irb):14: syntax error, unexpected '='

person.happy? = true

               ^

from /Users/flatironschool/.rvm/rubies/ruby-2.0.0-p353/bin/irb:12:in `<main>'

2.0.0-p353 :015 > person.happy = true

 => true 

2.0.0-p353 :016 > person.happy

 => true 

2.0.0-p353 :017 > person.favorite_author = "Ernest Hemingway"

 => "Ernest Hemingway" 

2.0.0-p353 :018 > person.favorite_author

 => "Ernest Hemingway" 

2.0.0-p353 :019 > person.favorite_book

 => nil 

So apparently our person can hold any variable we want.  Which is great, because people are multifaceted, and no person's variables will be quite like another's.  But you usually don't want to do this.

Also, note that `person.happy? = true` raised an error.  This is because Ruby doesn't allow happiness.

No, I'm just kidding!  Matz says that Ruby is all about making people happy.  The problem is that variable names can only include alphanumeric characters and underscores.  That means no punctuation.  Only method names can have that.  If I wanted to let you extract boolean values by querying with a question mark, here's an even fancier method_missing:

def method_missing(method_name, *args)
  attribute = "@#{method_name.to_s}"

  if attribute.end_with?("=")

    instance_variable_set(attribute[0..-2], args[0])

  elsif attribute.end_with?("?")

    !!instance_variable_get(attribute[0..-2])

  else

    instance_variable_get(attribute)

  end

end

And back to IRB:

2.0.0-p353 :001 > class Person

2.0.0-p353 :002?>   def method_missing(method_name, *args)

2.0.0-p353 :003?>       attribute = "@#{method_name.to_s}"

2.0.0-p353 :004?>       if attribute.end_with?("=")

2.0.0-p353 :005?>           instance_variable_set(attribute[0..-2], args[0])

2.0.0-p353 :006?>       elsif attribute.end_with?("?")

2.0.0-p353 :007?>           !!instance_variable_get(attribute[0..-2])

2.0.0-p353 :008?>       else

2.0.0-p353 :009 >            instance_variable_get(attribute)

2.0.0-p353 :010?>       end

2.0.0-p353 :011?>   end

2.0.0-p353 :012?> end

 => nil 

2.0.0-p353 :013 > person = Person.new

 => #<Person:0x0000010128e0e0> 

2.0.0-p353 :014 > person.happy = true

 => true 

2.0.0-p353 :015 > person.happy?

 => true 

2.0.0-p353 :016 > person.cool = false

 => false 

2.0.0-p353 :017 > person.cool?

 => false 

2.0.0-p353 :018 > person.employment = nil

 => nil 

2.0.0-p353 :019 > person.employment?

 => false 

2.0.0-p353 :020 > person.employment = "computer programmer"

 => "computer programmer" 

2.0.0-p353 :021 > person.employment

 => "computer programmer" 

2.0.0-p353 :022 > person.employment?

 => true 

Notice how I used the double-bang (`!!`) to force a truth value out of the variable, even if it's not a boolean.

It's amazing how a little IRB can add lots of length to an otherwise medium-sized blog post! :)

Skills developed: Rake, ActiveRecord, importing YAML files

Week 3 Day 5: The Calm After the Storm

Major Activities of the Day: Today was actually pretty relaxed.  We've been flying forward, so we began with a few hours for people to catch up on assignments that had perhaps presented until-now insurmountable difficulties.  In the afternoon, we worked on a project to apply our knowledge: take a folder full of files named in the form "Artist - Song Name [genre]" and turn them into a directory of web pages.  I copied lots of code from previous projects and did everything through databases.  Cool beans.

Skills developed: Practice with databases, modules and class inheritance, ERB.

Sorry about the lack of QOTDs recently.  I'll try to be better about it next week!

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.  :)

Week 3 Day 3: Mixin 'n' Match

Major Activities of the Day: Lecture and lab to introduce modules, and more work with ORMs (the latter being the "Match" in the title, because they match up all sorts of data).  Modules are Ruby's way to gain the functionality of multiple inheritance without some of the problems that come along with it.  A class can inherit from only one superclass, but it can mix in as many modules as you want, to add shared functionality.  Although we didn't discuss it yet, my favorite examples are Enumerable and Comparable, which add lots of functionality to an object as long as you define a few extra methods.  We really focused on writing our own modules, though.  The homework was our most difficult challenge yet; we had to put together a students/courses/departments/registrations model using databases, and I decided to be super-cool and write a metaprogrammed module that would take care of all the database-y stuff.  This includes a method_missing method to handle queries like Department.find_by_name or Student.find_all_by_course.  It was really hard, but it made the rest of the assignment way easier to do.

One second, though - what's metaprogramming, and what is method_missing?

Metaprogramming is writing code that writes code.  In other words, you tell the interpreter to compose methods or do other code-writing-y things on the fly.  The celebrated 'attr_accessor' method does just that; it takes one or more Symbols as an argument, and writes a method for each Symbol to assign and query an instance variable with the name defined by the Symbol.  So `attr_accessor :name` is the same as:

def name
  @name
end

def name=(name)
  @name = name
end


Pretty neat, huh?

method_missing is, in my opinion, one of the coolest - yet most dangerous - features of Ruby.  It is a method defined on every object that specifies the handling of methods whose name it doesn't recognize.  The default handling is to raise a NoMethodError.  But you can do this:

def method_missing(method_name, *args)
  7
end


and then every unknown method will instead return "7" instead of raising an error.  Why would you want to do this?  I don't know.  But maybe you would do this:

def method_missing(method_name, *args)
  if method_name.to_s.start_with?("find_by_")
    attribute = method_name.to_s[8..-1]
    @players.find{ |player| player.send(attribute) == args[0] }
  else
    super
  end
end


so you could do baseball_card_collection.find_by_homeruns(319) and, despite the method not being defined anywhere in your code, it will find the player with 319 homeruns.  By the way, player.send(attribute) in this example is also an example of metaprogramming; it sends the method that shares the name of whatever attribute is passed in.  This creates a lot of possibilities!  Supposedly, however, objects with method_missing can present really annoying behavior and be notoriously difficult to debug, so it's often ill-advised to write a method_missing method.

P.S. Today I presented a technical blog post from my other blog; you can see it at http://amcaplan.wordpress.com/2014/02/19/lessons-from-a-failed-successful-gem/ (it's all about reflections on the experience of writing a gem, what I learned, what I could have done better, etc.).

Skills developed: Module writing, more ORMs, metaprogramming

Week 3 Day 2: ORM (not just a sea monster!)

(If you don't get this post's title, see here.)

Major Activities of the Day: Writing a Secret Handshake class that parses a binary number (but not a string containing letters) and spits out instructions for a Secret Handshake, reviewing yesterday's assignments quickly, and then moving on to the Next Step: ORM.  ORM (Object Relational Mapping) is the interconversion between two data types that are understandable to different programs.  Essentially, we created a Student class that interfaces with a SQLite database to take input in Ruby and output SQL into the database, then draw information from the database and return a usable Student object to Ruby.  This is all very complicated, and luckily we will usually have ActiveRecord to take care of this for us.  At the end, we even touched on a bit of metaprogramming!  Apparently, there is more metaprogramming to come this week.

Skills Developed: ORM (seriously, it's fantastically difficult to do)

QOTD: "When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous." - Martin Fowler (expressing an idea that is absolutely emphasized at Flatiron)

Week 3 Day 1: Ruby Redux

Major activities of the day: Presidents' Day!!!  Spent the day at home, but had lots of assignments.  We basically redid most of the simpler assignments from before, but this time did everything in the context of a class.  I think the point was to make sure we really understand everything we've learned so far.  We also did a new playlister with a command line interface.  I really enjoyed the assignment because it demonstrated the power of classes.  This time, we were able to search by artist, genre, or song name, and if everything was programmed right, it all ran smoothly.  Cool stuff.

Skills developed: Ruby review

Week 2 Day 5: Data - Making and Scraping

Major activities of the day: Morning assignment to put together a School model, lecture about use of databases in Ruby (very exciting to put together databases and Ruby - interactions between tools are super cool, and this allows you to let objects persists across runs of the program!), and a group assignment to scrape our student profiles from the website using the Nokogiri gem.  Nokogiri is fantastic; I'm just starting to learn its power, and I already love it.  Among other things, it lets you take a website and select bits of it using CSS selectors.  So for example, I can look at all the parts that are links within a particular type of element (div, figcaption, whatever) or have a certain class or ID.

Weekend homework was putting together a model of Artist, Genre, and Song where each class relates to the other two.  'Twas fun.

Skills developed: Combining SQLite3 with Ruby, web scraping with Nokogiri

QOTD: "Yes, I'm afraid chartreuse is one of my favorite colors... No, I'm not going to change it just because it's not your favorite..." - Larry Wall, creator of PERL, on his website's background color, see http://wall.org/~larry/

Week 2 Day 4: SQL in the Snow

Today was a crazy snowstorm, and, sadly, school was cancelled.  We were given an online SQL tutorial and some SQL work to do at home (though of course, I'm told that some students went in anyway despite the weather).  Since all the assignments follow RSPEC-defined specifications, we got our first look at how Ruby and databases can interact through the SQLite3 and SQLRunner gems.

Skills developed: SQLite3 CRUD operations, being productive at home

Week 2 Day 3: A Shining Moment

Major activities of the day: Assignment working with classes, homework review, lecture about the subtleties of classes and instances and variable scope.  Honestly, though, I'm mostly focused on (and super excited about) my first Ruby Gem!  It's now available by typing "gem install check_everything" on the command line.  The documentation and source code is at https://github.com/amcaplan/check_everything.  Check it out!  It's an easy way to launch a set of favorite websites from your command line.  It takes a bit of initial configuration, but if you commonly check a particular set of websites, this will make your life just a bit easier.

Skills developed: Working with classes/objects and variable scope, and - in my case - making Ruby Gems!

Week 2 Day 2: I Object!

Major activities of the day: Introduction to O-values through a prime numbers exercise, more homework review, and the long-awaited intro to Object-Oriented Programming!  (Henceforth, it shall be known as OOP.)  One of today's exercises was reimplementing a jukebox we previously created, this time as a Jukebox object.  We also played around a lot with Regexps.  Lots of confusing things.  I'm not entirely clear on how they're evaluated; it's a lengthy topic, and I'm discovering it by tinkering.  Also, I am a huge fan of www.rubular.com.  The instructors have pointed us to it a few times, though I already knew about it before Flatiron.  It's a fantastic way to play with Regexps and discover how to properly construct them to evaluate the way you want.

Today was also the first day of blog reviews.  Every day, 4 students will briefly (in <5 minutes) present technical blog posts they have written.  Everyone does at least 5 over the course of the semester.  Mine is in about a week from now - I'll post a link, don't worry!

Skills developed: Working with objects and Regexps

QOTD: "The best way to predict the future is to invent it." - Alan Kay

Week 2 Day 1: Hashing Out Enumerable Methods

Major activities of the day: Homework review.  We seem to be moving a bit slowly because we're dealing with very fundamental programming tasks.  So we're focusing a lot on how to deal with hashes and arrays and manipulate them in ways that give us the information we need.

On the bright side, we had some time to go over the homework with other students and compare our algorithms, and we exchanged ideas that we had picked up while doing the homework.

One interesting thing I learned from another student was the .tap method, which can be used on all Ruby Objects.  Here's an example of how to use it:

def return_an_array_of_perfect_squares_up_to_25

  [].tap do |squares|

    i = 1

    while i**2 <= 25 

      squares << i**2

      i += 1

    end

  end

end

HUH???  What's the return value?  It turns out that .tap creates a placeholder, feeds that into a block, and returns the placeholder.  So it's the same as this:

def return_an_array_of_perfect_squares_up_to_25

  squares = []

  i = 1

  while i**2 <= 25 

    squares << i**2

    i += 1

  end

  squares

end

Possibly a bit more confusing, which is why I'm hesitant to use it in my own code, but it is a bit more concise, which is nice.  And it gives an excuse to indent!

NOTE: Example provided for illustration purposes only.  If I were programming this for real, this is how I would do it:

def return_an_array_of_perfect_squares_up_to_25

  (1..Math.sqrt(25)).map{|num| num**2}

end

And of course, that's the power of map/collect and select!    ＼（＾○＾）／


Skills developed: Extracting data from Arrays/Hashes, iterating over Arrays/Hashes


QOTD: "When you don’t create things, you become defined by your tastes rather than ability. Your tastes only narrow and exclude people. So create." - why the lucky stiff, author of why's (poignant) guide to ruby

Week 1 Day 5: Fridays[0]

Major activities of the day: Fixing up HW and labs from yesterday, and lots of lecturing about enumerable classes (mostly Array and Hash) and the map/collect and select methods.  These were extremely useful in our labs, where we had to restructure hashes, extract data from complex multi-level hashes, and use hash data to modify Strings.  At this point, I think I'm addicted to map and select, and I've even figured out how the pretzel operator works:

an_array.map(&:to_s)

is the same as

an_array.map{ |element| element.to_s }

I'm also severely disappointed that the pretzel operator can't be used with parameters.  Oh, well.

There was also Feeling Friday, but I had to leave early, and hence missed it.  It's supposed to be lots of fun, though!

Skills developed: Iteration for enumerable classes

QOTD: "I hope that Ruby jumps out of my computer and punches me in the eye!" - Avi (before trying to pop elements off an array while mapping it)

Week 1 Day 4: Rockin' out with Ruby

Major activities of the day: Ruby, Ruby, and more Ruby!!!  A bit about splat arguments, but mostly working with control flow (i.e. if/elsif/else and various forms of loops), plus Strings and Arrays, as well as gaining a deeper understanding of scope and how methods (and their return values) are passed around.  Today was also Flatiron's famous knot-tying workshop, led by our very own Arel English!  Homework was to make a jukebox program that responds to a variety of input commands and plays music.  Mine currently launches songs by loading a YouTube link to the song, through the "system" function.  Kinda hacky, but it works!  :)

Cool new thing I learned today: there's a convention to have a separate file which executes your program so you can run specs on your methods without having the program actually execute.  In other words, the program should be executable via a "run" method, which is called not in the program file itself, but in another program, like so:

program.rb

def run(args)
  #do some stuff
end

#helper methods


bin/program

require '../program.rb'
run(args)

This way, I can require program.rb in my specification file without the program actually running before the specs are checked.  This is especially useful for programs that usually take user input.

Skills developed: Control flow, Strings, and Arrays in Ruby

QOTD: "This is one way that knot-tying is like programming.  You're thinking about future you."  (because you'll eventually have to untie the knot, or read your code) -Avi

Week 1 Day 3: Welcome to the Ruby City! We're not in Kansas anymore...

Get it?  Like the Emerald City in The Wizard of Oz?   Whatever...

Major activities of the day: Git merging a large project, Ruby fundamentals (and learning why Matz is awesome and how Ruby is a secret formula for happiness through programming), programming methods to fit RSpec specifications.  Yes, you read that right - we're already learning to read RSpec code, run tests, and do TDD to fulfill the specs!  We won't be actually writing any RSpec for a while - we need to get a solid grip on Ruby first - but we're starting out with immersion in TDD best practices (including actually reading error messages - they are our friends!).

Skills developed: Git merge and rebase, Ruby coding, TDD with RSpec

QOTD + bonus extra life QOTD! (to make up for yesterday):

"The goal of Ruby is to make programmers happy." - Matz

"It's the exact same reason you make a todo list. Also testing is not for present you, it's for future you." Joe M Burgess

Week 1 Day 2: Bash Your HEAD 'Til You Git the Idea

Sorry for all the bad puns in the title... it may become a running theme...

Major activities of the day: Explored how Git deals with branching, merging, and rebasing.  (We were introduced to GitX(L) today - fantastic tool for visualizing repos!)  Installed a bunch of software and got our systems ready to code without being distracted by missing software or messed-up settings.  Installing software from the command line can be scary, but when you're in a supportive group and have instructors who are always ready to help, it's much easier to get past the fear and, well, just do it!  We also got the chance to tinker around with our Bash profiles.  Here's what my prompt looks like (showing my current path, working branch, and a robot smiley to keep me motivated):

~/Development/code/amcaplan.github.io  (source)

[°‿°] > 

Skills developed: Git, command line, software installation, system customization

QOTD: Sorry, wait 'til tomorrow for a great quote!  I wasn't paying enough attention today - too focused on the work!

Tomorrow we start Ruby.  Best of all, RSPEC also starts tomorrow - TDD (or will it be BDD?) from Day 3!

Week 1 Day 1: Push and Pull

Major activity of the day: Customizing a static HTML page to give ourselves a profile, working in groups of 4 to create the pages, put together a joint CSS modification, and push to Github with a pull request to be added to the project for the whole class.

Skills developed: Lots and lots of basic Git commands (Git was essentially the point of the exercise): push, pull, fetch, merge, branch.  Step 1 is to get super-comfy with Git and Github, to be able to collaborate effectively on projects in our group and with larger groups.

QOTD: "You will probably mark your life as before today and after today." - Avi

About

This blog serves as a journal of my adventures at the Flatiron School in NYC!

When I was first looking into bootcamps, I found journal-type blogs to be extremely helpful in getting a sense of each program.  I have therefore decided to give back to the community by writing my own journal.  I will try to do one post per day, including:

Activities
Skills Developed
QOTD (Quote of the Day)

An important note: good bootcamps will adjust their sights and improve their programs with every class, so if you apply to Flatiron, don't expect the exact same experience.  Hopefully it will be even better!