Smalltalk Tidbits, Industry Rants

Scoble points to this piece examining open source motivations:

I think the "gift economy" and "peer respect" aspects are often overemphasized as reasons for programmers to contribute to open source projects. Most people contribute fixes and new features for selfish reasons: They're using the program and have fixed bugs or implemented new features that they need in their own daily use of the system, whether they use it at home or for business purposes. I remember Linus saying at one time that now he wanted to concentrate his own work on power-saving features for the Linux kernel, because he just got a new laptop and felt that the battery time needed improvement.

Pretty much the size of it, IMHO. People will do all sorts of work without formal compensation - but that will be stuff they want to do, and - in general - won't include 'finishing touches' type work. Think about it - how many unfunded open source efforts come with reasonable documentation? Or a decent GUI? Or a set of configuration files you can figure out? The 'grunt work' that no one wants to do doesn't typically get done unless someone is funding it.

Ted Leung posts on a BOF at OSCON. the BOF - Dynamic Language support in the MS CLR - apparently, with members of the MS CLR team. That's really good news! Sun has been utterly ignoring this space for years now, since they want to see all Java, all the time - us Smalltalk folks have to take the goodness where we see it.

Oracle hires military adviser.

Today's spotlight is on Travis Grigg's VW fonts talk:

Fun with (VisualWorks) Fonts presentation Travis Griggs: Key Technologies Monday 8:30:00 am to 9:30:00 am

Overview: VisualWorks fonts are not the most understood of things. Many VW programmers pass up the opportunity to make their applications look nicer than they could, because they little understand the fonts. Recently, frustrated with merging font hacks for PDP, super/sub-script support, and the RB Code Highlighter, I implemented the ExtraEmphases framework. This presentation will cover why and how that was implemented, as well as how to use and extend it. Hopefully, along the way, we can provide a better understanding about how the basic font system works.

Bio: Travis works for Key Technology, figuring out how to sort the world's food (among other things). He's worked with Smalltalk (mostly, but not entirely VisualWorks) since 1991. His work in that domain ranges from embedded programming to high level user interface design. Before coming to Key Technology, he worked at Siemens Power Corp writing nuclear fuel design automation software in Smalltalk. When not hacking for Key, he does his best to contribute to various open source projects, some in Smalltalk, some not.

Smalltalk Solutions 2003 is rapidly approaching - I plan to take notes and blog the various talks - both formal and informal - that I attend. Anyone interested in having their notes posted can send them to me - I'll give credit and post the notes here. It should be a great conference.

Sun really makes me wonder. They say they want to increase the number of Java developers from 3 million to 10 million - left unstated is how this would actually help Sun's bottom line. Sun seems to be trapped in one of those cycles that some companies get into. I saw this at PPD - the management there between 1997 and 1999 had decided that Java and Java tools were where all the money was - even when they heard things like this from customers (Smalltalk) and prospects:

If I buy Java tools, why would I buy them from you?

Sun is stuck in the same place. They make all their money from Solaris on sparc - Java server installations can run equally well on Solaris and Linux - (or Windows, for that matter) - and here was Sun's CTO on that topic:

Linux, and Linux on the x86 architecture in particular, will make inroads into the Windows market. With the ability to run several different flavors of Unix on an inexpensive x86 system, the option to run the prohibitively expensive Windows platform becomes significantly less attractive. We believe we'll see this transition happen slowly, as companies realize that the availability of Unix on x86 means they can get an easier-to-manage system with better uptime and performance than was previously available.

Apparently, Sun's CTO hasn't noticed that server installations of both Linux and Windows are increasing - Linux is taking a far, far bigger bite out of proprietary Unix than of Windows, at least at this point. The transition from a Unix server to a Linux server is far, far easier than the transition from a Windows server to a Linux server is.

So what's Sun's answer to all this? More spending on free Java tools (Rave). Yeah, there's a plan. Anything sun does with Rave will exist on Eclipse, either before it gets to Rave, or shortly thereafter. And in the tools space, Eclipse has all the buzz - there's even an Eclipse for Smalltalkers talk at Smalltalk Solutions 2003! Want to bet on there ever being such a thing for Rave? Then there's buzz like this.

My guess is that Rave will be every bit as successful as NetBeans. The only question is how long it will take Sun to figure it all out. When PPD got infected by C level cluelessness, it stayed on that path until bankruptcy. Unless McNealy goes, I think the same will happen to Sun.

A few weeks ago, IE started always launching new windows on links. Since I almost always launch browsers from BottomFeeder, I first thought it was a bug in Bf. I did some investigation, and found out that it happened regardless of how I hit an URL. I hadn't purposely reset any options in IE, and under Tools - Internet Options - Advanced there are a bazillion options. eventually, I noticed that reuse windows for launching shortcuts was unset. Ok, setting that fixed the problem - back to the way I wanted the damn thing to work.

Things were fine for awhile, and then suddenly two days ago, the same thing started happening. I had fortgotten what option it was, so it took some careful browsing of the various options to remember - but there it was, unset again. Well frell - how did that happen? Anyone know how or why IE just up and decides to turn that option off?

James Copelien has a new blog - and today's post on teaching OO is well worth reading.

After I posted on my IE weirdness problems, one of my readers sent me an email suggesting spyware as a potential culprit. I really need to re-up my norton subscription, but in the meantime, I ran ad-aware (highly recommended!) found 30 different things hanging around my system. Cleaned them out, and we'll see how it goes. Thanks Rick!

If you wanted to go to OSCON, but couldn't make it - start reading Ted Leung's blog here and keep going. Ted also points to the OSCON Wiki

Wired points out the inevitable problems caused by working when everyone else is asleep. I've seen articles on the health problems third shifters have, so this is not a terribly huge surprise. There's never a free lunch...

I've got some nasty travel stories, but this one from the Ken Coar is in a league of its own. You couldn't write fiction like this...

Ted Leung expresses an issue with Ruby and Smalltalk:

Looks like I'm going to end up looking at Ruby after all. My issue with Ruby (and Smalltalk) is that I don't think that I buy that everything needs to be an object.

I can't say that this has ever looked like a problem to me - and I've seen plenty of code that made no such assumptions ;). In cases where a real object model doesn't seem to make sense, you can always just use a class and just write class methods - but again, I don't know how often that need would come up.

As I mentioned yesterday, Ted's blog has a good set of entries on OSCON. There's more new posts on the show up today.

They both seem to like the SCO dustup - Sun just bought more licenses and an option to invest. Feh - a pox on both their houses!

Via Clarence Westberg:

One thing I have learned from aggregators, it is amazing how we can shape what we percieve the news to be based on what we look for. Makes you think about who the aggregators are for the real news media.

Makes you think - about all of our tendencies to reinforce our own biases.

I added a new feature to BottomFeeder a few days ago - when you select an item, you can spawn an email based on that item. At first, I was just spinning up an internal Bf mail tool. A few people asked me about providing access to the default mail client on Windows - only I had no idea how to prefill fields like the subject and body. After some more abuse on that topic, I went and googled for mailto: - and realized that all the support I needed was already part of the way things work. So now, when you see an item you are interested in - just send it along using the built in support.

Angelika Langer laments the lack of revolutionary languages:

The industry is spinning in circles inventing one "curly brace" language after another - C++, Java, C#, ... The popular object-oriented programming languages of today fatally remind us of the heyday of procedural languages: in the 60ies, a cluster of very similar languages (Fortran, PL/I, COBOL, Algol) dominated the IT business, until the advent of C changed the world. Finally, a language invented by programmers for programmers! C was a revolution; Java and C# are just evolution. Where is the C language of our times?

lol. We already have plenty of candidates - Smalltalk, Lisp, Python, Ruby - the issue is that IT shops and developers are blinkered into a curly braces world view, mostly unable or unwilling to venture out and look at something different. People like Bob Martin have been talking up dynamic languages - all we need is for more people to get interested. Go read the rest of the article - it's an interesting lament. Someone tell Angelika that Smalltalk and Lisp are still kicking, and that Python and Ruby are out there.

From Dennis Smith of Cherniak Software:

I would like to invite all Gemstone users and those interested in gemstone to "an open session on gemstone solutions" Monday July 14th at 4:00pm, at the Smalltalk Solutions 2003 conference. This session will be introduced by a very short presentation on a couple of our "solutions" and will then be opened up to attendees to talk about their use of gemstone, and any problems or solutions they would like to mention. There will be others attending who will be able to discuss problems and ideas. This is also an excellent forum for making contacts which will be of value on an ongoing basis. This should be of interest to gemstone users at any level from novice to advanced. We had such a session two years ago held by James Foster, and it was one of the more useful sessions of the conference.

So if you are using Gemstone, or considering it - check this out

So I'm out at a lunch place with my wife this afternoon - we bought a mocha and a latte, and sat down. Then they tell us, "Sorry, the machine's down. Is regular coffee ok?". I said sure, but asked for a refund of the difference. That's where the trouble started. The clerk stands at the register and looks baffled - he has no idea how to even approach the problem. A girl comes over and tells him to subtract $3.17 from $7.00. He writes the numbers down, buts stops - he has no idea how to actually subtract them. The girl looks at the numbers, realizes that the subtraction involves carrying, and gets baffled. They both look at me for help. Sigh. I tell them to give me $3.83. They are relieved that someone knew the answer, and gave me my change.

Here's the real question - if I had made a mistake, or given them the wrong answer purposely, would they have noticed? I was just stunned - not so much by the inability to do the problem mentally - neither of them could do it on paper!. What are they teaching in schools these days anyway?

Today's spotlight is on Don MacQueen's JWARS Tuning talk:

JWARS performance tuning presentation Donald MacQueen: JWARS Tuesday 3:00:00 pm to 3:30:00 pm

Abstract: JWARS (the Joint Warfare System) is a simulation, written in VisualAge Smalltalk, that models theater level warfare. One of its primary requirements is that the model run 1000:1; that is, a 100 day campaign (2400 hours) must run in 2.4 hours.

This presentation will discuss how we improved JWARS runtime from 133:1 to over 1500:1 by using the profiler, experimenting with settings for old space, and taking care not to overtax the garbage collector.

Bio: Donald MacQueen has been a jWarrior since 1997. He recently added sonobuoy modelling to JWARS for the US Navy. His love affair with Smalltalk began in 1992 when he was toiling in the C++ salt mines, and it's been sunshine and blue skies ever since.

According to star Edward James Olmos, the new miniseries - probably the start of a new series - will not stick to the storylines of the original series. In fact, it looks like they are going to restart from the beginning. There's no way that could be bad :)

I've posted a few times now (try this site search) - as you can see, I'm skeptical about the motivations, and cynical about the benefits. Had they stuck to:

• Providing a standard posting format
• Coming up with a best practices document for RSS

we might have seen something useful. Instead, what we have now is a format that has (other than a couple of pointless tags, like subtitle and contributors) all the functionality of RSS 0.91. Soon, this effort will spawn modules that look astonishingly like RSS modules, but with different tag names.

Think about this from two standpoints - one, the end user of a news aggregator. Does necho provide said user any benefit over RSS? The sad truth is, no, it doesn't. In fact, it provides a user experience that looks a lot like an RSS 0.91 feed. Two, how does this affect aggregator authors? It's another format (and, if I'm correct, another set of modules) to support. Does it relieve us of the burden of supporting RSS? No, it doesn't. Does it gives us, as aggregator authors, any information we currently don't have that we could make use of for the end user? No, it doesn't. So, as Mark Bernstein so eloquently put it, this is an unfunded mandate for developers.

I'm sure the necho folks are having a good time; it's always fun to invent something new - even when the new thing has no real point (just find a software engineer and ask if you don't believe me - in particular, find a Lisp or Smalltalk or Java guy and ask them why everything has to exist in native (insert language here)). Looking at this from the outside, it seems to mostly be politics driven. A lot of people either don't like Dave Winer, or think he's too hard to work with. Having read a lot of his posts, I can say that sure, he's posted some childish things. On the other hand, Sam Ruby can be an uninformed jerk as well (read the first comment, and Mark Pilgrim seems to be obsessed with Dave Winer. In other words, this is a bunch of pots calling the kettles black. The lot of them need to grow up and share their toys.

It seems I'm hardly the only one that has a few issues with all this. Have a look at Mike over at Sax.net - here and here. All pretty good points, IMHO. In the end, I'm supporting necho - BottomFeeder parses it, and my blog has a necho feed and a necho comment feed. Right from those examples you can see how much less functional necho is - no way to advertise a comment API. No way to advertise trackback and pingback API's. etc.

In the end, it's mostly just too bad that all this effort is going into necho. That energy could have been directed into something useful. Instead, it's directed into unfunded (and pointless) mandates. I guess in that respect, it's like a lot of the rest of the software industry...

This paper says they do. Nothing is left unskewered; see this passage:

Some languages, such as Smalltalk and its object-oriented followers, present us with a deluge of classes. It is easier to drown than to swim. Smalltalk itself is simple and elegant. Using it in a practical environment is complex and messy. And, as is usual these days, there is a dearth of documentation. The IDEs for languages such as Smalltalk and Java are conventional GUIs, with their inhumane over-reliance on the mouse. None of this is necessary. It is merely customary.

I will definitely agree with the mousing problems. I think the Refactoring browser obviates some of the other issues, but the over-reliance on the mouse is a real problem. VW has gotten better in terms of having keyboard shortcuts - now it needs to get better in terms of making them consistent.

Only two days until StS 2003 - go register now!. Today's spotlight is on Giorgio Ferraris' persistence talk:

HOP: Multidialect Object Persistency framework presentation Giorgio Ferraris: Elevensoft Wednesday 10:30:00 am to 12:00:00 pm

Abstract: HOP is a persistency framework for various smalltalk dialects (VW, VSE, Dolphin, VA) with a high level of functionality. The framework's development started in the early '90s, and now it's used in hundreds of applications at several customer sites. We are now releasing a free, non commercial version, so this presentation will be a tutorial on the framework's use.

The presentation, with the help of some PowerPoint slide, will demonstrate the use of HOP in the development of a small application, with the definition of classes and the corresponding relational infrastructure for the persistency of objects. To demonstrate the feature of the framework, a small business model based on an Order will be defined.

To demonstrate the data base independence of the resulting structure, a MySql and a Dbase or SQLServer relational data base will be used for persistency.

Bio: Giorgio Ferraris is a chemical engineer totally devoted to software. After years of work as a software free-lance consultant he co-founded, 15 years ago, Eleven srl, a small (20 people) Italian firm developing turn-key software solutions.

He started using Smalltalk more than 15 year ago (Smalltalk/V). He began following the international community first using Compuserve and the Digitalk forum, then participating in Smalltalk and OO related user conferences, starting from the Digitalk one, to SmalltalkSolution and OOPSLA.

He has been involved on OO analysis, design and architecture definition for 10's of customers (from small to medium to large). He follows his company's internal projects like lead technical mentor.

He has held several tutorials on OO, Smalltalk, OO analysis and design for 100's of Italian people and has worked as a mentor and supervisor on several OO projects. He is currently working as a mentor on several OO projects in Italy (Smalltalk, Java and C#), and following a big customer on his evaluation of Smalltalk as his possible next development language of choice.

Mark Pilgrim shows that he can be as whiny and immature as he accuses Dave Winer of being. Half of this is politics, and the other half is sheer silliness. There's precious little technical merit anywhere around it....

Keith Ray discusses them here:

Sometimes you have lots of cohesive classes, but they depend on each other in a tangle... it is particularly nasty if the tangle has cyclic dependencies. Robert Martin's tool for untangling dependent classes is the Dependancy Inversion Principle [pdf]. Classes are cohesive and independent if you only have to change one class when you want to change one thing.

An aside: Of course, with manifestly-typed languages like Java, changing one thing (like changing coordinate values from ints to floats) could bubble up and across many classes purely for keeping the compiler happy. Advocates of dynamically-typed languages say that manifestly-typed languages promote leaky abstractions because of this need to keep the compiler happy.

The leaky abstractions reference comes from Joel on Software. I've seen (and written!) plenty of overly coupled software in Smalltalk. However, I think the decoupling process is far easier when you have a dynamic language than when you have a static one. The need to keep the compiler happy is a much stronger force for inertia; it encourages people to just "leave well enough alone". In software maintenance, that's not necessarily what we want.

Scoble talks about self censorship and corporate blogging. I can definitely identify with the thrust of that article. Cincom is a much smaller outfit than MS - but as a remote employee, I have only the smallest sense of all corporate activities as well. I live pretty much in the Smalltalk bubble here, and I interact with the other Smalltalk folks - or with corporate folks who are dealing with us Smalltalkers (and a rowdy little bunch we are, too!). I avoid certain topics here - politics especially! - since I'm on a Cincom server. The way I figure it, people coming to read what I'm saying don't care to know what I think about US or International politics - IT industry politics, on the other hand, are fair game (and arguably, part of my job). For that reason, the policing I do is less than what Scoble is talking about - there's nothing secret about Smalltalk release strategy (compared, say, to MS Longhorn strategy). Nevertheless, it's there.

Scoble talks about Windows bugs:

Jeff Key asks why Windows still has so many nagging bugs that don't get fixed.

That's a tough question to answer. Why? Because every bug has a different story about why it's in there.

And, believe me, every bug does have a story. Fixing code isn't easy and don't think that Open Source would fix the issues any better than Microsoft's own developers can (they might fix bugs better, but then you'd have other interesting problems that you didn't consider before -- for instance, training costs. 100 million people have existing Windows. What happens if you throw a new version of the operating system out there every week? Does that cause problems that you didn't forsee?).

I don't think this has anything to do with Open Source, closed source, or unforeseen consequences - at least not for the most part. While our Smalltalk products have much, much smaller codebases, most of our unadressed bugs come down to resource allocation issues - given this bug over here, and the need for that new feature over there, we have to balance the engineering resources against the perceived needs of customers. That's difficult, since our perceptions don't necessarily match the big picture perfectly - and to the person or team suffering from a given bug, our focus can look completely wrong. My guess is that MS has much the same problem. Sure, their resource base is much bigger - but at a certain point, adding people to a development team just makes things worse, not better. Here's how Scoble puts it:

Some bugs get put off until the future, too, because it means changing something underlying everything, which means that that code would need to go through massive testing. Or, because everyone knows that there's a new product or technology coming that'd fix the issue. My educated guess is that this is the case with the file-names-that-start-with-periods problem that Jeff answers (Longhorn will come with a technology that should fix this problem, for instance).

There are UI issues in VW (take the Dataset, please!) that have this problem. Pollock is the fix for that and a raft of other UI issues - which means that, in the meantime - users of VW have to suffer with what we have. Every development team faces a variation on this theme. The part that torques people off is when - because of changed circumstances - the fix you've been touting for quite awhile never comes to pass. Maybe there was a strategy change, or the market moved - but either way, the new project that would "fix all problems" never comes to pass, and the users are left with the same unaddressed bugs. In my experience, many of these changes are for reasons that really irritate users (The PPD merger killed Van Gogh, for instance) - but at the time they made sense to the parties involved in the decision making process.

The bottom line is, it's almost never as simple as just drop other things and fix the blasted bug!.

I finally got tired of the oddly changing font problem in the blog - the one where the first paragraph was one size, while the next paragraph was a smaller font. I removed the style sheet for a few hours, but I was very unhappy with that result - so I looked at the style sheet in more detail. At some point in my mostly uninformed editing, I had left an extra, duplicated line in one of the descriptions - and that was causing some of the problem. I still have to get it properly done though. Sometime, I really have to read up on style sheets....

This is the last plug before the show - so I'll use the time to plug my own talk on blogs and RSS:

WebLog and associated tools presentation James Robertson: Cincom Wednesday 2:45:00 pm to 3:30:00 pm

Abstract: James Robertson, Product Manager for Cincom Smalltalk, will talk about Blogs, RSS, and news aggregators. Over the last two years, blogs have exploded as a new communications mechanism. While most of the well known ones are political in nature (cf InstaPundit) - there are a large number of blogs oriented towards a wide variety of topics. The Groove project has a blog devoted to the progress of that project. This is an area that should be of interest to project managers - blogs are an excellent way to spread information on your project - both publically and internally.

Over the course of the last year, I've run a blog, devoted to discussing IT industry trends, with an eye on Smalltalk. I'll discuss the technical issues involved in implementing the blog, and the connections that have flowed out of it via RSS and news aggregation. This will involve some discussion of BottomFeeder - an open source RSS News aggregator.

Check it out - Seaside for VW has been published to the public Store - fire up VW and check out the Seaside bundle!

I couldn't find any stray wireless signal, so it looks like my event blogging will all be done offline. I'm heading down to StS in a few minutes - expect a batch of new items when you see them :)

Travis Griggs talks about fonts in VisualWorks, and the problems/limitations. This talk will stick to the emphasis level - not the lower level stuff. First, you have to understand Text and runs.

• DisplayScanner scans each run looking for changes
• DefaultFontDescription is copied and modified
• FontDescription - flat data structure used for finding the font to match the font policy, and renders the font for the subrange of this text.

So - 2 layers of fonts - the raw character glyphs provided by the OS. They are finite. They have to be matched to what you ask for. Second layer is Glyph decorations (SyntheticFont in VW). It wraps a DeviceFont. Not finite - can have decorations added.

To add new descriptions - patch CharacterAttributes, #newWithDefaultAttributes. Add new attributes to FontDescription and SyntheticFont.

There are lots of people mucking ariound here - PDP (Breakpoint glyphs), RB (code highlighting). What this means is that everyone who wants to change things hacks CharacterAttributes #newWithDefaultAttributes. The conflicting patches to the various requisite classes simply cannot co-exist (similar to the old problem with adding launcher menu items).

Solution - new framework, Extra Emphases in the Public Store. If you hack it, save early, save often! Only patches the base system in 2 places. Obsoletes SyntheticFont. Adds a class side registry to CharacterAttributes so that multiple changes by multiple people are possible.

Adds a new class - DecoratedFont - one subclass per font description. Each font encapsulates its own wrapping logic. The subclasses of DecoratedFont are similar to the UI wrappers - each is added to make its own changes to the base DeviceFont.

ExtraEmphases adds: ColoredFont, Underline, Strikeout, JaggedEdge, SuperScript, SubScript, TrailingInsert, LeadingInsert, Substitute, BackColor.

Now Travis is going to bail from the slides and add one of these as a demo. He's got a few scripted up, so we can see how this is done when you want to extend things. Let's see how one adds Blinking Text. In the DecoratedFont subclass, there are 3 methods you need to implement - a fourth, if you are in composite text land. Have to add two extensions to FontDescription.

Are you Agile or Fragile?

The traditional view of Agile. Funny tidbit - this is "Baghdad Bob's" view of Agile methods.

• No documentation, don't model, all hacking, no design/architecture, no planning - then refactor.
• Cannot produce large systems, produces unmaintainable system, does not consider enterprise systems

Key point - Design and Architecture is so important that we do it every day - as opposed to traditional development, where it happens once, in advance.

Assertion - a team together for a few months doing actual XP will produce a system faster and with fewer bugs than a Sigma 6 CMM level 5 team. Scott's extremely confident about this. Another - CMM and 6 Sigma (as implemented) are bureaucratic, process driven systems. Again, Scott shows a picture of "Baghdad Bob" with this. Standish group "Chaos Report" - failure rate is getting worse - 65% of projects fail (cancelled, or significant cost overruns).

What is Agile? It's focused on the actual development of software - as opposed to the current setup, where much of IT management has never (or not recently) built any software. Agile is people focused - on the end users and the developers both.

Individuals and Interactions	over	Processes and Tools
Working Software	over	Comprehensive Documentation
Customer Collaboration	over	Contract Negotiation
Responding to Change	over	Following a Plan

"If the lawyers are doing anything more than fetching me coffee, I'm doing something wrong"

"If we can't get the design of a living room done in one pass, what makes us think we can do it for a complex software system in one pass?

"Being able to respond to a late set of requirements can be a competitive advantage"

What Agile is not

• Code and Fix
• An excuse not to document
• An excuse not to model
• An excuse to short-change quality
• An excuse to ignore enterprise concerns

Assertion - One of the reasons that outsourcing is gaining popularity - if it's going to be failing this much, it might as well be cheaper. The business community is giving up on us. A shakeout is happening - the expensive developers have already shaken out (dot com blowup). The bureaucrats will be next. Agile is trying to take back the eindustry.

Scot is now going through the various agile methods:

• XP: http://www.extremeprogramming.org or http://www.xprogramming.com
• SCRUM: http://controlchaos.com. SCRUM can be used in conjunction with XP, since it does not define a development metaphor. SCRUM works through 30 day (N day) sprints towards a set of requirements - typically the highest priority ones. The issue - since the number of sprints are not defined up front, upfront budgets are hard - does not meet senior management's expectations
• DSDM: http://www.dsdm.org - "heaviest" Agile method. Scott - RAD done right
• Feature Driven Development - http://www.featuredrivendevelopment.com - much like XP, features instead of XP. Does worry about a domain model up front. Modeling more explicit than XP
• The Crystal Family - http://www.crystalmethodologies.org - "Process is secondary to people and communication, therefore it should be barely sufficient
• "Agile Unified Process" http://www.enterpriseunifiedprocess.info - Sort of agile with RUP, because RUP speaks well to management. Interesting anecdote - Apply "Blockers" to a heavy process - people who produce the docs management wants, while the rest of the team does XP
• Agile Modeling http://www.agilemodeling.com - Some modeling up front, but not a lot - need to prove the models work
• Test Driven Development http://www.agiledata.org/essays/tdd.htm - just covers development. Can be part of something else (like XP, for instance).
• Agile Data Method http://www.agiledata.org - Get the IT, operations, QA (etc) folks working together.

"All methodologies have risks - which ones are you willing to live with, based on the proclivities of your organization?"

"Why does all this stuff work?" - We focus on quality, requirements, and design every day.

"We shorten the feedback loop whenever we can, because working without feedback is incredibly dangerous" - assertion - outsourcing lengthens the feedback loop, which will end up causing large problems.

"Software Development is a Communication Game" - Alistair Cockburn

Rethinking "Sacred Cows"

• Reviews are a process smell. The "heroic, genius" developer is the worst person on the project. They will eventually burn you, when they leave and the code left behind is incomprehensible
• Stakeholders, not developers, should decide what documentation is needed
• The vast majority of models should be discarded
• The best modeling tools are simple, inclusive ones
• An "IT Professional" that doesn't code is like an accountant that doesn't know how to work with spreadsheets

Observations The people associated with the Agile Alliance build software for a living - they are not academics. It's a diverse range of people with ha good level of experience. There are case studies and experience reports now. It's here to stay. Agile is now (with business people) where objects were in 1990 (adoption curve wise).

More information - join the Agile Modeling mailing list and the Agile Data mailing list

Almost all of the agile folks are or were Smalltalkers. "Choose the Red Pill"

Questions "How do we sell this to management?" - tough. Management is frustrated with the failure rates as well, but does not know how to fix it. From their perspective, this is one more fad with one more set of developers pushing it. Will likely require a pilot project after finding someone willing to take a risk on it. Likely after one or more spectacular failures. "If Agility is where objects were in 1990, then in 10 years will we see a dumbed down, broken version of it?" - Likely, yes

Monday, noon - a bunch of us gathered for a Store BOF while the rest of the conference enjoys lunch. Good set of questions, comments, and conversations. Let's see what I can jot down:

• Issues (Terry Raymond/SOOPS) - Automated Builds, Merging, need lineups
• Moving Classes between packages - sometimes confuses Store?
• Renaming clases after a move (above) - ditto
• Change Event for add/remove instance variables
• Overrides within Bundles - we deferred this, but it's a huge point of contention
• Specifying pre-reqs - very ugly. Have to type in the names
• Difference loading is much slower than loading clean? I'm (personally) not sure on that, but many people concurred. It's a large problem over high latency links
• preload/postload (etc) blocks - should be methods, not just strings.
• Clean up the UI silliness - menus that differ between tools, tools that don't make a lot of sense, etc.
• Unchanged methods should not cause add/remove doits to show up.
• Replicator: To do - get the Store replicator into the base. If you use the replicator, push from the slowest (network) to the fastest system. It would be nice to be able to preserve user names across a replication
• Merge tool: Alan - "The merge tool stinks". Trying to do more than a 2 way merge is a bad idea.
• Niall would like to see some success/failure stories for Store usage, so he can see what development patterns work and don't work.
• Keywords would be a nice thing for searches
• Diana Merry-Shapiro has a nice method history tool that can show the sources of all methods - i.e., where they come from, etc (which Store DB, the change file, which parcel, etc.)
• Schema of the DB - Optimizing the db is in process during this release. we would prefer not to break backwards compatibility. Bruce Badger suggests doing a whole new tool?
• Martin McClure (Gemstone) - would like to see an object model so that Gemstone could be a back end. Terry agrees, and would like to see a fuill ST server on the far end, not just a db. A server back end could improve high latency connections. Policies could be server based (easier to share). Could make change notification easier (note that we have RSS). Extends benefits of no client db libs to non-Postgres users.
• Properties should be stored binary (BOSS)
• DB specific optimizations should be more accessible, even if they are not integrated by Cincom Engineering. Issue - they need testing and verification before we bless them
• Package Comments are not easily visible past the specific version in which they were published. This makes large repositories (like the public store) hard to view and use.
• Doc for newbies? There's Alan's presentation from StS 2002. There's the Store docs. Cincom Wiki Store notes.
• Cees de Groot published a lineup tool for Store in the public Store. TOIStoreExtensions
• Travis comments that new information on Store (as opposed to, say, Pollock) is not forthcoming. Can we get more and better information out?
• Automating Builds - everyone builds their own - we should provide something. Headless, scriptable Store? Very hard now. The Store connection dialog should not come up on start, ever.
• Bundles - One should be able to delete bundles as easily as packages
• Ease of Use for neophytes - the base development image should be easier to get going with Store. Get the base Store image to have the read-only connection to the public store pre-set
• Atomic Source Load

Eric Clayberg and John O'Keefe gave this talk. Starts with a brief overview of Eclipse. Eclipse is an integration platform built in Java. Number of services, etc. Platform services, Common Frameworks (SWT, for instance).

User's Perspective - Looks like a native app, since it uses SWT (similar to Common Widgets in VAST). Eclipse is a "state of the art" IDE for any language. Feature by feature comparision shows that Eclipse is good, probably better than most IDE's - not as full featured as most Smalltalks, although it's likely snazzier looking with better polish (there's a large Eclipse dev team). One of the new things Java people are excited about is "hot code replacement" (in the debugger).

Extending Eclipse is limited to the plugin points and the reflective capabilities of the environment. Eclipse does make deployment easier than it is in Smalltalk. The UI is a classic "C" style multi-paned, single window environment. The IDE type of features exposed to a developer are better in Smalltalk, with the exception of "Code Assist" type tools, aided by the manifest typing.

Eclipse now has decent refactoring capabilities, not as extensive or as scriptable as the RB in VW or VA. One can add more, via plugins. By default, no method categories. There are options via plugins. Many, many people creating plugins.

Developer's View There are a number of layers with extension (plugin) points for adding new/improved tools. The weaknesses are all due to Java language restrictions. The architecture is based on layered, dependent plugins. Isolation for plugins is better in Eclipse (although, namespaces in VW help here, a lot). Experimentation is a lot more restricted due to the structured nature of plugins.

Plugins - written in Java, integrated via XML (describes the plugin, etc.). Eric lists some of the workbench extension points - there are a lot of them. Question in my mind - yes, the plugins provide better idolation - but at the same time, they limit what you can actually do. If the original designers didn't envision it as a possibility, how limited are you?

Now a Demo of Eclipse VisualStudio style - tree views of packages - newer view offers a Smalltalk style 4 pane browser view. Instead of method categories, some kind of Type split.

Now onto John O'Keefe and the Eclipse for Smalltalk part of the show. First, he addresses the obvious question - Why are they doing this. Indeed, from my perspective, why aren't they improving VAST instead? I guess they get more developers this way, but.... Assertion - Smalltalk too closed a space, too introspective. There's truth in that. However, I'm not sure that getting commonality this way is the best path. Anyway....

The idea: Leverage the Eclipse environment (and the huge amount of work that has gone into it). Accomodate existing Smalltalk applications in. Use Smalltalk within Eclipse. I see a red flag there - if this works, VAST as an independent environment will be sunsetted. No, they didn't say that, but I read it that way.

Ahh, there we go. Second point here - choose WSAD over .NET. The enemy is Microsoft :) The plan, provide one IDE for everyone (note - monocultures are not good, IMHO). A partially unstated desire - it's a way to migrate the existing smalltalk base - VA and otherwise - over to this environment. What is it?

A "technical preview"

• STDT - Eclipse Smalltalk Development Tools
• STCL - Smalltalk Class Library (part of VA class lib)
• STRT - Smalltalk Runtime Support

STDT - Another plugin for Eclipse. Nothing "unique" about this from the Eclipse standpoint. Interesting that there's no actual Smalltalk innovation here - no namespaces, for instance. File based Smalltalk source - source versioning with whatever Eclipse is hooked to. Provides a debugger, intent is to be Smalltalk neutral. Interesting, but VW has moved along - namespaces, shared variables, etc. Would likely take a fair bit of work to get that in - how much sharing with what IBM has done would be possible? I don't know; I'm sure that some of the VW engineers will eventually comment on that aspect.

What it has now - Package Explorer View, Editor. Search support - all based on underlying Eclipse code. Debugger is basic at this point.

STCL Initial release mirrors ENVY Smalltalk closely.

• Application - Project
• SubApp - Package
• Application lifecycle (#loaded, etc) - same
• Pragma methods for pools are now Pool Definition files

STRT Command line Smalltalk. Compiler, runtime with dynamic class loading. Image is used as a performance enhancer. Not released through Eclipse.org - this part will not be open source. Proprietary VM, free download. Windows (possibly Linux) only at start

What's missing? Envy Manager meta-data. Categories. App/Class/Method comments and notes. IC's.

Whew. It's got some interesting ideas - could provide a scripting alternative to S# with the command line compiler. Not sure that the IDE is a step forward for Smalltalkers - it may well allow greater access to people who don't know Smalltalk though, since it will look a lot more familiar. Ack! The source format is Smalltalk chunk format. That will be fun to edit. They will cover that from the user and offer method level editing. They will not support SIF, will likely do XML.

Platform speceific code? A bit crufty in VAST - had to use an additional tool. In the Eclipse env, that is no longer a problem.

A Demo - running an app from the env. You can customize the launch from within Eclipse. Launches a VM and Image, loading the code. When you resave a method, it does hot-load the new code into a running version of it. It's an extension to his demo at present, but will be a core feature eventually. Now we get a look at the debugger. Clearly a work in progress - no inspector yet. much further along than at OOPSLA 2002 though.

STDT - what's next? Will create JAR like files for packaging Smalltalk code collections. Will add method at a time editing. Will add a Class Hierarchy Browser. Will add wizards for - source folder, package, class creation. The greatest benefit out of this effort will likely be the creation of a Smalltalk runtime environment for VA. Will add a JNI bridge. Debugger will be improved greatly. Support for "halt".

STCL - what's next Additional apps ported from VA - SST in particular. Will rework lifecycle, expand the API for dynamic loading. Will rework catalog files, will move NLS to pools. Will reorganize projects into config map like scheme. This is going to cause as much of a migration issue for VAST users (ENVY to CVS style and new tools) as the move from VW ENVY to Store has. Will add scripting support:

• stdin/out/err
• synch and asynch exec
• unix shell and WSH startup
• Compile and Go support

STRT - what's next Dynamic loading from JARs, saving of the class cache, performance tuning, more platforms (Linux, zOS)

So in summary - John wants to remind everyone that this is early dev days for this - it's at technology preview level, not beta (or even alpha!). Everything is in flux, so things stated in the talk may not go forward as planned now. He's interested in feedback, wants to know if the VA customers (and others) see value in all this.

Questions Vendor Neutral? How would that work? They would like to work with other ST vendors - like us, for instance :) - and see if there's shared interest in this. Licensing - the libraries will be open source (as will be the IDE plugins). The VM will be a free download, but will not be open source. It will be available under goodie style license restrictions - binary style license. Other Eclipse Plugins - would they fit in? Likely not well, at least not at this point. Follow up - if the goal is to leverage Eclipse, how doe it do that if most plugins are orthogonal? Good question. According to Eric, resource based (not language specific) plugins will be usable. Joseph Pelrine - use Rosetta (XML) and you get a lot of the meta-data you want. Resource constraints limit this at the moment. Audience member - Idiocy (no ENVY - where have I heard that before?). The main point seems to be why try to recreate what you already have (a valid question, IMHO). This complaint is all about two things - wasted effort (we already have all this), and What, no ENVY??? The VW move to Store had a lot (and still has some) of the latter. Follow up, Bob Nemec - why would an existing VAST shop consider moving to this? With the resources all in this, what (if anything) is being done for VAST? Likely, little benefit now. Probably more later as contributions come along. Secondly, this is a spare time, nights and weekends project. Team at IBM still working on VAST. The danger for IBM here is that some customers will read this like people read the PPD problems in the 2.5.2/3.0 era. IBM has not blessed (officially) this, while the Eclipse board has done so. No way to write Eclipse plugins in Smalltalk? Not at this point, no. Will it ever be? Not exactly. There will be the JNI hooks, might be possible - needs to be explored. Follow up - looks like a boil the frogs strategy. It will look that way, and it will be a question these guys get asked a lot. Unified Debugger?? Not an initial goal, it's a hard problem all by itself.

I have to admit, there's schadenfreude in hearing the IBM guys get the commitment questions that I used to get. It's dangerous for Smalltalk in general though, so I can't take too much enjoymenet in it.

I attended three talks today - Scott Ambler's Keynote, The IBM Smalltalk for Eclipse talk, and Travis Griggs' Font talk. There was also the lunchtime Store BOF. Scroll down, and send your comments! It's starting out great - I'm off for dinner and drinks - more impressions later

The Fishbowl has some iRC thoughts - and most of them are pretty good. Have a look.

As I take notes and get them posted (delayed, due to the lack of wireless connectivity in the hotel), I'll be posting links to the items here

Dave Buck talks about VWUnit, an open source GUI testing kit for VW. Motivation - EDC (where he was working) released every 6 months, and developers had to drop everything for two weeks leading up to a release. They needed something better.

Old System - tests consisted of binders (18!) of the UIs as screenshots. Users had to use the shots as scripts and test the screen vs. the paper, and match it up. This was slow and error prone - small inconsistencies (some relevant, some not) were missed.

Difficulties

• Release Frequently
• Minimize user test time
• Ensure consistent testing

Run test suites frequently (approach an XP style of development)

What did they use? SUnit for non-GUI - needed a UI level tool. Needed to verify UI widgets, handle dialogs, menus, window launches, etc. Added onto SUnit. Created a "UI Test Harness"

Issues

• UI Tests had to run in a specific order (state issues in the app). Overrode the #buildSuite method to manually build the test suite as they needed it
• Running the tests changed the DB state, so that had to be dealt with

Hmm - sounds like they need Dave Astel's mock object framework in order to create a mock db. Might save them a fair bit of work

Testing Harness

harness rightOfLabel: 'Name:' enter: 'John Doe'

Didn't actually deal with widget ID names! SOOPS added such support. They had to create code that searched down through the VisualParts looking for the widget(s) in question. Sometimes had to delay and try over in case UI was still being built.

Locating widgets by type

• locateLabel:
• locateButton:
• locateRadioButton:
• locateCheckBox:
• locateListBox:
• locateTopLeftWidget:

There are issues with things like the list box - it finds the first one (w/o search by ID, how do you find a 2nd or 3rd? It's a problem). They had a speed issue here, and thought it was in widget locating - profiling proved it was flashing the widgets. Always profile!

They added code to move up, left, right, down in order to move to the next widget in the test. Added various press methods to change widget state, use button, etc. Various and sundry convenience methods. Can restrict the search for widgets to a group box. Responding to dialogs was tricky. Had to use semaphores to signal completion of the dialog so that tests could continue, with the forking of the dialogs.

Tables VWUnit supports tables - the client here used tables but not data sets (old app)

.

• Rows can be any order.
• cell by cell comparison to be added.
• If check fails, copies table data printString to the copy buffer so it could be pasted into the testcase method.

Each Window has its own test harness. A given harness can attach to the active window. VWUnit can print screens, so users can point out issues. Can Automatically scrolls to new page for tables, lists and print all. That version is not in the public store - a bit crufty.

Added a reporting harness - captures a textual description of what has been done. Polymorphic with the test harness, only records the steps. Users actually didn't care, but useful for developers.

At EDC - over 100 test cases for the UI. All tests run in about 2 hours. Reports export to Excel so that they can be compared easily. Tests are logged to a Wiki (manual now)

Assessment Dave would prefer more non-UI tests, and fewer UI tests. Developers have not been writing domain tests. UI testing do not catch all issues - or capture them badly. Does not capture enablement/disablement of widgets. Does give reasonable converage.

Future Directions

• Datasets
• Add cell by cell compare
• Add support for widget by name (regardless of location)
• No support for window menus
• Use #performUIBlock to make all UI calls
• Integrate with Pollock as it happens

Now Dave demos the system. Same green/red metaphor as SUnit. Pretty cool little system. Looks to be a bit specific to the needs of EDC - not suprising, since they built it. Reinout Heeck is working on it, so it will evolve.

Questions Validation? - end users are responsible for ultimate validation. The system does validate whether a given field contains what it's supposed to. Notebooks? - no support for the VW notebook. Not hard to add, hard to locate things in a notebook, or find the notebook Recoding Tests (like Excel macros?) - Dave would like to support that, and they have some tools to create testcases. No recording at present, it's more manual than that. Overriding #buildSuite - why not hand it a testcase instead? - more convenient to do it this way. Niall would not have done it his way. Niall suggests that method wrappers would do dialog wrapping more easily than what they do now. Points out that this is really regression testing, not unit testing. Yes, that's what it is. Wow, Niall asks hard questions :) He suggests a meta-object comparison system instead of per-widget comparisons. Flashing of widgets - why not have code to turn that off? Should be Can you test without actually visualizing the UI? Not really (Sames). Sames suggests that you could actually create your own display policy and fake the whole thing. Have you looked at FIT? - (Dave Astels) - no, not yet. HTML table driven approach to acceptance testing. What if there are multiple instances of the same subcanvas? ick, just give it directions. Pain in the neck. Why not TestMentor? - nothing wrong with it - organization in question couldn't manage to buy it because of the IT bureacracy issues. Would have been better off with TestMentor

BRITE Acceptance testing tools - Ontario Teachers pension. Sean Morrison - Smalltalk, some Java. Why not SUnit or TestMentor? One, predates both. Two, written for the QA staff, who are business experts, not tech staff.

• Emphasis is on doc management
• "Excel like" interface, since that's a tool they are familiar with
• Users spend most of their time on input and data analysis

Reported on this tool in 1996 at OOPSLA. Started as a simple method invocation mechanism using reflection. More sophisticatio added over time. Modern system is a ground up rewrite that is data compatible with the preceding system.

TestCase Editor screen shot - looks similar in layout to BottomFeeder without the html view, instead an excel like dataset view. Very sharp looking UI. Terminology is different from SUnit, because it predates and has its own lingo. Layout - left side, tree view of testcases or business functions. Right side has a textual description and the tabular layout of the data/functions. Running a test creates an object graph and a report. There are a number of view formats depending on user interest. Information can be extracted as XML and then displayed in a number of formats via XSLT.

This is cool, because it throws testing out a level to the business people - ties into the talk by Scott Ambler yesterday in terms of who's spending the money and who ought to be responsible for it all.

Some implementation details

Domain Test objects exist within the context of a data source. All test objects know how to save, delete, restore, execute (etc).

Application There's one Application, many appModels. All appModels live within a given Application (which manages global resources (db connections etc). To manage menus, took all of it away from the appModel and built a custom command object pattern. Makes for simpler enable/disable (etc) behavior.

The tool is in the process of beiing open sourced, so look for news and a website to come. Changes are going to be driven by Sean's employer's needs, since they pay for this. Want more info - Go Here. If you came to the conference, all the presentations are on the StS CD.

Questions Have you applied the tool to test the tool? - laugh, no. Not even enough SUnits for it at this point. It could be done, it should be done.

Croquet and Collaborative Computing David Smith and Michael Ruger

Croquet is an example of what they want to produce - innovation in action. Starts off with a picture of one of the original (1984) Macs. Example of the sort of innovation he's talking about. The gartuitous slap at IE and Windows gets a good laugh - but the point is, what's fundamentally new about Windows as compared to the original Mac (For that matter, what was fundamentally new about that compared to ST 80?). It all comes from the original Xerox Parc work - Dynabook, Smalltalk, etc.

Croquet - Transmission of presence, shared spaces. The two computers being used in this presentation are connected in a shared, 3D environment. Nifty view of the shared space from each person's perspective. It's a Squeak system all the way through, with OpenGL at the bottom. Andreas Raab, David Reed, Alan Kay, and David Smith - main collaborators in this system. They didn't create a protocol (for shared communication) at the level of tcp/ip - they created a meta-protocol for object communication. They do work with it across high latency links w/o serious issues.

David actually wasn't a Smalltalker until 2 years ago, because of the speed perceptions. He was able to build a highly performant rendering engine very quickly - still jazzed over the idea of being able to modify it while it's running. Based on the performance, you could run something like Starcraft (networked) on this.

Just amazing watching the two of them describe how to navigate - instead of directories, things like "go to the left and down the stairs". Very cool - consider that for people that find PCs hard to use - and there are far more of them than we like to admit.

As in the 2D Squeak worlds - which are really neat for teaching programming to kids, btw - all the objects are editable. Anything you can draw can become a 3D object in the world immediately. And over to the side, a Flash movie playing - into David's world, looks like a D&D style gaming world. Now he climbs an aqueduct, and the crowd shouts "jump!" - laughter all around.

Internet telephony is built in. You can take snapshots (like favorites, kind of) of places you want to be able to get back to quickly.

Mind you, I'm only capturing a shadow of this talk. The things David and Michael are showing are really cool, and have to be seen to really be understood. What this puts together, in one environment, is objects, networking, and 3D graphics - and leverages them in a way to create interesting and useful views of the world. This, or something very much like this, is going to start being used over the next few years.

Questions Will it be economically useful? - it's open source, we are defining a net based economy. It's going to require some interesting applications of the technology that people will pay for. Here's my thought on a useful implementation - online training manuals for hardware. You would be able to walk through a machine of system of machines from all possible viewpoints, and truly be able to understand it. Simulation training should improve a lot . Personal or shared forums - you would be able eto set up shared space for entertainment (music, etc) and take tickets at the door. Could make the whole concert experience very different, and more accessiible. Security and Permissions? - Each object can have permissions set up. Each object owns its own access state. Seen other 3D world implementations? - David has been doing 3D for 20 years, disappointed that it has not progressed past pretty pictures. "The mosst interesting thing you can do with 3D games is blow people up. It's fun, but I don't think it scales" (laughter) What about visual programming instead of textual? - no, not a good way to symbolically represent programs. Some things like EToys can be expanded, but it won't scale with complexity. Avatar interaction? Would it be possible for avatars to (for example) pick you up and place you on an object? - yes. might even work in what we have now, but it will work eventually. Just needs to be developed. Commercial Applications - where will we see this? - Navigational interfaces (for example, store clerks). IMHO, training will be one of the first places. That, and the "sin" industry, of course. Those guys will be all over it :) Will it lead to the William Gibson view? - this will be better. Are you happy with the object model (based on ST80?) or do you need/want something better? - Politically charged question. They have already modified Smalltalk to suit their needs, and will continue to do so. Objects are the center, but they are looking at parallel architectures and scripting. Will not be tied to the status quo. They are trying to invent the future . They are using Smalltalk to rewrite and re-invent itself.

That's the key part to me. This is why Java and C# are such utter dead ends - you can't get there using static, unchangable tools like that. You need a tool that can change and evolve into what you need.

Automated testing? - no, David is not the right person to ask. Sounds like he has my answer to this :) What have you changed in Smalltalk? - Made modifications to the compiler and support for scripting.

It's Smalltalk, so we can change it while we are running - shows an example by changing window color in a browser. Will it be perceived as too big a gun with too many ways to blow your foot off? - "Yeah, use Java so you can't do anything, that's safe". Adding scripting to make it accessible to those who are used to doing Python, Perl, VBScript, etc. They would like to make it as accessible as Hypercard was.

Vassili has an ST80 image up in VW 7 - i.e., the VM is implemented in VW. What did he compare this against:

• The Blue Book VM
• The Dorado (Microcode)
• Bob's VM (C, transliterated from the Blue Book) - done on a dare, about a year
• Hobbes, VW, OO implementation, on a PIII 500 - done as a lark, not in C. Took three days and an evening

Generally faster than the C VM or the Dorado! Some things were simpler - already had an ObjectMemory, did not need to create one. The VM implementation is truly OO and modular.

Performance - just reusing what's in VW - don't have to invent it.

Graphics

• ST80 - BitBlt
VW - RasterOp

Debugging - you are debugging a VM in Smalltalk, so it's a lot easier to figure out what's going on. Actually implemented an emulator for the old Alto file system. The old file list tool works against it.

Very Cool!

ElastoLab started out as a C++ project - real time physics simulator. When Dave got going, did the UI in VW, the physics in C++. Only later did he replace the physics in Smalltalk. It was too hard to improve the algorithms in C++

His initial proof of concept tests worked out - it was fast enough on a 400 particle test. Smalltalk ended up 3.8X times slower than C++ for the physicss calculations. Profiling indicates that this is as fast as VW can go - 80% of the time is in 4 methods. So the question is, is that fast enough?

ElastoLab requires 10 frames/second. 50% calculate time, 10% display time, 40% wait time. So while it's slower, it's fast enough. The algorithm - uses 4th order Adaptive Runge Kutta differential equation solver. Hard to code, but stable - i.e., it will look better on screen.

Finding collisions - more complex than you think. Uses the Bisection algorithm to determine the collision points. Resting Contacts are also complex - it all gets into the performance with barriers and collisions. David was able to more easily implement this in Smalltalk than in C++ due to the algorithm complexity - Baraff[94]. This was one of the drivers to doing it in Smalltalk.

Tradeoff - accuracy vs. speed - use 0.01, 0.001, or 0.001 (etc)? - the more accuracy, the lesss speed. What's "good enough"? There are better methods than Bisection; David went to Smalltalk in order to allow for better algorithms that would actually yield bigger performance gains.

So far, latest release is a tad slower - but he was focused on correctness. Next - better algorithms (as above). The better algorithms have not yet been done.

Question How much harder was the physics in C++ than Smalltalk? - the translation from C++ to Smalltalk was just transliteration, so there's no easy way to compare. The UI was much, much faster to do in ST.

Panel: David Buck, Dan Antion, James Foster, Avi Bryant, Niall Ross, Dave Pennington

The panel introduced themselves - all are (or have recently) been doing remote development. Dan starts off - anything to avoid? Dave Buck - if the end users are remote, it's much, much harder to get good feedback. Hmm. Vendors all face this, so it's nothing new. James Foster: That's a business model issue, not a development problem. James reiterates the point I just made - if you are a vendor of any sort, your end users are all remote. To his mind, very little changed, because the vendor is already remote. Niall - Agrees with James. Any Agile project can be maade remote, but the people really should meet socially first - it will help to get rapport up. Hmm - BottomFeeder and TypeLess were developed over an IRC with no meeting beforehand. How much open source work progresses that way? David P - Doing commercial development when the remote folks are across a border creates its own problems. Most of his problems have been hardware based - no easy way to replicate the environment from a remote spot. James Foster - equipment issues really depend on your corporate set up. If IT makes it easier, it is. If they make it harder,. it's not. Niall - in that situation, we have a remote connection setup. David P - this case was with a customer who bought a cheap component, no prior relationship. It was supposed to "just work". Avi Bryant - Is there a scale that cannot be crossed remote? No, Open Source (my point above) manages projects like this remotely. Squeak, for instance, has 50 developers, all remote David P - but, it would have gotten harder the more detail the customer wanted to get into. Willing to work hands off made it easy Avi - We have cases where we have real design discussions - they take longer due to time/distance. Email is less efficient. Things spread out over time

Dan Antion - time and design is just where we wanted to go next. How does that go? We do small things remote, but large projects with design? James Foster - yeah, that's how it's commonly understood. Partition the tasks and farm it out (as per outsourcing). (of course, this is one of things that Scott Ambler warned against). Projects are laid out to encourage long distance interactions in order to build team development. Separating out tasks leads to silos Dave P - Time zones are a huge issue - For instance, can lose a day if you miss the email window to somewhere far enough away. Holidays across borders are an issue - someone you need may not be available (although, he says, Dan Antion was there :) on the 4th of July). Dave Buck - Partner on ElastoLab was working one daya week from 8 a - 8 p on ElastoLab. Dave works 8-5 on consultiing projects - not a lot of overlap (hey, try IRC interactions with folks in Germany or Australia :) ). Dan Antion - issue with users, as they time shift and telecommute. Niall - usually use a computer sharing device and work together. Use drawing tool instead of white board, etc.

Side note - the teams here all sound small (other than Squeak)

Avi - Finding out reasons for a decision are possible to find via transcript logs, etc. Question for Niall - what tools for connectivity? - NetMeeting (Windows only). Also used PC Anywhere (not great for pair development, ok for remote management). Have to be able to switch control quickly. Also used COAST and some Lotus Notes plugins. Somewhere in between the other two in ease of use. James Foster - reiterates that with customer being remote, these problems are not unique to remote development. They end up being the same. His customers are hospitals - HIPAA is interpreted as not allowing any data access - so remote help is back to screen descriptrion over the phone, talking through what's happening. The impediment is already there. David Buck - remoteness adds a need for more doc, since issues cannot be directly talked through or demonstrated. How to load up code, build an app, etc.

Dan Antion - Face time - how do you manage the need for periodic face time? Do you go to the users, do they come to you? Neither? Dan finds the conversations to be shorter and more to the point Niall - May be personality - finds it easieir if he knows the persson he's talking to personally. Otherwise, how to judge how to talk with them? Dave P - First face to face after 3 years of email was terrifying - how would it go, would they like each other? Worked out, now use IM. More inclined to talk on phone - before personal meeting, would never have used phone James Foster - all have started with things becoming remote over time, with personal relationships pre-existing. The pre-existing relationship enabled the remote relationship Dave P - have not personally met many of their clients - for custom development, it's all been remote, no personal contact, all email James Foster - Is it part of the Smalltalk culture and the size of the community that allows that? Would it work as well in a bigger culture? Feels like he "knows" people who hee has met only electronically via reputation. Dave P - Will speak to NYC STUG in September - they know him by name and reputation - he does not know them. He's curious how they will take him Niall - things go differently in commercial work than they have in Open Source Camp Smalltalk work. Gives impression of having imagined John Brant by reputation, then in person

Question Managerial? How does that go? Niall - managed such a team with remote folks. Have to take account of remoteness when holding meetings. Can actually run all people as remote even if they are local Dave Buck - not if there's time shifting/time zone issues

Response from Terry Raymond - started working with SOOPS in Holland - started with going over there to meet entire team before starting, so as to enable smoother flow later. Adapts to time shifting by moving his day. Uses IRC/IM extensively.

Dave P - It can all depend on when you "happen to be motivated" as well. There needs to be adaptation to time shifts by all parties. Somehow, have to arrange time overlap. As a self employed consultant, have to deal with "just in time" schedule Niall - Can deal with time shifting by doing some work "after hours" and overlapping from home James Foster - time shifting happens locally as well. Niall - if you are willing to work from home, you can obviate some of these time shifting issues.

Dan Antion - Technology? Are there issues with the existing Smalltalk tools? Are some better/worse than others? Sometimes you 'miss' giving someone what they need to get work done, and the time shift issue just blows that day. Avi - remote development in Squeak was hard without version control systems. Avi spent the last year building tools to solve that issue. Integrated with CVS, but that's non-trivial with the way Smalltalk works (load order, sub/superclass, etc). Ended up bringing a lit of the CVS tools up into Squeak to solve that NiallNetMeeting didn't work with the client's Java based (Swing) UI. Never had such an issue with ST. Avi - Shared Screen - in Squeak, there's Nebraska, a Squeak specific tool. Connect as many as you want, everyone gets their own cursor 9need lots of screen turf). Heading out to Squeak BOF James Foster - underlying tool support for moving source around. VA with ENVY - hard if you are not on the same library manager. Lots of work arounds, but they are work arounds. This is a challenge that does not exist locally, unlike the others. Need truly high bandwidth to address that Dan Antion - works with a high school graduate, segregated to own repository. Same issue Dave P - Expect the client to provide them with what they need, so that they can do the work locally. Use mock objects to simulate databases, etc. Also have to make sure that they are working on a version of their own tools (or compat) that the users have. i.e., no good using an upgrade no one else has. Dave Buck - Source Code Management was easiest issue, using Store. Connected/Disconnected development, used Postgres (no client libs required). Made it easy at that level Niall - ENVY is chatty, too much so for remote development. Export code, share screens, etc. Don't use remote db with ENVY Dave Buck - hard to specify what the developer should load. Used a Wiki to manage that information in a shared space. Worked "well enough" - time shifting was a far bigger issue. Niall - Remote development trained them to do pair programming. Get two people around two keyboards, but share the screen. Hmm - might this solve some of the objections you hear? Solves issues with "not my machine", ergonomics, etc. Learned from remote, and now routine for Niall. Share screens, not keyboard. Get headsets for you phone! - makes a huge, huge difference. Simulates being next to each other Dave Buck - interested in Avi's shared screen work pattern. Niall - Smalltalk tools do that James Foster - agrees that PC Anywhere is subpar, NetMeeting is ok. Citrix and terminal server work pretty well. More than two people can share. There are connectivity issues that make this harder or easier. If IT insists on controlling "everything", then things are hard. Easier to try and "fly under the radar". Working away from IS can actually make things easier, sicne you can avoid policies that don't help. Dave Buck - What if you work on Classified projects? Can't do any of that stuff. Niall - All the tools have bandwidth requirements. Either you have it, or you are screwed. Things like COAST work well even on slow dialup.

Question - what about VNC? Niall - swapping control makes things harder (as per PC Anywhere).

Question - What about division of labor in remote development?

Dan Antion - carve things up into well defined blocks of the system. Dave P - does the same, but more implicitly Terry Raymond from the audience - sharing code in a publish/merge with shared code is hard, with or without remote development. Looking tot rearrange packaging to starat avoiding that. Me - in VW development, we mostly have projects partitioned, not the same level of sharing Terry talks about Niall - Doing pairing to obviate the whole issue. The merge issues were orthogonal to remoteness.

Dan Antion - selling this to non-technical management - How do you do that? How do sell using a developer far away when you have soft and hard costs - even if it's cheaper in raw salary terms?

James Foster "Remote Development is a bad form of development, unless something else is worse" - i.e., someone is moving, corporate office is moving, etc. It may be the best choice given a sub-optimal situation. Dave P - Any resentment that builds up from people who are living/working in less desirable places? "Someone has to stay local" can cause grief? James Foster - It can, but doesn't think so. Niall - another bad but better than failure is working over holidays due to issues. Dave Buck - Agrees with James Foster. If it's not possible, it's not possible. Me - we got remote developers mostly because we couldn't get them any other way Dave P - cannot imagine working any way but remote.

Dan Antion - Wrap up. Slides with questions on the CD. Link on the CD where Dan will update.

I got up early today and jogged - Toronto is a beautiful city. Then it was off to a great day of preresentations. I attended a lot of talks - the notes are all accessible here. Or just scroll down and read :)

Michael Lucas-Smith and Steve Aldred have been working on Nyx - it sounds truly cool. Go read up!

David Buck took these notes yesterday at a talk he attended, and was kind enough to make them available to me. So here you go - Dan Antion's talk on hiring and training pre-college workers

There's a benefit to hiring people straight out of school with no programming experience.

American Nuclear Insurers

• small business providing insurance to nuclear industry
• hard to find software that's appropriate
• need to support engineering
• problems lead to in house development

Hard to keep college graduates interested High turnover due to career management concerns

Took a chance on a high school student who wanted a job. Took him on and trained him - worked well.

Finding candidates was hard.

• Advertising hard
• Recruiters don't do this
• Tech school focused on certification and hop topics
• Technical college didn't help
• High school was a good choice

  Tips

  • Work with schools to find students
  • Attend career fairs
  • Industry groups help
  • School to career committee for students who aren't planning on going to college.
  • Networking

  Important: get coordinated within the company. Employment policies are unusual for this kind of arrangement - eg. hiring someone well below salary range and after 6 months give them a large raise to bring them up to the normal salary range. Not well understood by corporations.

  The kids normally don't have resumes. Different hiring practices needed

  • how do you like to learn?
  • can you learn by working with another person?
  • why are you graduating from high school and not working?
  • past successes?
  • what technology are you familiar with (probably games)
  • long term goals (probably games)

  Explain and agree on expectations. Explain salary - they start below the market level. Do 6 month reviews and salary review for 2 years. Not bound by HR guidelines. Short term goals must be clearly defined. Leave an escape route - pack to the pizza shop if it doesn't work. Long term goals - if you want to pursue college you can and our company would reimburse you.

  "Contract" - failure is not an option. This is going to work. You have to accept the fact that you are not bringing in a qualified person. What you ask them to do is necessary. They are not put on useless projects. Differentiate between personal style and company policy. If this person moves to a larger organization, they should have experience in things that are normally expected. Work assignments must be meaningful. "Can you manage multiple assignments?" - hard question for kids to answer. It's an important issue since they may need some of your time to continue on one assignment when you don't have the time. They can switch assignments. Some assignments are aimed at their interests. Have a project path in place before you bring on the students. Start with less technical longer duration projects. There is more business input than technical input. Follow by a small utility they can do on their own.

  Move into a small project for a few users.

  • Gradually increase complexity.
  • Design tasks introduced slowly.Remove the nets and let them fly on their own. They may need to scrap small failures and try again.

  Should have 6-8 weeks of work ready to give them. Prepare to give them coding on day 1 - they don't care about pension plans, etc. Use laptops that they can take with them. Keep them in their own library - they don't understand impacts on other parts of the system. Expect that they want to learn and won't stop learning. They may move much faster than you expect. Hard to get out of the comfort zone of things they know how to do. Don't understand competing interests. Less concern for traditional amenities. Student may not even realize how much he makes. More concern for technical amenities. More concerned about the kind of laptop he uses. Security risk - may have a hacker mentality. May see nothing wrong with pirating software. Problems with objects. They haven't had exposure to objects. It's hard to sell the value of objects. Reuse is unknown to them. The class library can be intimidating. Let some things get rewritten. Explain the business side of the business objects first. Then show objects used.

  Working with Smalltalk

• cookbook of scripts is useful. Sometimes they don't want to use it, sometimes they do
• Introduce common objects. Some are very old so you may need to review it yourself ahead of time.
• Critical elements of Smalltalk are hard to introduce (eg, blocks, events, collections, etc) - best to introduce them at the time they are needed rather than explain in advance.
• Question their questions - why are they asking that question. Need to ask why they are asking the question.
• Review their code frequently. Don't let them get too far along with something that's not right.
• Introduce UML through documenting their own code.
• Keep leading them with more and more difficult things.
• Non technical learning required. They may need to travel but don't have credit cards.
• Don't put them on accounting projects - hey, it's only off by 2 cents - it's good enough.

Work close by. Constant feedback. Keep everybody in the loop. Don't hide weaknesses. Everybody realizes that he'll mess up from time to time but you have to let him learn from it. Don't force classroom training.

Summary Had 4 kids do this. 4 successes. Kids still excited about coming to work!

Well, AOL is waxing all the Netscape and Mozilla developers. It will be interesting to see if it can sustain itself as an open source effort....

How many times have you been told that Smalltalk has weak typing or is untyped? It's an old misconception from people who confuse type declarations with strong typing - the example I often give is that C and C++ are statically typed, but are also weakly typed - you can get the system to attempt an operation that it has no business attempting. Smalltalk is dynamically, but stringly typed - you get well understood exceptions when you try an illegal type operation.

Why am I rehashing all of this? Because the Python folks are engaged in the same debate now. The curly brace crowd continues to live in an oblivious bubble....

John Aspinell, longtime (1992) Smalltalker. Started this project in 2000, turned commercial in 2001, released by fall 2001.

O/R Frameworks he's known - TopLink, developed others on own. Considers TopLink is great, but heavyweight for his needs.

• Persitency is not free, even with an OODBMS
• Issues - deepCopy. Copying an object model requires thought. You don't need everything, but what do you need?
• Relational DB's do have some advantages

Define the DB yourself? It's a luxury and a responsibility. Duplicates a lot of effort. You end up maintaining not just the Object Model, but also the db schema.

How did he get to ReStore? Went from large clients and large systems to smaller clients and smaller systems. Changed from working with VW, VSE, VA to mostly Dolphin. Why Dolphin? Mostly low cost, along with the tight Windows integration. In short, Dolphin = VB for Smalltalkers. In other words, it's fully replaced the slot Smalltalk/V was in before Digitalk got stupid.

What other possibilities?

• Binary Storage (BOSS equivalent)
• OmniBase

OmniBase got the "where's my data?" question - so relational db's gave them a warm fuzzy. Also leverages customer's existing investment in tools like access, Oracle, SQL Server (etc). Also makes data visible to stock reporting tools. Made things flexible (Just add ODBC!). Got transactions and security and querying "for free".

OODBMS

• Transparency
• Object Identity

RDBMS

• Querying support
• Visibility

Wanted minimal impact on ST work - support agile development, reduce duplication of effort, did not want to make refactor/redesign a feared activity because of the db. Wanted Collection support (transparent). Wanted to not require SQL knowledge by developer. Wanted to be generic (not tied to a specific db).

What about existing databases? Was not aware of GLORP when he started.

Technical side of ReStore - pretty standard

• Classes map to tables
• Inst vars map to fields
• Proxies wrap persistent objects

Identity maintained by

• Single, Unique ID per object (row)
• System Generated
• Invisible to client objects
• used by all foreign references
• Not required to subclass from a specific class

SSWRestore - main broker

• handles all db interaction
• caches persistent objects
• manages transactions

Transactions

• Handle all db updates
• Work with proxies to track changes
• single level (not nested) - something of a limitation
• Strong support for update clash detection and conflict resolution

Proxies knows the class and id it wraps. Asks ReStore for its object on demand. When referenced it adds self to current transaction. Uses #become to become the wrapped object. Pro - very fast. Con - needs tidying up (Dolphin become is two way).

Using ReStore in an application

Define the classes you want to persist. Avoids relational terminology. Specify the class of object held in each inst var to be persisted. Can be a base class or a collection.

For a class Person:

aTable
	define: #surname as: String;
	define; #dateOfBirth as: Date;

and so on. Then define the mappings of low Smalltalk classes to db tables. This is configurable.

Collections - specified as a template collection. Support OrderedCollections, Arrays, and Sets. Two types - Owned, General.

Owned

define: #pets as: (OrderedCollection of: Pet owner: #master).

One to many in relational terms. Membership specified by the reference to collection owner in the inst var.

General

define #friends as: (OrderedCollection of: Person).

Many to many in relational terms. Collection stored in an intermediate table. Will be created and then automatically given a name (like PERSON_FRIENDS).

Inheritance - simple support. All classes in a hiearchy share a single table. Controllable bu subclass or superclass. System column specifies the class. Pro: Single query searches all subclass. Con: Redundant fields. Some wasted space in the db. On the other hand, disk space is cheap.

Create the DB. Add classes to ReStore. Synchronize with the db.

reStore
	addClass: Person;
	addClass: Animal;
	synchronizeAllClasses.

This creates the table schema, without adding any actual data. It's now ready for use. Tables created from class specifications (a method). Tables created if they don't exist, if it does exist, it will compare and possibly update the structure.

reStore evaluateAsTransaction: 
	[[johnsmith := Person new
		firstName: 'John;
		lastName; 'Smith';
		pets: (OrderedCollection with: (Dog named: 'Rover'));
		storeIn: reStore].

reStore evaluateAsTransaction: [johnsmith emailAddress: 'js@foo.com']

That does the transaction to update the object in the db. When the transaction commits, all the relevant SQL generated and fired.

At this point there was a lively discussion of the proxies, and the collection interfaces being used. Pointed out that collections need to be homogenous - heterogeneous collections are a problem. It's a limitation based on the static typing in the db. This may be addressed in future.

Querying the database - What is a database? A collection of tables. What is a Table? A collection of Rows. What's querying? Searching db for objects matching a certain criteria. Querying in ST uses #select: and friends.

allPersons := aRestore instancesOf: Person.

Answers a virtual collection of all persistent objects. Understand #select:, #reject: (etc). Only brings objects into memory upin query at ST level

allPersons select: [[:each | each surname = 'Smith'].

allPersons anySatisy: [[:each | (each firstName = 'John') & (each lastName = 'Smith')].

End up being able to use mostly normal looking Smalltalk queries. Blocks are parsed in a special parsing object to create SQL (there are some limitations). Traverses messages sent in the block via #doesNotUnderstand: Builds up a map of tables, columns, joins, and conditions. Translates to SQL. Some of this gets ugly in code (system, not app)

1. satisying:

• virtual enumerator
• like #select:
• returns another #instanceof: collection
• no querying takes place!
• easy, gradual refinement

allSmiths := (reSTore instancesOf: Person) satisfying: [[:each | each surname = 'Smith'].

allJohnSmiths := allSmiths satisfying: [[:eacvh | each firstName = 'John'].

and so on. Also an #addAll: that can merge results of a collection query. Also virtual. Other virtual collection methods: #asOrderedCollection, #asSortedCollection: [] - answers a real collection. #size, #isEmpty - issues a COUNT query.

Future Plans

• Convert to other Smalltalks (VW in particular)
• Integrate with the RB (catch class renames, etc)
• Nested and Parallel Transactions
• Relational integrity

Questions What about reverse engineering a db? - not now, maybe in future. What about storing partial classes into db? - does that now - based on the specification Cursors and Paging? - has a readstream that keeps track, likely needs a bit more transparency Any support for weak caching? - everything coming back is dictionary cached. The cache is all weak, not string Two way become on proxies - what if I have multiple proxy refs? - not a problem Collection faulting? - done differently, as one would expect Update/class resolution? - can be turned off. Each object has a version field. gets updated on write to db. Update looks for that in order to resolve, if fails, will rollback transaction - can provide a block to handle that (similar, sounds like, to BOSS schema migrations). Do you ask user, or the code what to do? - can be handled in code, with or without user interaction multiple db sessions? - multiple instances of the reStore object. This can support multiple transactions, through independent reStore objects. When rollback, object state is restored - yes. People note that the class resolution across multiple reStore objects could be an issue in web apps with multiple users in an image

Scoble writes on why conferences are worthwhile:

But, let's look at the real value. Let's say I'm a corporate developer, and my boss is about to spend a million (or more) on developing .NET apps. How do I get my questions answered? Am I gonna see if my architecture is really the right way by reading a weblog? Give me a break! (Well, Chris Brumme might change my opinion there, but still, give a corporate developer 10 minutes with Chris, and he could switch his architecture and save his team months of development work).

Let's say you're a small guy. Probably a consultant. You do a job here, and a job there. What will make you more valueable? Your relationships with key program managers at Microsoft. Why is that? Well, let's see, if a client is hitting a wall, in, say C#'s new reflection features, and you can open your IM up and ask the guy who runs the C# team a quick question right in front of your client, think you'll get the job? Yeah, Eric Gunnerson has a weblog too, but there's nothing like hearing him talk, and then getting his business card and making a HUMAN contact after his talk.

The same is true of things like this conference I'm at - I've been talking to a whole lot of peoplepersonal contacts a whole lot better. And the after hours talks with people are really useful as well - it's all personal, direct - and exactly the sort of contact you won't get electronically.

So yes, the notes I've been taking are worth reading (at least, I like to think they are) - but don't mistake it as "Just like being there". I'm capturing, but a lot of what I get is summary and interpretation.

Dorin Sandu and Mark Suska

VM - the basics

• Interpreter
• mark and sweep gc
• direct pointers
• non-moving objects
• weak reference

It's small, it's portable. The VM is 68k compiled, the image (with all source) is 3MB. The VM is implemented in C++ and has been run on other platforms than Mac OS X. Minimal set of primitives, reclaims circular weak by key refs. Given the small number of primitives, platform ports are possible and not too hard. Have run it on Windows and older versions of Mac OS.

Native Framwork

• interfaces to shared libs
• automatic interface generation from C headers
• C code translated one to one to ST equivalent
• functions and callbacks
• type checking
• bounds checking

Native calls can call back into Smalltalk. The VM is single threaded from an OS perspective.

Now a look at the system - the browsere looks like a VW browser without Store loaded. Some of the 'system' level code (Behavior, Blocks, etc) is a bit sparse, but it is a new implementation.

Smalltalk Environment

• no development time state or behavior in kernel classes
• "SmalltalkEnvironment current" - gets current state info
• Modular design of the entire system - tools, app, GUI, environment, kernel, native ifc, VM and libs - cleanly separated. For instance, GUI can be cleanly removed

Generating a standalone image - scripts to remove unneeded classes (is there wizard type support for that? Not clear).

Now Dorin is talking about the UI framework. The goal - provide a consistent, intuitive API over the Mac API (which is confusing and hard to use, in his opinion. I wouldn't know :) ). The GUI framework is using the kind of composition pattern you would expect - doesn't look that different from what I've seen in VW (at the 30,000 foot level, mind you). Resource management was critical as well - need to manage the lifecycle of the widgets, since it's all native. Heh - the demo ended with the screen saver coming up after he didn't touch the kbd for awhile :)

Questions

Why did you do it?
To learn, interested in the problem. We were just interested in the problem

Is it downloadable?
Alpha available within a month. Probably free for personal use, will probably follow the Dolphin model of sales

Plan to make commercial then?
yes

GUI Builder?
I have one for Dolphin, will port it to this

How long have you been working on this?
Started in 1998, 2 years. Broke for 2 years, then started again. Mostly nights/weekends, started pushing once the talk for StS got accepted.

Any decent sized apps done?
have ODBC, probably will port GLORP. Have an app they use to manage tasks for this project

With non-moving objects, is the allocator more complex? - some fragmentation issues, but have had image running for weeks. Compact memory on image save.
What is your commercial model? - Dorin was mostly a Windows guy - other dev environments for Mac are expensive, and/or limited. Taragetting the hobbyists and smaller developers who do not want to spend the "big bucks".

Cooperating with other ST vendors (small) like Dolphin? - possible, but needs exploration.
Eliot - suggests that they partner with Dolphin

#Smalltalk for .NET - Don Roberts and John Brant

This is a 9 month effort so far (from OOPSLA last year). "Our use of S# would have been better since we really are Smalltalk". Ouch :)

Completely new Smalltalk on top of the CLR. Hey, I can download it from a #Smalltalk based web server here.... It's ANSI compliant. Seamless access to the .NET framework. Open Source, Free as in Beer. .NET classes look like Smalltalk classes. .NET messages are transliterated into same name with keyword syntax. Constructors are done with #new or #new:

x := Regex new.
x := Regex new: '[[Ff]oo'.
matches := x Matches: 'hello foo' starting: 5.

Yes, the cap method name is because it's calling a .NET method in a .NET class.

Implemented

• LargeIntegers
• #doesNotUnderstand
• Exceptions

Not Implemented

• #become:
• Modifying classes at runtime
• Changing the class of objects at runtime

Collections All Smalltalk collections are implemented - they are mostly wrappers on top of the .NET framework, in addition to a full set of Smalltalk collections. Performance - about on par with Dolphin speed. VW and VA are typically faster.

Good

• Based on MS technology
• Good for scripting windows
• Easy for smalltalkers to use .NET
• Relatively small, standalone exes
• Available now
• Free, as in beer
• Complete source available
• Self-hosting

The Bad

• Based on MS technology
• Edit/compile/run (repeat) cycle
• No IDE - yet (use EMACS)
• Very few optimizations

Demo time - they've got Store working for this, and GLORP ported. Hey cool - he's got a demo of a radar weather view. There's a bunch of stuff that comes "free" with the .NET framework. They develop in VW and then export as SIF. The code behind this is pretty simple looking.

open
	| thread |
	files := OrderedCollection new.
	form := Form new.
	form Width: 650 Height: 680.
	form Text: 'Don''s Radar'.
	scrollbar := HScrollBar new.
	scrollbar Minimum: 0 Maximum: 100 Value: 10.
	form Controls Add: scrollbar.
	picture := PictureBox new.
	....

And so on. Other than the naming convention for methods, it looks fairly normal. To run this, install .NET 1.1. About a 100 MB download for runtime, dev, and doc. Integrated with the MS debugger, so you can do things the MS debugger can do - such as attach it to a running Windows process (like the #Smalltalk interpreter). Not as transparent as a Smalltalk debugger, but ok in this world. Primitives to the .NET framework are implemented via compiler calls using blocks. For some of the common Smalltalk optimizations (#ifTrue:, etc) - they have macros built on the rb parser instead of the kinds of compiler hints most Smalltalks use). Allows for 'on the fly, extensible' optimizations. This rewriting is part of the compiling, so the developer's source stays as they expect.

To ship an app - ship the exe, the LargeInteger dll, and ensure that the .NET runtime is down.

Questions Have you looked at Eclipse, thought about that - Don: "We thought about it, when we looked at it I wasn't that impressed". No image, right? - Correct Compiling to the CLR bytecodes? - Yes What about the VisualStudio? We don't own it Why do we need the LargeInteger DLL? - because we wrote it in C# instead of paying for the #Smalltalk overhead. Does it run under Mono? - We have had it running there, but it breaks frequently. Almost runs under Mono.

The talk went very well. I'll get my slides posted shortly - I actually couldn't find them on my drive, but the audience saved me with an STS CD, which had my presentation on it. There was a good sized crowd, and fair bit of interest in RSS and blogs. I didn't even have time to get to necho :)

Ok campers, these are ideas we came up with - send those cards and letters with your own ideas.

Suggestions for next year:

• Scottsdale, AZ - all in one price, reasonable, great resort
• What about Las Vegas?
• Washington DC Metro area - US politics may be an issue?
• Toronto again?

Other STIC directions

• Getting STIC to show a Smalltalk presence at other shows (Internet World, etc)
• Getting people to give talks at non-ST shows - many are eager for speakers
• Get more content to why Smalltalk, get more Smalltalk bloggers out there
• Get STIC to help out the local Users Groups - help coordinate schedules, presentation topics, etc.
• Start a community blog
• Start a user group news page - scrape it into a feed
• Someone needs to update the cls FAQ. Can the STIC coordinate updating/keeping that info current?
• Also coordinate information on user group locations and coordinators, so as to make that available to vendors and users
• Teach classes and/or work with local xp groups exposing Smalltalk
• Library of canned presentations/content, coordinated by STIC?
• Analyst relations - especially Gartner - private communications very negative - solution will be to get a countervailing opinion from another analyst. Need to find more friendly analysts
• Great discussion about talking to the Python/Ruby community about Smalltalk - not from a competitive standpoint, but as a tool they could be interested in
• Once a year Smalltalk journal? Off cut by 6 months from StS?

Ok gang - We need the community's help. Send your cards and letter

The conference is over for the year, and it was a great conference - high energy levels, a lot of great talks - my only regret is how many I missed! Today's notes are here, or just start scrolling down. See you next year - see the STIC wrapup for some of our preliminary thoughts!

This year's show is over - for a quick set of links to the talks I have notes for, go here. The talks were great - but that's not really the best part of the show. The best part are the dinners and ad-hoc meetings - where else are you going to be able to sit down with people like Terry Raymond, Eliot Miranda, Alan Knight, Avi Bryant, Travis Griggs - and a whole lot of others - all at the same time? That's what we had at lunchtime every day, and at dinner and drinks all week - and it wasn't on the schedule :)

So yes, the notes give you some sense of how things went this week, but it's not at all like being here. And for those of you wondering what your STIC membership bought - this show, and future events like it, are a big part of it. I'm already looking forward to seeing everyone next year!

Some of the Java Community have determined that the LGPL is just as viral as the GPL with regards to Java code. That's interesting, because that would apply - for the same reasons - to Smalltalk. For that reason, I'll be watching to see how that comes out - especially if any legal precedents actually get set. I'll quote Bruce Badger with regards to how the LGPL "should" be interpreted - The Facts don't matter. here's the relevant communication from the FSF:

Apache Developer: Brett Smith referred me to you regarding a question regarding the Lesser Gnu Public License (LGPL) in regards to Java. It is the interpretation of most of the open/free software communities that the use of a "jar" file by a piece of software linked via a Java "import" statement does not bind the linking work under the terms of the LGPL. The Apache Software Foundation, presently takes a more conservative view and thus projects of the ASF are not allowed to link/distribute LGPL programs into Java projects of the foundation.

DT (FSF): This sort of linking falls under section 6 of the LGPL.

The Fishbowl tells us how to crash a developer:

Near the end of the day, the boss walked up to my desk and asked me how a third task (that had neatly slipped my mind) was progressing. What I experienced could only be described as a stack overflow. The attempt to add the third task to my stack caused the whole mess to fall over, leaving me babbling like an idiot for a few seconds while I tried to reconstruct enough state to allow me to provide an intelligent response.

So that's it. I have a stack for significant tasks that is two deep. Any more and I crash.

Oh, do I ever identify with that...

• Loading and Configuring the Web Toolkit
• Web Toolkit and the ASP model
• Web Toolkit and the JSP model

Point your browser here to see parts one and two - the final part should be ready by the end of the month. Enjoy, and send comments to me. Kudos go to Jim Fuldner of our training group for all the hard work - I just publicize it.

It's always a weird kind of day for me when I get back home during the work day - it just has an odd feel to start out in one place, and then back in my office at work. I think it's the change in rythms - lots of people around at a trade show, lots of things going on, old friends to catch up with - and then bam, back in the home office. Things will be back to normal after a good night's sleep - which is something I never get eough of at a show