MakerSquare Day 14: Mondays! (4/1)

Theme: Many roads lead to the palace of wisdom. Or, in this case, the palace of correct implementation.

It's not a great theme, but that's Monday for you. My girlfriend has noted that I have certain cat-like qualities: fast reflexes, purr when chin is scratched, nuzzle when hungry, etc. Has MakerSquare finally completed the transformation and turned me into... Garfield?

Which would explain my sudden urge to mail Nermal to Abu Dhabi.

(It should also be noted that many of my cohort are too young to have marinated in the brilliance that was Garfield and Friends.)

And that long intro should indicate to you that I've had a very long day here, at Chez Code. I don't mean long in hours so much as long in content, if that makes any sense. (If it doesn't, see above comment about "long day.") 

Today started off with seeing the instructor's code for Songify 3 (subtitled: This Time It's Personal and also a Database with a Web portal on top), which was interesting. There are lots of useful ideas I got, but I also noticed that we had a lot of overlaps, which could not always be said of previous code. (::Pats self on back for learning.::)

No, wait, today started off with some Ruby challenges, then Songify (::pats self on back again::), then segued roughly into Javascript (::no pats on the back::). 

Don't get me wrong: I like Javascript and last week I had some really fun and slightly advanced implementations of a pseudo-minesweeper web game. 

(That came about when I finished some work early and the teaching fellow said, "I bet you could make this into pseudo-minesweeper." To which I responded, "Never! That's impossible! Oh, wait, I guess if I..." Which is how a lot of my projects start: "I guess I could do this... which means I could do this... which means...".) 

But today's practice was strangely difficult, and not just for me (thank god). I blame the weekend, which means that, yes, I'm back to blaming Monday, which means that, yes, I am Garfield again.

With one crucial difference: Garfield never stayed up late to run through the practices again and see how he could do better. (Or maybe he did: the cartoon was always a little vague about his evenings.)

MakerSquare Day 12: "Think in trees" (3/4)

At least, that's what our afternoon instructor said. I think he mostly meant that we should "think in trees" as it relates to the DOM--the document object model--which is representation of HTML, where everything is a node and all the nodes are connected in a family-tree-like structure. It's helpful to think in trees so you remember what's a parent node and what's a child node, which is helpful when you style things in CSS* or get things with jQuery**.

But I prefer to take him in the more philosophical sense of "think in trees"; as in, think in improving incrementally, like a tree growing. Or think in a tree's branches, so that all your ideas can spin off into other ideas. (Or, if you're using git, think in branches so that you always have some earlier version to go back to.) Or think in trees because sometimes--always and inevitably--you'll have to prune back your code to improve it.

Which is what I spent a fair amount of the morning doing. Today we started the third part of our Songify project, involving multiple tables in a database. It wasn't easy, particularly because the first change that I made involved me going back and changing a bunch of my old code. Which makes it a weird morning: not very productive in terms of code, but very educational in terms of re-viewing my code.

Today wasn't all sitting through: I did play two games of ping pong and did a lunch-time yoga. I'd be in really OK shape by the end of this program if I wasn't constantly eating.

* Cascading Style Sheets: a way to apply lots of formatting and structure to HTML.

** jQuery: a Javascript library specifically for working with online materials.

MakerSquare Day 11: If you don't ask, you don't get (3/3)

Today's theme is basically the title.

And it all started with cereal.

See, in classic tech-company style, MakerSquare has a little kitchen with some snacks stocked by the company, including my favorite, Honey Nut Cheerios. (Consider this a plug, and, if you work for General Mills, feel free to send me cereal.) There's milk too, but, gasp!, it's regular cow's milk, which I am allergic to or intolerant to or scared of. (Whichever you prefer.)

So today, after looking at the cereal for two days, I sent an email to someone in the organization asking if we could get soy milk. And instead of telling me I'm a prima donna (which is true), she said, "sure!"

Which goes to show the truth of that old saw: If you don't ask, you don't get.

And that brings me to the structure of MakerSquare, which is very student-centered and student-led in a way. For instance, today, we spent some part of the morning talking about mentorship and about being clear about what you want from your mentor. Then, in the afternoon, we talked about CSS by all coding up a little web page together, with the students offering suggestions on what they'd want to see and then everyone--including the instructor as the final arbiter--figuring out how to write the HTML and CSS to get that.

The rest of my notes for today are all super specific CSS comments, so I'll leave you with the note that I am still terrible at ping pong, but that our master ping pong player just gave me a little lesson.

(Yes, this is tagged "Sinatra" and "Songify" because we spent time doing that, though I didn't have much to say.)

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.