Apple Hater Converted? I want an iPad!

I've tweeted several times about my misgivings on the Apple iPad.

• Still not getting an iPad (I'm a h8r), but Gruber's got a point against my main beef (the closed platform) http://bit.ly/a0vO6j
  Apr 02 2010
• No scripting/coding on the iPhone was pad enough. But the iPad could have been great 4 kids to learn 2 code. Too bad. http://bit.ly/ayKHYM
  Jan 31st
• if I had an iPad rather than a real computer as a kid, I’d never be a programmer today -- Alex Payne http://al3x.net/2010/01/28/ipad.html
  Jan 29th

I'd prefer an open platform. I think the changes to section 3.2.2 of the developer agreement are a small step in the right direction, and  I'd like to see more openness. From Boy Genius:

Apple has again tweaked section 3.2.2 of the agreement, adding in a loophole which will allow them to approve certain interpretive code tools. The old section 3.2.2 read like this: No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).

While the updated version looks like this: Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s). Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.

And I particularly hope that Squeak and Scratch and other great programming environments for kids and otherwise make it onto the iPad or similar devices.

But, the iPad is just too good for me to not want one. Stefan Miller let me try his iPad a couple of times and I'm sold.

The main reason is that I want a great PDF reader. The iPad is significantly better than the Kindle or even the Kindle DX for reading PDFs. I also want to annotate, and that capability is available as well.

I read a lot of books on programming. These books tend to be heavy and expensive. The PDF versions can often be had for less than half the cost. But, that means carrying a laptop. (I've been known to hold my HP EliteBook sideways with the screen orientation on portrait.

Hopefully innovative programming environments like the Lively Kernel will make it possible to write some code on the device and do some programming with kids. Quoting an interview with Dan Ingalls:

The fact that the Lively Kernel is just a web page and you click on it and you're running this system, it's a system that can do graphics editing, can produce images, can do simple programs, like Squeak that you can save a page from, means that basically anywhere you have a network computer, you can have authoring.

That's one ingredient. Another is I noticed that there is a certain challenge you have before you can become a developer for say the iPhone and yet the iPhone has Safari in it and it runs Lively Kernel applications just fine. It seems to me there is an opportunity here for something much more open than the App Store in which everybody can contribute and produce and share active content.

And, I hold out hope that eToys, Squeak and Scratch will someday be approved as well.

But, for now, I am looking forward to compromising my principles! The iPad is on my birthday list! As are a number of apps, gift cards will be welcomed!

Iowa Code Camp 5 on May 1, 2010

The site is still showing ICC4 info, but the countdown clock has been updated to a new date! Looks like I need to free up a spring day for some hacking!

While browsing the site, found a picture of me presenting Seaside at ICC4. The book in the picture is Learning Programming with Robots. I think I was answering a question about Alice.

Nice and simple script to install rails on Ubuntu 9.10

Thanks to castilho:
http://castilho.biz/blog/2009/11/05/ruby-on-rails-ubuntu-9-10-karmic-koala/

Refactoring – Ruby Ed.

The original Refactoring book by Martin Fowler had a big impact on how I thought about writing software. I’d used the refactoring tools in Smalltalk, but the book changed the way I thought about refactoring and gave names to many new refactorings.

This Ruby edition of the book is highly anticipated. I received my copy at a drawing in our local Ruby user’s group. Part of the deal was you had to write a review (you are reading it) in exchange for the book. Nearly everyone at the meeting wanted a crack at the book.

The authors suggest that if you have the original work, you probably shouldn’t purchase this new edition. I don’t agree. There is plenty of new content with around 20 new refactorings and a few new code smells to make the difference worthwhile. There is a tremendous amount of thoughtful Ruby code snippets inserted throughout the text.

In fact, this is one of those books that is great for everyone on a team to have a copy. It is the kind of book that can be used to raise the quality of communication across the team.

You can see the respect the new authors had for the original work, as the new refactorings jibe with the old. Much of the text remains unchanged, which is good as things like the justification, most of the code smells, and background have aged well. Even the order of the refactorings has been largely preserved, which makes it easy to compare the two editions.

Jay Fields and Shane Harvey have updated the examples and step-by-step examples using idiomatic Ruby. Where the original book used Java for the code examples, the examples were pretty language-agnostic, not using anything from beyond the core SDK and even avoiding things like inner classes in examples. This book leverages Ruby’s strengths.

New Environment for "Programming with Kids"

I was psyched to see the Etoys 4.0 release last week. It's been a while since I looked at Squeakland so I took some time to play with it last weekend. I am directing a hands-on exploratory session called "Programming with Kids" this Saturday at Iowa Code Camp 4 and Etoys will definitely be the jumping off spot.

I'll be using the Etoys to Go package. This is a nicely packaged environment that runs your code portably across Windows, Mac, and Linux without installation. You can put it on a flash drive, plug it in, and go. Save your work, switch to another computer and go. Etoys to Go is a much better name than the old "One-click image" since it really has little to do with the image or how many clicks it takes.

In addition to eToys, I'll be mixing in some examples from Ducasse's great book, "Learn Programming with Robots," and from the Seaside web application framework.

I just finished testing the distribution on Windows, Mac, and Ubuntu. I'll be putting it on media to hand out at the conference and I'll post a download link here soon.

Updated:

Download the ZIP here and expand to any folder on Windows, Macintosh, or Linux:
http://bit.ly/4khd83

Hands-on Microformats: Quickly build an hCalendar-based view with XSLT and Seaside

I gave a talk with the title, "Hands-on Microformats: Quickly build an hCalendar-based view" at the 2009 BarCamp Omaha. Since the presentation was really looking at code, I didn't have a slide deck. So I thought I would share my notes in a series of posts. This is the first.

Short version: By adding a few specific attributes and abiding by some date formatting rules, you can generate a great-looking monthly calendar with surprisingly little effort. That is, get something like this:



From HTML that looks like this:



A microformat lets you use standard XHTML but add in some semantic goodness without resorting to a separate XML namespace and corresponding set of tags (or formally, an XML application).

For our example, hCalendar uses a 1:1 representation of standard iCalendar (RFC2445) VEVENT properties and values in semantic XHTML.

hCalendar wouldn't have caught my attention if it weren't for js-hCalendar. This bit of JavaScript created by David Glasser and hosted at Google code will take some hCalendar-laced HTML and give you back a Monthly calendar view of the data.

Now, if you are working in the heart of the application and you already have (or can acquire) a calendar component that does what you want, then this code may be less useful. But, I've found it very handy when I'm working around the edges of an application or I'm using a language with a smaller set of available components. The key is, no matter what platform on which I'm running, I can probably generate the required HTML to get this working in an hour or two.

Up next: some examples from XSLT and Seaside (Smalltalk).

What makes Squeak special?

Avidan Ackerson asked a great question:

I know that Squeak is written in Smalltalk, but are there specific advantages to Squeak over Smalltalk proper?

What makes Squeak special is the Squeak community. Fantastic history and tradition. Inspiring thinkers. Colorful ideas.

For someone used to commercial Smalltalk development, Squeak is a bit of a siren song. I've certainly felt that way. Much of Squeak's GUI wasn't built to satisfy commercial developers, but to get some wild, crazy, next generation media playground for kids and adults to experiment with. Very trippy but sometimes frustrating to someone who just wants to build a CRUD GUI.

If you want to build for the web, Squeak is a nice home for Seaside development. I'm currently using Pharo, which is still Squeak to me, but it may diverge in the near future.

Now to get a little pedantic:

Squeak is a Smalltalk. It is written in Squeak Smalltalk^[*]. Visual Works is a Smalltalk. Most of it is also written in Visual Works Smalltalk.

All Smalltalks have little variations. There is no downloadable, runnable thing called Smalltalk proper. You might call Smalltalk-80 Smalltalk proper. Squeak and VisualWorks both descend^[**] from Smalltalk-80. You might also call ANSI Smalltalk proper, but there is no implementation of Smalltalk that is only ANSI Smalltalk.

If you want to write code that you can take from one Smalltalk into another, you're in for a bit of a bumpy ride. The Seaside team probably has the most broad and most current experience here. Looking at the work they are doing for 2.9 (as well as their coding standards) are a good things to emulate.

Squeak and GNU Smalltalk are both open-source. GNU is GPL, natch. Squeak predates the OSI definition of that term and so has a more colorful license history, but it will (soon) be MIT with bits of APSL.

VisualWorks and GemStone are not open-source, but each provides professional commercial support and licenses that make it easy to start exploring and developing. VW is probably the most mainstream, commercial tool. GemStone is the leader for big Object-Oriented DBs.

Instantiations still supports VisualAge Smalltalk (formerly IBM Smalltalk). Also good commercial support.

Lots of other Smalltalks I'm leaving out.

Between Squeak and GNU, Squeak is the more traditional, image-based Smalltalk. GNU keeps its code in files, which makes sense to most non-Smalltalkers. But, as MarkusQ wrote recently:

Trying to get your head around smalltalk without using the IDE is like going to Paris and eating at McDonalds. Sure, you're in Paris, but you aren't really exposing yourself to what it's all about.

Footnotes:

[*] There are a few parts of the Virtual Machine that are written in C, but even those are actually written in a pidgin (reduced) Squeak Smalltalk called Slang. It really is a C subset with Squeak Smalltalk style. The benefit of this is you can simulate the VM using Smalltalk tools as you develop.

[**] and lore has it they may actually both still be running some of the same bits as an ancient Smalltalk image.