MakerSquare Day 26: Little nifty bits of magic (6/3)

You don't often hear "magic" and "database" in the same sentence, except for those sentences that start out, like this one, noting how rarely you hear "magic" and "database" in the same sentence, except for those sentences...

I can never resist a recursion joke.

So "database" and "magic" don't often go together, except for today, when I came back to ActiveRecord and saw how it had all these nifty bits of magic.

Seriously: I can't think of a better word than magic--or nifty--to describe ActiveRecord.

Up till now, a lot of the database work I've done has been directly in postgreSQL, which I weirdly liked. About a week ago, we looked briefly at how ActiveRecord serves as a mediator between SQL-like language and Ruby. It looked interesting and, sure, helpful, but I didn't want to give up the control I had of talking directly to my PSQL database; and anyway, I didn't have any project that needed a database right then.

Fast forward to today, when I was implementing a Rock-Paper-Scissors game and needed a database, and, what's that?, my old notes on ActiveRecord. "Well, why not?" I said to myself.

If you've seen 2001, you'll know what it's like after that, with all the colored lights and the brain-expanding monolith. To be clear: there's something slightly sinister about the Monolith in 2001 and there's something slightly sinister in letting ActiveRecord mediate for you. But still, there are all sorts of--I'll say it again--nifty bits of magic that go into ActiveRecord. Like telling tables so easily what they hold and then, automatically, the entities for those tables know what they should hold too. Or the ease of telling a table to make sure that it has a certain bit of info with "validates." Or--

And so on. You see that none of this is ground-shaking, Level 9 spellcasting. But it's all useful and neat and easy to use. Perfect for a Rock-Paper-Scissors game.

Now I'm off to update my database to show that I've beaten a million people at RPS, because that's one of the simple pleasures of having server access.

MakerSquare Day 19: There's always a better way (5/1)

I have just finished inventing a new game I call "Checkers," so I may keep this short.*

Today's theme is the title: "There's always a better way," whether you're creating a database or writing a bunch of if/else statements for Checkers.

In today's lesson, the better ways include 

• a) using ActiveRecord as a programming interface between you and the database, so that you don't have SQL language in the middle of your Ruby program; 
• b) why you don't need to check if either array is empty in your MergeSort (because if you just attach the two original arrays to your solution array, whichever array is empty will just disappear); and 
• c) how you can always make your life easier by not trying to make it complex too soon (i.e., if you're programming Checkers, start with moving a piece, then work your way up to jumping).

Also, I'd like to note that I went out after school to meet with my mentor and we had a very pleasant conversation. He also laid out the number of ways he can assist me in preparing for the job market--everything from code reviews to mock interviews (oh, how we will mock those interviews! That's what that means, right?). So now I'm really excited for our next meeting.

Perhaps he would like to play this brand new game I invented.

*Claims of inventing Checkers not fact-checked. I did, however, write a bunch of functions that allows Checkers to be played; and now I have to just slap some interface together and it'll be playable in the console or in a webpage (according to the assignment instructions).**

**Note: Slapping together an interface isn't as fun as it sounds.

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 9: He did it his way (3/1)

Huh, I just realized that I stopped giving each day a theme. Which seems fine now because, really, how do you boil a day down to a theme?

Take today for instance: we started a new project we're calling Songify, a music/playlist manager. So we started by creating a song instance; then we created a database for those songs, along with all the methods that you would need.

(And here I'll talk about one of my strength/weaknesses: I like to do things the best way. I know, it probably sounds like I'm preparing for a job interview, but it's a true problem, and here's the example for the day: I wanted to write a method that could search by album or by artist and return all the songs that matched that category. Off the top of my head, there's a simple way to do that with some basic control flow: ask the user if they want option A or B and give two fully-written methods for each of those options. BUT! Since those options are almost identical, wouldn't it be great if you could somehow provide the switch INSIDE the meat of the method? And that's how I ended up looking around online for a while--even going so far as to post my question to Reddit.)

This program will eventually become a web application of some sort, which I know because we spent the afternoon looking at how Ruby and HTML can interact. The answer is Sinatra, which is a ... well, it's not a "framework" in the technical sense, but that's what most people call it. Curiously, whereas most work in class is hands-on coding, individually or in small groups, this was an all-class discussion and example. Which might sound relaxing, but since it was pretty new, it was pretty intense.

Luckily, I'd spent part of my lunch hour doing a little yoga with some other students, as well as playing ping pong, so I was up for the challenge.

Special bonus note: After class, I went to playtest a video game, which was very interesting--both the game and the process.

And apologies for the title of this blog post, today was full of Frank Sinatra puns and references.

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.