Python's string formatting tools annoy me. And what annoys me, eventually gets fixed, even if it's with an evil hack.

In Perl (and originally in Bourne Shell), you can write:

print "It is ${foo}!";

In Python up to 2.4, you would write:

print "It is %s!" % (foo,)

print "It is %(foo)s!" % {"foo":foo}

In Python 2.5 and later, there's a new formatter:

print "It is {foo}!".format(foo=foo)

In Python 3.0 and later, it's now:

print("It is {foo}!".format(foo=foo))

This is a mess. You can't even find the message in all that line noise, and the name is repeated 2 extra times. Printing several values is unmaintainable.

Hack #1: Use vars() to hide the redundant name assignment.

print("It is {foo}!".format(**vars()))
# **aDict expands the dict as keyword args

print("It is %(foo)s!" % vars())

Still a lot of noise, but foo is just pulled from local scope. Maybe I can hide that vars() assignment?

Hack #2:

print(fmt("It is {foo}!"))

Sweet! How did I do that? It is magic! But it's black, vile, corrupt magic, and it's about 120x slower than the ugly one (though still unnoticeably fast on modern hardware).

""">>>import inspect
>>>x=2
>>>fmt("{0} {x} {y}", 1, y=3)
'1 2 3'
"""
def fmt(s, *args, **kwargs):
	c_frame = inspect.getouterframes(inspect.currentframe(), 1)[1][0]
	c_args, c_varargs, c_varkw, c_locals = inspect.getargvalues(c_frame)
	d = dict(c_locals)
	if kwargs: d.update(kwargs)
	return s.format(*args, **d)

So, I'm not inherently the most productive monkey on the planet. I am, in fact, near-amnesiac, easily OOH SHINY distracted, and have no willpower against fun (say, making that "shiny" joke which was funny once a hundred years ago).

Out of desperation is born solutions. I track what I've done and what I'm doing in two complementary ways:

• Work Journal.

  Whether it's a cheap spiral-bound or a fancy Moleskine or little Field Notes, every day I start a new line with the date, write down what I plan to do.

  As I go, I write down what I'm actually doing, and what I need to do, or any reminders to myself. I lead unfinished items with "-", resolved with "+" or a checkmark, questions with "?".

  My journals are kind of boring, just "fix the framistan" or "remember to CFRelease(bob)", but they're better than my memory.

  Every few weeks (or months) I trawl through my old journal entries and type up any unresolved items which are still relevant.

• Marker Comments.

  Inline in my code, I write // FIXME: xxx for known bugs, or // TODO: xxx for things I plan to do.

  This has two advantages. First, Xcode recognizes these comments and lists them in the function dropdown in the editor.

  Second, they're easy to search for with grep or Xcode's project search. When I'm looking for something to do next, I'll find one of these to work on. In Java, I had an Ant task that marked those comment lines as warnings, so I got notified on every build.

There is a significant missing feature in Mobile Safari on iPhone, iPod touch, and iPad: View Source.

Drag the javascript link below to your browser address bar, and sync your bookmarks to your iThings. When you "visit" the bookmark, the visible page will be replaced with a source view! Click on the link at the top or hit back to revisit the site.

View Source

Oh, how nice. Adobe's Flash Platform Evangelist has a New Year's message for everyone. But it's written in Adobe's internal language, so I'll translate it:

I wanted to make a New Year's post to get the year started off right.

"Like all Adobe marketing people, I hate customers, and want you all to perish in flames."

To the Flash community

"Everyone who sucks our dicks, we like you. Everyone who doesn't, die in a fire."

To unnamed company 1 (Microsoft)

"Silverlight works reasonably well on Linux and Mac OS X, unlike Flash, but we will still bury you!"

To unnamed company 2 (Apple)

"You're mean and won't let us fuck up the browser on the iPhone with our poorly-performing, crash-prone Flash plugin! Arrogant people always lose. Just look at us: We're arrogant, and we're determined to lose!"

To open-source and standards zealots

"Flash IS TOO IS TOO IS TOO a standard! Just because there's no specification, or full independent implementations, doesn't mean it's not standard! Besides, where are you gonna go? HTML 5 and JavaScript? Those are only the basis of the World Wide Web, they don't matter."

To all the complainers

"People who suck our dicks can say we aren't perfect, and we won't beat them senseless for it. But if you don't suck our dicks, we will hate you FOREVER."

To Latin America

"I'm too stupid to realize that Portuguese is the language of Brazil, not Spanish."

I can't wait to spend 2010 with you all!

"As long as you suck our dicks."

Dave Winer, once upon a time the author of a scripting system called Frontier, posted We need: A programmable Twitter client.

Well, interesting idea. Except we already have multiple programmable Twitter solutions.

Twitterrific can call AppleScript on new tweets (and comes with a demo script), and you can use AppleScript to control it, at least as far as posting tweets.

I'm not suggesting that AppleScript is perfect. The core AppleScript language is easy to pick up, but every app you try to control is like learning a new language, and the core language isn't very powerful, so you end up using other apps as helpers. I spend days fighting AppleScript and swearing a lot every time I have to deal with it, and I do this for a living.

But AppleScript is the standard scripting tool on Mac, and it's well-suited to simple cases. If Twitterrific (or another client) had more scripting commands, you wouldn't need anything else.

The more advanced solution is Python-twitter, which provides Twitter API access from Python. Python is easy to learn (Learning Python or Python for Software Design are both fantastic tutorials), and Python-twitter seems to be a pretty complete and easy wrapper around the API.

So this brings me to my real point: Apps with custom scripting interfaces are obsolete. Unix shell scripts, DOS batch files, Lotus 1-2-3, Emacs-lisp, these are all ancient and archaic systems. For Unix scripting, last year I quit using bash after 20+ years because Python's easier to get right (esp. with filenames containing spaces).

Dave wants an "unfollow-with-timeout". Fine, write one. Make a tiny Python script that calls the Twitter API to unfollow someone and adds them to a list with the timestamp. Write a second script that runs daily (add it to cron or launchd; there are GUI clients to edit both) to scan that list, find people past their 24-hour unfollow, refollow them, and remove them from the list. It probably took me longer to write this blog post than it would to write those scripts.

I have a love/hate relationship with Apple & the iTunes Store. Like a battered wife, I can't stay away. I'm sure they can change... But will they? Until then, I put up with it.

I love iPhone dev when it's like coding for the Mac, but better, with a GUI not encumbered by 25 years of legacy NeXTstep/OpenStep/Mac Carbon/Cocoa compatibility. What would the Mac look like if it was designed today? It'd look like an iPhone, apps sleek and directed and perfectly functional.

I hate iPhone dev when APIs are incomplete. The fucking Address Book and Keychain are so appalling I go mad dealing with them. The most basic functionality is missing. Audio is finally caught up, and I need to rewrite the audio stack of Perilar (and put one into Castles!), now that it doesn't suck. But plenty of new stuff I'm doing is entirely broken, and I'll have to fix it when Apple fixes the API.

I hate iTunes Connect more than anything ever. MORE THAN ANYTHING. It is seriously the most painful, awful, slow, malicious piece of malware ever written. I cannot imagine how people thought that passed muster. If Steve Jobs saw iTunes Connect, you'd need buckets and high-pressure hoses to remove the corpses of those responsible from One Infinite Loop.

I hate the Apple approval process. As of last week, they claim it's at 75% approval within 2 weeks; I know several people--SEVERAL--who've been waiting for 3 months or more. My own apps sometimes got bounced back to me a couple times, but were mostly approved in less than 2 weeks... but rarely much less. As we head into the Silly Season, it'll drop even further. Apple can't approve things quickly, and makes terrible mistakes about what's "offensive" and what isn't; Baby-Shaker was okay, but political parodies aren't? That's MADNESS.

The worst part of the approvals is when you have to remove a cool thing, or never even add it, because you know Apple won't allow it. I want to put a couple of programmable toys and an adventure game engine up. I can't, they use interpreters with downloadable code, which is forbidden. It's preemptive censorship, like trying to be an artist in the USSR.

The iTunes Store itself is a disaster area. A giant pile of everything, good and bad, like a sci-fi junkyard. You might find some sweet loot, or you might find radioactive waste. The approval process has done nothing to improve on that, if anything it's made it far worse.

I love the payments: 70% royalty on gross from a publisher is sweet. Really sweet. Typical publisher royalties are 10-20%, often from wholesale or "net" (which is always nothing). I wasn't making enough to live on, but I still get some solid pocket money even with no real advertising or new apps (and those will happen as soon as possible, but doubtful before New Year, with the holiday approval slowdown).

So the end result is I hate the App Store system. But I'm still in it, sort of. I'm VERY disappointed by Apple's handling of all this, but I don't believe it'll get better anytime soon, and I still like making iPhone apps more than anything else.

[The Torment of Tantalus, in Greek mythology]

[Update 2009-11-13: From Christopher Lloyd, the stories of Watson and WebObjects. Apple sometimes beats up indie developers and takes our lunch money. They do what's best for them, sometimes with apologies, but never with mercy. ]

The argument over App Store upgrades is still going on, on Twitter and blogs.

And more and more, even normally sane people are latching onto the mantra "IT'S ONLY THREE DOLLARS!", which completely misses the entire point. So much so that it's like watching a blind person chase a squirrel. Funny, but sad and pathetic.

See the monotone "It's $3!" from Jim Dalrymple or Jeff Lamarche, and many others who are being less civil and sane. These are not normally crazy people (well, Jim's a little weird). But they're acting in a profoundly crazy and short-sighted way about this.

None of this is about the money. IT IS NOT ABOUT THE MONEY.

It's about customer service for existing customers, and about keeping existing customers in your app.

The really key point is that most, 90-99%, of Tweetie 1 users are not going to switch to Tweetie 2. They're going to see the app never get new features, and break under them when Twitter changes, and then go to another app that is being updated. Think the sales process through: "Huh, my Tweetie app broke. GUESS I'LL BUY ANOTHER COPY OF TWEETIE." It's ludicrous.

If you give a customer the opportunity to switch, they will. If you burn a customer that way, they're lost for good, and will badmouth you forever. "Bad publicity" only works when it's not about bad quality or bad pricing.

Devs whining "But it's only $3!" are just showing they have zero clue about customer service, and zero clue about what the problem is.

Now, is in-app purchase a perfect solution? No. But Apple's not going to add upgrade pricing anytime soon, if ever.

A short-term discount won't help, because early sales are important, Tweetie 1 users won't know to go get it, and if they did, they'd go buy something else.

Loren Brichter (@atebits), the author of Tweetie, has good intentions: To get paid a reasonable amount for continued improvements to an app for his customers. Apple's App Store policies make that hard to do that. But the specific plan is one of the worst business and customer service ideas I've ever heard in my life.

Update: Patrick Burleson (@pbur) has filed a Radar ticket with Apple for proper upgrade pricing, rdar://7265066 (for those inside Apple), or on OpenRadar. Go hit up Radar and file a dup!

Suppose you have an app on the iTunes App Store, and you want to provide a new version. No, this isn't me. I'm talking about someone else's app.

As I see it, there are three options:

1. Free Upgrade. Just update the app in iTunes Connect, and it shows up as an update for all existing customers. New customers get the new version.

   Pro: Easy to implement. Generous to existing customers.

   Con: No way to get a paid upgrade.

2. Entirely New App: Create a new app, and remove the old app from sale.

   Pro: Easy to implement. Many new sales at full price. Some existing customers will go buy the new app.

   Con: Abandons existing customers, who get NO further updates. Most existing customers won't know there's a new version. Appalling customer service. Most existing customers will simply leave you and buy another app.

3. In-App Purchase: Separate the 2.0 features from the 1.0 features, and make them unlockable in the app.

   Pro: Allows existing customers to upgrade, just like a desktop app with a paid update. Allows a lower entry price for the base app, which drives sales up. Keeps existing customers locked into your app.

   Con: Much harder to implement. Slightly confusing when people buy the new app, and not all possible features are enabled.

I consider Free Upgrade the best option, if you can afford it. This maximizes the happiness of existing customers, and gives both old and new customers the full app.

In-App Purchases are certainly a lot of work, and maybe somewhat risky as a business model, but it's a fair balance between satisfying existing customers and making money on the upgrade. Apple appears to have no problem with unlocking functionality by purchase, and purchases can be re-downloaded if you uninstall and reinstall the app, so this appears to be a functional method.

The Entirely New App idea is appalling. It's the worst possible customer service to existing customers, and gets you few or no paid upgrades from them. They won't know the new version exists, unless you update version 1 with a message "go buy version 2", which Apple will almost certainly reject.

You may get normal new sales, nothing more, but those who know what's going on will remember how you shafted the previous customers, and realize you'll shaft them in the next version. Since you're going to get a low conversion rate from your former customers, there's little or no financial advantage over a Free Upgrade.

There is a sort of fourth option: Release an update to version 1 with ads. Now you can make some money on the existing customers, and sort of push them towards buying the new version without ads. It's annoying, and upsets their expectations of an ad-free app, but it'd work out financially.

While it would be nice if Apple would provide a "Paid Upgrade" option, and allow multiple versions of the same app on the App Store, that seems improbable to "never going to happen". Apple's business model works fine for THEM, and if it makes life hard on developers, they don't seem to care. Given that, it's up to the developer to make choices that make financial sense while NOT screwing over existing customers.

"We are having more tech difficulties than we could ever possibly deserve, once again proving that there is nothing but an indifferent void behind everything humans do. And that truth is evident once you try doing software demonstrations for a living."

The Last Lecture

Posted on my software blog: The iPhone App Store Blues

Sometimes sites use a color scheme you don't like. I can't stand looking at white text on black background; others love it. I like my black text on yellow graph paper theme, but not everyone has 20+ years of staring at engineer's pads. Nobody likes gray text on gray background, except John Gruber.

Just drag the javascript link below to your browser address bar, and click on it. It'll change every element on the page to black text on white background. Or you can edit it, and change the "white" and "black" at the end to the background and foreground colors you want.

Monochrome

Faruk Ateş has a shiny new web site, go take a look at it. SO SHINY! So how does he do that?

He wrote a new CSS library, Modernizr, that makes cross-browser development easier without having to write JavaScript if/else blocks testing for each feature, for each element.

THIS is the kind of stuff we need more of, if we're going to drag web development out of the dark ages when IE6 and Netscape stagnated.

Google's trying to advertise "Going Google", using Google Mail and Google Apps for all your business's work. I don't consider this a terribly good idea.

In less Google-focused circles, this is called "Cloud Computing", because network services are typically drawn as a cloud in block diagrams:

I've worked at two places now that "went Google". Sometimes it reduced the IT load. Other times… Google Apps is unresponsive (either too slow to use, or just down) at least once a week. It's always too slow for comfort (I'll get back to that in a moment).

Gmail has rather strict restrictions on sending a lot of messages (whether "I forgot my password" or more spam-like newsletters), and on the content of the messages, which can lead to the account being temporarily or permanently shut down. The hacks to work around that cost more time and effort than getting a proper mail server & sysadmin would have.

Your data & email are entirely at the mercy of someone else, who may shut you down at any time, for any reason they feel like, and may be difficult or impossible to get an explanation out of. If it's your gmail junk email box, that's no big deal. If you're running a company on it, it's a big deal, maybe a company- and career-killing bad decision.

This isn't specific to Google. Google's fine, as cloud computing servers go. There are five problems inherent to storing your information in the cloud:

Speed

If an operation takes 1x time in memory, it'll take 100x longer on a local hard drive, 1000x longer on a local area network, and 10K-1M x longer over the Internet. Saving a file might take milliseconds (0.001 seconds) locally, but can take 1-10 seconds or longer to the cloud. Most Internet connections are not symmetric, which means they upload files MUCH slower than they can download, often 5-10x slower.

Reliability

Sending something over the Internet is not all that reliable; it's entirely possible for a connection to just fail. Usually you can just resubmit, but I'm sure everyone has lost web comments or posts when a submit failed. Or worse, when they hit "Back" by accident, or when the browser crashed. That's why I write every blog post in BBEdit, save it locally (actually, I neurotically save after every paragraph), and THEN post it to my blog through a web form.

Offline Use

You can't use any of your documents or mail offline if they're in the cloud. If your office or home Internet goes out, you can't do any work, you're completely shut down for the day. Wifi and tethered cell phones can give you some coverage when you're out of office, but they're even less reliable.

Backups

Do you have redundant offsite backups? I do. Any halfway-competent sysadmin will. On one hand, the cloud gives you a permanent offsite backup. But you have no control over it. You are entirely at the mercy of Google. Maybe they'll suspend your account. Maybe you'll delete a file by accident; can you get it back? How far back is it saved? These aren't insurmountable, and Google's databases are safer than most home users non-backed-up data, sitting on a single computer. But for a business these are terrifying risks.

Privacy

So Google has all your documents. Your mail. Your contacts. Your business plan. Your financial data in spreadsheets. And they're scanning it. No Google employee should, supposedly, ever see it, but the search engine does… and accidents happen, and people aren't always trustworthy.

So what's the alternative? Get a real mail server & a sysadmin to run it. Store your documents in version control (preferably Perforce or maybe Mercurial; Subversion is awful for non-programmers, and painfully slow). A wiki on a LAN can work, but has the same problem of slow updates, and makes anything except wiki markup a pain to work with.

I've released Castles 2.0, and you can read about it here!

On my Python page, I've updated my command-line Utility.py framework and added the Filter.py app I use instead of grep, sed, awk, etc.

Utility.py is one of those things that's trivial to make not quite right, but really hard to get the last half-mile, so the framework, tiny as it is, takes away a small headache.

Filter.py solves a big headache. I used to be the zen master of awk, but these days it's hard to remember every little language's syntax, while I use Python daily. So I can do something easy like this:

Filter.py -e "print line.center(80)" somefile

Or something complex like this:

Filter.py -b "self.data.total = 0.0" \
    -s "^(-?[0-9.]*)\s+(.*)$" -r "\1" \
    -e "self.data.total += float(line)" \
    -a "print 'T:', self.data.total, ', AVG:', self.data.total / max(1, self.matched)" \
    example-data.txt

(An equivalent single-purpose Python script wouldn't be much longer, but would be a pain to write, whereas that long command was trivial to write)

It's all under a BSD license.

I have a little HTML animation demo. But I need some help.

• HTML, JavaScript, DOM
• HTML, JavaScript, Canvas

All it does is create 512 sprites, which bounce left and right in a box. If you click on it, it reverses their directions. The DOM version creates 512 image objects, which it then moves around inside a div. The Canvas version redraws the entire canvas every frame, blitting the images on.

On my MacBook Air, I get about 30 FPS for the DOM manipulation, 13 FPS for Canvas (which is doing considerably more work). That's shockingly good performance for such a ridiculous number of sprites, in a web browser.

I need help: I made a Flash version (very bad, since I don't know how to write Flash properly, it was painfully slow which I believe is the fault of Flash), but I've misplaced it (probably on wiped work computer). Can someone who does know Flash make an equivalent to this test? I want to do some proper head-to-head performance testing.

Android has 3 lethal problems:

1. Poor usability; open-source projects can make nice screenshots, but never make usable software.

   "Design is not just what it looks like and feels like. Design is how it works."
   — Steve Jobs

   This is the classic Linux problem, and none of them understand this, or how to fix it. The newer versions of KDE look pretty, but are miserably painful to use, and other window managers and desktop managers for Linux are even harder to use (I was fond of WindowMaker, a clone of parts of NeXTstep, but it was very primitive and lacked even a real file manager).

2. Multiple platforms and implementors and versions, so apps can't rely on consistent hardware or OS.

   This is what killed J2ME; you had to build and test on 20-30 combinations of phones and carriers to release any software. This is part of what keeps Nokia and Blackberry from having significant 3rd-party apps, each app only works on some subset of the phones. Classic Palm OS managed backward compatibility most of the time, but even so, the Palm V and Treo couldn't run some Palm III apps.

   Android is not what anyone would consider "release quality" software yet, it's still beta. The API and implementation are going to change, and change in incompatible ways, and the existing software will break.

3. Conflict between business interests and the freetards will sour the freetards on it.

   (By "freetard", I mean specifically the FSF, the EFF who have been completely infiltrated by the FSF, and associated fanboys; not everyone who uses or even develops on Linux is a freetard, but almost all freetards use Linux)

   This has already occurred, with tethering apps being removed from the G1's app store, and the freetards screaming "TRAITORS! UNCLEAN!" at them. It's only going to get worse, because business and real customers want a stable platform, while the freetards feel they have the right to do anything they want with no regard for cost to others.

I expect Android will be around for a couple years as a crappy second-rate system for non-Apple phones, then die.

Not everyone loves Xcode with the burning, still-illegal-in-49-states passion that I do. Some people still like Eclipse. I know, I know. No, really, stop laughing, it's a serious mental illness. A mental illness that AlBlue has.

Almost everything he says is simply wrong, and shows that he hasn't even read the docs and learned to use Xcode.

• The correct spelling is "Xcode". Not "XCode".
• The editor window can be vertically split with the vertical split icon above the scrollbar, and can show different files.
• To show multiple windows, double-click the file, or change back out of "All-in-One" display mode.
• To flip from .h to .m, use Cmd-Opt-Up or the "Go To Counterpart" icon in the editor.
• Autocompletion relies on having a correct type. NSArray *foo; and id foo; will give different autocompletes because Objective-C is a dynamic language.
• Xcode has had refactoring since 3.0, and it works rather well, including safely correcting your NIB files.
• You can Cmd-double-click a class to jump to its definition, or Opt-double-click to open its documentation.
• The documentation can be shown in full either in the Help|Documentation window, or by turning on the Research Assistant, which gives a floating window with constantly-updated API information and sample code for whatever type is selected. Seems to work fine for me.
• The doc set size is fairly large, but it's also significantly better documentation than the 56MB Java 6 docs. Look inside the JDK download: it's full of example code, too. You'd just whine like a high-pitched whiny thing if there were no examples.

If you want to use Eclipse, that's fine (though stupidly masochistic), but lying or failing to check your statements just makes you look like a fool.

People who write comments on YouTube and Flickr are, with very few exceptions, idiots. It irritates me to have a page half-full of stupid comments when I just want to watch a video or look at a photo... Neither site has any option to remove the comments. So, how do I eliminate them?

The following works in Safari:

Visit http://kuoi.com/~kamikaze/doc/stupidcomments.php, hit submit, and you'll get a customized style sheet.

Save this file as "stupidcomments.css" in your Documents folder.

In Safari's Preferences | Advanced, change the style sheet to Other..., and pick "stupidcomments.css".

Now reload those YouTube or Flickr pages, and voilá! No more comments from idiots! If you ever do want to see them, you can open preferences and change the style sheet to "None Selected" briefly, then put it back.

[Updated 2009-07-02: Moved to a file, not just a blog post.]

[Updated 2010-08-07: Generator form lets you pick the parts you like.]

Python 3000 came out, 992 years ahead of schedule!

# dowdy old Python 2.5:
def something(n):
    print "S %dtD %d" % (n, n+1)

becomes:

# fancy new Python 3.0
def something(n : int):
    print("♠{0}t♢{1}".format(n, n+1))

Not a useful example, but it shows four of my favorite new features: annotated function parameter types, print as a function, and format as a string method. The string in the first example is ASCII-only. The one in the second is full Unicode, and all Python 3.0 scripts are assumed to be encoded as UTF-8.

It's still probably not something you'd want to use on existing production code, even with the 2to3 migration tool; it's not backwards-compatible, and it's not as efficient yet. Python 2.6 has most of the new features in a backwards-compatible form, and remains one of the fastest dynamic languages. For new code, though, Python 3.0 is looking pretty cool.

Perl, however, is in trouble. Perl 5 came out in 1994-Oct-17. Perl 6 was announced in 2000-Jul-19, and still isn't out. The Parrot VM designed for it doesn't actually run Perl 6 code yet. The whole project has been one of unfocused nerds doing nothing productive for years.

Over on use.perl.org, the soi-disant "Ovid" writes: Perl 5 Programmers Are Dying, about the increasing difficulty of hiring qualified Perl programmers. This should be obvious, but the reason he can't find qualified Perl programmers is because all the qualified programmers have moved to other languages, and new ones aren't bothering to learn such an old and awkward language. Redesigning and advertising the Perl site better isn't going to change the situation. Where did all those Ruby users come from? I'm no fan of Ruby, but it's a better Perl than Perl 5, and it's in active development.