Five things to like about Perl

It’s been a while since I blogged, huh? Look, I never said I was reliable.

If you’re like me, you thought programming was for nerds until the year 2000, when you were surrounded by a bunch of nerds you liked, and then you gave in and admitted you were not-so-secretly a nerd all along and discovered you actually like programming. If that’s the case, you were probably raised to believe that Perl is evil. I certainly was. I heard all of the lousy things about how it’s totally unreadable, and how the variable scoping is weird and kind of leaky if you’re not careful, and how the subroutines are completely not self-documenting, and how it’s totally unreadable. Then I took a job that required me to learn Perl, and while I still don’t love it, I’m making an attempt to embrace new things and not become one of those people who is totally set in her ways and completely resistant to change of any kind. That’s a good thing, right? So, to that end, I give to you a list of things to appreciate about Perl. Read it before you go hatin’:

1. Regular expressions support. Okay, this is the easy one. If you need to parse a string (or, say, a log file), Perl will make it real easy for you. If you don’t know what regular expressions are, dude, you are missing out. Start with the Wikipedia page (as always) and then check out this awesome cheat sheet. I could do an entire post on regular expressions (and I probably should!), so I won’t go into great detail, but basically, regular expressions provide a language for matching, grouping, and manipulating strings (or substrings) that allows you to operate on said strings in a concise and readable way. That’s right, I just said regular expressions and, by association, Perl were readable. Bring it on (in the comments), haters.
2. String formatting. It’s a simple pleasure, but, boy howdy do I love the fact that I can reference a variable in a string in Perl. No concatenation, just embedded right in there. Love it.
3. Compile-time failure. Obviously, this is a feature of all compiled languages, but Perl isn’t a compiled language! As a result, you get (some of) the benefits of a compiled language along with the development and iteration speed of an interpreted language. Pretty nifty, huh?
4. Brevity. One of the reasons Perl is often unreadable is because you can do a lot in a one-liner. This can be incredibly frustrating, but it can also be incredibly awesome, especially if you do something crazy like add a comment.
5. 37 ways to do anything. Another reason why people complain about the readability of Perl is the lack of consistency. This is because Perl provides eleventy billion ways to do anything. It’s a blessing and a curse, in that consistency is a good thing, and a hammer isn’t the right tool for every situation. So, it’s nice when you can come up with a screwdriver, even if that screwdriver doesn’t fit into your previously established pattern of hammers.

In all fairness, I still like Python better. I find that it has better support for object-oriented programming, a better (read:existing) type system, and is generally more human-parsable. In fact, I started this post with an attempt to come up with 10 things and gave up after 5. That said, as I learn Perl, perhaps I’ll grow to love it more. Perhaps.

Unemployment Survival Guide

I got a new job! As of this past Monday, I’m working as a build engineer at Bioware Austin. I’m super excited, and it’s a super exciting time to be joining the company, seeing as we’re just about to launch this little Star Wars MMO you may have heard of. I have a feeling that it’ll give me a chance to put some of that last survival guide to good use. In the meantime, it’s a good time to post-mort this last bout of unemployment, which, on the whole, went pretty well.

It may go without saying, but successful unemployed life requires a different kind of discipline than having a job. To some degree, I think it’s like being self-employed, except that instead of creating and selling your product and/or service, the goal is usually to (create and) sell yourself. While this affords a huge amount of freedom, I think it’s a hard thing for most Americans. For one thing, most of us have spent some, if not all, of our lives working for someone else, meaning we’re not used to setting our own schedules, making final calls, or even determining priorities. Certainly, we all do these things to some degree in other parts of our lives, like figuring out dinner for the evening or determining how many days to take off for the holidays, but when your whole day is wide open, every day, and you haven’t even necessarily set any goals or deadlines yet, it can be pretty daunting. But we’re game developers, so we’re all used to daunting tasks. We’ll just do what we do with all daunting tasks — break it down!

• Have goals other than “get a job.” If you’re like me, your first thought when you found yourself unemployed was “Oh, crap, I need a job!” This is a fine and laudable goal, but it’s easy, if you’re career-oriented, to get a kind of tunnel vision, where this is your only goal.  This can be dangerous, and not only for the obvious reasons. You see, despite what Herman Cain has to say about the matter, getting the job you want is something that’s almost entirely out of your control. That’s not to say there’s nothing you can do to work towards the goal of getting your dream job, but when it comes right down to it, there’s no way you can make that employer hire you. As of August 2011, about 9.1% of the population is unemployed like you are, and I’m guessing that about the same number are employed but looking for a new job. Add to that the fact that the video game industry is pretty attractive, and the odds are pretty good that there’s at least one more person out there who is better qualified for that job you want. It sounds pretty bleak when put that way, and it kind of is, particularly if you have no other purpose. So, instead of obsessing over something that’s not in your control, reassess and start making goals that you do have control over, like “exercise 3 times this week” or “make something I’ve never made before for dinner tonight” or “make a single level of my rogue-like work before I go back to playing Batman: Arkham City.” Silly as it might sound, achieving these small goals will give you more confidence (which is key in interviews), and when you really think about it, is your major goal in life really to work for someone?
• Stick to a schedule (roughly). On the first day of unemployment, I set some goals for myself and told myself that I had plenty of time to get them done. Then, somehow, ten hours had gone by, and I’d done nothing but play Arkham City. I used to think that schedules were mostly for the benefit of coordinating between people, so I’m a little embarrassed to admit that it took nearly a week for me to figure out that I would be much more productive if I imposed a very loose schedule on my day. It wasn’t a crazy rigorous schedule. That wouldn’t have made sense, given that every day was different, and it might have restricted me unnecessarily.  The important thing is that this is a tool to help you get things done — you want your schedule to work for you, rather than the other way around. Mine went a little something like this:
• 8-9AM: Get up.
• 9AM-10AM: Code.
• 10AM-12PM: Play video games, watch TV.
• 12PM-1:30PM: Gym.
• 2PM-5PM: Look for jobs, errands, explore Austin, possibly code a bit more.
• 5PM-12AM: Make something awesome for dinner, free time.
• Get the word out quickly. I actually stole this from some other list of tips for the unemployed, but I think it bears repeating. When I got laid off, I was embarrassed. I felt like it had to be because I wasn’t good enough, and I didn’t want anybody else to know. The fact is, people get laid off for all sorts of reasons, and potential employers know this. So, while you might be cringing on the inside, suck it up, and tell as many people as you can that you’re looking for a new job. Potential employers aren’t interested in candidates who play hard-to-get. And, while it’s a royal pain to update your resume, if you just sit down and do it, you’ll be done before you know it.
• Do that stuff you never have time for when you’re employed. This one is pretty straight-forward. Clean your apartment. Go to the bank. Get your glasses fixed. If you have medical insurance, go to the doctor and the dentist. Buy some new clothes, if you have some savings. Check out a new part of town you’ve been meaning to see. Do your taxes, if it’s that time of year. Cook something that takes all day. Work on your personal projects. Read some books. Play an epic, all-day game of Civ. Now is the time, because even though you tell yourself that you’ll do it on weekends and evenings when you’re employed, it’s a hell of a lot easier to take care of it now.
• Chill. You have just been relieved of a lot of responsibility! Sure, you’ve got bills to pay and things to worry about, but if you’re behind four people in line at Starbucks, all of whom take 10 minutes to order, who cares? You don’t have to be anywhere. You know that saying, “time is money”? It’s not really, for you, anymore. Sure, you’ve got things to do, but free time is no longer a restricted commodity, and you won’t be letting anyone down if you get to the grocery store half an hour later than you expected to.

I could probably overanalyze the unemployed productivity problem for ages, but I’ll stop for now. The last thing I’ll say is that this is a great time to pick up a personal project, if you don’t already have one. I had two in the works, and I ended up making some pretty good progress on one of them, putting the other on the back burner, and picking up a new one. In the process, I learned a few things and stretched my brain a bit. Meanwhile, I relaxed, made some serious progress on my video game and TV queues, and got a lot more healthy. Honestly, I may have to find a way to take a month off every year!

The Definition of Irony

Normally, I don’t use social networks to complain about work. I don’t think it’s too much of an exaggeration to say that I pretty much never do it. I figure that it’s just not a great career move, given that everything you put on the internet can come back to haunt you. Yesterday, though, Batman: Arkham City came out. And I have been waiting for that game for months. And I was dealing with a really annoying linker error. So I gave in to my baser urges and sent this tweet:

A few hours later, I learned that my contract was being terminated.

It had nothing to do with the tweet. Or my performance, for that matter. They simply didn’t have work for me. So, I’m looking for work, as a programmer, hopefully with an Austin-area video game company. I have a bit more resume polishing to do, including adding this most recent job, but the most recent version is (and forever will be) here. So, if you’ve got any leads, please do send ‘em my way, and if you don’t, just send good vibes. The good news, for all 2 of my loyal readers, is that I now have a lot more time to work on my personal projects, so I’ll probably be blogging a lot more about all of the stupid mistakes I make.

Today, though, I’m playing the hell out of Batman: Arkham City.

r.i.p. dmr

It’s been a rough month for technologists. Yesterday, Dennis Ritchie died at the age of 70.

If you’re a programmer, and you don’t know who Ritchie is, you should, because his work has had a serious impact on your life. He’s the co-creator of UNIX, from which Linux, Mac OS X, and CellOS (the PS3 OS) are all descended, just to name a few. He literally wrote the book on C because he created the language.  (The C Programming Language, cowritten with Brian Kernighan. Yeah, it’s that skinny little book gathering dust on your shelf because you’ve been too busy with all of those C++ books.) Even if you’re not a C programmer, if you use C++, Objective C, C#, Java, Python, Ruby, or even some shell scripting languages, you’re using a C descendant, or at least something heavily influenced by C. He played a very major part in shaping the computing world into what it is today.

Thank you for everything, Dennis Ritchie.

Ada Lovelace: This One’s for the Ladies

Today is Ada Lovelace Day. For those of you not familiar with the Countess of Lovelace, she was the only child of Lord Byron and is widely credited with being the world’s first computer programmer.

Ada Lovelace, Queen of the Nerds

There’s a large gender disparity in the video game industry. Likewise, there’s a large gender disparity in computer programming. While I’m fairly certain nobody would argue the truth of those statements, there’s quite a bit of controversy surrounding what to do about this and whether it is even a bad thing. I’m not going to attempt to address any of those issues today. Instead, I’m going to point out a few ladies in engineering who have influenced my life (positively!), and who I consider role models in my current career path.

R.I.P. Steve Jobs

“Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma – which is living with the results of other people’s thinking. Don’t let the noise of other’s opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.”

Rest in peace, Steve Jobs. You are immortal.

Crunch Survival Guide

Regardless of whether you think crunch is avoidable or not, if you work in the game industry, you will inevitably have to crunch at some point. While the amount of extra hours and the duration of the crunch will vary, you will almost certainly find yourself, for some period of time working more hours than is strictly comfortable. Having just finished one of these periods of crunch (see how I failed to blog for, like, ever?), I figured this might be a good time to jot down some things that I did that helped and some warnings for the next time:

1. Eat sensibly, sleep, and drink water. It sounds like a no-brainer, but taking care of yourself will make an enormous difference in your ability to survive crunch. Water is easy. You’ll need to get up from your desk every couple of hours anyway, so keep a large-ish cup at work and refill it every couple of hours. If you’re the sort of person who forgets to eat, set an alarm on your phone. If you’re like me, you tell yourself that you deserve those french fries, or you deserve to sleep in an extra hour. Most of those things that you deserve aren’t going to actually make you feel better. You deserve to feel good.
2. Do something in your off-hours. Some days, you won’t have time to do anything but work and sleep. These days suck, and there’s not much you can do about it. Hopefully, though, your crunch does not consist of 16 hours of work/commute for 7 days a week. After 6 (or 12) 14-hour days, the temptation to plop down on the couch for a day-long marathon of Desperate Housewives is incredibly tempting, but if you do this, you will probably find yourself feeling pretty bummed about wasting your one day off. Work out. Go for a walk. Clean your refrigerator. If you can afford it, get a massage. Personally, I’ve been enjoying cooking, and I have to give a big shout-out to Domestocrat for providing me with tons of awesome new recipes to try. Plus, this helps with the whole “eating sensibly” thing.
3. Communicate with friends and family. This is where social networks come in really handy. You’re not going to have a lot of time to go out, but that doesn’t mean you can’t stay attuned to what’s going on in the lives of the people you love. Keeping in touch will keep you sane, and if you have friends who aren’t crunching, they’re likely to be a lot more sympathetic when you say you have to work this weekend. It can be hard to find things to talk about when all you’re doing is working. When in doubt, remember that most people enjoy talking about themselves, and you’ll probably want to hear what they’ve been up to too.
4. Be kind to your coworkers. The longer crunch goes on, the more tired people get. People make mistakes. People get snippy. People occasionally have to leave at a reasonable hour because their kids are sick, and you’ll be annoyed because you don’t have kids, and so you don’t get an excuse to leave. Just remember that when it comes down to it, you’re all in the same boat, and you’ve all got each other’s backs.
5. Focus on your goal. Remember, the goal is not the end of crunch or the ship date. The goal is to create an awesome game. If you remember that there’s an actual reason why you’re putting in these extra hours, you’ll feel a lot better about doing it, and you’ll be a lot more productive as well.

“Great idea. Please create a tracker.”

Sometimes my job is pretty calm. Nobody really needs anything. My tools seem to be functioning pretty smoothly. I have time to work on my own ideas and a normal and sane pace. Other times, it’s like juggling rabid beavers in the middle of a kindergarten playroom. Fur is flying, jaws are snapping, timing is essential, and I’m going to have to deal with a lot of angry parents if I let something drop. Now is one of those times.

Great idea. Please create a tracker.

I used to know this phrase by heart. I can’t believe I forgot it. It’s so incredibly necessary.

Inlining and #includes

I’m on build coverage tonight, meaning I’m working until 2AM. Not the most glamorous aspect of the game dev industry, but when you’re trying to hit beta, making sure we have solid builds for QA every day is pretty important. So at least I’m important. Right?

So, the incremental build failed on me in an interesting way this evening. A header failed to compile because there was a class method defined (inlined) in it that used a function that wasn’t declared in any of the included headers. This, in and of itself, isn’t a particularly interesting failure. In fact, it’s a fairly typical, easy-to-catch-on-your-own-machine failure, one that you can usually shoot your fellow devs with nerf darts for causing. What made this particular instance interesting is that the check-in that broke the build wasn’t the one that broke the code.

Of course, it’s fairly common for a perfectly valid piece of code to expose a flaw in another piece of code, but I just couldn’t seem to figure out how the original code, which clearly called a function that wasn’t declared in any of its included headers, had ever compiled. My first thought was that maybe before this check-in, the header had included another header that had included the necessary header, but when I checked, none of the included headers had changed. It turns out the issue was that the new code changed the method from private to public.

Previously, the method had been private, meaning that it was guaranteed not to be used by any other translation units, so, even though the header was included by other files, that particular method was expanded. In the source file for the defined class, the header include was preceded by an include for another header which did declare the needed function. Once the method was made public, that method became expandable in other translation units, ones that may not have had the missing header in their includes.

This fix for this particular issue is incredibly simple — add the necessary header to the includes. But what’s the moral here?

1. Always include all of the necessary headers for your code, and don’t rely on compilation to tell you whether you’ve done so. If you’re worried about build times or violating the one definition rule, use include guards. Actually, always use include guards. It’s a tiny amount of effort and extremely low-risk for a potentially epic payoff. (If you name your guards after the namespace and class that they guard, your chance of naming collisions is slim.)
2. Please, for the love of all that is good, compile your code before you check it in.

ThreadHead

Some people don’t like threads, and with good reason. They complicate a program and introduce a whole new class of potential bugs that you don’t see in unthreaded software. However, while I’m the first to espouse the KISS principle, I think there are certain situations (like trying to render 60 fps on an Xbox 360), where the benefits outweigh the dangers.

That said, I always feel really embarrassed when I introduce a deadlock into the codebase, especially an easily avoidable one, like I did a few days ago. Once they’re in, deadlocks are devious little bastards and managing to reproduce them with a debugger attached is a royal pain. Assuming you’re lucky enough to discover that they exist before your game ships. That’s why you have to catch them before they make it into your code repository. So how do we avoid this terrible scourge? With this one simple rule:

Always grab mutexes in the same order.

It really is that simple. If you know exactly what mutexes are being acquired, in what order, by every part of your code, you’ll be absolutely fine! Of course, this is akin to someone telling me to eat right and exercise. Sure, it’s simple and effective, but with that kind of effort involved, I’m more likely to go for the tube of cookie dough and some miracle drug featured in 3AM infomercials. But, just as every dieter has their own tips and tricks for avoiding brownies and hitting the treadmill, I have a small but growing collection of guidelines for writing thread-safe code.

1. Minimize the scope of your mutex grab. This one is easy. The greater the number of lines of code executed while you’ve acquired a mutex, the greater the chance that one of them acquires a different mutex. The more mutexes acquired, the greater the chance of deadlock. So restrict the scope of your mutex to what it is supposed to protect. No more, no less. If you haven’t yet subscribed to the Resource Acquisition Is Initialization philosophy, now would be a good time to start, and apply it to your mutexes.
2. Know what your mutex meant to protect. This goes hand-in-hand with the previous guideline. If you don’t know what you’re trying to keep consistent, you can’t know what the scope of your mutex should be.
3. (Try to) know the order of mutex acquisition in the codepath you’re modifying. This one is a bit trickier. The advice I’ve always heard is to designate a mutex order from the start and always abide by it, but in practice, I’ve yet to see that happen, and honestly, I can’t think of a good way to document and communicate that to new coders, especially with a changing codebase. Instead, you usually have to determine the order by reading the code. Going down the chain is pretty straightforward (if sometimes a bit tedious), but determining  all of the clients of your code and what order they grab mutexes can be nearly impossible, especially if you’re working in a large codebase or your mutex is embedded in low-level code (like, say, new or alloc). Theoretically, it seems like it would be pretty easy to make a tool that crawls your code (like test coverage tools do) and writes out an ordering, though I’ve never done it.

That’s all I’ve got. It’s not perfect – even if you do know the order of mutex acquisition in your codepath, it still might be different in another codepath. But I think these guidelines make some of these nasty bugs a bit more avoidable. The bug I fixed today, for example, could probably have been avoided if I had not assumed that the code it called didn’t acquire any mutexes. If I’d noticed that, I might have then gone on to see where else that mutex gets acquired, and noticed that I was introducing an out-of-order mutex grab. Or maybe not. But at the very least, I’d have been aware of the order for the next time I modified the code, something that has saved me some pain multiple times already.