Nov. 29, 2012
7:08 pm


Launching a project: Don’t Stop Pop That

Don’t Stop Pop That, a year-end bracket-style music review project, launched today. I handled the web design and development while Jason Lipshutz and Steven Horowitz handled the content which comes from a slew of awesome music writers. It was a really fun project to be a part of, and exciting to launch.

I want to write a more in-depth post about the development of it, but I wanted to note that it’s my first responsively designed project. I’m still tweaking it a little bit, but I think it came out pretty well. It’s also my first time using SASS on something more than a proof-of-concept, and I’ve really loved using it.

Anyhow, check it out — I’m hoping to deploy a few more features before the project is over, then I’ll write up a longer post about building it.

Jul. 10, 2012
1:01 am


Lessons from Indie Game: The Movie

I downloaded Indie Game: The Movie last month, and the film’s been kicking around in my head ever since. Andy Baio recommended it, saying that it “perfectly captures the anguish from developing a long-term project.”

To create is to make a personal connection, regardless of the platform

Jonathan Blow, the developer of Braid, talked about how the major studios will create something glossy with mass appeal; to do that is to remove the rough edges and take away the personal connection between the developer and the player. As with any art form, it’s about the communication to another individual through whatever platform or medium. In this case, that platform is video games, leveraging just about every storytelling medium into an interactive bundle.

The best games I’ve played are games that have an emotional component. RPGs like Earthbound and Chrono Trigger do this through character, story and charm. Braid does this through a story woven through the core game mechanic. Fez does it through ambiance. No matter what you’re creating or making, ultimately that act is about relating to your audience in some way — through enjoyment, utility or feeling.

Great projects take a toll

During long-term projects, life goes on — everyone in the film detailed parts of their personal lives that were happening at the same time. The film shows both the everyday and details the dramatic. At times, life seemed to stand still for the creators; at others, life would go on, steamrolling through everything.

The game creators seems to be in limbo (or maybe in purgatory) during the development process.

Anything worth doing is worth doing all the way

The creators of Super Meat Boy worked nonstop for nearly two years. Braid took three years. Fez took five years to complete. In each case, the end result is an amazing work.

All three are the vision of one or two people working toward the end goal, taking a single idea and expanding upon it until it’s complete. It’s really fascinating to see that process up close, from the anguish of the endless work to the catharsis of release. From the interviews in the film, the creators had a sense of what the finished product should be, and didn’t stop until they achieved that goal.

I’ve now played the three games featured in the movie. (I knocked out Fez this past weekend, and it’s a really beautiful game from beginning to end.) Though they’re all platformers, they’re all so different and unique — it’s clear that each game expresses something different from the designer.

May. 31, 2012
11:45 pm


On mud, desperation and defeat

Reading this Deadspin piece about Rajon Rondo’s insanely awesome performance last night in the second game of the Eastern Conference Finals reminded me of a story from high school. The phrase “playing f–k-you basketball” brought this memory back.

I went to a really small private high school in South Carolina. I mean really small — my graduating class numbered 33 students. I played (mediocre) soccer for two of those years (on a mediocre but scrappy team). With a small school, that meant I got some playing time as a defender.

One away game junior year, we arrived at the field and it immediately started raining. No lightning, just a cold, wet rain on a field that was set below the ground around it. The coaches decided not to call the game, and both teams trudged out onto a field that started flooding. The bench players, including me, put on jackets and huddled under the bleachers. The rain still splashed down through the seats. Somehow I hit my head, hard, on one of the metal supports. My head started throbbing — I was cold, wet and hurting at a game I was unlikely to play in anyway.

Come the second half, we’re down by a goal or two and our players are demoralized and exhausted. There’s standing water across large swaths of the field. Running through it is impossible, and the ball either stops or skips across the puddle and spins in another direction. The game turns into a sloppy, sluggish rendition of six-year-olds playing a soccer game, with a miserable pack of teenagers chasing after the ball in a disorganized pack.

Since our starters are burnt out, our bench players get called on to the field during the second half, including me. I’m put in as a forward, oddly, and I’m angry and miserable.

I start playing “f–k-you soccer.”

If the ball’s at midfield, I’m after it, kicking it downfield or out to the side. None of my teammates are around me most of the time, so occasionally it’s me punting the ball forward, chasing it, and doing it again if a defender hasn’t managed to get to it. I’m trudging through puddles, often bashing the ball to only have it go a couple of feet forward, then repeating. There’s no ball control, there’s no strategy, there’s no thought. Just me in the middle of the field toiling away, working as hard as I can to get something going. Eventually our team put some semblance of a game back together, but the conditions were too much to even get anything done.

I wish this story had a happy ending, but it doesn’t. Nothing came of my second-half performance except mud and water splashed all over my uniform and a newfound respect from my coaches for what I can do on the field when desperate and angry. Right after the game (in a corner of some rural McDonald’s I’m sure we completely dirtied up), the assistant coach called me a “mudder,” as in a racehorse that runs better on a muddy track.

There are a few other moments that come to mind in my time playing soccer in high school. None of them particularly glorious, but all significant in their own way. There’s something about sports that creates that moment.

Seeing Rondo summon a performance like his last night, getting little help and ultimately resulting in defeat, brought that feeling back to me.

Mar. 22, 2012
5:33 pm


The best and worst HTML references

I’ve been recommending people to W3Schools for a while. I’m not linking to it here, but if you search for any HTML element, it’s the first thing that comes up. Turns out, using that site as a reference is a bad idea.

I saw Jeffrey Zeldman tweet a post earlier about how it’s fairly difficult to block W3Schools from your search results. Or at least, more difficult than it should be. That led me to look up why you’d want to block them in the first place, which led me to They outline, in detail, errors and misleading statements on the W3Schools site and also offer up a number of alternatives for HTML, CSS and JavaScript reference guides.

The best of which, after looking for a while, seems to be the Mozilla Developer Doc Center. After browsing for a bit, I was really impressed with their clarity and detail, and the site’s easy on the eyes.

While the w3fools site isn’t without criticism itself, its larger point about how it’s problematic to rely on a single, non-transparent resource for accurate information rings true. It’s time to move on.

So today starts a new habit of adding “mdc” to my searches when I need a quick answer to something HTML- or CSS-related.

Mar. 20, 2012
12:06 am


How to learn to code: Don’t learn how to code

These notes are compiled from a session I attended at SXSW called “Learn to Code and Make the Software You Want.” A lot of what the session organizers (Nate Westheimer and Vin Vacanti) said rang true, and they managed to outline the path to coding better than anyone else I’ve heard speak on the subject.

Nate and Vin said there was only one prerequisite for learning to code: you need to build something. You have to have a problem in front of you that will drive you enough to want to solve it. That problem can be anything (building a personal website, manipulating some data in a unique way, fixing a Twitter widget), as long as the answer is writing or editing code to solve it.

This year, I tried Codecademy, which is designed to teach you JavaScript through some basic tutorial lessons. It takes the approach of a foreign language class, where the idea is to get you speaking the language and saying phrases as quickly as possible, which is kind of empowering. The thing was, I got bored with it — it’s really hard to just academically learn a programming language. You need some reason to be learning it, which is why you need a problem to solve. With programming, you don’t learn by learning; you learn by doing.

Perfection is the enemy

So once you have a the problem in front of you, start stealing and editing code to get it to do what you want. Don’t worry if it’s clean — no one starts off writing code the “right” way.

This can be the hardest part. If you’re a perfectionist, you want to do it right from the very beginning. If you’re afraid of doing something wrong, you won’t have the courage to fail and learn from your mistakes. The thing is, you have to experiment until you have a bit of programming that does something. Then you can see what it’s doing and fix it.

(I’ve had moments when I’ve worked on something for a while and finally got an error message out of it — and I was relieved. “It’s finally doing something!” Not working, broken, and working are parts of a richer spectrum than it might seem.)

Getting started

How you get started is up to you. Once you learn the basics of one language, you have enough of a foothold to take that knowledge to another language.

My personal trajectory has been learning snippets of JavaScript occasionally to pair with my HTML and CSS skills, followed by learning PHP through WordPress and Drupal. I now use Python to do some scripting, but nothing web-based like Django (yet). I haven’t touched Ruby at all yet since I haven’t had need.

One of the key moments for me was getting MAMP running for the first time and playing around with a WordPress install on my machine. MAMP mimics a web host and all its parts. It meant that I had immediate access to all the files I was working on, and it also meant that if I ever really broke something, I could start from scratch without worrying too much about it. So I could even dig around in MySQL without the “oh no I broke it” feeling. MAMP is PHP-based, so it’s best for playing around with WordPress and Drupal.

Resources for when you’re stuck

Google. I sent out a tweet earlier today alluding to the fact that coding means having many tabs open. Every problem you’re having, someone else has likely had. It doesn’t help that sometimes this stuff makes no sense. Google will lead you to sites where people have discussed your exact problem. Just hope that they leave you with the solution too. Googling your problem has another benefit: you’ll learn stuff along the way. You’ll have to comb through similarly-worded questions and learn things tangential to solving your problem. All of this helps in the long run. Sometimes the answer you’re looking for is a footnote to another semi-related problem, but you’ll gain the knowledge in the entire thread as you’re sifting through it.

Stack Overflow is an awesome question and answer community. Odds are, Google will send you here for your coding conundrum. I’ve never asked a question, but I’ve heard that people will get back to you very quickly (as long as you politely ask your question in the right way and provide enough information for it to be answered).

When all else fails, it’s good to have a patient friend. Someone who will put up with your panicked instant messages and emails. It’s best to try and solve it on your own, but it’s always good to have someone to fall back on to point out something stupid you forgot. (Like a semicolon.) I usually start running at people screaming right after I’ve started tearing my hair out. Help me Obi-Wan Kenobi, you’re my only hope.

Language documentation

The official PHP manual is good for syntax and parameters for certain functions (I think I’ve looked at the date parameters more times than I’d like). For any WordPress-related issues, I’ll check the WordPress Codex before I go anywhere else. If there’s not a page that addresses my particular issue, there may be a forum thread that gets at it.

The Python documentation is more formal than the PHP documentation in my opinion. It’s still handy. I’ll often use the Python manual to more accurately Google for my problem.

This is in no way thorough, but it can’t be. Coding is something where you really have to get thrown into the deep end and find your way out again. Nate and Vin called it “the Sweat Lodge,” where you isolate yourself and just focus on making something work (or even breaking something so you know how it works). It’s not as hard as it seems.

Once you get started and get that initial traction, you can build amazing things. And it’s an awesome feeling to build something that works.