iPhone applications in Python -
A guide to writing iPhone applications in Python. Seems to apply to the jailbreak SDK rather than the real one (though this isn’t very clear) and is undated (I hate it when people don’t put dates on things) so I have no idea if it’s still relevant. But nevertheless.
A chat with TumblrBot. Not that I’m finding it very clever. Ideally it would understand image urls and post image entries. Pity.
The Golden Ratio. Again, from the iPhone 3G video.
Cute Overload in the iPhone 3G video. Even Steve likes kittens. Though I don’t really rate Mobile Safari’s chances of rendering the Cute Overload homepage. It’s.. big.
The key feature of “scalability” that most people care about is actually the ability of a system to efficiently convert money to increased capacity
Almost any small web service could have $10,000 thrown at it and get faster. A new server. More memory! A better load balancer. But you won’t see ten times the benefit if you throw $100,000 at it. What would you get? Lots more memory? You’ll just bottleneck somewhere else. Ten more servers? Your database won’t take the increased load. Maybe it’s the salary of another developer. But that won’t get you a x10 speedup either.
It’s a keyboard firmware update. Why does this require a restart of my computer?


via http://www.rockpapershotgun.com/?p=1811
The current dichotomy is not sustainable (ha!), and nor is the system which generates it. Environmentalism prolongs the existence of this system.
— http://interconnected.org/home/2007/11/11/i_read_the_space
Paul Mison pointed me at this very odd twitter. It’s from a phone, so it seems unlikely that is was supposed to look like this. It contains ‘@s@t@r@a@ @e’ - that was supposed to be ‘Straße’? So this is probably a Windows Mobile phone falling back to UTF-16 / UCS-2 to send non-ascii. Every other phone I’ve ever see falls back to UTF-8 to do this.
Don’t you just love windows?
Updated: this one worked..
Why do people writing server-side code, where limited CPU and memory resources much be shared between hundreds of users, use ‘high-level’ scripting language, whereas those writing client-side code, running on a machine where CPU and memory are much cheaper, use C and other lower-level languages?
In 1999, Germany sold some mobile-phone spectrum by auction, with one rule specifying that any new bid had to exceed the previous high bid by 10 percent. Two serious bidders were involved.
One company bid 18.18 million marks on blocks 1 to 5 and 20 million on blocks 6 to 10. Why the difference? Note that 18.18 million plus 10 percent is just about 20 million. The first company was sending the second a message: ”We think 20 million is the right price: let’s not compete to push it up.” The signaling strategy worked: the auction ended after two rounds, and each bidder got half the blocks at the same low price.
— http://economistsview.typepad.com/economistsview/2007/11/deregulation-an.html
..the document-centric model was never allowed to bloom as we had hoped, to the point where it would differentiate the Mac user experience.
Personally, I feel that nowadays the Mac’s obviously application-centric interface (the dock, application-global menus, etc) is the thing that sets it apart from (and above) Windows’ more fluffy ‘some documents, some apps’ attitude.
I prefer it because it’s more honest as to how the system actually works. Running applications use memory. They take time to start. So a document-based system behaves differently when opening the first document of a give type vs the second document of that type, or closing the last open document of a particular type vs closing any other document.
Another ‘embed Perl in Apache’ module, this one trying to get rid of the thing that makes mod_perl so great and awful at the same time - the persistent run-time. It seems to be that this is an odd time to produce such a thing - the recent trend seems to be towards even small projects having a lightweight front-end server like lighttpd or nginx, and a specialised back-end server like mongrel.