MakerSquare Day 31: A Million Little Tiny Tricks: Trick one: Delegation (7/3)

Today was our last day of our current project, a single-page application that gave the reader a quiz. Simple enough to do (that is, not at all simple when we started), but then we had several extensions and expansions, like: allowing the viewer to create their own quiz. To do so, we learned all about localStorage, which is where we were storing information about the quiz.

Which brings me to something interesting that we discovered as a class (i.e., something the instructor wasn't quite clear on), which is that you can iterate over localStorage as if it were an array-like structure.

Which brings me to the real topic of this blog-post: there are a lot of high-level topics and concepts in learning programming, everything from abstract patterns (like MVC) to language foundations (objects, type-sensitivity, etc.).

But there's also a whole range of tiny details and little tricks that you pick up along the way, that even really smart and experienced instructors might not know. And I'd like to share some of them, as I pick them up.

Yes, finally, after 28 days, I have an idea for an on-going blog feature!

Today's trick isn't really a trick: it's a life-saving idea about JavaScript and event listeners. Beginning developers (cough, cough) often have a problem where they/we create an HTML button and add a JavaScript listener to the button--only that button is added after the event listener and so the event listener can't find the button.

So there's a nice jQuery fix where you set a listener to load after the page loads:

$(document).on('ready', function() {

...your listeners here...

}

 But you can also delegate the event listener to the document, like so:

$(document).on(...what event you want to listen to, ...what you want to trigger the event... , function( event ) {...}

That way, the event listener is delegated to the document, which will hand it off to whatever you want to trigger the event, and it will work whenever that event-triggering object is added to the document.

MakerSquare Day 30: Quiet room, loud room (7/2)

Instead of one big room like our Brazos office, the Congress office is, well, one big main room, but with a few smaller rooms coming off of it: we have our own kitchen, a little tv room area, and the Quiet Room.

I'm not sure it's actually capitalized like that, but as a long-time reader of horror, I like it with a hint of sinister. Though it's really not sinister; it used to be the tv room, where people would play Super Smash Bros. and other games from long ago.

But now it's the Quiet Room, where people can go to get away from the hubbub of the main room to get some work done.

I tried it out yesterday when we were continuing on our single-page-application project: a quiz purely written in JavaScript. It wasn't bad. (The room, I mean. My quiz page is also pretty nice, which brings up another issue we should talk about: front-end vs. back-end work.)

But the Quiet Room wasn't quite the productivity silver-bullet that it might sound like. Sure, I could get some reading done in there, but there were a couple of times where I wanted to talk to someone about what I was trying to do or see what they were trying to do.

I was reminded of (I'm always reminded of something) the title of a book about the culture of the Jewish shtetl that I read in college: Life Is With People. Except if I were writing a book about MakerSquare (and coding more generally), I'd title it Work is With People.

It's like what I learned about the culture of creative writing and really successful writers over the last few years: you may do some really great work by yourself, but what really makes it both possible and worthwhile is bringing your writing (fiction or code) to the group, either to get corrected or to show what you learned or just to share.

So maybe I'll leave the Quiet Room for the ghosts that surely inhabit it. I mean, a lot of Super Smash Bros. died in that room.

MakerSquare Day 29: First day on the senior side: so much to learn (7/1)

Today was the first day we spent on the senior side, which (as I said before) is both a philosophical shift (towards preparing for our final projects) and a physical shift (moving from our Brazos office to our Congress office).

Which might sound banal, but I'm a big believer in the effects of the built environment on people. So what effect will it have on us, I wonder, now that we've moved from the cod modernism of a big office building, with lots of glass and blank walls (and basement views), to the slightly warmer--but still windowless--office with the painted walls.

And on this day, I was struck with three thoughts.

1. Biking to the office rather than walking is a lot faster. Probably an obvious observation, but one which was driven home to me since I only now have a bike here in Austin. (My girlfriend recently bought a really sweet hybrid road/mountain bike, but since she's not using it, she let me borrow it.)
2. We know a fair bit of stuff already. Monday's task was to make a single-page application with a quiz, with a fair bit of wiggle room about what that quiz should be about or how it should be delivered. The goal was to think about MVC design pattern, where the Model, View, and Controller were all given their own design space. And there were lots of fiddly bits and some harder moments, but it all made sense and was doable. So it was striking to me how much trouble we would've had with this just a few days and weeks ago.
3. There's still quite a bit that we need to learn. Which was less striking as a thought because it's a thought I've had constantly for the last few weeks. After finally really getting the MVC pattern (which I'd heard of before, when I was dabbling in iOS programming), I went to a meetup to hear about functional programming in Ruby. See? There's always more to learn.

Maybe's that's why I like this stuff so much.

MakerSquare Day 20: Time is on my side (5/2)

At the beginning of our second week, I went to meetup for AustinRB to hear a talk on testing. Now, at the beginning of my fifth week, I went to a meetup for Austin on Rails to hear... well, the same talk. Not the same topic of conversation--the same talk, given by the same speaker. And, surprise surprise, I'm able to follow this talk a fair bit more after three weeks of learning.

(Also, after hearing this talk for the second time. But let's just focus on me learning.)

But besides that repeated talk, today was full of churn: new Javascript tricks, new implementation of our Checkers game, new paddles for ping pong, and a new great example of instructor trolling, when our current Javascript instructor launched today's lesson by saying

"I'm sure you all finished the console and the jQuery version of Checkers, so today we're going to bring in Backbone [a Javascript library that we haven't used yet], so you'll probably have to Google that..."

And he went on for a little while before we stopped him to say, no, we were still working on Checkers.

I guess you had to be there to understand how funny it was. But I'm honestly not sure what my favorite part of the day was: the super-cool trick I learned for connecting to my game logic to my mock web-page or our instructor trolling us just to see if we'd stop him.

No, I know: my favorite part was when our instructor started a list of things we learned yesterday and things we found challenging. I'm a sucker for lists. And also feeling like I learned something. But mostly lists.

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 17: Javascript: weird or just different? (4/4)

In college (Bard '01, varsity fencer), I took an advanced computer science class that involved a few weeks of working with assembly code.

Assembly is not the computer's native language--we'd call that machine code--but it's pretty close. So after weeks (and semesters) of dealing with higher-level languages, we were thrust into this desert of strange commands and odd syntax. Imagine moving from learning French and suddenly being told that you were going to learn a new language that was all basic phonemes. So now, if you wanted to talk to the computer, you might come up with a sentence in English--and then remember that there's a different syntax (French!)--and then remember that you've got to go even deeper.

That's not exactly what we're going through now, but it gets close: after weeks of dealing with Ruby, we suddenly have been switched to Javascript almost exclusively. And Javascript does not move like Ruby. Javascript has behaviors like closure and first-class functions and hoisting and curly brackets all over. My god, the curly brackets!

But slowly, we are learning.

(Or at the very least, I was able to create a Javascript module to turn a sentence into a mess on purpose.)

MakerSquare Day 16: The problem with synchronicity (4/3)

I know, that sounds like the title of a heart-warming indie drama--or maybe one of those really low budget science fiction films like Primer--but it really was the focus of this morning's class.

So here's the scenario: you try to get info from a server and get that info to display on your computer. But the internet being what it is, you get some of that information before others; so if you're asking for a poem, you might get the end before the beginning.

If you've read Stephen Hawking's A Brief History of Time, then you're familiar with this black hole/faster-than-light sort of scenario. But in programming, there's a solution that's a bit easier than reading Hawking: AJAX (asynchronous Javascript and XML).

The basic idea of that is that you can hold off on displaying that info until it's all delivered. That was our morning challenge.

If you've been reading along and thinking, "god, how do they fit so many topics in?" then you are not alone. Apparently, our cohort is pretty advanced.

Which was a nice shot of confidence and pride leading into our evening activity, a meet-and-greet with some potential mentors. That was a good time; it's always nice to meet people who are farther along the road than we are and to see how they've progressed; to see how they put these skills we're learning into practice in their day-to-day lives. (Or how they don't--or don't consciously.)

So, it'll be a few days before I pick a mentor/the mentors pick us, but I met some interesting people and it was very interesting.

Note: In grad school, a critic once pointed out that "interesting" was the go-to empty word for talking to people about their work, especially about their presentation. If you didn't like a lecture, you said "it was interesting," the way poets who have nothing to say about another's poetry will say, "I get the sense that you're really playing with language." But here, in programming world, "interesting" isn't exactly so empty. It is also about all I can commit to this late at night, after I have run into the N-Queens problem.

MakerSquare Day 15: "Computers are always right and people are always wrong..." (4/2)

"...until we get it right."

That's what one of my instructors said today when we had a brief interlude of philosophical introspection about coding and humanity.

Speaking of humanity, how great, how very altruistic and communal and just plain nice is it, that many programmers put their work up online and share it. In part, it's just interesting to see people's codes and to hear their thoughts about it. But in (probably larger) part, there's the tremendous use value of these tools that people built. For instance, today, we learned about how to use Underscore for templating in Javascript, which, as far as I know, is just something some people made and made available for the rest of us. (Also, is one of the many sentences that I swear makes sense even though it looks like a bad translation.)

Also, today's project was to make a bell ringing program, which meant that our normally quiet classroom was awash in cowbells. And SNL references. Which is not a bad recipe for a day.

P.S. I just remembered, a peer and I passed some pretty terrible ping pong/computer puns around last night, like:

Lili: why does everyone request permission from the database to play ping pong? it has all the tables.

Ben: Why wasn't the Ping pong table able to play online? The net was down.

So, I'm keeping that part of my brain sharp(ish).

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 13: Rising tide of teamwork lifts all boats, tables (3/5)

I mentioned the lesson in ping pong I got a couple days ago (both: I got it and I mentioned it a few days ago). But I never told you the revelatory bit of info from that lesson: don't slap the ball, don't even hit the ball--push it.

Which I only mention because it might be useful to you.

You're probably asking, "Why would you want to help me?" I'm glad you asked me that, mysterious stranger, because it gives me a chance to go on and on and on about how I believe humans are naturally both competitive and altruistic, both individualistic and community-minded.

Actually, let's just pretend I went on and on about that topic. If you went through an Ayn Randian phase as a teen (when it's most appropriate), then you might know her idea about the virtue of selfishness: you help everyone by helping yourself. I mostly believe in the reverse: you help yourself by helping other people.

So, for instance, I'll tell you how to play ping pong better and maybe you'll beat me. Or maybe you'll be such tough competition that I'll become a better player by playing against you.

Or, to take an example from this morning, maybe you'll help me extend the legs on this adjustable table--and now we have a standing table in the classroom. Which means that all of us have a chance to get off our keisters sometime during the day. (The keister is where programmers are most vulnerable to work-related injuries.)

Result: everyone's happier and physically more comfortable. Result: All our code is better. Result: Everything is awesome.

Also, in a few weeks we'll be split into teams to complete some bigger project, which is very exciting and interesting to me since we're a huge resource for each other.

As was proved both when we made a standing desk this morning and when we worked on Javascript this afternoon.