I should mention the "outputs" of the Smalltalk tutorial that I did last Sunday. The SPA conference (and Ot before it) has always been big on session outputs - the idea being that other people should be able to benefit even if they didn't/couldn't attend the session.

With that in mind, the tutorial page on the Wiki is here.

To summarize the summary :)

• Download Cincom Smalltalk non-commercial here
• Access the Smalltalk Daily screencasts in order
• Access the Smalltalk Daily screencasts by topic
• Subscribe to Smalltalk Daily in your news aggregator

Technorati Tags: smalltalk, tutorial, learning

Another SPA is done - and it was a fun conference. I'll be back next year - it looks like another Smalltalk tutorial is a real possibility. I like the Cambridge location, too - it's nice, and being near a sizeable town has its advantages.

As the show wrapped, we all put up post-its with "what did you learn", or "what did you think" ideas on them - I took a few shots, and no - I didn't add the "Smalltalk" one :) I did like the one in the middle:

It's been a great week!

There was a very good session this morning on scoping, which involved a game to get the idea across. We set up teams of three, and each of us got money, product cards, and feature cards, along with marketing info. Our task - decide which products to ship with which features, given the constraints of reuse vs. one off features (more cost for reuse) and the monetary limit. Here's a picture I took of the board after round 2:

In round one, we didn't spot a way to tradeoff one of our dollars, and decided to ship only 2 of 3 possible products - which is why we tied for second in round two: we were just too far behind after that mistake. It was fun though, and it put the whole product marketing/management decision process "in my face" in a very good way. Food for thought.

Technorati Tags: marketing, development, product%20management

After the sessions wrapped up, we had a champagne tasting event - I don't much care for champagne, but I gave it a whirl. We had five bottles to identify by taste. Since I've already said more than I know about the topic, I got one of each and lined them up:

That didn't help me much, but other people used the lineup to compare:

Later, we retired to the Combination Room (lots of couches and chairs) to while away the evening:

After the API talk and lunch, there was a croquet game set up outside - so I headed out and played two games. It was a lot of fun, and I managed to get a lucky wicket by rolling my ball over another :) Here are two pictures of the Croquet game:

After that diversion, I headed to the Web 2.0 Fishbowl session, as I was part of the initial panel. I took two shots while I was outside the fishbowl:

That was fun - second fishbowl I've done, and I hope not the last :)

I wasn't awake enough to take notes on Brian Marick's keynote, but I should have - it was a great talk. In any event, I'm attending Michael Feather's talk on API design. He's starting with a common problem developers have: say you want to fetch mail in code. You then have to dig through the API documentation (or in VW, the PDF docs) to figure out how to use the mail code. Interestingly enough, raw API doc isn't that useful without accompanying "how to" type doc. IMHO, what you really want in this case is example code - the API documentation doesn't help you initially (although it will help you down the road, when you want to do more. On the Smalltalk side, you then go browse code, but that works just as well - even though it's "politically incorrect" compared to massive API doc :) )

This particular example is of interest to me because I did screencasts on mail sending and receiving just last week - and I didn't have to create a new class just to figure that out. After perusing the example code in ours doc, I just tossed a few lines into a workspace and tried them out. Once I had that down, I just did the screencasts :). Ultimately, you do what I did in BottomFeeder - create a class that wraps mail sending (or receiving), and deal with your own API, and then have a simple place where the underlying vendor API is isolated and easy to manage.

So API Design: The art of creating interfaces that are useful to clients and extensible for future needs. Not all interfaces are APIs.

Unit Tests: They really do need to be isolated (i.e., not dependent on network communication, database results, etc).

API Development is hard work because:

• APIs live forever
• Meaning, Mistakes live forever
• Early choices can close off future desires

Interesting comment next: Avoid Static Methods. I would have said that Sun simply screwed up, and didn't create real objects. If classes in Java were actual objects, this problem wouldn't exist. Heh - he also recommends against using Sealed, Final, and non-virtual. Again, those aren't features - they are bugs.

Here's a good piece of advice: write code that uses your own APIs. If it's too hard for you to use, then what will your clients think? As well - supply your tests to the end users (developers). There's no good reason not to.

Here are a few shots I took during the day. First: Dave Thomas' keynote - and it was a great talk:

Funny dinner story on that - turns out that a lot of people didn't really "get" Dave's talk - those of us in the room who were Smalltalkers, or Ruby-ists (etc) - we spent the entire speech nodding our heads. Very interesting difference in perspectives :)

Here are two pictures from a humorous "panel" that ran this evening - hard to describe, but think of tech/geek word association and Startup send-ups:

I really do like this conference - it's a great bunch of people :)

It's been a good day at SPA 2007 - I attended a Creativity workshop this morning, which was pretty neat. The idea was this: we got a problem statement, and then we did some brainstorming exercises to either find solutions or better understand the problem. Our group had a "Lotus Blosson" exercise:

• Toss out an idea
• Find eight related ideas and ring them around it
• Then pick one or more of those, put them out, and repeat

We didn't find solutions, but we iterated towards understanding the problem. Here's a shot of one of the other groups, using lots of paper on another approach:

Earlier, we had a little exercise that went like this: Statements on a board, handouts with other statements. Find the ones that are "opposite" and tack them up:

So that was a fun session - I might well try some of the ideas out at work.