Teamwork

One thing you’d better learn quickly when riding a tandem: how to work as a team. A *lot* of communication is required. Generally, the person in back (the stoker) has no idea what’s coming, so it’s inherent on the person in front to warn about things like bumps in the road (so the stoker can stand up). By the same token, the person in front (the captain) has a hard time hearing any cars approaching from behind, so it’s up to the stoker to provide warnings, and to act as a flag-man for the cars, when riding through blind turns.

One of the things I like about Metis is the teamwork approach – which appears in multiple guises: the teachers, working in tandem to keep a disparate group of learners nominally in synch; the formal “pair programming” in which we students team up with each other to work on a problem, jointly; and the informal atmosphere of helping one another out with questions.

Learning so much in so little time can feel a lot like riding through a series of blind turns with traffic approaching from both directions. It’s nice to have a team of people to work with while navigating through it all.

So far, for me, Metis has been a great program. I feel so unbelievably lucky to have this opportunity!

The Mystery of the Uninitialized Constant

screenshot of an error in my code

With error driven development, you see a lot of red and pink on your web site. The trick is to learn how to interpret what the message is trying to tell you.

Most of them are pretty clear. If the word “path” appears, you’re probably missing something (or have a typo) in the routes list in your routes.rb file. If the word “relation,” or “table” appears, it’s probably the database.

This one was less obvious to me (ignore the line highlighted in pinkish-red, and read the text at the top of the image):

error message: uninitialized constant
the mystery uninitialized constant

I checked that the class existed, and that its name had no typos. I checked that it was being referenced correctly in the methods that needed it.

I checked that the things that need it (and that it needs) had relations specifications (“has_many” and “belongs_to”) in the right files.

I was stumped. So I asked for help.

And the answer is:

Model names are singular. The error message shows that the server was looking for a plural model name.

Hmmmm, so where in the app is it being used in plural form?

The model was properly defined, and its file name was correct, so “unwinding the stack” to the methods that use the model showed that they were also properly defined with no mystery plurals.

The next step was to look at the places where relations were specified, and voila! There was a plural instead of singular in the Tagging class’s “belongs_to” relation.

Yay! It’s fixed, now.

Here’s what should appear, instead of that error message:

image of an adorable rodent
much cuter than an error message!

So, This Just Happened

Undefined Table Error

I wanted to better cement what we learned today by re-doing the day’s coding in a new branch. With a bit of help re: how to not have to nuke my existing database for the evening’s fun, I got it all up and running, and started coding.

The methodology we’re using is called “error driven development.” You start by adding code to the page that users see, pretending that the stuff it’s supposed to do on the back-end has already been written. Load the page, see the error message, then go code exactly (and only) what’s needed on the back end to make *that one error* go away.

When I got the error shown above, this *actually* went through my head:

“Woo hoo! I know how to fix that!”

Is it sad that I’m getting excited over error messages?

Week 3 Commences!

I can’t believe that, as of Friday, we’ll be 1/4 of the way through this course!

I can believe that, if the pace keeps up, we’ll be making some pretty cool [stuff] by the end of it all.

Today was the introduction of rails. Some of you know that I started working on a web site a couple of years ago, made a ton of progress, but decided I *really* need to *understand* what I’m doing in order to implement the payments API properly. I’ve had several “ah ha!” moments in the last couple of weeks, but today is the first time a bunch of the “whys” and “wherefores” of some of the rails-specific coding conventions became clear. I think I’ll spend some of our “free coding” time on Friday to troll back through the work I did for green planet heroes and see if I can better understand some of the trickier bits.

I take notes in 3 different places, depending on context: a hand-written notebook for things like diagrams, definitions, and references, a dated text file for the day’s lectur-y bits, and in the comments on the sample code. The snippet above is in a file where we did all the work rails could have done for us, then learned the simple rails commands that do the work. All the other stuff is now commented out above where this snippet begins, so I can refer back to it.

This is so awesome!

Committing to Good Git Commits

screen capture of google search results on the words "git commit messages"

The preferred version control system in the ruby world is named “git.” The name doesn’t really have a meaning. Its inventor, Tim Berners-Lee, who also happens to be the inventor of the linux operating system, indicates that its meaning is as varied as his mood at the time he’s thinking about it.

This week’s Friday guest speaker dove into git, some of the nitty-gritty of how it works, and how important it is to be descriptive in the message you include with each commit. You want other people – and more importantly, yourself – to be able to figure out what the heck you thought you were doing when you saved this particular work of coding art into the source control system.

I was originally taught to make really, really short commit messages, a habit I’m going to have to un-learn.

A Few Long Days

Between 6:30 Tuesday AM, and 11:30 Wednesday PM, I managed to get about 3 hours sleep, due to a family emergency – thus, no post last night.

We’ve started learning the nitty gritty of using ActiveRecord to interact with the database. I went to a Boston Ruby Group event on Tuesday evening, where one of the speakers was speaking about ActiveRecord. I figured this would be a great way to get a little info on what we were about to start doing in class. However, it turns out the speaker, Ernie Miller was there to talk about his new effort, “norm”, which is a lighter-weight DB API, intended to replace the now old & crufty ActiveRecord for the most common db access requirements. It was a great talk, and I have a feeling we’ll be seeing more of norm in the future.

In the mean time, the class has started digging into the process of learning to understand what ActiveRecord code looks looks like, how it works, and some cool shortcuts to save a bunch of typing.

curling

Nope, not your hair, and not that thing they do in Canada, with brooms and a hunk of granite that has a handle screwed onto it.

I’ve seen curl in use, but never used it before.

Think of it as a browser without the actual browser – you can access URLs with it, and the server will answer with stuff you’d see if you right clicked on the page in your browser and chose “view source.”

It’s got some nice other features, too: for example, you can send a request to the server that you can’t directly send via a browser, such as directly sending a POST or PATCH command. It’s great for testing when you’re not quite getting back what you think you should be getting when you use your page in a browser. If you send the command that *should* be going to the server, seeing what comes back will tell you a lot about whether is sending what you *think* it’s sending.

ILIKE sushi

I don’t actually like sushi. As a matter of fact, it ranks right up there with mushroom quiche on the “food hate” scale. But I find it wicked funny that the case-insensitive SQL command for filtering by a string is ILIKE (the case sensitive version is LIKE). It means you can end up writing a query that looks like this code snippet:

   SELECT galleries.name, COUNT(images.id)
   FROM galleries JOIN images
   ON galleries.id = images.gallery_id
   WHERE images.name ILIKE ‘sushi’
   GROUP BY galleries.id ORDER BY galleries.id;

I’m easily amused.

Hung up on Hangman

I started fixing one little bug in the hangman problem for class, ended up rewriting the whole thing, then had a total brain cramp on the way the array iterator works, wasting a ton of time on trying to figure out why a number was incrementing incorrectly. Sigh.

Hopefully, I’ll get better at seeing that kind of “obvious” error as I get used to the syntax.

Rubber Ducking

So, um, this is a thing. If you’re stuck on a coding problem, you can try “rubber ducking” – pretend that you have a rubber duck on your desk, and try to describe to the duck what you’re trying to do, and what’s going wrong.

Sometimes, just talking through the problem (even if the conversation is imaginary), you can get a better perspective on the issue, and be able to resolve it.

Skip to content