Code Cadet

Today, I (briefly) met the new Code Academy class and am so excited to get to really know (and pair) with the new students!  However, the new members of the new class weren't the only ones to get good advice out of the alumni Q&A this morning: after listening to the other alums, I realized it was time to revive this blog.  Which is really a way of saying "stop writing everything down in a notebook and hiding everything you've written from the rest of the world so that you actually do what you're say you're going to do."

Over the holidays, I took a small break from coding - and BYOBuddy - to evaluate what I learned during Code Academy (more on that later), what I wanted to learn next, and how to facilitate that learning.  I came to the conclusion that I need to work on a bunch of frontend skills:

UI design

JQuery

Getting more familiar with new HTML5 features

Becoming more fluent with CSS3

Sass

JavaScript

Mobile

And a bunch of backend skills:

Get better at TDD (and I still need to wrap up the last 3 chapters of the Hartl tutorial)

SQL

And a bunch of random skills:

Remember to use git and push code to github!  Geez.  Shame on me.

Make the switch over... to Vim.

To facilitate this learning, I've set up a small number of breakable toys, before returning to BYOBuddy.  I've decided to tackle most of my "needed frontend skills" first, so I'm:

Honing my basic Illustrator skills through Lynda's "Up and Running with Illustrator tutorial" (just wrapped up an entire course 15 minutes ago!)

Reviewing basic RoR concepts by helping a friend build a small form app for his startup (about to start in a few minutes)

Do a deep dive into Git

Going through Lynda JavaScript tutorials

Plunging into JavaScript by helping another friend build a map feature for his startup

Finish the Hartl tutorial by the end of the week

Building an interactive "menagerie" of animals to practice JQuery, HTML5, CSS3, and Sass (i.e. an illustrated zoo of breakable toys!  Sketches forthcoming )

And there you have it - a post that will help me put my money where my mouth is (or, should I fail at building, put my foot where my mouth is).

Fellow Code Cadets, I need your help.

Today, I wanted to get the models of my breakable toy - a beer pairing application - up and running.  But then, I hit a snag: I couldn't figure out whether to use has_many :throughs to create many-to-many associations OR if I should just use polymorphic associations.  I'm pretty sure the best solution is many-to-many, but I might also be leaning that way because I'm not sure if I really understand polymorphic associations.

In a nutshell, I would like to be able to pair beers styles with different cuisine types (e.g. Thai, Mexican, etc.) and/or main ingredient (e.g. beef, pork, chicken) and/or spices (e.g. heavy on cilantro, garlic, etc.  My boss, who has been at this for 30 years, is going to give me a better explanation of the "spice" thing).  However, once a pairing has been made, I would also like to tell the user why the pairing works.  I would also like to be able to do the opposite: isolate a cuisine, main ingredient, or spice and give users beers that pair with them.

And so, I think I'm going to need five models: Beer, Cuisine, Main_Ingredient, Spice, and Pairings. The associations will look like this:

class Pairings belongs_to :beer belongs_to :cuisine belongs_to :main_ingredient belongs_to :spice end

class Beer has_many :cuisines, :through => :pairings has_many :main_ingredients, :through => :pairings has_many :spices, :through => :pairings end

class Cuisine has_many :beers, :through => :pairings end

class Main_Ingredient has_many :beers, :through => :pairings end

class Spice has_many :beers, :through => :pairings end

If I'm understanding polymorphic associations correctly - which I've mainly learned about by reading the RoR guide and random blog posts like this one and this one - they're great if you want to set up relationships between models WITHOUT creating another join table. However, since I will want to include additional information as to why the pairings work - e.g. a string that is associated with a specific pairing - using has_many :through and the Pairings table seems to make the most sense.

I'm hoping that a) this post made sense and b) someone will opine.   

Confession #1: I've been terrible at blogging.

Confession #2: I've been terrible at blogging because I keep starting posts, then leave them as half-finished drafts because RoR does something new and/or magical and I become completely entranced by the new and/or magical thing it does.

I also got distracted by the Programmer's Manifesto and the Become a Programmer, Mother[expletive deleted] resources (I'm trying to keep this programming blog PG-13!).

As I told Alfonso yesterday, Code Academy has always been intense.  However, things really picked up steam around week 5 which, coincidentally, was when I started writing halves of blog posts.  I'm certain that this jolt in learning speed and pace was a direct result of the first 4 weeks of Code Academy, during which Jeff Cohen carefully laid out an educational framework that has made it infinitely easier for us to pick up new material on our own.

Since week 4, I've been working on a bevy of things:

Writing wrapper classes for APIs (and getting up close and personal with HTTParty)

Learning about mocking, stubbing, and RSpec

Overcoming my irrational avoidance of Git and GitHub

Working my way through the Michael Hartl Ruby on Rails Tutorial

Mockups and research for a breakable (beer) toy!

Debugging the bug(s) from hell so that my computer finally plays nice with RVM and Ruby 1.9.2.  This is an epic five week saga that finally concluded after 48 hours of crazy bug-tracking.  Granted, it's nothing compared to this awesome article about an incredibly subtle bug that Raghu emailed out to the rest of Code Academy, though I'm pretty sure the adrenaline rush I got after getting everything to work was comparable.

Tonight, I'll be working on mocking and stubbing with RSpec so that I can finish writing some wrapper classes, which may or may not unleash a deluge of backlogged blog posts.

Lately, I have been thinking about the craft of writing and the art of coding, and how the two are not as mutually exclusive as people think.  

For years, my friends have thought of me as a "writer" - a poet, an essayist, an MFA/PhD candidate in the making.  In high school, I was the weird kid who spent her summers in writing camps and passed time in the subway by scribbling furiously into hard-backed, lined notebooks.  I was in love with the written word, and spent hours, days, weeks writing and re-writing manuscripts, agonizing over each comma, over shades of meaning and finding le mot juste.  My college education was funded, in large part, by writing scholarships.  

But the term "writer" is one that makes me wince: I could barely stomach the other "writers" in my New York City high school, its geographic location alone dooming it to pretention and a student body with a predilection for cigarettes, black clothing, and the term "ennui."  What bothered me about "artists" who dotted my school's halls, however, was their insistence on wearing the label "writer," "musician," or "painter" without the creative products to substantiate their claims.  And when my classmates would tell me that I was a "writer" (and that I should take up smoking and wear more black.  Oh, high school), I would tell them that I was really just enamored with words. 

What I realized this week is that the path of the software craftsman is much like the path of the "writer."  The "wordsmith," if you will.  The discipline of writing and re-writing is akin to to that of coding and re-factoring, exercises that push you to trim the fat from your words and your code to create a final product of expressive eloquence.  My motivation to write stemmed from the irritation of feeling silenced, of the scratch of a phantom muzzle: words are tools of expression, but without honing their edges, they become dull and clumsy.  Words are, in the end, just strokes upon a page.  I think my motivation to code is the same: computer languages exist as a means to express and create, but without syntactical and linguistic understanding, they are simply bytes flashing upon a glowing screen.  The desire to write and build seems fueled by the same creative spark.

Which leads to what I've learned this week: I have been feeling strange about adopting the label of "programmer" because I have not built anything of my own.  Yet.  I haven't coded something of my own for a number of reasons: at the beginning, it was because I did not know enough to code something effectively.  As of last week, it was a mix of failing health, apprehension, and fear of failure that (stupidly) held me back.  And now, I realize my big project - a tool to help the beer industry - is a business to business app that requires more research and interviews to whittle down into a viable MVP.  I shot off more rounds of emails yesterday, and think that I should have more information by next week.  While good, the benefits are limited since I am itching to code now.

The biggest hurdle from the list above is my fear of failure, which I think I am starting to get over as I talk more and more to others in Code Academy.  Seeing everyone else's apps is inspirational, as was pairing with Paul and Ryan earlier this week to create a Stack Overflow clone.  And after an absolutely wonderful discussion with Raghu yesterday - about life, APIs, beer, and databases - I think I've come up with a breakable toy that might help me figure out how to code parts of my larger project: a BYOB beer sommelier app that uses the Geocoder API to figure out BYOB restaurants and nearby liquor stores, as well as the Untappd API (that I need to apply for.  Happening as soon as this entry is over) to handle beer ratings and descriptions.  Pairing beers to cuisines is what my friends rely on me to do anyway, so the bulk of this app is going to be creating many-to-many relations between cuisines and beers and a ton of if-then rules per each cuisine type.  At least, in its first iteration.

I realize this week's entry skimped on the crazy amount of stuff we learned this week - password authentication, sessions and cookies, filters, seeding databases, to name a few - but I think the biggest lesson I've learned this week is to stop hedging and start building.  

A-HA Moment

While working with today's Academy Air app, I realized that I didn't understand something in one of our controllers.  I am currently realizing that I should have dropboxed a version of the file to myself - I have Jeff's code, but Dave Anderson and I seem to have coded something differently.  In any event, the gist of my a-ha moment was having Geoff explain some of the magic under the Rails convention hood.  

Essentially, I was confused about how one of our controllers was setting the name of a symbol following a method call on an instance variable.  Geoff explained the Rails naming conventions behind it beautifully, using getter/setter functions (note to self: when I get my hands on my/Dave's code, I'll need to come back to this post and clarify what Geoff explained.  Further note to self: Paul also explained "build" wonderfully and eloquently as a contrast to something in our code.  Again, the moment I get my hands on said code, I'm clarifying this entry).

The A-HA moment, however, was Geoff's referencing the Rails API and PULLING UP THE RAILS SOURCE CODE.  I realize that Rails is open source, but hadn't made the connection to check the source code to gain a better understanding of how certain methods work.

Non-A-HA Moment

A much-delayed post, but better late than never... right?

My poor excuse for lateness: sickness.  Devastating sickness.  I rarely get sick, but when I do, my entire body shuts down for days.  There are, however, pros and cons to being confined to your home.

Pros

When you can't leave your apartment, lots of reading gets done:

Unix for the Beginning Mage: complete!

The Lean Startup - 50% done

I have also developed a huge crush on the Rails Guides and ended up going through everything on the T-Th Backpack page.  This means:

Model Associations

Model Validations

Rails Guides: Getting Started

Rails Guides: Routing

Forms in Rails

More Forms in Rails

It's simply mind-blowing to realize how much ground we've covered... in three weeks.

Cons

I've fallen WAY behind on hustling up some more problem interviews and making headway on my startup idea.  This just means I need to work doubly hard this week to make up for lost time and ground.  I also realize that while reading guides is well and good, nothing beats actually _building_ something.

Ok, fine.  The last point isn't really a byproduct of being sick as much as my own anxiety over building something and failing miserably.

That said, I'm so very grateful for Code Academy's supportive environment: although I missed Tuesday's class, I ended up working on a Stack Overflow clone with Ryan and Paul on Wednesday.  "Working" is a generous term, seeing as I did little more than attempt to follow their logic, but it was amazing seeing all of the concepts we've learned over the past few weeks become a _thing_.  Working with them also gave me an informal and intuitive introduction to everything I missed on Tuesday.  I'm looking forward to playing more with our app... and to actually contributing _something_ as we continue building it out.

 A Brief History of Unix and Unix-like Spellcrafts

The Unix craft was created long before other spellcrafts -- before Windows, before Macintosh, even before DOS. It was first forged by archmages in the Fortress of AT&T back in the 1960s.

- Unix for the Beginning Mage

It's amazing how much can change in a week, how much the brain can hold, how easy it is to (re)form habits.

Unix for the Beginning Mage

In response to my command line heebie jeebies in my last post, a wonderful Code Academy soul introduced me to Unix for the Beginning Mage.  To be honest, I'm not sure who this wonderful person is, but if you are that wonderful person, please do reveal yourself so I can thank you properly!  I'm only 4 chapters in, but I can say, with complete certainty, that it is one of the most fun computer books I have ever read - it manages to make learning about the command line as much fun as playing Hocus Pocus.

...and now that I've alerted myself to Hocus Pocus' existence on the DOS games archive, I may or may not be spending part of the evening revisiting my childhood.

(Hacked) Pomodoro Technique

At the end of the Pomodoro Technique, Staffan Noteberg mentioned an index card-based time management technique that was eerily similar to the one I followed in college.  In an attempt to minimize stress, I would write down all of my activities, assignments, meetings, and papers for the week, then divvy up each day's tasks on notecards.  Each morning, I would post the day's notecard above my desk, and swore to tackle every item on my list.  I consider my college diploma a sign of (mild) success (stress... well, the minimizing stress thing didn't always work).

Two years later, I have found myself flanked by index cards yet again.  Instead of using a single index card, however, I divvy up multiple index cards into 30-40 minutes worth of work; when those 30-40 minutes are up, I shed my index card with a satisfying riiiiiiiiip. 

For the past week, this method has worked wonders.  Primarily, I think, due to the paper-ripping satisfaction. =)

Rails

Each week, Jeff posts the concepts we will cover on the Code Academy Backpack site.  My new project is to be able to define each and every project - in my own words - by the end of the week.  Not that this is a valid excuse for a late blog entry, but I grossly miscalculated the amount of time I would need to write up definitions for each of the concepts.  Programming, I think, is a neverending digital journey down a rabbit hole: just when you think you've grasped a concept, you find something new and mysterious and plunge ever further down, down into the coding depths.

I'm hoping to post each of my weekly definitions on this blog - spread out over the course of a few days so that I don't end up with a gigantic, monster post - but Code Academy definitely keeps me busy!

Some A-ha! moments:

RESTful routing

Using "resources" on the routes page to perform GET, POST, EDIT, and DELETE

Discovered while reading some resources Jeff suggested to us: when to use paths v. absolute URIs (uniform resource identifiers): http://www.viget.com/extend/rails-named-routes-path-vs-url/.  In simple form, absolute URIs are used to link SSL to non-SSL sites (and vice versa), as well as redirects.

Lean Startup

Just throwing this in here because, well, following the Lean Startup Challenge's directions and updating my lean canvas via problem interviews has taken up a lot of my past week.  As much time as it eats up, however, it's also incredibly fun!  I'm looking forward to talking to my classmates about their ideas and utilization of lean principles.

  Hello, World.

My name is Danica and I just completed my first week of Code Academy.  Rather, the second week will be heralded by the midnight stroke in 1.5 hours... which really just means I've got to get this post up and out FAST, and that I need to write more frequently and with more buffer time (see "Improving").

So much has happened over the past week that I'm not sure where to begin - a problem I anticipate recurring over and over the next 12 weeks, given the speed at which we are moving and the superb human beings who compose the rest of the class.  Some thoughts in digestible form:

Coding 

I absolutely adore our instructor, Jeff Cohen.  Aside from being incredibly smart and articulate, Jeff has all of the qualities of a great teacher: patience, lucidity, approachability, and genuine concern for student understanding.  I feel incredibly lucky to be learning from him, especially since the next weeks promise to move at breakneck speed.

While Tuesday's lesson was mostly an HTML and CSS review (certainly helpful for highlighting some HTML5 and CSS3 differences and serving as a jumping point for further research), Thursday's first Rails lesson was completely new to me.  Although I was a web developer in a past life and have tinkered with Java and Ruby, "Rails for Zombies" is just about all the Rails I know.  Which isn't much.

I met with my mentor, Mike Busch, on Friday, at which point I discovered that he is probably some sort of saintly reincarnation.  After presenting him with a laptop with all sorts of funky Rails environment and git issues (namely, gems behaving badly and a git executable that insisted on playing hide and seek), Mike worked some magic in the Terminal and had everything up and running within minutes.  

Have I mentioned that using the command line makes me exceedingly uncomfortable?  

However, seeing Mike work his wizardry - and having him explain some of the methodology behind the magic - has helped me overcome my irrational intimidation of the command line.  Command line, I will learn you.

Reflecting

The biggest takeaway I have from the first week has absolutely nothing to do with coding and everything to do with the people.  I am absolutely astounded by everyone else in the class - their stories, motivation, and determination - and am slowly finding the courage to dissolve a business that I worked 1.5 years to build.  This is a class built on passion - people have quit jobs and traveled across the nation (and globe!) for Code Academy - and it's time to take a cue from my classmates and follow what my (geeky) heart is telling me to do. Besides,

Waste is any human activity which absorbs resources but creates no value.

- Womak and Jones, Lean Thinking

Preach.

Improving

As I wrap up this entry with bleary eyes:

Write more frequently.

Get more sleep.

Begin working through "Agile Development with Rails" as a supplement to the class...  once UPS decides to release my copy from captivity.  

Get more comfortable with the command line by working through man pages.