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 28: Skills on the line (6/5)

Children play "Rock Paper Scissors" in jest, but web developers build "Rock Paper Scissors" apps in earnest. (To paraphrase Bion.)

It's been real interesting to go from some of our smaller, more focused projects--projects where we learned and employed one new technology or section of technology--to something like a full project. Because, even though "Rock Paper Scissors" is a pretty simple game, with a high requirement of two hands, as an app, there's a lot of little pieces.

You'll need HTML and CSS to display the page, with some sort of web app technology, like Sinatra, to host the server and pass info from your front-end to your back-end. Throw in a little Javascript and jQuery to make the site interactive, and you've already gone beyond the technology I had when I made my first website at Geocities. Then, on the back-end, you have Ruby handling the logic and ActiveRecord handling the database to keep track of how players are doing.

Also, at some point you have to grab some silly pictures of rocks, paper, and scissors; or come up with some weird angle to make your Rock-Paper-Scissors game stand-out. (My favorite theme so far is pirates.)

And you have to do all of that before the big, cohort-wide ping pong tournament on Friday. Because no matter how much your skills have improved in terms of HTML, CSS, Javascript, and Ruby, the real judge of a developing developer is ping pong.

Until next week, when we move into our new office. Then the only skills that matter will be coding skills.

And also Super Smash Bros. on the N64.

MakerSquare Day 27: Oh the places they'll go! (6/4)

If I haven't already mentioned this, MakerSquare currently has two classes going in Austin, known as C8 and C9, with C9 beginning halfway through C8's 12-week run. And this is the last time--at least for now--that Austin will be hosting two simultaneous cohorts.

Which is nice in some ways: I won't have to share my room at the DevHouse with anyone from C10; now we get all of the attention from all the teachers.

But it's bad in some ways. For instance, today we went over at lunchtime to see C8's final projects. And they were pretty gosh darn good. I mean, I was proud of our hackathon project, that we made in 36 hours; but these projects that the seniors did--some in weeks, some in days-- were really kind of great.

They also gave me a pretty good shot-in-the-arm about all the project ideas I have. Yes, I have lots of ideas for apps, but one lesson I learned in creative writing: ideas are cheap. Now, after seeing all the things that people who are only 6 weeks more advanced can do, I feel like, sure, ideas are cheap and implementation is expensive, but I can pay the bills.

Or rather: the C8 demo was really both inspiring and impressive, in that I can't quite pay those bills yet, but I feel myself getting closer.

And I'm very excited for my friends and peers in C8, who inspired the title of this post.

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 25: Shiny happy programmers (6/2)

I'm not on the job market right now, but I'd be lying if I said I didn't occasionally think about what the job market is like for developers. Or what it will be like in six weeks, when I am on the market.

And the market is even more on my mind on those days when we talk to career services; or when established developers--MakerSquare grads, mentors, or just allies--come to talk to us about what it's like for them out there in the real world.

The real world is rather disappointing when compared to the computer world, in that the real world has far fewer arrays. I hope it's not too forward of me to say this, but: I love arrays.

But the real world is not so disappointing in terms of careers and places of employment. For instance, today a group of front-end developers at RetailMeNot came to speak to MakerSquare at lunch and they were--what's the word? Happy. They seemed like they liked their jobs and their co-workers, which is a real shock for me to see. (In grad school, where a large chunk of my adult life post-college was spent, people by-and-large are not happy. Or not at my grad school, at least.) 

On top of that shocking expose of what it was like to work in this field (they have foozball tables!), I also had a nice one-on-one chat with the head of MakerSquare career services, discussing possible places I would like to end up and possible salaries. It was a little on the abstract side--nothing as concrete as "I will work for foozball table time"--but it was a good start and something I hope will pay off when I do go on the market.

Which, ahem, will be in six weeks now. In case any possible employers are reading. And have a foozball table that isn't being used enough.

Note: Although we did a bunch of coding today, from brain-waking morning coding challenges to logging users in to a website, I've tagged this as "Teambuilding" to memorialize the time we spent at the end of the day working through a bunch of visual puns and jokes. As a team.