The art of the conference

March 12th, 2010 by Mims H Wright

I’ve just wrapped up my third GDC conference. I learned loads from it and feel incredibly rejuvenated creatively! But before I talk about what I learned there, I wanted to take a moment to share some helpful guiding principles for attending conferences. Here’s sort of a top ten list of tips for making the most of it.

By the way, even though I attend conferences for programmers, I believe these guidelines are good for any conference attendee.

  1. Talk to people

    When you break it down, the whole reason to go to conferences is to talk to people. The sessions are good too but I tend to find satisfaction from them only about 50% of the time. People are why I’m there. Don’t be surprised if people aren’t rushing up to talk to you, especially if you’re attending a conference with lots of programmers. Make an effort to approach people and start the dialogue. It doesn’t have to be fancy. You can literally walk up to a stranger and say “Hi. My name is Mims. How’s it going?” and you’re doing it.

  2. Know your story

    You’re going to get a lot of chances to tell people about yourself, your company, your projects, and your brand so make sure you know what you’re going to say when someone asks you. There’s a good chance that you’ll be speaking to your industry heroes which can feel very intimidating. Know your own story and be able to communicate it concisely and confidently even if in you’re head you’re thinking “I’m not worthy.” Keep it short and positive.

  3. Be interesting

    In other words, have good conversation skills. Of course, this is easier said than done for most people. But even YOU can be interesting with a couple of little tricks. Aside from telling your story, ask them about their story. It’s mysterious but true, asking people about themselves makes you seem more interesting! Furthermore, someone wiser than me once said that if you want to find success, ask your clients what’s keeping them up at night then tailor your service to help them solve the problem. Asking about what’s been inspiring them at the conference is good too because it’s usually something they’re excited to discuss and there’s a slim chance they’ll accidentally tell you their million dollar idea.

    Also, don’t talk forever, just say “Hey, great meeting you. I’ll check out your stuff.” and you’re done. You don’t have to wait for an awkward silence, you can end it on a high note.

  4. Bring lots of business cards

    Your card reminds the people you talk to of the conversation you had with them and tells them how to find out more about you. That’s really it. You can make really flashy, expensive cards but printing them on your inkjet works just as well in my opinion. What doesn’t work is when you don’t have one. They’ll go faster than you think so bring a bunch.

    Also, when you trade cards, you can write a note on the back of your card about the project you discussed and do the same for yourself when you receive a card from them.

  5. Not a vacation

    It can be tempting to get drunk every night, or blow off sessions, or even to see some sights while you’re away at a conference. I’m not saying you shouldn’t have fun and I’m definitely not saying you shouldn’t have drinks with your industry colleagues. Just remember that you (or your company) are paying a lot for you to be there and every minute is an opportunity to learn something or make a connection with a new client, employee or friend.

  6. Do some research about the speakers / topics / sponsors

    Obviously, it’s a good idea to review the schedule to see which sessions you may want to attend. It can also be good to do a quick background check on the companies that will be speaking. A quick visit to their website will do usually and you may discover that they did some work you really admire. Chances are, they did or they wouldn’t be speaking. If the schedule is too overwhelming, you can always bring the program home and research retroactively.

  7. If a talk is bad, it’s okay to leave

    Unless it would be an obvious or odious disturbance to the session, there’s no rule that says you have to sit through a boring or irrelevant session. Duck out respectfully and go into another session or just mingle in the hallway.

  8. Attend some sessions that aren’t targeted at you

    I’ve found that some of the most interesting talks at conferences are ones aimed at other jobs. It’s eye-opening to see what business-people, project managers, and programmers from other languages are talking about.

  9. Use Twitter

    Like it or not, at a conference, Twitter is the little bird that tells you what’s happening all around you – what talks are worth attending, what news is being announced, where the party is at, and who you need to talk to. Using and watching hashtags suddenly makes your tweets visible to people who otherwise wouldn’t see you and vice versa. I meet lots of strangers through twitter at conferences. For example, this year I had lunch with the cool dudes at Tribal Games who I met simply because they tweeted “going to lunch, who wants to go?” An icon that shows your face helps too – I recognize a lot of people from their icons! Finally, if you don’t have separate accounts, try not to twitter about your personal life at the conference.

  10. Don’t waste the momentum

    You’re going to meet people, see new things, and be inspired on multiple fronts. When you get home, do something with all of that good energy immediately. If you just go back to your routine of clients, meetings and daily bullshit, it’s going to go away.

Downtime

March 12th, 2010 by Mims H Wright

Had a little unexpected downtime this week when my host turned off our site when a wordpress plug-in caused the shared server to crash. After much jousting with tech support, we’re back online.

Copy text to clipboard in AS3

March 2nd, 2010 by Mims H Wright

Here’s how you do it!
http://mandarin.no/as3/as3-snippet-1-copy-text-to-clipboard/

iPhone Project Keeps Appearing in iPad Simulator?

March 1st, 2010 by Roger Braunstein

Hey guys, this is a quick thing I’ve run into while using the beta of the iPhone OS 3.2 SDK. If you create an iPhone project for iPhone OS 3.2, you might notice that every time you launch it, it appears in the iPad simulator instead of the iPhone simulator.

If this happens to you, it’s because 3.2 isn’t available on the iPhone yet, so regardless of your active configuration, the project has to run on iPad. For now, to fix this, you’ll want to roll your project back to iPhone OS 3.1.3 or earlier. Just go into your project info → Build Settings and set the Base SDK to iPhone Device 3.1.3 (or what have you). You’ll also want to make sure that SDK version is active in the Active SDK run settings.

I know this little fix is only going to be necessary for a short while, but if you were one of the 14 people wondering why this happens, there you go.

Learn Yourself to Debug Good With XCode and Instruments

February 25th, 2010 by Roger Braunstein

Hi! (Here Roger pretends it hasn’t been 100 years since his last posting and moves on swiftly.) So if you’ve been learning or practicing iPhone development, you might agree with me that there’s one topic that inspires a little FUD and that is covered a little sparsely by books — debugging. Between scary messages like EXC_BAD_ACCESS, uncaught exceptions deep in the guts of thorny disassembled framework code, crashes that don’t break into the debugger, and the direct interface to the gdb console, debugging in XCode can have a learning curve even if you know your way around a debugger. I’ve seen too many good men use NSLog() to debug, and it bugs me.

So here’s a few screencasts I found around town on debugging, that I wanted to share. Do yourself a favor and watch them.

First up, a series of two screencasts by Jeff LaMarche on debugging basics. I’ll reiterate, even if it starts out basic, you might learn something since it seems everyone uses the debugger differently. Part One, Part Two. Key takeaways:

  • Dude. Just drag the breakpoint out of the gutter to remove it. I’ve been right-clicking the damn thing my whole life. Sighhh….
  • XCode breakpoints are heckuv powerful. Use symbolic breakpoints, conditional breakpoints, and breakpoint actions wisely.
  • Single most important thing: Add a symbolic breakpoint on objc_exception_throw. Newer XCode builds have a menu item for this in Run→Stop on Objective-C Exceptions.

Next, a screencast on debugging EXC_BAD_ACCESS, which is raised when you access an object that has vanished into thin air, most likely because you over-released it. This screencast from Mark Johnson shows you how to debug these errors with Instruments and NSZombies. You’ll see how to generate a complete history of any object, from allocation and including every release or retain. You’ll also see how to find the objects of interest by enabling zombies (you know, after your object is completely released and freed it sticks around, undead). For those of you who see Instruments and aren’t quite sure what to do with it, just watching Mark use it is helpful. My takeaway was that it’s much easier and nicer to use Instruments than to enable zombies by hand.

Finally, here’s a nice tutorial by Owen Goss on using Instruments to find memory leaks. It’s also another good scenario which you can follow to help get your head around Instruments.

Bonus info: XCode 3.2 and later has the Clang Static Analyzer built in. This is a sweet tool that analyzes your code without running it (thus the static part). Just run Build→Build and Analyze and you’ll get a brutal report of how and where Clang thinks your code is totally sketchy. John Muchow shows you how here.

Anything that still baffles you about XCode/iPhone debugging? Care to add any other beginner debugging help? Hit the comments!