MakerSquare Day 34: The hard way first (8/1)

First, I've been bad about holding my blogging time to 15 minutes, so I'm back to setting an alarm. So let's see what I can tell you about the Monday of our eighth week in only 15 minutes. (It's so interesting to me how 15 minutes can seem like an eternity--if, say, you're waiting for a bus--or like no time at all if you're trying to get something done.)

(Speaking of buses, I decided not to wait for one last night, and on the walk home, I saw a fox running along the street, which means that I really made the right decision. Have I told you how much I like most animals in the Canidae form? I guess that doesn't really have much place in a coding blog. Unless I can somehow come up with a dog-related coding project...)

Many weeks ago, we learned how to use PostgreSQL to create and access database tables. Which meant that, on top of learning Ruby, we had big chunks of this other language in our code. Then we were introduced to Active Record, which is--ok, this gets a little jargony, but here goes--an ORM (object-relational mapping), or, in less-jargony form: Active Record is a way to write Ruby that will talk to your database in whatever language that database likes to talk.

I've said it before, but Active Record is kind of magical and cool (for at least some value of cool); and the topic was introduced to us with,

"Now that we made you learn PostgreSQL, we're going to teach you this easier way to do things, and you're going to hate us for making you do it the hard way first."

But I really didn't. It was hard to start with PSQL, but doing things the hard way first means that (a) you appreciate the magic of the easy way and (b) you understand what's going on under the hood.

I thought of that yesterday after our first day of Rails. Have you seen Rails? It's kind of amazing how Rails does so much for you. So after weeks of hand-producing files slowly and carefully, now I just type "rails new <Project_name>" and everything appears as if by magic. Which is great and amazing--but I'm still glad that we did it the hard way first, so I can understand what's happening.

MakerSquare Day 21: Hackathon (almost)! (5/3)

Instructors, like everyone else, have catch-phrases. Now, it's possible that I was raised on old sitcoms, so I think everyone has catch-phrases, when in reality, only instructors do, but it comes to the same thing.

Instructors have catch-phrases.

And one catch-phrase that we heard several times in one day from our great Javascript instructor is that "The other students are our biggest resource."

And, as much as I like Google for looking for an answer, he's not wrong when he says that. Which is why I'm so excited about the Hackathon starting tomorrow. (Or, rather, starting today, by the time this is posted.)

A large part of today was dedicated to preparing for the Hackathon: coming up with ideas, dividing into teams, asking some questions of ourselves and our instructors (who, I'll admit, are also a pretty good resource).

And here's something else that happened today which may help demonstrate why I'm so excited for tomorrow. (Oh, and also: there will be breakfast tacos.) We started today with a coding challenge: given a list of words, find which words in the list are anagrams of each other; and return an array for each group of anagrams. Following the dictum "make it work," I wrote out several lines of code that were basically readable English. It wasn't an elegant or the fastest solution--it was merely the quickest to write out.

Then a peer/colleague presented her solution and it was this beautiful one line of code that worked because she found the Ruby method that was a perfect match for the task: group_by.

Now maybe in my younger days I would've been jealous to be outdone like that; but with the perspective of my thousands of years (or maybe it just feels that way), I can see that single line of code and just enjoy the elegance.

And also, now I know group_by.

So yeah, the other students are a pretty good resource.

Bring on the Hackathon!

MakerSquare Day 18: I am beginning to love this. (4/5)

To be sure, when I say "this," I am referring to something very particular: Javascript's "this", which is a reserved keyword that refers (roughly speaking) to the context in which it's called.

So, for example, if I write a function--let's call it contextA--and I give that function a this.name property with a return value of "Ben," then any time I'm in contextA and I call this.name, I'm going to get back "Ben."

But if, let's say, contextA calls another function--and, off the top of my head, let's call this one contextB--and contextB calls this.name, it will no longer give back "Ben."

Now, I'm sure, given 10 minutes, I could come up with some non-computer-y analogy that might make this clearer to the average joe and jane, something like:

"this" is the undead hand of a convicted murderer, always pointing back to its traumatic origin story--except for when it doesn't. Which is all the time. Scrap that. "this" is like a compass in a world where everything is magnetic north and also ghosts are out to get you. No, that's not it.

(Also, can you tell Halloween talk is beginning to get to me?)

To sum up, "this" is a strange little word that can be very helpful once you understand what it can do--and what it can't do.

And today, with a great hour of Q&A with our Javascript instructor, I felt something click into place, as if I found a spot for "this"--that undead hand trying to crawl home, that swinging compass needle trying to orient itself.

Now if only Javascript had a "that" as well.

(Actually, it's pretty great that Javascript doesn't have a "that" because this way, if you ever need to save your context at one moment so you can call it later, you can do so by saying

that = this

which makes me so happy.)

MakerSquare Day 8: The day we had an actual puppy in class (2/4)

I no longer could stand calling my puppy-breeder classes by that name and today I decided to rename them "PAWS," after the shelter in Chicago where I got my puppy.

Due to a change in schedule, today was entirely dedicated to that one challenge: getting our puppy-breeder (ahem: PAWS) classes to work with our PostgreSQL database.

It was interesting to sit and code on one project for so long. It was especially helpful to have the other students and the instructor just focused on this one issue (getting the Ruby to talk to the database). And I'm glad to say that it all worked out.

I'm also glad to say that we had an actual puppy in class today. One of my fellow students has a service animal, a big German Shepherd (I think) named Mischa, who was very well behaved for the whole day. Which was a cute change of pace for the class. Now we have to start thinking: what other animals can we bring to class? I'd love a trained bear who could walk on my back when it starts to get cramped. Or: how about a trained chiropractor?

Though I'll end this by noting that there's rumors of a student-led yoga session on Monday. What do you wear to a casual class that might also be a yoga session?

MakerSquare Day 7: Puppies and databases--two great flavors! (2/3)

I have added a "puppy" label, since much of this week has been dedicated to that puppy project, which has steadily grown: first we did it; then we added some new functions; and now we're really going deep into databases.

However, the morning was given over to working on and improving our Project Gutenberg algorithm. Which I never explained my version of, so: 

For my first version, I did what I considered the obvious: I trained the program by taking the training books, making a hash for each category, and counting all the meaningful words. (We were given a list of "stopwords" that we could discount, like "and," "the," and "Gutenberg." Part of me rebelled against that since, as we know from Franco Moretti, you can sometimes learn a lot by looking at "the" vs. "a." Lit-nerd out.) I then took the top few words for each category and looked for them in the books-to-be-tested.

But since I was already done with that version on Thursday, I decided to spend my time looking at the TF-IDF version, where you

1) go through a text and count each time a word appears for that text (the TF or term frequency); and

2) go through a set of texts and count how many texts have that word--and then take the log of the ratio (the IDF or inverse document frequency.

Weird, right? Anyway, that gives you a number that tells you how important a word is to a set of documents. So you can use that word score to help judge what genre a book is in.

Which was a long and interesting trip that resulted in a score that wasn't too much higher. Ah well.

After that, we did more database stuff for our puppy program.

Also, ping pong. Am I getting better? Well, I'm not getting worse.

MakerSquare Day 5: Swimming with a new pod (2/1)

Our second week started with a bunch of pod-switching, which makes me realize I never described our office beyond "has a ping pong table." Really, the ping pong table is most important. But if you must know, we have three big desks that the students sit at; along with a tall desk for the instructors; and a wireless-enabled projector that has only once or twice accidentally picked up on someone's music or Skype call.

First week, I was in pod one; second week, pod two. Which seems like a great idea. I could imagine someone saying "why do we need to do this?" But already I've had more conversations with my new pod-mates than I had with them when they were not my podmates. Of course, given my sentimental nature, I'll probably start thinking of pod two as a close family and then get wrenched away from them next week.

Speaking of wrenching away, today's big project was to work on something for a puppy breeder. (If I can get political for a second: people, check with your local animal shelter or rescue before purchasing a puppy from a store or breeder.) There was a lot of individual coding time working on setting up the tests and turning them green. 

Bonus challenge: we were given a list of things the client wanted... which was not all the information we needed. The lesson being that sometimes you got to form questions to ask the client so that you can do your work. Or that our client was irredeemably sloppy in their thinking and should not be allowed to have any puppies.

Extra bonus: after class, a few of us went to a meetup for the Austin Ruby community, which was interesting since the topic was testing and rspec and how sometimes you shouldn't let your tests drive your programming. All in all, it was very interesting to meet some experienced web dev and programming people.

Though my real takeaway was this line of argument, which I'm paraphrasing from something that night's speaker said:

"When something is painful, it is broken; make it better—nobody else can."

I don't know about you--like, literally, I have no idea who you are reading this--but that line moved me some. With all this talk about Ruby and rspec, we shouldn't forget to make our code beautiful in its own way. Or put another way: don't forget to have fun.

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 3: Surrender to the algorithm (1/3)

Theme: Don't worry--except about ping pong

In case you wondered, yes, I take a few notes every day. Or at least, I do when I remember to. The notes for Day 3 include the note "just lots of coding."

Which is like the time I wrote on my calendar "Thursday." I mean, at least I wrote "Thursday" on a Thursday, but... Dear Past Ben: "Thursday" is not a helpful note.

But it's hard to take really interesting notes when you're engrossed in really interesting coding. Which might sound sarcastic to some people--what is "really interesting coding"? But here's something else to add to the list of things I'm nerdy about: science fiction, movies, 19th century history, and Ruby code.

So Day 3 involved practicing with objects: thinking about how many classes you might need to create a really effective library object. Which, honestly, is something I could add to the nerd list: libraries.

That was the morning learning module; the afternoon lesson, after lunch, started with a quick walk around the building before we tackled algorithms. Now, at Bard College, I took a bunch of computer science classes; and I hated algorithms. Hated the subject in the way that you hate things where you don't really remember why you hate, but only remember that you do hate.

So it's an understatement to say that I wasn't looking forward to the subject. Well, that's not quite true; on the first day, we'd heard that our instructor Patrick had an interesting way of working through algorithms, so part of me was looking forward to revisiting algorithms. Maybe now I would like it?

And you know, I kind of did. I mean, we'll see what happens when we get to run-time algorithms--worst-case, best-case, average-case. But here, Patrick's idea of the processor touching each element does make a sort of intuitive sense.

Also, I'm a sucker for any example that uses Legos.

And, let's be honest, no matter how hard algorithms might be, they are not as hard as the ping pong competition in C9.

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."

MakerSquare Day 1: "We are your seat belt." (1/1)

Theme: Deep ends and safety nets

First, logistics: I'm going to try to schedule my posts to appear the morning after.

Second: Day 1 was riven--riven, I say!--by one big paradox: we were thrown into the deep end, but told we had a safety net. Or maybe the paradox is more like: learning programming can be intensely rewarding or intensely frustrating. Or put another way, instructor Nick drew a chart of our progress, which would involve sudden breakthroughs and grinding plateaus.

Which was then demonstrated for us--or on us--when we had to do some pretty heavy coding in the afternoon (after preparing our computers). There were some abstract data structure questions that weren't very abstract at all: what's the best way to think about a library? What's the best way to model a book? Would you make those as arrays? Or as hashes?

(Rule of thumb: the answer is almost always "hash" unless order matters.)

But the real work was building a program that could take a plain text file with a recipe (well, a shopping list, really) and parse it into a special class for recipes that--gasp!--we created ourselves. This is one of those lessons where... well, you know when you try to print something and the computer says "Cannot find printer" and you point at the printer and yell, "it's right there!" Well, reading is something that comes pretty easily to us, but that computers need some help with.

So Day 1 basically tossed us into the deep end of Ruby.

But, and here's the contradiction at work, we have a safety net, both in the form of the instructors (Nick, Flip, Patrick, with MakerSquare fellow Ben, who lives at the DevHouse where I live) and of the other students. When things get too frustrating or weird or you don't know what you should do or what you already did--ask someone.

As Nick said, "We are your seat belt."

Also, our office has a ping pong table. That probably shouldn't be important, but I kind of already know what our big office hobby is going to be. I mean, seat belts and safety nets are great--but so are pressure release valves like banging a little white ball around.