programming

One of my goals for SIGPWNED has always been that it would be a place where I could share not only my ideas and my writing, but also my work. And so today I announce a new section of my site, the Projects section, as well as my first open source project ever: Jsonification.

The projects page will be where I keep a laundry list of all of my most current projects and where they stand at the moment. Right now, I’ve got WhatsTwending there, as well as the new project I’m announcing in this post.

Jsonification has its own project page, so I’ll let you head over there to read all about it. I’ll just mention the high points here, as paraphrased from the project page:

Now that I’m fully recovered from Chirp and have had the chance to relax a bit, it’s time to start talking about what’s most important now that Chirp is over:

What the hell are annotations for?

If you weren’t at Chirp (or you were there but weren’t paying attention), the Twitter Annotations API will let you attach arbitrary metadata to tweets. So just as Twitter clients can attach GPS coordinates to tweets, so too will you be able to attach moods, who you were with, or funny pictures of cats to your tweets.

The daytime part of #chirp was a lot of fun, but the overnight hackathon is another thing altogether. Not only do we get to play with newly-released APIs — user streams, I’m looking at you — but we also get introductions to some pretty bad-ass new libraries like the @ Anywhere JavaScript API from the developers who wrote them.

Oh. And then there’s the rate limit bump to 20,000 requests per hour. That’s kinda neat too.

As a quick first project for the evening, I decided to follow up on a suggestion from @_stritti_ to do some quick analysis on which Twitter clients were popular at the daytime part of the conference.

I’ll be at Chirp, the official Twitter conference, on April 14-15. Anyone going and want to meet up for a frosty beverage? Or anyone not going who has questions they’d like me to ask the Twitter team? Leave a comment here, or drop me a line at @sigpwned! And I’ll be tweeting the whole time, so for live updates during the conference, follow me at @sigpwned, too.

Regardless, though, be sure to follow @twitter and @chirp at least for the week. There are sure to be some interesting announcements coming down the pipe.

Expect to see new stories here during the conference, and I’ll be sure to post a recap as soon as I get back, so subscribe to my RSS feed or check back for a wrap-up and postmortem.

The tweetmeme API is pretty neat: given a long link, it will tell you how many times that link has been tweeted. And it even works, which is nice.

Well, it works most of the time.

On my recent post on the origin of perfect software, I looked over at my custom Tweetmeme badge and saw that this story which had just been published had 42147 tweets. Now, my work is good, but it’s not that good.

In another post, I claimed that software can’t be written with no bugs at all. Well, it turns out that’s not quite true. What I should have said is that writing bug-free software is not possible within the constraints of most software businesses or open-source projects.

But that just doesn’t have the same pizazz, does it?

The trouble is that software businesses exist to make money, and open source projects exist to give developers interesting things to do and exposure. (Naturally, there are some exceptions in both camps, but if you imagine that’s always true, you won’t be too far off.) And if these are the goals you’re chasing — customers and money, or interesting problems and exposure — you don’t end up with perfect software. You go broke or get bored before you get there.

Ask 100 CEOs of software companies if they want to ship software with bugs. What will they say? 50 won’t answer at all, saying something about how bugs are a huge problem in the industry that needs to be addressed; 40 will say “Of course not!” and promptly call their shark tank in preparation for a lawsuit; 9 will hang their heads and say “we can’t help it”; and that last 1 will look you straight in the eye and say “Absolutely.”

I have no idea what that last guy’s doing heading up a software company, because he studied economics.

As I was poking around the web looking for some Objective-C documentation while writing my iPhone keyboard post, I ran across this site, which has some really helpful Xcode tips. Thought I’d share, and also make sure I don’t lose track of it!

As I started building the latest Consumetrics iPhone app over the weekend, I had to choose which keyboard style to use for some input fields like name, email, and so on. These fields live in a “settings table” (really just a grouped table with input fields on it), so picking keyboards in Interface Builder is out of the question, unfortunately, since I require some pretty customized cells. Naturally, I checked the documentation first, where I was confronted by this plethora of options:

Writing software is hard. If the guy next to you hasn’t created ten new bugs, management hasn’t added 10 new features, the customer hasn’t tightened the due date by a week, and your technical lead hasn’t passed a new programming commandment (“Thou shalt not use identifiers with fewer than 4 characters!”) – all by noon – then it’s a good day in Developerstan.

Writing software is hard enough just dealing with the practical, every-day, mundane bits without even having to think about the difficulty added by the actual technical work itself. To write really good, clean, correct code, the programmer has to have a million tiny things in his head – “What does Integer.parseInt() throw if it fails?” “Which directory is ServletContext.getResourceAsStream() relative to?” “Which language is this product in again?” – before he can even write a single line of code. And the really good programmer has to check all his assumptions and return codes before he can even get down to business.

Wouldn’t it be nice if your tools yelled at you when you miss something?