H/T: David Wiley

From the programmer’s point of view, it’s just another set of Xcode project templates. I’m not a Cocoa/Objective C expert, but Xcode/Cocoa (especially Interface Builder, which isn’t fully functional in the beta SDK) is pretty sweet — as long as you don’t mind limiting your code to Apple products. That’s not a big deal in this segment; the Touch (Alexandre Enkerli’s term) devices are pretty much it, at least until someone starts shipping Android products.

A couple of things I’ve heard and learned concern me, though.

1) Apparently there’s no way under the current SDK to have a application run in the background. Some of the cooler educational applications I can imagine would really work better if they could talk to a server all the time, or at least check in every few minutes. Some have said that this is due to the limited processing power of the Touch devices, but I’m not convinced that’s it. For one, the ARM processors in the Touch devices are more powerful and have more memory than the ones I used to run Linux on in the early 90s <codger voice> I used to run Linux on a 386SX 16 MHz machine with 8 megs of RAM. We didn’t have any fancy “distros” or “CDs”. We had to download the packages one at a time over a dialup and put them on floppy disks! And we liked it!</codger voice>. For another, the Touch devices don’t seem to have a problem decoding and playing music files (a fairly compute-intensive process) while in the background, so clearly the capacity is there.

I suspect this has more to do with avoiding competition for the (lucrative) SMS market than it does with processing capacity. It just seems a shame to have “always on” Internet access, then prevent the device from actually making use of it.

2) Applications are (reportedly) sandboxed from talking to each other at all. That makes some sense from a security standpoint, but is going to make it vastly more difficult to write any kind of mashup or add-on (for instance, a working spam filter for the Mail application).

3) This is the biggie: “No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built- in interpreter(s).”

Domain-specific languages (DSLs) are mini-languages that are designed to solve a specific problem. They’re pretty easy to write in some languages (especially Lisp but also in some modern scripting languages, such as Ruby). The advantage of a DSL is that you can create a mini-language which makes sense for the problem (or which makes sense to your users).
An example that’s been around for a while is the MIDI protocol for controlling electronic instruments. While I wouldn’t necessarily hold MIDI up as a good DSL, the idea is there — MIDI uses terms and concepts with which its users (muscians) are already familiar, rather than having them poke values in registers and hand-control oscillators. SCORM and IMS Learning Design might also be called DSLs, in a way.

Just about every education app I can imagine would benefit from some kind of scripting. I don’t know that I’d want to spend a lot of time writing a cool education app only to have some lawyer at Apple (for example, the one who wrote that clause) decide that my DSL was an “interpreter” and ban it from distribution (especially since the App Store is the only way to distribute your code).

I was excited by the SDK at first. Now, not so much.

Thanks!

As a result, things may go pear-shaped for brief intervals during the transition. Apologies in advance.

Current status: 97 pages.

We had a cold front move through on Wednesday, bringing a temperature drop of more than 50 degrees F.

It also produced a variety of “exciting” weather across the state, as you can see from the graphic. Something for everybody!

Bill Kerr
D’Arcy Norman
Evil Mad Scientist Laboratories
Greenbush Labs Blog
Mark Guzdial’s Amazon Blog
Learn Online
Iterating Toward Openness
Online Learning Update
infoisland.org
Wormtalk and Slugspeak
Blogger
WordPress
LiveJournal
OPML 1.0 Specification
Clay Shirky: A Group is its Own Worst Enemy
Bloglines
My Yahoo!
Google Reader
NewsGator Technologies
National Weather Service
Google News
Brief add-on for Firefox
Lankshear & Knobel, “New” Literacies: Research and Social Practice
Will Richardson: Blogs, Wikis, Podcasts, and Other Powerful Web Tools for Classrooms

Some notes about the current status:

I’ve been collecting a lot of references (thanks, Zotero!) and now believe the reference list is more or less complete (the current reference list is included with the chapter, feedback is welcome on that as well).

Several of the other chapters are partially written, but aren’t really close to being ready for posting.

The PDF is formatted for a 6″x9″ book, so it won’t be particularly kind to trees if you print it out on standard-sized paper (I guess you could shrink it to fit two pages on one physical sheet, but then the diagrams might not look very good).

I’m planning to have the book printed by CreateSpace and listed for sale on Amazon.com (this is free, by the way). I thought about submitting the book to a commercial publisher, but after learning about the generally abusive state of academic publishing in a seminar last semester, I’m not willing to do that (in particular, I’m not going to give up my right to distribute copies of my own work as I see fit).

The material is licensed under Creative Commons, so you’re free to share. However, I’d prefer that you link back to this post rather than distributing the PDF (mainly because this is a draft, and could well contain errors at this stage).

Current status: 86 pages written since December 24, 2007, roughly three chapters worth of material. I should be able to finish by April or so at this rate.

I hope it’s useful to some of you!

I do have a cover mockup finished.

covermockup.pdf

As with everything else, subject to change without notice. Note that this is a low-res version. The full image file is close to 150 megs.

Chapter 1 is essentially done, other than a final edit. Draft coming soon!