BATTLESHIPS (a trip down memory lane, with a twist)

Week two has been exhausting, exhilarating, frustrating and incredibly fun. I have been tested a lot this week in so many ways, yet the hardest things I continuously face are the obstacles I make for myself. Some days I feel like I am finally wrapping my head around things, and others, I feel like a slug sitting on top of a 90 year old tortoise that's sitting on top of a couch with 3 uneven legs being pushed by a small child down a gravely road while I watch others drive by at 320 km/h in their souped up Ferraris. Nevertheless, it's only week 2 and I know I have to just keep pushing on.

Fortunately for me, my cohort and coaches are pretty awesome. Regardless of how chaotic the day is, or how difficult things get, I can count on my coaches to be smiling at our standups and I can tell that they care. On top of that, I can count on my cohort to be patient and understanding enough to explain something to me for as long as it takes, laugh at my stupid jokes and be comfortable enough with me to give me honest and constructive (but not hurtful) feedback.

The content for the week has somewhat mirrored that of last week, except this week we had to rely more on our partners and less on templates or tutorials to walk us through each process. This weeks's project consisted of writing a Battleship program which simulates the popular board game, starting from the breakdown of user stories and writing of domain models to implementing methods that place a ship on the board (and make sure the ship is within bounds), fire at an opponent's ship, and tell the player when a ship has been sunk (just to name a few of the many methods we have incorporated).

We got a lot of practice writing code with Test Driven Development (TDD) which is essential for building your program stepwise to make sure that every facet of your program runs as intended. To do this, we must alternate between creating and/or working in the spec file, running rspec to get an error message, creating and/or working in the class file, getting an error message and then fixing the errors so that rspec passes all tests, and then moving on to writing the next method. This week we were also introduced to the automated feature spec which basically allows us to do what we would normally do in irb without having to type everything out every time.

This weekend I plan on looking over some important vocabulary/terminology that I feel unfamiliar with and possibly refactoring some code from the airport challenge we had over the previous weekend. I definitely still don't know what I'm doing most of the time, but I'm learning many many ways how not to write code, and that is for sure progress.