The conference is starting today - I've got my talk in a couple of hours. Unlike the chilly drizzle we had yesterday, it's nice out today: I took a picture of the central quad here at Homerton:
Looks like it'll be a good day to teach Smalltalk!
The tutorial I gave this afternoon went fairly well - I had fifteen people and a lot of questions. It was fun to get in front of a group of non-Smalltalkers and show off the system again - and it also reminded me of how long it's been since I was a beginner (the beginner questions they had weren't anything like the beginner questions were back in the 90's, when I taught for ParcPlace. Oh, for anyone interested in what I covered: it was a shorter version of Smalltalk Daily - which you can watch in order here.
I got some more requests from CD's after the session as well, so word of mouth must have been ok :)
After things wrapped up at 7 PM, we headed down to the great room for a Google sponsored dinner:
Joseph Pelrine is here, so I took a picture of him chatting at a table - I also want to thank Joseph for his help during the tutorial today - he sat in and had some helpful and timely suggestions. Thanks!
So now I just have to sit back and enjoy the conference - and there are a number of good sessions that conflict tomorrow. Decisions, decisions...
Technorati Tags: smalltalk
It's the opening session of SPA 2007, here at Homerton College. It's a nice location - I like it better than last year's spot, the Robinson Centre. There are three sessions of interest to me this afternoon after the opening - I'm going to head on over to Joseph's session though, since we are adopting more of a Scrum-type approach to development on the Cincom Smalltalk team. Here's to a good week!
I wanted to exercise, but I couldn't pass up the opportunity to hear Dave Thomas (Smalltalk Dave) give a talk. Dave is having a fun time offering to let us vote on which of his two presentations to give :) Heh - he's skipping the planned talk due to audience demand, and saying only that there are ways to introduce agile techniques into large organizations. Instead, we're going to take a look at where Dave thinks development is going in the next decade and a half.
Since leaving OTI, Dave has founded Bedarra Research Labs - he's looking to be able to do some development again, but current technology fads make him feel like he's had all his limbs hacked off. The problem: we're in an incredible complexity mess due to the badness of the current languages. This has generated a plethora of tools to try and compensate for that, but it only makes for a bigger pile. We have what Dave calls "Latent Technical Complexity".
Open SOurce from OS to Application allow every customer application to be "unique".
Why the latent complexity?
Lessons:
There's a real skills gap: "everyone" knows Java: "Certification is a statement that you aren't competent". If you want to be where the action is, it's in the domain (business) side, not the development side.
MDD: The Ideal. Then there's the OMG (Object Losers Group, heh). way: MDA, or UML all the way down. This gives you development and debugging at the level of the abstraction. Interestingly, UML isn't even fully defined.
Heh - you aren't getting the real flavor of this talk - Dave is a truly funny guy.
The challenges of next generation applications: Business Driven vs. Technology Driven.
Real time business:development in real-time, execution in real time. They have masses of data and event streams. Important point: Processors, memory, bandwidth, and storage are "free" - Amazon ECL and S3, for instance.
So going back to games: Not just the fun stuff of the graphics and physics. You also have data persistence and versioning. You have distributed processing, visual content editors, scripting and compiler technologies, and UI work.
Game updates happen at high speed, they are distributed, and state changes hit multiple other objects. So back to MDD: a natural way of expressing application requirements in a disciplined and well understood "language" which models some aspect of the domain.
We want to work in a high level, domain oriented language - which will allow us to specify the domain more easily. Ideally, the developers would work with a domain (not a software engineer) expert who is versed in computational modeling. This is really about DSL (Steve Kelly!) - Domain Specific Languages.
Back to the future: We want languages that encourage "think and try it" - not ones that favor "design code and test". There are lots of examples of end user programming: Spreadsheets, MatLab, QBE tools, visual languages like ProGraph, DabbleDB, etc. There are lots of important things that aren't being taught anymore:
He listed others - point being, "fad" training is what Universities do now. Language design challenges:
This workshop is going to deal with how we deal with problems on a project - Joseph Pelrine and Ben Fuchs (tech and psychology). More information on this stuff on their website: http://www.cateams.com/index.php. Difficult Behaviors - from minor to bad:
For our purposes, "difficulty" is in the context of the team and the project. We can deal with the team or with the individual.
A nice metaphor for team state - compare to cooking:
Periodically, you have to "turn the heat up", and then let things cool on their own (as the team self organizes). How do you turn the knobs?
Dealing with conflict: Pre-Conventional (Police, Medical staff use these sorts of approaches)
Conventional (most professional situations)
Post-Conventional (teams/inter-personal, for instance)
Constructive conflict requires emotional maturity and an ability to be self reflective. The session included multiple exercises, and I can't really convey those here.
Interesting perspective: We look at things via OIC: Observation, Interpretation, Conclusion - where the latter two come from our own beliefs, biases (etc). Often times, we see things completely differently than the other person intended.
We wrapped up with a group exercise: one of the participants related an actual work problem, in order to generate some feedback. I'm not going to say anything about it, as we all agreed to keep all the people involved anonymous.
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:
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.
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 :)
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:
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.
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 :)
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:
| Next | (13 total) |
|
| Subscribe to WebVelocity |
| Visit this group |
