I've been teaching courses on object-oriented programming and design using Smalltalk since 1985, and some of my students are working as Smalltalk programmers for ParcPlace, Digitalk, OTI, and IBM, plus dozens of other companies that use Smalltalk. I know how to teach people to become Smalltalk experts.
I have a one semester course that I use to train graduate students so that they can work on my Smalltalk-oriented research projects. By the time students finish this course, they can contribute to a project. They know a good design from a bad, they know how to use the classes in the image, and they know good Smalltalk programming habits. They can build new systems from scratch or can work on extending old systems. Although they still have a lot to learn, they have become productive members of the Smalltalk community.
The Smalltalk Summer School is a version of this course that is open to the public. I taught it for the first time in 1995. There were only a few students, but they were all successful. I plan to teach it again in 1996. It was five weeks long last year, but it will be four weeks long this year. It will be a little easier to fit into your schedule, but I expect to achieve just as much.
I will assume that students are programmers and know a little about Smalltalk. There are many good 1-week courses on Smalltalk. If I were to start by teaching the basics of Smalltalk, people who had taken a 1-week course would be bored and there would be less time for more advanced material. The ideal person to take my course has taken a 1-week course and then worked a few months with Smalltalk, which is long enough to be frustrated and to realize that there is a lot more to learn. A person who has read a book or two on Smalltalk and spent a few months trying to teach it to himself would also be prepared. Someone who has worked six months on an existing project under the supervision of an experienced mentor and is just now starting to come up to speed is probably over-qualified. On the other hand, I know people who have been programming in Smalltalk for a year or two and still are not very productive, in large part because they were led down the wrong path in the beginning. They would find the course enlightening. My goal is to get people up to speed, and to get them going in the right direction.
I am planning to teach the course June 3 through June 28 in Urbana. The course will be based on VisualWorks. There will be a limit of 12 students, though if there is enough interest I might consider teaching another session in August. It will be a very intense, lab-oriented course.
The first week will focus on the basic architecture of a Smalltalk program, including GUI design, separating domain models from application models, and an overview of the class library. The second week will focus on designing an application and on translating that design into Smalltalk. This will include modeling an application domain and connecting the model to your databases. The theme of the third week is building frameworks either on top or underneath the user interface, depending on your point of view. We'll use HotDraw and Accounts, two frameworks we've worked on a lot. The theme of the fourth week will be testing, tuning, and packaging.
Another theme of the course is patterns. I teach the kind of patterns that are in the Design Patterns book, as well as patterns of using the standard classes, patterns of rewriting (or refactoring) programs, and system development patterns like prototyping. I work a lot with Kent Beck and will also be using his Smalltalk Best Practices patterns.
I've been using patterns in my teaching for several years, and find that they are very useful. Before I started using patterns, I depended on projects to teach design. Projects are important, of course, but a lot of design knowledge can be taught with patterns. It is easier to measure what a person is learning when you are teaching patterns, and easer to find out when I am not communicating. Using patterns makes teaching more repeatable and predictable.
Different parts of the course will teach different patterns. In the beginning we'll focus on basic analysis and design patterns like Abstract Classes and Composite and the patterns for using the core Smalltalk classes. Later we'll move to patterns that provide the flexibility and reusability that frameworks need, and use them to describe the frameworks we are looking at. In the end we'll focus on patterns that help transform a prototype into an efficient and maintainable system.
Half of each day (and half your nights!) will be spent in the lab with practical hands-on programming projects. The first week we'll work with a payroll system, and you'll see how to extend it and how to refactor it. Then we'll start working on bigger group projects. This year I hope to develop a framework for managing conference papers. It will have a WWW interface (courtesy of VisualWave), an e-mail interface, a reliable database, a simple workflow system, and be customizable to fit a wide range of conferences. Feel free to suggest problems if you'd like to work on a particular topic.
Another theme of the course is frameworks. Frameworks are an important aspect of object-oriented design. Nobody can be a decent Smalltalk programmer unless they know how to use a framework, but it requires much more expertise to design a framework. It is probably unreasonable to expect graduates of this course to be able to design a good framework, though they should know the general steps that they would have to take. It will usually require a year of two of experience before people are ready for that, and some people never seem to acquire the knack. On the other hand, some U of I students were able to design a framework after taking my course, so perhaps it is more a matter of individual ability. In any case, I do not claim that this course will produce good framework designers, but it should produce people who understand what they are and how to use them, who understand the frameworks inside VisualWorks, and who are on the right track to becoming a framework designer.
Although the course will be taught using university facilities, it is not a university course and you will not get university credit for it. This is something I am teaching on my own initiative. I'm acting more as an entrepreneur than as a faculty member, though I have the blessings of the department for this.
Several of my grad students will be helping me with labs, so we will deliver personal attention to everyone in the class. Learning Smalltalk is always an apprenticeship process and requires a fairly small student/teacher ratio. My grad students have been programming in Smalltalk for 2-5 years, and are both good designers and good teachers, so you can be assured that you will be well taken care of. I'll do most of the lecturing.
The course will be four weeks, from June 3 to June 28. There won't be any classes during the weekend, but we will keep the lab open for people who want to stay over the weekend to work. We'll be available to answer questions and work with you. Last year the students worked from 9 a.m. to midnight most days, and at least half time on weekends. They learned a lot. I won't force you to work hard, but I'll certainly encourage it! The best way to learn Smalltalk is to jump right in.
The cost will be $6000 per student, which includes books, materials and lunch, but does not include other living expenses. If you send three or more students then the cost is $5000 per student. Payment is due at the start of the class unless you make other arrangements in advance. Let me know if you need help finding places to stay.
Please contact me if you are interested. E-mail is best. If you call my phone number then you'll probably get my secretary, but tell her that you are interested in the Smalltalk class and I'll call you back.
If you would like to reserve a place, please send me the names of each person taking the course and contact information (address, phone number, e-mail).
Two of my students from last summer, Ron Absher (absher@VNET.IBM.COM) and John McIntosh (johnmci@ibm.net), said they would be happy to give references.
Ralph Johnson -- johnson@cs.uiuc.edu