Yesterday’s iPhone/iPod touch firmware updates seem to fix the most obnoxious of the early release bugs. My favorite fix? The music player no longer randomly crashes while browsing the web. Safari seems snappier too.

I was thinking about why I hate frameworks. It’s not a full-on hate, of course, but I find that wrapping and abstracting every aspect of an approach insulates you from what you really need to understand. I call it the inverse law of elbows: the more elbows you add to something, the harder it is to get it to do anything useful.

So while my mind was wandering around the why-do-people-insist-on-frameworks question, I started thinking about what I do like. Here’s what I came up with:

• Engines (solve a narrow class of problem with a simple interface)
• Libraries (functions and groups of functions)
• Toolkits (larger groups of functions)
• Languages (alternate ways to describe solutions)
• Domain specific languages (solve small parts of your domain well)
• Concrete, simple implementations (just the straight dope)
• And, always, always, always consider standard/common things first

It comes down to choice, orthogonality, and the smallest number of immutable constraints on how you can put the parts together.

You can replace engines easily, based on their well defined, loosely coupled interfaces. You can take or leave portions of libraries and toolkits. Languages (outside of little languages) give you some level of choice. DSLs let you express things in your domain. And simple, concrete implementations give you things that work.

I’m going to work on posting links to some metaphors of products using engines, libraries, DSLs (and the like) really well. I’ve been inspired by dozens of things that other people have written, which have moulded how I see approaches.

Here are a pair of tech talks on mobile Safari web development (part 1, part 2, and PDF notes). A choice quote:

Probably the tastiest morsel of information I got from the Apple iPhone Tech Talk was hearing Mark Malone explain that Apple developed all of the iPhone native applications, such as the Stocks, Clock, and Weather apps, using Canvas. It makes sense now when one understands that Apple developed Canvas as part of their Mac OS X Dashboard SDK for creating widgets. Who knew?

Here’s a list of file types supported on mobile Safari, and my Del.ico.us stream of iPhone development links.

My iPod touch “development” hardware arrived today. I’ve been more excited by this toy than any I can remember, as it seems like such a disruptive leap in technology. And once the hardware was unpacked and set up, it was no disappointment: it’s the most enjoyable computing device I’ve every touched.

So what have I liked so far?

• It’s fun, and the interface is fall-over obvious
• The web browser works really well
• The screen is perfect for video
• iTunes store and uTube work better than expected
• Wifi works better than my HP laptop’s

What don’t I like?

• No easy local file storage (offline eBooks might be tough)
• Closed OS (ignoring the current hacks in the wild)
• Smudges easily
• Google reader doesn’t run very well
• No Java/Flash
• Selection of uTube content is limited

This device is perfect for me. I can read eBooks online, read news, watch some video, and listen to my music library. It’s also a tool I can use to test iPhone/iPod touch applications for work.

Update

The iTouch can view PDF files (which was one of my main questions before I bought it).

The Jargon file lists phases of the moon as a humourous cause of bugs.

Here are Wikipedia’s articles on the DRY principle, YAGNI principle, and MCV pattern. Also check out C2’s article on DRY (via).

Akismet has caught 35,255 spam for you since you first installed it. (That’s a lot of spam in the 2 years I’ve had the plugin installed).

Steve McConnell walks us through a bunged estimation process, for a kid’s playhouse he built this summer. He shows us, in real-world terms, the sorts of estimation bugs that creep into our thinking about project planning.

What every programmer should know about memory, Part 1, a very thorough look at current generation memory architecture for programmers.