MakerSquare Day 4: How to write a test (1/4)

Friday is notable because it's the end of the first week, which means it's the traditional day for a MakerSquare student party. It's interesting to meet the C8 students, the people who were in our spot only six weeks ago, but who seem awfully experienced. Whenever we mention a challenge, they look at each other and nod knowingly. Will we be like that in just a few weeks?

My guess is yes, because it's kind of amazing to think about all the stuff we've been exposed to this week. Friday was, planned or not, a kind of summation day, where we went over some challenges from the week: how to work through algorithm problems, how to design a library*, how to write a test.

As expected, I continue to be roundly beaten at ping pong. I sort of wish we had an A league and a B league; but at the same time, getting beaten by A-league players sure does stretch my skills.

* We designed library from the tests backward: given a bunch of rspec tests, we had to make them all pass by steadily expanding our library's functions. (A failed test comes up in red, a passed test comes up in green; so you'll hear people talking about making the test "go green.") But after thinking about it some more, I think I'm going to spend part of the weekend re-working the library with a few extra classes: a book, a library wrapper, a borrower-card, a library, and a review class. That way I could extend it in various ways: the "book" class could be reused by a book-store; and the library-wrapper class could be used to wrap any other object the library wants to lend.

MakerSquare Day 2: An Intro to Github and Rspec (1/2)

Theme: Zen and the art of testing

I don't know what will make less sense to people reading this blog: my title or my theme. Or maybe you're a MakerSquare student and you understand it all--as well as the pain behind it.

But for my parents, here's the quick skinny: Git is a version control system that I didn't quite get before but that I'm devoted to now; and Github is a website where you can store all of the versions you've written. So, for instance, let's say you write your code and it works--great! Commit it to Github. 

Then you decide to add some new function and it breaks something in your old code and you don't remember what--well, not that big a problem. Just rollback your program to the last time you committed. In short, Git and Github are great ways to experiment on things without screwing up what you've already got. 

In a similar but completely different vein, rspec is also a very logistical side issue to coding: it's a way to set up a program to test your original code. Which means that, yes, now you have two chances to screw up and twice as much code to debug. But really (say the instructors) it makes a lot more sense to work with rspec rather than to test your program by copying everything over to irb.

(Oh boy, I really should link you to a dictionary site because there's lots of special words here. "Irb" is the interactive Ruby shell, where you can run Ruby right in your terminal.)

Today also involved a visit from Savrut of career services, which was very interesting and full of plans for future events: mock interviews, resume reviews, etc.

Also, he said that any tech company thinking of hiring you would find your online presence, so... Hi!

But I am running out of steam here and I still wanted to note something Nick said today that pinged my sense that coding involves a lot of strange Zen overlaps. (Or Derridean deconstruction, if that's the way you want to take it.) Today's comment (paraphrased):

"You want your code to be broad and very specific."