One lesson here is that a simple but well-done web app […] can be vastly superior to a full-fledged but terrible iPhone application.
It’s doubtful that anybody reading this blog missed the news that Apple finally took the wraps off their much rumored tablet: the iPad. Trouble is, a bunch of folks seem to be upset about the features and specs, or something that made the buzz machine go meh. It’s just a bigger iPhone, complain the privileged […] » about 400 words
Stefan Savage, speaking in a segment on March 13’s On The Media, asked: The question I like to ask people is, what are you going to do to the highway system to reduce crime. And when you put it that way, it sounds absolutely ridiculous, because while criminals do use the highway, no rational person […] » about 400 words
I’m flying Virgin America from BOS to SFO, and apparently all their planes on that route offer in-flight internet via Gogo. $12.95 buys 3Mbps down and 300Kbps up (at least early on when nobody else seemed to be using it). I can get my iPhone online for only 8 bucks, but as far as I […] » about 200 words
You’d think the top search results on the matter would be newer than 1999, but that’s where you’ll find this NYT article and PubLaw item story, both from precambrian times. Worse, both of those articles suggest that my links to them may not be entirely kosher.
The problem is probably that US courts have not spoken clearly on such a case. A Danish court in 2006 did, but I think that no case in the US has gone far enough to actually set a precedent. Another chance at settling this issue was lost earlier this month when BlockShopper settled, rather than continue a costly defense of such a case. The EFF is confident BlockShopper could have won, but that means little when the legal bills come in.
If you’re already building web apps, you might wonder why you should bother to build an iPhone native app. The short answer is that you might not need to, but you should still optimize the app for iPhones. Native-looking chrome Set these in the head: // set a custom icon for when a user bookmarks […] » about 500 words
Social Media in Plain English and RSS In Plain English, among others from Common Craft among the best explanations you’ll find. » about 100 words
This two year old post about Rasmus Lerdorf’s PHP scaling tips (slides) is interesting in the context of what we’ve learned since then. APC now seems common, and it’s supposedly built-in to PHP6. Still, I’d be interested in seeing an update. Are MySQL prepared statements still slow?
And that’s where Rasmus’ latest presentation comes in. We don’t learn anything about MySQL prepared statements, but we do learn how to find choke points in our applications using callgrind and other tools. In his examples, he can do a little over 600 transactions per second with both static HTML and simple PHP, but various frameworks — with many inclusions and function calls — can slow that to under 50 transactions per second (I suppose they’d explain that in a TPS report).
What I’ll need is an easy way to manipulate the contents of a simple array, and these JSON editors may give me a start.
The Braincast JSON editor was the first I found, but it doesn’t allow creation/expansion of the JSON. Katamari‘s JSON editor seems to work and has a lot of features and a post 2005-looking interface, but that doesn’t make it simple. Worse, I don’t think it’s available for me to re-use, modify, or extend in my projects. Thomas Frank‘s JSON editor, on the other hand, does have the features I need and a GPL license. That’s the place to start.
Extra: a JSON diff.