Monthly Archives: September 2008

10 Things I Learned from C4[2]

I went to C4[2] last month. For the uninitiated, C4[2] is the third (yes we count from zero) conference of its kind, a conference for independent-minded Mac and now iPhone developers, held annually in Chicago, Illinois. It is run by Jonathan “Wolf” Rentzsch, who is an independent Mac / WebObjects consultant.

It was a great gathering and I look forward to going to C4[3] if I have the opportunity. So I thought I’d share my top 10 things that I learned at the conference:

1. Getting like-minded developers together at one place generates a lot of energy, enthusiasm and knowledge sharing.

I think it’d be great if we could replicate what has been happening in the Ruby community and start to have Regional Objective-C conferences. This has started to happen with the iPhone Dev Camps already, but it’d be great to have combined Mac / iPhone Regional conferences, so devs that can’t afford to travel to Chicago and San Francisco can still get involved and interact with each other in Washington D.C., New York, Seattle, Denver, and wherever else we all are.

2. iPhone development has really come into its own, but its knowledge continues to be restrained by the NDA.

We started off with a presentation by Craig Hockenberry of how iPhone has changed the way humans interact with computers in much the same way the mouse did. We ended with a programming contest called Iron Coder (a play off of Iron Chef) which traditionally has been with Mac OS X APIs but this time was on iPhone with an iPhone API. I finally participated (after helping with past Iron Coders by providing licenses of WebnoteHappy as prizes), collaborating with Joe Pezzillo to produce CoreParanoia and also contributed a tiny bit to Jose Vazquez‘s 2nd place Tipster.

The rest of the presentations were not iPhone focused, but there were mentions of it throughout. And it seemed like having an iPhone was part of the requirements for attendance. I personally got a live demo from Tim Burks of his iPhone app Masyu which is a pretty fun puzzle game.

The problem however was that the NDA on iPhone development stifled a lot of the conversation. This generated a lot of complaints and even a t-shirt that rebelled against it.

3. Security is scary, but not as scary as not succeeding.

There was a wild presentation on security that said: don’t pretend to be a security expert. Stick to using the Keychain or bcrypt for passwords, use openssl or gpg. Don’t use installers or open up listeners on ports. Don’t write directly into the DOM. But all of that doesn’t matter if your business doesn’t succeed if you don’t have a nice looking application and it is unstable or slow. Also, filter user-supplied content and write a fuzzer for the content you accept. Make sure you have a security contact, use a crash reporter, and use auto-update securely. Finally, turn off Java in your web browser to prevent against some of the newer, crazier attacks like GIFAR.

4. Mac users really care about user experience (as if you already didn’t know that.)

To reiterate what we all sort of know but sometimes overlook since we are so deep in our code, Mike Lee presented “Pimp My App.” The basics: Use real artists, don’t skimp on your art budget, watch real users use your app, solve a specific problem, and cut as many features as you can.

He also offered some iPhone specific UI tips: start as fast you can, the start-up screen should not be used as a splash screen but more like the real app, restore the state of your app instead of just restarting, don’t block the UI, and think about the user’s first experience carefully.

5. Contractors / consultants are Indies too.

I’ve made applications and I’ve done consulting. Both qualify you to be an Indie, meaning independent from another company. There was a presentation by Andy Finnell on this and it mostly reiterated what I knew but it was nice to hear it from someone else. Basically: make sure you have good contracts, these will help you get paid properly and avoid constraints your future development. I’d add to this that if you can be choosy, it is good to figure out what kind of clients you want to work for and what kind of projects you want to work on and then only choose those to work on, even if it means taking some time off between projects.

6. Pricing sends a message

Rich Siegel of Bare Bones gave a presentation on lessons learned over his career. One of the key ones is that pricing: is a marketing message and shows how you feel about your product. It also needs to consider how much your overall costs are. It also positions you among competitors. That being said, your product / service definitely needs to be differentiated to justify a premium.

7. Warnings should be fixed

This is probably also a no-brainer but I’ve been at a few companies / projects where warnings are tolerated. Mentioned by both Rich and Mike, warnings can be the cause of run-time errors down the road. Its best to generate the most warnings possible and fix them as they come up. You may find it also advantageous to treat warnings as errors, but either way way, fix them.

8. Mac programmers really care about fonts

Minor but revealing tidbit: the fonts at C4 are carefully chosen. Compared to other conferences I have been to, I think this shows that Mac programmers care about design more than other programmers.

9. Twitter is the preferred method of communication in the Mac / iPhone developer community

When I wanted to see what was going on and what people were thinking, I checked Twitter. At other conferences, sometimes we would have IRC back-channels. Using twitter makes the back-channels more open. Also, we voted for Iron Coder via Twitter.

10. Do the simplest thing possible

Mentioned by Craig, Buzz Andersen, and Mike, doing the simplest thing possible, getting feedback and then iterating on that is a good technique when developing products. I knew this before, but many of us are perfectionists and so we have to keep reminding ourselves of this in order to combat the tendency to either add more features or to keep trying to perfect a certain specific part of our app.

How to fix a corrupted WordPress comments table

I logged into my WordPress admin panel and saw these ominous warnings:

'./your_wordpress_database/wp_comments' is marked as crashed and should be repaired.

Uh oh. That doesn’t seem good. I went to one of my blog posts and it said the same thing. OK no need to panic. I run my own WordPress on a virtual private server and also administer my own MySQL databases.

The solution is remarkably simple:

  1. Run the mysql client. mysql -u your_wordpress_user -p
  2. Switch to your WordPress database. use your_wordpress_database
  3. Issue the command repair table wp_comments