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).
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:
- 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.
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.
- 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"
- 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
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
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.
- 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.
- 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.
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. 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
- 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.
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 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".
- Object Identity
- Querying support
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
- 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.
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.
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: 'firstname.lastname@example.org']
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)
- 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.
- 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
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
- 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.
- 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.
- 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 :)
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?
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.
- 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.
- 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
- 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
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.
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
And I'm not talking about the international variety. Check out this thread if you don't believe me...
If you have used the installer for BottomFeeder, you will have noticed that the startup directory - as set for the start menu - was not correct. This was due to my not understanding how to set that properly in the NSIS installer I'm using. I just fixed that and uploaded the updated install package - it's all good now.
Mind you, if you have already installed any version of BottomFeeder from 2.8 up, there's no reason to do a full re-install - just stay current via the upgrades menu pick or toolbar option.
CNet has an interesting article on server adoptions - they are reporting that Windows 2003 Server is stealing market share from Linux. If nothing else, that that runs completely counter to the conventional wisdom.
Microsoft has seen a 300 percent increase in the last three months in the number of Web sites hosted on its recently launched Windows Server 2003 -- with a considerable amount of the new business representing moves away from Linux, according to a survey published this week.
The figures are a win for Microsoft, which dominates the desktop operating system market but currently rates a distant second to the open-source Apache, often running on Linux, in servers. Open-source software is not controlled by any one organization and can often be obtained and maintained far more cheaply than proprietary software.
The number of active Web sites hosted on Server 2003 tripled to 88,400 in the past three months, according to Netcraft, which monitors server use. A significant portion of this growth has been at the expense of the Linux operating system, with 5 percent, or 8,000 sites, having migrated from Linux.
However, note that later in the article, it's noted that there are 4.7 million websites using IIS, and over 13 million using Apache - so while this activity is certainly interesting, it's happening in a small part of the overall market. IMHO, this isn't a bad thing - it represents competition in action - the Apache folks are ahead, but will have to work to stay there. Nothing wrong with that.
For about 6 months now, our dishwasher has slowly been breaking down. The various baskets on the inside developed gaping holes. The door stopped being able to lock closed properly. It got loud. The door was a pain in the butt - I had a "trick" for getting it to close and start, but my wife and daughter couldn't figure it out - so while I was at Smalltalk Solutions, they had to hand wash dishes. This sort of accumulation of cruft makes everyone crabbier. The noise made TV watching more painful in the living room. The door not working right made every load a chore. etc. So we just got a new one installed - and boy, is it quiet! (it better be, for what I had to pay for it). The door closes, the noise is gone - all the parts inside are whole - it just lifted a bunch of cruft right off us. Sometimes, letting things go is not the answer.
"28 Days Later" was really, really good. It was tense all the way through - and it never really gave you time to "rest up" - things kept moving. It sort of runs like a cross between "Night of the Living Dead" and "Lord of the Flies". I fully expect badly done copies. Highly recommended.
Then go to the Public Store and load up the new ReportWriter package. It's a work in progress, so lend a hand
By now, you should have no illusions about my knowledge of HTML - everything I know could be fit onto a 3x5 card, with space left over. With that caveat out of the way, you'll notice a change in the way the content looks. A friend pointed out that the way I was using paragraph tags was just stupid, so I went through and transformed the whole thing to be more reasonable. I should just change some of the code transforms, but it's Saturday, and I wanted to escape that stuff for the weekend.
Via the Fishbowl comes this fascinating look at contract stuff - from Van Halen (the band), no less:
The contract rider read like a version of the Chinese Yellow Pages because there was so much equipment, and so many human beings to make it function. So just as a little test, in the technical aspect of the rider, it would say "Article 148: There will be fifteen amperage voltage sockets at twenty-foot spaces, evenly, providing nineteen amperes . . ." This kind of thing. And article number 126, in the middle of nowhere, was: "There will be no brown M&M's in the backstage area, upon pain of forfeiture of the show, with full compensation."
So, when I would walk backstage, if I saw a brown M&M in that bowl . . . well, line-check the entire production. Guaranteed you're going to arrive at a technical error. They didn't read the contract. Guaranteed you'd run into a problem. Sometimes it would threaten to just destroy the whole show. Something like, literally, life-threatening.
Now that's entertainment - using a seemingly pointless contract clause as a "canary in the mine" test. I wonder how many contracting firms do something similar?
In yet another example of reinventing the past, we get a link to Oracle talking about TopLink being added to the 9i EJB server. I found this via Manageability, as part of a rant about the lack of O/R features in most EJB implementations:
What's even more amazing, is that people keep asking "What's missing?" It's as if EJB 2.0 was the greatest thing since sliced bread and that they can't conceive of any shortcomings. When I try to mention two little tidbits like "optimistic locking" and "object relational mapping" features, I get ignorant remarks like "It's already there!".
Yet another instance of software that already existed - many, many years ago - being noticed by the Java masses, who somehow seem to think that it's all new. The way I figure it, somewhere in Armonk New York, there's a 75 year old mainframe guy who spends all day laughing. He should get together with Alan Kay for a beer...
Wants you jailed, that is - if you are caught file-sharing in unapproved ways. Check out The Register's take on this. This has all the hallmarks of a "let's make a few examples" campaign.
On Friday the lobby group that works on behalf of the large, mostly foreign-owned, music conglomerates that own the music copyrights and distribution channels confirmed that it was serving subpoenas at the rate of 75 a day on US citizens for the crime of sharing the music they love.
The Register is out of the UK, so foreign in the context of this article likely means American.
Lambda the Ultimate references this story - where a security analyst is quoted:
It's not surprising that the flaw found its way into Windows Server 2003, said Russ Cooper, an analyst at Reston, Va.-based TruSecure Corp. and moderator of the popular NTBugtraq mailing list. "For all its work, Microsoft knows that solving the buffer-overflow problem is not going to happen," Cooper said. "They can reduce the number, minimize the effects for some services, but [neither] they nor anyone else can get rid of them, no matter what hype is associated with it."
Sort of explains why MS is trying to map all their API's up to managed code in the .NET framework :)
I spent 2 1/2 years in the trenches as a teacher, so this essay was interesting to me. I'm not sure what I think about his ideas; I can definitely identify with his administrative issues though. While I was teaching, actual backup from the school bureaucracy just didn't happen - as a teacher, you either have the help of the parents, or you have no one - don't expect help from the system. I often tell people I left because of the money (going to work for the US government actually got me a significant pay raise!) - but that was only part of it. Trying to make a difference in a system where too many parents don't care at all, and where the system doesn't support you as a teacher, is deeply frustrating. I taught in an urban district, and that had a lot to do with the lack of partental support - nearly every student I taught came from a broken (or worse) home.
There's something to what the author of that essay said about learning disabilities though. I was teaching what New York State called compensatory education - in my case, mathematics. I was trying to catch kids - 6th, 7th, and 8th graders - up to grade level. Out of 120 students I had my last year, exactly one was actually slow. He was a sweet kid - less trouble than all the rest - and also dumb as a post. Not his fault; he was clearly born that way. The rest of them though - that was an entirely different story. They came from a background of social promotion and families that simply were not interested in education. Calling the parents in those cases on matters of discipline or educational performance was just a losing game.
After awhile, all of that - combined with the pay and my first year (which had been a classically bad experience) - drove me out of the profession. I'm not sure what keeps people in the job anymore.
Sometimes you want to remove a bundle from Store, without removing any of the constituet packages - maybe you decided the organization was wrong, for instance. There is no menu pick for this, but it turns out to be very easy to do:
bundles := Bundle allNamesMatching: 'BundleNameToRemoveHere'. GarbageCollector removeBundles: bundles packages: #()
And that's it - the packages will all be there, but the bundle definition disappears. Not hard at all!
While I'm catching up on news this morning, I stumbled on this:
It happens all the time. You're in a hotel room, with a nice fast DSL or cable connection, but no mail relay.
Actually, I have the other end of that problem. I have a mail relay to use, but rarely find a hotel with fast connections. Where is he staying?
If Web Services are the next big thing, then why is Mark Baker right?
Back in May, I was worried that my prediction that XMethods would list less than 400 available services may not come true, as 358 services were listed back then. I just checked the number now, and it was down to 342. I'm not sure why the dip
Oh heck, just what we need here on the east coast - more rain. Right then, I'll just go back to building that ark...
By the time you've made HTTP + XML do all the things developers need for real-life systems, HTTP + XML will be just as complex [as Corba]; it's inevitable. What annoys me is that catch-cry of "look at how easy this is!", with no-one crying "yes, and did you notice how little it can do?"
He's got a point. The only difference is that we now have a fat textual format instead of a binary one. That's either an advantage or a disadvantage, depending on who you ask...
Mark Pilgrim has a post on things an aggregator should support. BottomFeeder does everything on the list except digest authentication (which is what? I have no idea). I do vary on two error conditions:
- 500 (server error) - I ignore this and treat it as a no updates available situation
- 404 - I treat that the same way. If I get 'enough' of these with no updates, I mark the feed black in the UI as a hint to the user, leaving it up to them.
Why not unsubscribe immediately? Because - in my experience - both errors are transient far more often than they are permanent
Via Sean McGrath comes this interview with Bruce Eckel discussing Python. There's some interesting talk about productivity relative to Java - similar to what us Smalltalk folks have been saying for a long while now. IMHO, the Python and Smalltalk communities should be closer - each language has optimal uses, and developers familiar with one should be pretty happy with the other. Sure, there's overlap between the two in terms of "best tool for the job" - but the two camps have a lot more in common with each other than either does with the Java hordes :)
You have to hand it to Sun. After C# came out, they decided they had to add features. As one of the Java bloggers points out, they added a mass of complexity. Templates (like C++), additional keywords to muck things up - the works. They really don't get this simplicity thing. There's Smalltalk and Python and Ruby as examples of simplicity and power - and there's the Sun crew, not understanding a bit of it. Meanwhile, there's Gosling discovering the power of parse trees - apparently, he's under some delusion that doing that kind of thing is "new" and "radical".
Come on over to the dynamic language side of the fence guys - the productivity is great, and the complexity is low. You might even save your job from being outsourced :)
Question spotted on a Java blog:
"Will it be possible in the future to fix a bug and retest without stopping the debugger?"
yes, the clue meter continues to read zero.