Smalltalk Tidbits, Industry Rants

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

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 :)

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.

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.

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!

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.

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.

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

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

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

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

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.

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

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

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.

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 :)

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

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.

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....

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!.

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.

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.

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....

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.

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.

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...

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 :)

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.

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?

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

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.

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.

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.

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!

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.

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...

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...

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

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!

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

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?

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.

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.

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.

Oracle hires military adviser.

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.

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.

I posted on Adam Curry's silliness earlier - and I just read the .NET guy's response:

I don't have $10,000 to bribe people with, so I guess I'll just have to put my blog on the line instead. Six months after whatever (n)Echo is to become is released, I will hereby cease to provide ANY form of RSS.

Yeah, there's a plan. First, necho needs a lot more functionality before it can replace RSS. There are a lot of useful modules, there's categories (of what possible use is subtitle, for goodness sake?) - and so on. BottomFeeder already supports necho (in the dev stream for 3.1), and I have a necho feed here - but there's no way I'm getting rid of the RSS feed - it's more fully functional, and - for the forseeable future - more easily consumed.

Today's spotlight is on Norm Green's Gemstone tuning talk:

Performance Tuning in GemStone/S tutorial (extra cost applies) Green, Norm: Gemstone Wednesday 2:00:00 pm to 5:30:00 pm

Abstract: Gemstone performance tuning tutorial.

Bio: Norm Green has been using Smalltalk since 1992 when he worked for IBM Canada Manufacturing (now Celestica Inc.) in Toronto. There he was a lead developer on the DACS project, a data collection and shop floor control system written in GemStone/S and VisualWorks. Green joined GemStone in 1996 as a Senior Consultant and has traveled the world helping GemStone customers with their projects. Currently he manages the Smalltalk Engineering team at GemStone. Green earned a degree in Electrical Engineering from the University of New Brunswick in 1989.

Kent is disappaointed in the progress rate:

dW: What do you think about software quality? Beck: I wish developers would consider the enormous consequences of their actions. When I got my driver's license at 16, I was both elated and terrified; I had newfound freedom and responsibilities to go with it. Now, compare that feeling to when Microsoft sends me a new operating system. Do I have the same feeling? No, I think it's going to screw up my life for months. For how many decades and for how many millions of people has that negative emotion been created around software. I think it's such a shame we set our sights so low. Either you're stuck with software that works the way it works because you don't want to break it, or you get an upgrade that causes pain and anguish. I just want my stupid computer to work and it doesn't. That's not computing.

Of course, Kent migrated his work from Smalltalk to Java, so one could argue that he's being part of the problem, not part of the solution. He knows damn well that static typing is sub-optimal, and that there are far better solutions - Smalltalk, Python, Ruby, Lisp - than Java. If someone of his stature started speaking out on that topic, it might help.

There's been interest expressed in having a Store BOF at StS, and the consensus now is to hold it during lunch (noon) on Monday, July 14th. so if you have Store issues/concerns/questions, look up Alan Knight on monday at noon!

This is interesting. I've personally been very cynical about the necho format, but Adam Curry is pissed:

The $10k didn't 'just' give me an automatic base within the userland community, it got pasted on web pages all over the world and I've built up an audience that consists of 50% aggergator users.

But this investment is clearly being halted short by the (N)echo project.

So I'm invoking an age olde american tradition of letting my wallet do the talking. I will again invest $10k in aggregator default placements this year, but I will spread it around, to all developers who adhere to RSS2.0. Include (N)echo and you're out of luck.

Well, that will open some eyes.

InfoWorld CTO Chad Dickerson nails the value of RSS:

When I started using an RSS newsreader daily, some remarkable things happened that I didn't necessarily expect: I began to spend almost no time surfing to keep up with current technology information, and I was suddenly able to manage a large body of incoming information with incredible efficiency. My newsreader has become so integral that it's now sitting in my Windows startup folder along with my e-mail client and contact manager. I'm humming "RSS Killed the Infoglut Star" when I fire up my RSS newsreader in the morning.

That's what I've discovered as well. There are a handful of non-RSS enabled sites I still visit - Dilbert and Day by Day being my two favorites. Other than that, most of my browsing proceeds directly from BottomFeeder, based on the subscribed content I'm actually interested in. This is just so much better than going through an enormous favorites list each day. I'm starting to think that a combination of wikis and comment enabled blogs could easily replace most internal email as well - making it far easier to find out what's going on in projects I need to track. RSS is still in the what's that stage for most people, and the not Echo project will be seen the same way. That's about to change, with AOL jumping into the blogging fray. Doc Searls was right - RSS newsreaders are TiVo for bloggers. Soon, bloggers won't be the only ones.

Dear Abby weighs in on blogs and etiquette. Appropriate noises about the end of the world as we know it are off stage, left....

The technical jargon problem goes beyond the IT industry. Just as non-tech management and workers often have no idea what we are talking about, consumers have an even dimmer idea of what the industry is talking about. Here's a story outlining the problem. You can see the problem in any ad for PC products or new electronics - while many of us in the tech sector understand the terminology, most non-tech consumers are baffled:

Terms such as MP3 and Bluetooth are only understood by a small number of people, a report by a consumer research group found. The findings are bad news for the industry, as it suggests that the baffling terms are putting people off buying the latest gadget. "The technology industry must simplify its vocabulary so that consumers around the world can better understand the benefits technology can bring to their lives," said Patrick Moorhead, chairman of AMD's Global Consumer Advisory Board, which commissioned the study.

In the IT shop, this kind of thing causes grief - but in the consumer space, it costs money - it's hard to sell gadgets when the potential customer has no idea what the heck they are. If you have a ReplayTV or a Tivo, you've probably already seen this in action - when I first describe the device to friends and acquaintences, the common reaction is huh??. Then I show them the device. In a quick demo, people tend to ooh and ahh appropriately. This is looks like a problem throughout the tech sector.

It's also an issue in development. The blogging community seems to have no idea just how isolated from reality it is right now. while we argue and fuss over RSS and necho, go ask some line developer about blogs and RSS. you'll likely be surprised when you find out how much they don't know. What the entire tech sector needs is the Star Trek Universal Translator, so that we can communicate with the rest of humanity....

I read this story on MS bloggers with interest. It seems to me that MS is tacitly encouraging blogging, which is good - and the bloggers themselves are watching themselves. That's pretty much what I do here - since I post on Cincom's servers, I try to police myself. Eventually, some blogger somewhere is going to cross a line that irritates management at their firm, and it will be very interesting to see what (if any) fallout comes from that. I'm sure all corporate bloggers are wondering about that. In the meantime, we try to be interesting within our own self described boundaries....

I posted on this reverese engineering lawsuit earlier, and then came across this story in Linux Today. Combine the two together, and you end up handing MS (or any large company that gives source code access) an interesting weapon - any future open source efforts by developers who saw the shared source could be liable to suits given this precedent. It's an interesting potential issue; I wonder if corporate lawyers will try to use this.

It's clear what The Register means here, but I have to hand it to whoever put this eye grabbing headline up:

Spam and porn lift SurfControl

Yep, that one caught my eye and lured me to follow the link :)

Ben Hammersly notes that there are classes being taught on how to blog. Like he said, whoa

The Register pees on Oracle's cornflakes this morning:

As a leading influencer of IT strategy and directions, Oracle's IT vision is

• Data-Centric
• We're all heading towards one single enterprise database, and
• We are spending too much on hardware

For the first time Oracle appears to be seriously out of touch with the reality of IT architectural thinking. Most people would only agree with one of those three goals, and there is an alternative vision

Interesting takedown of a corporate level strategy.