Chris Double talks about stackless operations, showing a process that migrates back and forth across systems as an example. I've done this in Smalltalk, with a stack, using BOSS to serialize a process, send it across the wire, and have it run. I suppose I could make it come back the same way...
Scoble says he wants a feature I don't follow:
Anyway, here's a feature request for the Outlook team: I want a magic folder.
What would this magic folder to? It'd post to my blog everything I drag into it.
What does that mean? It would repost the content? Post a link saying "Look at this?" Typically, when I want to blog something, I want to comment on it...
PR Opinions talks about the big screwup Coke made with Dasani in the UK. This brought to mind this post from Ted Neward - a bad customer service story. Here's the kicker - it used to be that bad service, or even a bad marketing campaign, had limited fallout. Now, it's potentially global:
It's also and interesting example of how the geographical barriers for crises are falling, this story has been covered all over the globe: UK Story, US Story, Australian Story, New Zealand story, African Story.
Marketing and PR people have to be very careful now. Heck, everyone does. Just look at how far this John Gray suit threat story has spread. Things can get lost on the web - or they can blown up into super-sized stories. It's a new world out there
Here's an announcement from STIC on StS 2004:
In just a few short weeks, from May 3-5, the Crowne Plaza Hotel in beautiful Seattle, Washington will play host to Smalltalk Solutions 2004.
Early Bird Discount!
Remember to sign up before April 3 to receive the early registration discounts. Current STIC members receive a $75 USD discount for the conference. You can easily join STIC or renew your membership while signing up. To register, visit: http://www.smalltalksolutions.com/registration/register.htm
Conference Exhibitors and Keynote Speakers
Some of the top companies in the world of Smalltalk will be exhibiting at this year's conference, including Cincom, Gemstone, Knowledge Systems Corporation, IBM, and many more.
Our three keynote speakers this year are Avi Bryant, Lars Bak, and Microsoft 19s George Bosworth. They will be offering insightful, dynamically charged presentations discussing such fascinating items as Smalltalk in web development to making embedded systems serviceable.
An Educational Experience!
The conference will also offer informative, in-depth, educational tutorials as well as discussions and information on future Smalltalk plans and directions.
When you register for the conference, don't forget to book your hotel. Smalltalk Solutions will take place entirely within the Crowne Plaza Seattle hotel. Make sure to mention you are attending SS 2004 in order to receive a significant hotel discount. Hotel rooms are booked on a first come first served basis, so make sure to make your reservation right away. More information can be found at: http://www.smalltalksolutions.com/hotel/hotel.htm.
26 Add a Little Entertainment and Socializing!
Keep your Tuesday night open while in Seattle because the STIC has planned a fun-filled night for conference attendees at the world-famous Seattle Space Needle. We have reserved a banquet room high above the Seattle skyline for you to enjoy. Hors d'oeuvres and drinks will be served starting at 6:30 p.m. followed by a delicious dinner and entertainment later in the evening.
May is right around the corner and the conference will be here before you know it. Don't forget that registering before April 3, 2004 can result in significant savings to you!
To register, please visit http://www.smalltalksolutions.com/registration/register.htm.
We look forward to seeing you at Smalltalk Solutions 2004!
The Smalltalk Industry Council
See you in Seattle!
OpenAugment: Preserving Engelbart's Augment Legacy
Tuesday 9:15:00 am to 10:00:00 am
Abstract: Created in the 1960's by Dr. Douglas Engelbart and his imaginative team at Stanford Research Labs (SRI), Augment is one of the most groundbreaking and important historical artifacts of the software industry. Many of today's desktop and network computing innovations can be traced back to the original Augment system. Today, the OpenAugment Consortium (http://www.openaugment.org/)is taking steps to ensure that future generations will have access to the Augment heritage through its open source initiative. This talk will describe the Augment architecture and the role that Smalltalk has played in its development. It will then trace the discoveries that drove the evolution of the current OpenAugment implementation. Bio: Jeff Eastman is best known in the Smalltalk community for his contributions to Smalltalk Object Request Brokers. A long time HP engineer and now entrepreneur, Jeff was involved in the formative period of the Object Management Group (OMG) and contributed to many of its early works. He later served on the staff of the Object Data Management Group (ODMG) and led their Object Model and Smalltalk groups through three major publications. Recently he has been working with the OpenAugment Consortium to preserve the works of the Augment team on a stable and open computing platform.
See you in Seattle!
Pollock : Into The Breach
Sames Shuster: Cincom
Tuesday 9:15:00 am to 10:00:00 am
Abstract: Now that Pollock, VisualWorks new GUI framework, is about to come out of Beta and into Production, it's time you learn what it does for you. In this presentation, we will demonstrate the capabilities of the Pollock framework, and how, even in it's first Production release, it surpasses the current framework capabilities. We'll present an overview the future migration and translation tools which will take most of your existing current framework code and move them to Pollock. We will be present the short term and long term roadmaps for the VisualWorks GUI. Finally, time at the end will be devoted to answering questions and addressing any concerns that Pollock somehow represents a disruptive technology change.
Bio: Samuel S. Shuster is the GUI Project Lead in the VisualWorks Engineering Team. After almost four years of thinking about, designing and working on Pollock, he is thrilled that the light at the end of the tunnel is so close at hand. So much so that he actually is making plans to take is first real vacation in almost 10 years... However, he hasn't as yet decided if he'll take his portable with him.
See you in Seattle!
I had a nice meeting with a customer this morning - they are using Smalltalk (VisualWorks) to schedule the trains for a large part of Germany. That was neat; the system has some very nice graphical pieces with very fast zoom in/zoom out capabilities. That was cool. Then I came back to the corporate (Cincom) office, where I find that the firewall has made life unbearable. All I have is port 80 - no SSH, no IRC, no non-corporate email access... it's like being cut off from the world. Is this what net access is like for most people who work in offices? How do people stand it?
Sci Fi Wire reports that Buffy (Sarah Michelle Gellar) will not be appearing in the finale of Angel. What will we do with no BuffVerse, and no Firefly?
I haven't posted much in the last few days - I've been visiting customers, going to meetings, and generally been without good connectivity. That should change as I head back to the UK for ot2004, where I'll be speaking about RSS, XML, and Blogs. Assuming decent connectivity, I'll be blogging the talks I attend live - if not, I'll be batch posting.
Update: Simon Phipps was not only misquoted here, but the journalist who filed the story apparently did not even attend the talk. So it looks like the mud belongs on Julian Bajkowski of ComputerWorld, not Simon Phipps...
Now Here's an interesting story - Sun's Simon Phipp's is ripping Open Source opponents. Maybe he should call Scott McNealy - iirc, McNealy rejected Open Sourcing Java after IBM suggested it...
Only two years after publicly hugging a Microsoft executive live on stage, Sun's chief technology evangelist Simon Phipps has branded opponents of open source "Luddites" and predicted that the current proprietary vendor dominance will crumble through sheer collective will of a new generation of IT managers.
"The Luddites fighting the move to open source are certain to be defeated. Different parts of the software market may move to open source, at different speeds, but the move is an inevitable societal trend," Phipps vowed.
So if we should abandon proprietary software, should Sun open Java, or should developers shun it? Does Phipps pay any attention to what his company does at all?
Howard Ferch takes on a development management issue at StS - how do you manage multiple version streams of the same project? Register today and find out!:
TAPDance: a system for maintaining multiple versions of software
Howard Ferch: LynxGL
Tuesday 2:00:00 pm to 2:45:00 pm
Abstract: In order to produce multiple versions of packaged and customized software systems we have developed a system which isolates the user look and feel and database representation from the processing logic. This system stores the definition of all of the user interface in a database, which is read and analysed at runtime. The entire system is written in Smalltalk, and the talk will describe the design goals, how Smalltalk met those goals, and how we use the Smalltalk language itself as a GUI representation language to minimize our efforts in building multiple versions of user interfaces.
We will demonstrate the flexibility of the system by showing how the same executable will provide two different customizations of a Fire/Paramedic dispatching system, as well as a personnel roster system, and a reporting and modelling system.
Bio: Howard J Ferch, PhD, Computer Science, 1978. Currently President of a small software company developing high availability systems for fire and paramedic departments.
See you in Seattle!
I need an FAQ.... Ryan Lowe confuses strong typing with declarative typing:
Paul Vicks makes a good point when he says that generics make strongly typed languages even stronger, and this seems to go straight against the new wave of weakly typed languages like Python and older ones like Smalltalk.
Sigh. Smalltalk is dynamically, and stongly typed. You cannot get a type error in Smalltalk; if you send a message that is inappropriate, you get a well defined exception (which can be handled). We don't lie to the compiler either (Casting, anyone?). He later asks what the advantages are, pointing to some nice refactoring capabilities of Eclipse. The advantage is that I can define objects in ways that make sense - and have them conform to a specific protocol API. The advantage is that I don't end up with overflow situations because someone decided that 65,535 of something was all I'd ever need. I don't wind up with essentially random types being assigned to objects, just because some type has to be assigned... which makes the whole system more flexible.
Slashdot notices Slate, a Smalltalk-like system driven by ideas from Self, Smalltalk, and Scheme. As usual, many of the curly bracer commenters seem unwilling to even think about a system that doesn't use curly braces and semicolons :)
Danny Ayers is working on an RDF API for Smalltalk (Squeak in particular). I expect that'll port to VW pretty easily :)
Georg Heeg: Georg Heeg eK
Tuesday 2:00:00 pm to 2:30:00 pm
Abstract: Smalltalk on Windows CE is the next step toward's Alan Kay's dream of the dynabook of 1973 when Smalltalk got started.
Bio: 50 years old, founder of Georg Heeg eK, Germany oldest Smalltalk enterprise.
See you in Seattle!
I attended an interesting interactive event this afternoon - "Seeing the Forest for the Trees". It was a long (1 pm - 6:30 pm) session - very interactive, and very interesting. I have a lot of notes from it, and I'll be putting up a lengthy post on it later. If I feel ambitious, I may use paint to create pictures for it :) For now, off to the reception
I attended an interesting session this afternoon - Seeing the Forest and the Trees by Martine Devos and Diane Gibson. I've never attended a session quite like this; it was interactive, and a half day (1 pm - 6:30 pm) long. It didn't feel long though; the session flowed very well. The women running the event are R&D people, who work mostly on team focus/communication issues. We got an inkling of that in the first ice breaking exercise:
We split into pairs, and we were told to see how high we could score in thumb wrestling. So, we all went at it, competitively. Then Diane and Martine showed us that by cooperating and taking turns, we could score higher - as a team. That set the tone for the rest of the session, and most of us were pretty well hooked.
That led to introductions - everyone selected a picture (from a large set of postcards) or a small stuffed animal as a metaphor - either for themselves, or for what they did at work, or for what they hoped to get out of the session. I picked a picture of the Milky Way, with a "You are Here" pointer to the Sun (as with Smalltalk, "out of the mainstream" :) ). The selections were interesting:
- A bear with a duck swim flotation device - this person was just hired to be a team lead/team builder, and he saw it as unfamiliar territory - like the bear.
- A bat - "Wraps around a problem", has powers that others lack (night flying, etc)
- Mine - out of the mainstream (but highly useful!), just like Smalltalk.
- Next person - a picture of a girl lying on top of a chalk outline of a bike in the bike lane. This guy was going to be a team lead, and he was hoping for some help/direction - from anywhere
- A Zebra lying down - but the animal was actually a bear in a zebra suit. So is it a bear, or a zebra? The idea is that this represented the ability to talk about a subject w/o actually talking directly about it.
- A person working on a project that cuts across operational boundaries, and which may become a product (for sale). Picked a loud, green frog - said it looked troublesome, like his project
- Working on product design - selected a pink elephant. The product is for traders, who need short term answers, but within the context of a long term solution. i.e., the conspicuous "Elephant in the room" needing discussion
- Martine selected a starfish - "Likes to be the star". The Starfish is actually a wrapper ona different character - "fear of failure"
- Picked a Red Fox - need to look "outside the box", beyond the normal context for project solutions
- Diane picked a jester - funny, but also a truth teller
- 2 pictures of an eskimo - this guy had been to Greenland in the winter (something he said we should all do!) - and that reminded him of his project, which is being developed and deployed in multiple countries. He's the project architect - gathers requirements, gets credit/blame - works with people in a foreign (to him) country - thus the picture of a "remote" people
- A Purple bat - Flies in the dark (like her new job - no clear idea of her role yet). Hoping not to crash into anything, company is experiencing rapid growth (120 - 200 in her area the last year) - lots of issues to deal with. Bat can also "completely hide itself"
- Chicken - hiding inside is someone doing a workshop later this week
- Monkey with a red snout - consultant on a large project. Thousands of people, hundred in the IT dept (at this company) - hard to figure out what is going on - many people working "like a group of apes in a forest"
- Picture of a jazz band - individual players who come together for a gig - like a project team
- Lion - "King of the Jungle" - Stalking problems in the system, Focus on them, kill them, sleep in the afternoon. "beast of power"
- a Six String guitar - no expectations for the workshop, decided to come on a coin toss. Strings are for making music - must be played together and "in tune". Have to make a willful effort to get people to work together well
So, after the introductions we were asked to rate (personally, and on a communal board) this activity and all activities of the day on this scale of questions:
- How do you feel?
- What Happened?
- What did you learn?
- How does it relate to your work?
- Any "What ifs" or "What Nexts" ?
That took us to an interesting problem in scaling. We were given two decks of cards, which were mixed on a table. Two people were picked as implementors, one more as a customer. The customer determined how the cards should be sorted, and then the two implementors had to execute that while being timed. Here's what the customer wanted:
- Red deck on top
- Blue deck on bottom
- Cards within a suit sorted, Ace low
- Suits ordered by clubs/diamonds/hearts/spades
The two people each sorted a pile, and then they sorted the suits, one suit per person. That took 5 minutes, with some of the time engaged in planning. Then we got all 14 of us together, with 7 decks of mixed cards. The decks were different sizes as well, so a requirement that they be stacked biggest to smallest was added. We had to determine a process to use, which was simple:
- Each deck was sorted from the mixed pile by one person
- That person dealt out the suits to 4 other people
- Each person receiving a suit sorted numerically
- The individual decks were recombined in the right order
- The decks were peoperly stacked, and ten presented to the customer
We made some mistakes, which needed correction. This all got us into an interesting discussion on the value of Q/A and of up front planning. That got into the differences between manufacturing (which this was like), as opposed to software development. We talked about how we ended up with an emergent plan from emergent, ad-hoc project leaders. That ran through the rest of the day. So we determined that the 2 man job was ad-hoc, with an emergent plan. The larger team developed a pipeline approach, developed by a few emergent team leads. We decided that having someone check the order before turnover (Q/A) would have been useful. A few questions came up:
- Would written requirements have been better? No, but possibly had it gotten more complex
- Would more people have helped? We thought not, even woth more decks (unless we got more than 14, the number in the whole group). That would have bogged down our first step).
So ultimately, we found leaders and ended up with emergent design/planning. Sort of XP like, a few people thought.
That was maybe the first 1 1/2 - 2 hours. I'll post more of my notes on this tomorrow; It's late here (almost 2 AM!), so I'm off to bed.
After a break, we had a new game presented to us - this one was designed to demonstrate the kinds of communication issues that can crop up. Here's what we got:
We had one person on each red space, one person on each blue space. The goal was to get the people switched from side to side, given a set of rules:
- You can move forward one space
- You can "jump over" (like checkers) a person so long as they are facing you (started on other side)
- Each person was given one bit of the rules, and they could only be described verbally (we couldn't throw them on a table and all read them)
- The space we used was all in the hall (i.e., narrow). It was hard for people on one end to hear those on the other)
- When trying to do the move, we could not talk at all
This meant we had to practice. We did that using cards, and came up with hand signals for use during the actual run. We found that doing the practice run face to face with cards was invaluable - we then executed the actual run flawlessly. A few things we saw:
- Not everyone was playing - those observing affected the system - a "Heisenberg effect"
- During our planning, no one got frustrated - one guy immediately figured it out. Thus, no one grabbed a deck and went off by themselves.
- We knew it was possible (some had played before)
This was something of a metaphor for communication problems - the hall was like coordinating by phone instead of having a direct meeting. This led to a discussion on offshoring, and how communication would be an extra problem.
Anyway, more later - the keynote is beginning
We had another break, followed by a discussion on capacity. In this sense, capacity means how much can be done in a given stretch of time. This of course gets matched up (not often well) against expectations. We spoke a lot about the tendency of management to exert "work smarter, not harder" pressure (which leads to overtime). I noted that it's not only management that does this - engineers often do this to themselves via a congenital inability to say no to any new, interesting task that floats by them. So this led to another game:
Here's the rule - On each card there's a letter on one side, and a number on the other. How many cards have to be turned over to prove this assertion:
Is there always an even number on the other side of a card with a vowel on it?
This is an exercise that has apparently been done with lots of people, across loads of different domains (software, scientists, etc). It's common to get it wrong; the answer is left as an exercise to the reader :)
This led to a break and a short diversion - we paired off, and one person drew two circles on a page. We then took turns, and then ended with a name when anyone paused. What we got was an emergent diagram - the metaphor being that projects can fail simply through fear of saying I don't know to something. That took us to a discussion of project failures - but I'll get to that in the next post
So on to the "last lap" here. We had kind of a "roundtable" on problems that we've seen, been near, or helped create - that then led to project failure and/or crisis. So:
- Toot your own horn - if you don't, no one else will :) "Heroic" acts (often as a result of the "hero" screwing up) get rewarded - steady, good, quiet work rarely gets recognized
- Social success (golf with the boss, for instance) often leads to more success than does actual work
- Fixing the wrong problem
- Doing a project with new/trendy tech because management read a magazine, or the developers want to refashion their resumes
- Sticking with old tech for too long so as to stay in a "comfort zone"
- Death marches in general
- Announcing a launch date before there's a contract or requirements (Consulting firms!)
- Ill advised mergers - of corporations or internal teams (not that I've seen that :) )
- Focusing efforts on bug fixing to the exclusion of all else, w/o ever really paying attention as to whether the fixes are making customers happy
- Tensions between sales/marketing and engineering - either engineering taking too long for some "perfect" system that never arrives (hurts sales), or sales demanding customer specific fixes that may not be generally applicable - and thus disrupting new development
We drew a picture of that one:
The " " signs indicate pressure from one end exacerbating problems on the other. What you need is less "over the wall" and more face to face (issue for many offshoring projects, in the opinion of the room). We had another diagram that entered into this:
That diagram is trying to show the relationship between work that gets done, work that gets done with issues, and productivity - one can design models to predict where the "best" place to fix things are - but there are always tradeoffs.
That's about it - it was a great session, and I've only captured a pale shadow of it here. I'd welcome expanisons by any of the other attendees!
I've had people telling me for quite some time that I should be looking at Mock Objects - so I've decided to attend a morning session on the subject. I've done ad hoc mocks, of course; most Smalltalkers probably have. This talk is more specific though - there's an example to walk through
The example is a stock trading application. The presenters are using a TDD approach and a Mock framework for Java. One thing that falls out of this is that the Mock framework represents a code specification - an outline of the interfaces and API's that will need to be created. Interesting side point on the mock framework - it's a Java port of a Python port of a Ruby framework - both of which, according to the presenters, are simpler. Always the way...
One interesting fallout - more of TDD than of mocks, but having convenient mocks makes it easier - is that code smell is easier to detect early, when refactoring will be simpler.
Misconceptions about Mocks
- Mocks are just stubs
- Mocks should only be used at system boundaries
- They advise using the real (database, etc) at system bounds instead. Use mocks for internal systems (i.e., those which you have control over). So you would mock your interface to an external system rather than the external system.
- Gather state during the test for asserting at the end
- Testing with mocks duplicates code
- Mocks inhibit refactoring due to many tests failing together (countered by the example)
- Mocks should contain behavior that simulates the runtime environment
- Mocks should be a specification for what happens, not a specification for how it happens
Assertions - Lessons about Design
- Need-Driven, top-down design leads to a leaner system with higher business value
- ed - What?
- Create interfaces for the services an object requires, not to represent all the features an object provides
- Only mock objects you can change
- test how object references are passed around the system
- Getters are evil, setters less evil
- ed What?
- Visit, don't iterate
- ed - A Java issue :)
- Too many mocks?
- object is doing to much - refactor
- Cannot introduce a mock to an object?
- See above :)
Questions from the audience
- Where does architecture fit in?
- What about creation of objects
3D CAD Framework for Smalltalk
Tuesday 2:45:00 pm to 3:30:00 pm
Abstract: 'StCAD' is a basic 3D CAD framework in Smalltalk (VisualWorks 7.x). It extends the GF/ST 2D drawing framework into 3D. It also include 'StGeo' which is the 3D geometric domain, 'StMath' which provides the mathematical support for 3D CAD and motion simulation computations, and 'StDoc' which is a simple word processor. 'StMath' is also suitable for engineering, scientific and business computing. The parcels are open source using Lesser GNU Public License. Users can use these parcels with other private software to create 3D applications like motion simulation, finite element analysis, CAD, scientific visualization, etc.
'StCAD' allows users to create and manipulate assemblies, which are collections of 3D parts. The parts are 3D solids, which can be connected by joints, constraints, contacts, actuators, springs, dampers or forces. The parts and connections define the structure or mechanism that the assembly is meant to represent. Animation is possible, if the user can provide time series of position and orientation data for the parts.
Users can also obtain output data in the form of plots and tables. XY plots can be zoomed and set to equal scales. Data series available include linear and angular displacements, velocities, accelerations and other user generated data.
'StCAD' has been used to create a freeware called 'freeCAD' which is a 3D CAD with Motion Simulation. The parcel 'StMbD' has been included to provide a functional demonstration, but its source code is hidden. For more information visit: http://www.askoh.com
See you in Seattle!
I came in late on this talk - I had to drive to Maindenhead for the afternoon, and just got in after about 20 minutes of the even was done. So here I am - and he's talking about AOP (Aspect Oriented Programming). He sees it as the next step up from OOP - not as big a step - OO from C (etc) was a much bigger step. He sees AOP as a great way to separate concerns, and sees a direct correlation with Use Cases.
Question - While RUP is not the same as Objectory (a side question), what got lost/changed? Objectory 3.8 became the Rational process 4.0 (and then evolved forward from there). Anything lost? A few technology things that he had to accept, never happy with the complexity of architecture in RUP. Analysis was diluted in RUP - partly because it's hard to support via tools (ed - nothing to sell :) ) - so they ended up shortcutting there. Scrapped analysis because it did not fit in Rose (modeling had been supported in Objectory). There are actually still Objectory users (people do like Smalltalk tools :) ).
Objectory looked at the system as a set of models. A lot of things changed in the Rational tools (into view concepts). We identify models, so renaming the concepts was a little overkill. Does not like the term "Executable Architecture". The architecture should remain stable, while models and code will evolve.
Question - What about MDA? Are models (possibly in UML) just high level programs? Even those who are opposed to MDA are actually modeling - it's what we do. MDA means that we create a platform independent model (an architecture). While there are people trying to work on model to code compilers, thus far we only have one way systems, very limited, no real environments. Likes the idea, but thinks we aren't there. Those waiting for MDA are speculating with their company's money.
Side note - modeling survived from Objectory into RUP. Objectory did not handle project management - cared about modeling. In 1989, Objectory sold for $22k per seat. Sold 300 licenses.
Question - Most people associate Ivar with Use Cases. What is he most proud of? Never thought that Use Cases would be so well known and important. Very satisfied with that. Introduced component based development to Ericsson in 1968 - Sequence Diagrams, beginnings of message passing between components - a lot of things that became the foundation of later work.
Question - Which innovation earned the most money? The mistranslation of the original Swedish would have come out "Usage Case" - having it come out as "Use Case" worked.
Question- Professionalism in Software Engineering - with XP and Agile, more emphasis on craft/art - we don't seem to aspire to engineering. Is that forwards or back? The split view of software as a profession or craft has always been there. Progress is up and down - one of his favorite languages - Smalltalk - is coming back. Has worked to understand how to develop software and identify models and processes to simplify it. Ivar believes that it is an engineering effort whereby we can learn to be better. Refuses to believe that it is a craft at which only a few can be good.
Question - "XP Doesn't help you grow an organization" (quote from Ivar). Lots of good in XP - agility and speed. Has always viewed his work as improving agility and speed. The idea has always been to understand and model the steps involved. XP is substantial in terms of what we can gain from it. XP is something Ivar would use for every new project he would start up. XP has put together a lot of pre-existing good ideas. As soon as something succeeds, we need to grow the organization. The original team will leave - can a lightweight process support the ongoing development and maintenance? His new company, founded with his daughter and developing intelligent agents - uses a lightweight RUP. User Stories (Use Cases). Used Analysis, some model driven design, did most of the work in code. As the project grew, they needed more processes.
Does not disagree with XP - the knowledge is in the heads of people, and if they leave, away it goes. A process like RUP leaves that knowledge behind to be picked up. So XP is a way to begin, but not necessarily how to proceed at all times, especially after growth. RUP does not need to be heavyweight
Question - Any (technical) regrest? Got this question at an OOPSLA conference. Good friend of Dave Thomas. In 1988 he was visiting Ivar in Sweden. Looked at Objectory. He suggested two things:
- Write up how Use Cases work in 125 pages or less
- Let me design a tool for you that supports it, for $100k
Thought that writing such a slim book and such a slim tool was not useful. Thinks now that it would have been fun and useful
Question - What are you doing next? Look at automation (all of software is about automation). Look back 100 years - Ericsson did first switch in 1923 with relays. When he joined, each new feature became much more expensive - software got around that. Now, we are back to the point where adding new features are getting to be more and more expensive. How much of the software we get (in phones,etc) do we really use? 10 percent? 20 percent? We need active software that figures out what you want to do and teach you (instead of passive tech, like what we have now). His company (see above) is in that space. Thinks this will take awhile, and keep us all busy :)
I'm with Matt Croyden on this - I'm likely going to buy one of these real soon...
The Pomo Blog reports on the growing importance of the net - relative to TV - for young people:
My youngest daughter (13) was talking about "away messages" and her AOL Instant Messenger last week, so I thought it was time to Google. Apparently, there's a whole cottage industry developing for away messages, and sociologists are studying why. It seems that young people want to live simultaneously in the real and cyber worlds. This is especially true on college campuses. Clever away messages allow a student's "presence" to remain online while they're attending classes. The Web's social network capacity is unlike anything we've experienced before.
Maybe that's why last week's Edison Media Research/Arbitron survey showed 54 percent of people aged 12-24 would rather give up their television than the Internet. This is a significant generation gap, for their parents would rather do the opposite
heh. Maybe I'm not so far gone; I'd rathe lose TV than the net. I see the effect with kids as well. My daughter (13) spends a lot of time on NeoPets (as do most of her friends) and on IM. And she is adamant about leaving away messages and the like. It's a brave new world out there...
Immo Hüneke was kind enough to share his notes from Ivar's talk - he didn't miss the beginning. His notes:
An evening with Ivar Jacobson
Bruce Anderson introduced Ivar as someone very well known in the industry - best known for the introduction of Use Cases.
Q: Do you think that the move from text-based to more highly structured use cases is a step forwards or backwards?
A: It's a step forwards! We need structure in requirements. Anything else sends you to sleep in two hours. But I'm cautious not to formalise more than necessarily. It's easy to formalise, but very hard to get the right formalism. With experience of Vienna Development Method (VDM) and other formalisms, I believe that "some structure" is appropriate.
Q: Is Use Cases the universal method for expressing functional requirements or is there anything else?
A: There are things better expressed using mathematical formulae, spreadsheets or anything else - but such expressions should probably be attached to a use case.
Q: What about something like a video-game, which is very state-dependent?
A: Probably just one or two use cases there - "play the game". The radio in a Volvo car was described button by button in the manual: I could never learn how to work it. It would be nice to see appliance manuals structured along Use Case lines.
Q: Would such a use case be structured along the lines of what actions the user wanted to do in the game, e.g. "kill adversary"?
A: People use state charts, activity diagrams, screenshots etc. to describe the use-case. The documentation should be anchored in something concrete, not floating in semantic emptiness. Use an object model (we call it analysis). The analysis model is more precisely expressed than the use case model. It uses activity diagrams, swim lanes etc. to express the realisation of each use case more precisely.
Q: What about XP then, which just uses stories and goes straight to code?
A: That's a lightweight process, which can be used to generate rapid prototypes. Lightweight use cases are appropriate for a lightweight process.
Q: Sticking with requirements, how do you deal with the distinction between functional and other requirements? Is this a good categorisation?
A: In most cases, this distinction is useful. Most of the non-functional requirements are specific to one use-case (e.g. performance - making a telephone call has one performance requirement, hanging up a call has another).
Q: But what about qualities that have to apply to the whole system?
A: RUP puts these in a document called supplemental requirements. But security (an infrastructure requirement) is well accommodated within the Use Case structure. Aspect-oriented development has become quite popular for infrastructure requirements.
Q: Why has aspect-oriented become important?
A: Separation of concerns. Security can be dealt with separately, without even talking about specific applications. This can be traced to code and tested separately from the rest of the system. Every new feature (e.g. follow-me service, directory enquiry) can be specified separately but has to be integrated into existing code that handles telephone calls. Result: scattering and entangling. This is the nature of the systems that we have lived with for 20-30 years. Aspect-oriented approaches allow us to escape from these impacts.
Q: But what has this got to do with use cases?
A: A quite simple but powerful mechanism, which allows us to keep the use cases separate. In the future, we will be able to develop, deploy and test each use case in isolation. They can be composed to build systems rapidly. It was a huge step to move from structured to object-oriented languages, but this switch to aspect-oriented is just a refinement.
Q: (JD) Bruce, did you understand that answer?
JD: then it's just me!
Q: Before you started work for Rational, you were successfully promoting your own method, Objectory. Is RUP just Objectory renamed, as you are quoted as saying?
A: I have never said that.
Q: Well, you must have had to make compromises with your colleagues when leading the RUP development?
A: No. But Objectory v. 3.8 was really RUP.
Q: Was anything lost in the process?
A: Yes, a few things - I was never very happy with the way we describe architecture in RUP. It is correct, but probably unnecessarily complicated. Another thing I miss is analysis - we do analysis in a diluted way. Today we can not have a process that isn't supported by a tool. The process is said to have been adapted to the limitations of the tools, but perhaps analysis has been removed because the tools didn't support it. For example, Objectory supports multi-modelling, while ROSE doesn't. There still are people working with the old Objectory tool.
There is a perceived distinction between Objectory and RUP. Business processes including the software development process itself are modelled in Objectory. When I first began to develop Objectory at Ericsson, they had a good process for component-based development. But all we could give programmers was templates - there was no guidance about creating good sequence diagrams, state charts, good components etc. So this was where we concentrated in Objectory. We ignored project management. Just to give you an idea why Objectory was well-liked: it was the only tool that gave you help with these aspects. The single user licence was $22K! Yet we sold over 300 copies. The most expensive copy sold was $1M.
Q: RUP doesn't support architecture very well, does it?
A: The way Objectory got developed, the system is modelled through seven or so models - use case model, analysis model etc. Even the code is one model. There was also a test model at one time. Today we talk about viewpoints and perspectives. Models are easier to comprehend. Architecture should be just the use of the models. This should be fixed.
Q: So should we have architectural views of each of the models?
A: Yes, to present the essential core of those models. I don't like the term "executable architecture", I prefer to think of it as version 0.1 of the system.
Q: Let's talk about MDA, another "hot" topic. Some people look on the MDA models as just programs in a very high level language. What's your view on those models in MDA?
A: Model driven development is usually seen as a positive idea. MDA is more specific: it requires you to build a PIM (which is analogous to the analysis model in Objectory). It is supposed to be expressed in an executable language. I don't believe it is ready today to develop production-quality code. One day we will get there - the platform-specific extensions still need to be developed. Anyone waiting for MDA to be delivered before embarking on a new development is playing a high risk game.
Q: Looking back over your career, is there anything you would prefer to be remembered for than Use Cases?
A: I never thought that Use Cases would be so important - I was quite surprised by their success. I think the most important thing I did was to introduce component-based development in Ericsson. We had sequence and collaboration diagrams, state charts on components. This helped to make Ericsson as successful as it now is.
Q: Which of your innovations has earned you the most money?
A: Not an innovation, but perhaps a mis-translation: Use Case was originally Usage Case in Swedish!
Q: Software Engineering Professionalism: XP and agile approaches in general seem to emphasise the art/craft aspect of software development rather than engineering. Is this a step backwards?
A: Large groups of people have always viewed software as a craft - actually the proportion that views it as engineering is growing steadily. Languages go in cycles - Smalltalk is coming back into fashion. Tools are getting more powerful because we understand software engineering better. All my life I have worked on understanding how to develop software. I have worked with models and process to simplify it. It is engineering more than an art form. You can't be trained to be artistic, but I refuse to believe that only the select few can be really good at software development.
Q: Another quote is "XP doesn't help you to grow an organisation". What did you mean by that?
A: I can't remember saying this. In the context of the quote though, it makes sense. I believe that there are lots of good things in extreme programming. It has put the finger on agility, which was not explicitly addressed by my processes. However, the whole purpose of Objectory was to codify knowledge of how to create good software, with the aim of making the process more reliable and faster. Knowledge has to be applied, yet RUP by itself doesn't apply anything. You not only have to know something, you also have to be smart in applying it. I would use something like XP for every new product I worked on, because you have to start small. There isn't anything in XP that people haven't been using for 30 years, but it has put them together in a very nice way. As soon as a product is successful, we have to grow beyond XP processes in order to prevent loss of knowledge as people move away to other projects. You can use RUP in a very lightweight manner to support an agile process and then grow it. For example, my daughter and I recently developed a rule-based product based on intelligent agents. She had no need to use RUP, but did so anyway, and it is growing with the needs of the company now that the product is becoming successful. A shortcoming of XP is that knowledge is not explicit, it stays in people's heads. RUP makes knowledge so explicit that it can be automated using rules - which is what the product I mentioned does.
Q: Is RUP heavyweight then?
A: You can use as little or as much as you like.
Q: What do you regret not doing differently?
A: At OOPSLA, I got the same question. There are a couple of things. Dave Thomas is a very good friend. He visited me in '98 in Sweden. He had looked at Objectory and felt very positive about it. He said I should write a very thin book (125 pages at most) about Use Cases. He also urged me to let him develop a tool for it for $100K. But with my Ericsson background, I thought that writing such a thin "stupid" book and developing such a small "stupid" tool was not something I would ever do. In fact it could have been a lot of fun.
Q: What's on the cards for the second half of the Jacobson Career?
A: If you look at software and automation in general today, how has it advanced in 100 years? Ericsson's first switch in '23 was built out of relays, which was the dominant technology from '00 to '50. Joining Ericsson, I felt that we were nearing the top of the S curve. Software was the answer - it made it easy to add new features to switches. However, we now are reaching the limitations of software. Every piece of equipment you now buy comes loaded with software, most of which we cannot use because some idiot designed the user interface (passive software). We need to move towards active software - which can intuit what you are trying to do and help you to achieve it. Software that can help you to improve the way you do things and shorten the path to success. Active software is coming into all kinds of applications already and is going to grow.
This session is going to talk about:
- What an XP story is
- How stories differ from Use Cases
- Where analysis fits in the XP Process
On site customer - proxy for all the stakeholders (ed. - politics). The on site customer is used instead of documentation.
Q - What about maintenance phase, which is 80%? What about doc for that?
XP - XP is weak in this area.
On site customer needs to know the system requirements, Communicates context, required outcomes. Prioritizes work based on business value. Available to answer questions
Stories should be of a size where you can build a few of them in an iteration. Stories are time boxed by definition, and should be between 1 and 5 "ideal" programming weeks.
Q - What about projects that may well span much more time than that?
A - XP is not a silver bullet - not all problems can be solved via stories").
Story format is not important. Has a title, concise problem statement, sketches of screen layout, etc.). Now the group is discussing how you fit in things like refactoring (etc). Some things aren't part of the explicit customer stories, but are part of their implicit desire for a maintainable, working system. Side note on my part - I can see an RSS feed for stories being a very nice fit :)
- I Independent
- N Negotiable
- V Valuable
- E Estimable
- S Small
- T Testable
Unit tests are not enough, we need acceptance tests as well - "When I do tis action, I expect this result". Ideally, test suite should be automated. The tests help you collaborate with the customer and iterate towards "what they meant" as opposed to "what you did". This is easier said than done, IMHO.
So - why stories on index cards? Because you can't overdo it - can't fit much text on a card. Easy to get everyone involved.
- System requirements may be too large to fit in customer's head
- Customer does not have time to do their end
- Customer is not on site
- Customer blind spots (missing tests)
- Losing parts of stories
- Customer team, many voices
- If customer spends "too much" time with the team, may lose touch with business stakeholders
Shoring up - Multiple customer teams? Story repositories?
We took a simple order entry (CRUD) system. Split into roles (customer, QA, developers) and develop stories. Then, passed stories along to next table to look. As it turns out, the stories we received were much more complete than the ones we sent along - we were very incomplete. basically, we did not include enough story detail, and mostly omitted acceptance tests. The results were mixed - two groups created stories with tests, two groups (like ours) created decent stories and tests (within the time constraints). Very interesting exercise, opened my eyes on this area.
This is a case study presented by John daniels and Paul Dyson
What they are going to cover:
- Multiple teams - each team in one office? Not the topic
- Satellite Workers - most in one office, some remote workers. Not the topic exactly
- Dispersed team - Every team member is remote - this is what they are covering
Why do it?
- Cost (lower)
- Get people who do not want to travel/relocate
- Constrained by circumstances - (personal or business)
Case study, source: JD. Two FNL projects covered here. Both were part of a larger project
- Specialized Workflow engine, 2 people, fixed price, 5 months, server based (EJB), no UI
- Information management system with 4-6 people - T&M. Lot of interdependence between this part and others. Large EJB/J2EE project, 6 months
Case study - source: PD
- Integration of web services provision for internet platform. 4-5 people, fixed price, Java web services, no UI
- 4-5 people, 9 months, Java, multiple interfaces, migrated from office environment. Tried to develop a product from (1)
- Full broadband (beware upload chokes!) - needed cable/DSL
- Phones plus conf calls
- Could use VOIP for one to one
- Powerful machines for team.
- Beware desktop sharing over net with large displays
- Install complete platform at each site - so need power at each site
- Wiki for sharing
- Version control system that works in this fashion
- NetMeeting for collaboration
- VNC or equivalent
- IM for chat/see who's around
- Security (physical and cyber) - in practice, ignored many of the customer requirements for physical security)
- IPSec encryption (same router at each site)
- Encrypted email (PGP plugin)
- if appropriate, encrypt HDs
- Tool support for this is currently very weak (very ad-hoc)
- Supporting multiple/varied desktops is very hard. Everyone ends up being an SA.
Interacting with the customer
- Initial face to face meeting (ongoing)
- cannot support regular XP model of an onsite customer
- More expectation mgmt needed - lack of shared experience in team
- More formal review periods
- Need to schedule customer time, as it is not going to happen otherwise
- Need more doc - without direct interaction, necessary
- Issues need to be resolved by phone/chat/wiki
- Customers had no access to the environment (VPN or servers)
- Customer had already donse some prototyping
- Customer had done extensive business analysis
- Jointly produced feature list
- Had access to their intranet and repository
- They were happy to use dispersed dev - saved desks/space
- Many onsite meetings for clarification
- 2 - 3 week iterations, delivery after each
- 1-2 days onsite to assist with integration at each step
- 1 week onsite to really integrate
This latter project was hard
- Evolutionary approach
- Short iterations
- Daily "stand up" meetings
- features vs. tasks - used tools like the Wiki and spreadsheets to manage the difference
One thing learned - used Wiki as a "virtual wall" of cards for the project. Very difficult to enforce without discipline. Worked well, but the team needed to think about it. The actual development process was not a lot different from normal - other than the need for on site delivery and integration - in a full on site job, would have been more natural.
Designing the System
Needed to do early architecture/design work in up front face to face meetings. Worked better face to face, later on used shared desktop with virtual whiteboards. Did this in UML, used Rose (somewhat). The process was API driven (from the EJBs). Design doc was produced after the fact, not during or up front. Revisiting the design decisions were more important than in a "normal" XP process, as there is less lunch/coffee (etc) side conversations. Needed to make up for that lack. Ran up against poor tool support for dispersed diagramming.
mixed pairing with "buddying" - work alone, but check in with buddy on a regular basis. When pairing this way, agree on how work was to be done and split it up. Work as a pair until complexity was understood, then just go off and do it. One common split - tests vs. implementation. Most tasks were paired, there was the odd singleton task on the e2x project. In response to a question, code review and code quality takes extra work.
- Eclipse and Tortoise clients
- Server running on spare PC (Server hosting)
- e2x later switched to the tool they were building (Cyclex)
- Pair programming with NetMeeting
- Slight delay over wire if you are not the driver (mostly ok)
- re-synch to version control to switch driver
- Mostly worked w/o problems!
- Varying degrees of continuous integration as a result (IMHO, not a lot different from normal process issues)
- Process for programming tasks
- Sketch the ifc
- Code the tests
- Run new tests
- Code the implementation
- Run new tests
- Iterate until pass
- Run all tests until integrated
- Check in
- test focused rather than simply test driven
- Updated user abd design doc before each software release
Project 2 FNL
- Used customer repository
- No Eclipse integration
- Couldn't use NetMeeting while connected to their repository - made pairing very tedious
- Pairing over NetMeeting via ADSL
- Once VPN worked, easy
- audio and desktop sharing worked well over VPN
- Who's got the monkey?
- Used an actual "monkey" toy in the office, what to do remotely?
- Use IM (did not work as well)
- Lack of "overheard" conversations
- Interruptions are worse than when co-located (other phones, door, etc)
- Latency makes swap over a problem
- Poor support in CVS
- Supported in Cyclex
What about Testing?
- Focus on functional tests - are unit tests still important? They think less so
- Used JUnit
- Automated one click testing critical
- When paiting, both developers had to get all tests to pass on their machines before it was agreed to be done - the "it works on my machine" problem
- Shared understanding of the tasks is crucial
- e2x: Does work with people you don't know. Works better with people you do know
- FNL: Only employed people that they knew already
- Minimized start up time
- Minimized cultural/personal diffs
- Face to face - especially with customer - is still crucial!
- Important to establish working etiquette as you go along
- Allow time for setting up the infrastructure (VPNs, databases, etc)
- Test focused
- Maximum team size limit? They have done 5-6
- One thing that comes up is that all interaction has to be more considered - and somewhat more formal - than in an office environment. John Daniels: This form of pairing is actually more productive (admittdely, anecdotal).
- There are times and tasks where people work more efficiently alone. Remote development with buddying allows for that
Sci Fi Wire reports that there will be a new X-Files movie. The series went off the rails a good three years before it ended, and the first movie was pointless. We need more... why?
This one comes from Keith Braithwaite of WDS Global and Steve Freeman of ThoughtWorks UK.
We are going to
- Seed some stories
- Break into groups and share stories
- Each group to discuss their stories and extract 3 anti-patterns
- Each group will present their anti-patterns
- Pick top 3, discuss
Dissenters should be tolerated as long as possible, but no longer:
- Some people take time to convert, give them time
- One "Professional Skeptic" can bring everything to a halt
- Special treatment for the squeaky wheel can cause resentment amongst the rest - possible on a non-XP team, virtually impossible on one
Proxy customers must remember their place
- Very few people saying they are doing XP are - most have a proxy customer, not a real one (Product Manager?)
- Knowing the solution domain well does not imply knowing the business domain well
- Having a proxy available when the real customer is not available can help
- Can blow up if they forget that they are not, in fact, the customer - end product will then answer the wrong question(s)
Must be prepared to pay the cost of fixing the mess
- Decent engineering is expensive to retro-fit
- Customers will not see any progress from this - they will start to think you are "wasting time". Unclear how to do this well. Only real solution is constant checking, or deal with catostrophes as they occur
- Probably won't like the extra discipline... they don't feel the pain
You need to be doing other good stuff beyond XP. There's not a lot to XP - it's light. What's not part of XP that is necessary?
- Small design up front doesn't hurt, and will definitely help. Not BDUF....
- Many people do not absorb the rigor required - especially if they have only "read the books" and not discussed it
- Version control - surprising number of teams don't
- Test/Code/Refactor is necessary but not sufficient. Have to have skill, it's not a silver bullet. There are process/interpersonal issues as well. You can run down refactoring rabbit holes, for instance....
Don't frighten the customer
- Most orgs adopting XP have other, non-XP projects. Don't be a full-time evangelist
- Over emphasizing it can be dangerous, and get you labelled as a "religious fanatic"
Stand up to the Customer
- Customers drive the project
- Doesn't mean they are always right or know what they always want
- Developers can be frightened of customer, and not question them, even when they "know" they are wrong
- This can end up delivering the wrong solution to the wrong problem
Step up to the customer role
- The "Real" customer is unavailable
- lack of feedback and direction increases risk - recall the "remember your place" in the proxy customer role
- Someone in that role is better than no one...
The exercise - come up with a few anti-patterns and proposed solutions. We came up with:
Create a Customer
- There is no customer
- Without a customer, rat holes abound
- Some projects - such as vendor products - lack a single definable customer
Get a new Bo peep
- Need a working team
- Coach leaves
- Lost Sheep after coach leaves
Hire experienced people
- The blind leading the blind
- They fall off the clock
- There's no substitute for an experienced coach
- No customer - shut down the project (don't let marketing run wild
- Seeing the Forest and the trees - Lots of apparent chaos - step back, find the ball
- Right Rewards - Align incentives and development goals with reality and actual business goals
- 24 hour pair programming
- Not accomodating the individual
- Cabin fever - learning needs
- You have multiple customers
- You cannot serve two masters
Escape from refactoring
- Refactoring paralysis
- Stalled/No progress
- "The perfect is the enemy of the good enough"
- Small XP team in large company experiencing growth
- XP Team absorbed back into "mainstream" - XP practices lost
- Protect the team, keep it separate
Others I didn't quite get down - "Stealth XP" and "Explicit XP"
So we have a vote to determine the top three:
- Timely shutdown
- Personal Space
- See forest and trees
The voting results came back differently than at the Benelux conference - they all came back with issues surrounding customer relations, whereas we came back with technologist/team issues. Likely because this group is a technologist, but not necessarily doing XP. The Benelux conference was an explicitly XP Conference.
Interesting comments on software and piracy from Steve Ballmer in Information Week relative to piracy and marketing:
In fact, our market share relative to Linux is better in China than almost any other country in the world. It might be our strongest country. You might say, hmm, that's odd. But countries that have high piracy, you could say in a country like that, our acquisition cost is the same as Linux. I don't mean to sound facetious, that's not where we want to be, but really, for most people in China, Windows and Linux cost the same amount of money. I was in a book store when I was in Beijing last time, and I see all these copies of Windows in a funny-looking package for $2.50. Then, way in the back, behind a lock and key, I actually found a Microsoft Windows for $99. It was our copyright--you couldn't see it, it was collecting dust, it was behind lock and key. The $2.50 version was the popular version.
Now that's fascinating. Ballmer has seen piracy first hand - of Windows - and seems to recognize that it helps his company in China in the short term. Eventually, there will be better IP control in China - but in the meantime, the market is figuring out what it likes. Attempting to shut that down will only hurt them. There's a lesson in that...
Sam, Thanks for adding this to the validator. On a related note I'd like to thank you and Mark for writing the feed validator. I've lost count of the amount of times I've gotten mail or bugs filed about how some feed doesn't work in RSS Bandit which was quickly resolved by sending the person to the Feed Validator.
I don't think I'd say that sending someone to the validator solves a problem - I've taken that tack with users, more than once. It might work with a tech user; it's generally not going to wash (and hasn't washed for me) with general end users. Like it or not, users consider a failure to read available content to be a bug in the aggregator. It really doesn't matter who's fault it is; all the end user knows is that they can't read the content. That's why my tack has been to have the parser log errors but not blow up, if it's at all possible. I flag feeds with errors visibly, so that users who care can notify the source provider.
Even then, it's not that simple. I've notified source providers that there's a problem before, and more than once the issue has not been solvable by them - the error is part of the template used by their provider, and they have no easy way to fix it immediately. To my mind, simply pointing at the validator and saying "Not my problem" is punting
Naked Objects - a BOF session after the end of the normal day here. Naked Objects - oddball thing about the name - book lookup on Amazon yields some "interesting" nearby subjects
The idea - to get rid of all the extraneous things - reduce to the leanest, bare essentials. Four layers in classic architecture:
- Domain Object Model
Naked Objects eliminates the controller layer - encapsualtes all business functionality on the entity objects (note - this elides any issues with session access to behavior that is permission based). Make the presentation layer generic. Make the persistence layer generic. In theory, generate the presentation and persistence layers from the domain model. I detect MVC being reinvented in the Java sphere :)
An example - conference registration:
Noting that a delegate can be part of a company. The demo proceeded using Together/J to build the domain using UML (ed. - I am historically very wary of this kind of tool and development model. In particular, I find it easier and faster to just use a browser :) ). After building the four domain classes, a build yields a simple set of classes that have some basic UI behavior (not unlike a Smalltalk inspector, although less powerful than Trippy to be sure). Relationships? There's a visual programming way of doing that (like PARTS, noting that we've been there, and it doesn't scale...). Important note on that being that the Together/J linking behavior is not a necessary part of Naked Objects - it's a part of Together/J that is independent of what you are doing.
My main concern would be the assertion that we can make the UI generic. In my experience, lots of work ends up going into the UI that is only marginally related to the domain - ways that the UI can be configured by the end user (in BottomFeeder, for instance, the ability to zoom/unzoom different parts of the UI, and how that depends on the current UI state. I guess I just have a hard time with the notion of a generic UI. It flies in the face of what I've had to do with Bf.
Now a second session on ModelScope - a prototyping tool. The notion is model driven prototyping, using state transition diagrams. The tool interprets that to create the model. No code generation from the tool - it generates models. Events change the system, but may not be associated with a single object - thus the usage of state transition diagrams. No GUI for the front end, so things are loaded from a front end text file. They have an engine that generates models.
MODEL OT2004 OBJECT BOF NAME BOF Name ATTRIBUTES BOF Name String STATES proposed scheduled cancelled TRANSITION @new*Propose=proposed*Schedule=scheduled @any*Cancel=cancelled OBJECT Room NAME Room Room ATTRIBUTES Name Name String STATES available TRANSITION @new*Make Available=available available*Schedule=available EVENT Propose ATTRIBUTES BOF BOF BOF Name String EVENT Schedule ATTRIBUTES BOF BOF Room Room EVENT Cancel ATTRIBUTES BOF BOF EVENT Make Available ATTRIBUTES Room Room Room Name String
Then you run the model generator (ed. - Java based - wouldn't Smalltalk or Lisp be way, way easier for this sort of thing?). You get a model that allows you to work with the state transitions as they have been defined. Hard to tell much at this point - needs more fleshing out.
Ok, Likely everyone's seen this one already - but I couldn't resist. Via Madbean:
"The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein"
Plenary session on 3/31 - how to design a good API - and why it matters. Given by Joshua Bloch, senior staff engineer at Sun. The need for good API's remain as languages and platforms change - what do we mean by APIs here - the public interface to a component or sub-system. There are going to be examples (good and bad) given.
Why is API design important?
- APIs can be amongst a company's greates assets
- Customers get attuned to the apis that they have studied, and write (and buy) code that is aligned with those APIs
- APIs capture and retain customers
- A badly designed API is an unending source of support calls - and public APIs are forever. Once it's loose, you can't change it - you can only add to it
If ypu program, you are an API designer. Each module you create ends up with an API - either real or ad-hoc. Useful modules tend to get reused. Once you have users, you are not at liberty to change it - people rely on it. These "private" apis can be an asset or a liability.
- Easy to learn
- Easy to use, even w/o doc
- Hard to misuse
- Bad ones will be easy to misuse
- Easy to read and maintain code that uses it
- Sufficiently powerfil to satisfy requirements
- But not too powerful
- Easy to extend
- Appropriate to audience - no such thing as a "perfect" API for everyone
Methodology for API design - there are a few things that tend to lead to good API design. Gather requirements, and be skeptical. The audience will tell you what they want (may be different from what they need). Extract the real requirements from what you get told and what you observe. Use Cases are the best way to do this - what are the easiest things to accomplish with that API? Do the Use Cases look good when using the API? If not you have a problem. It can be easier to build something more general than what you are asked for - but don't go to "framework-itis
Start with a small (1 page) spec. Agility is good at this point. Bounce the spec off of as many people as possible. Keep the spec to a short description and method names - flesh it out only as you gain confidence. Shop it around while it's simple. When you get a large spec, it's hard to change (and involves politics).
Write the API before you implement it. Saves an implementation that may be useless. Start coding to it when it's a 1 page spec to test (TDD driven API design?). Continue to write code against the API as you develop as a constant check against it.
Writing to an API (Service Provider Interface) is even more important.
- Interface for supporting multiple implementations
- Example - Java Cryptography
Keep expectations realistic. Won't be all things to all people. "Aim to displease everyone equally". Say you have 6 customers - 5 happy, one angry - not good. 6 grumbling "can work with it, but..." - likely ok. Expect to make mistakes - you'll make them, and you'll have to evolve (NOT change!) the API.
General Principles - should do one thing, and one thing well. Use good naming. If it's hard to name, it's a bad sign of code smell. Bad names mean poor understanding. Be open to refactoring (splitting and merging modules). The API should be as small as possible but no smaller (Occam's razor). When in doubt, leave it out - in terms of classes, methods, functionality - they can be added later, but once it's there, it's there. Conceptual weight is more important - how long will it take to learn the API? A Java example - if you implement an interface that is already there, people have a guide.
Implementation should not impact the API. Implementation details constrain you and confuse users. Don't over specify (e.g., don't specify the details of a hash function...). Don't let implementation details leak into the API. Exceptions, on the wire, or on disk formats are good examples where leakage can hurt. The initial Java String hash function (which they almost had to live with) was very bad. Actual is better, but still specified (bad).
Minimize accessibilty - maximize information hiding. Make instance variables private (i.e., in ST, no accessors). APIs are a "little language" - be consistent - parts of speech and basic names. Intention revealing names important.
Documentation matters, a lot. Reuse won't happen without good design and good documentation. Document every class, every interface, every method, constructor, parameter, exception (ed. - most methods should not need doc - especially internal, non API ones. API methods, likely should. IMHO, intention revealing names should do most of this). If there are state constraints, doc that, or risk unusability.
Consider performance implications of an API.
- Constructor instead of static factories
- Implementation type instead of interface
ed. - These are issues that, IMHO, most people should never have to worry about....
Bad API designs are permanent. Example: In AWT, Component.getSize returns (mutable) Dimension object. Each getSize call allocates a Dimension (ed. - that's a GC issue. VW has never had an issue here....)
API's must co-exist with the platform. Obey naming conventions, avoid obsolete stuff, etc. Take advantage of any language features. Avoid any language/platform specific traps
- Minimize mutability - classes should be immutable unless there's a good reason... not sure I agree with that...
- If mutable, keep the state space small and well defined
- Date and Calendar are bad examples
- Timer is good
Seriously, I don't know that - other than (previously mutable) Strings in Smalltalk, this is ever something I've had to worry about...
Subclass only when makes sense
- Liskov substitutability principle
- Inheritance violates encapsulation - he says you should use final - I disagree violently. To me, this is a classic engineer's mistake of assuming all possible future uses of a class or library. You can't see that. Now, admittedly, making classes interface compatible rather than inheritance compatible is safer - but "fragile base class" is more of a Java/C issue. Final is a bug.
- Don't make the client do anything the module should do - reduce need for boilerplate. There's an example of this from the DOM code in Java. If you require boilerplate, then your library is missing a few things. Think as a user of the API and encapsulate that sort of thing.
- Don't violate the "principle of least astonishment" (old Smalltalk adage :) ). Spending time on the API to make it easier is more important than performance. Example - method called "interrupted" in Thread clears state as well as reporting it.
- Fail fast - he likes strong static typing, but he's wrong :) In general, good principle goes with "least astonishment" - fail early when it makes most sense. Ironically, his properties example shows the limits of declarative typing. put() in HashTable accepts any objects, but actually enforces Strings in code.
- Don't make the client play "20 questions" when asking for state.
- Provide programmatic access to all data available in String form - otherwise people will parse them. This ends up turning those strings into a de-facto API.
- Overload with care - no two with same number of args (ed. - not a Smalltalk problem due to keyword messages :) )
- Use appropriate parameters and return types - "least astonishment"
- Favor interfaces
- Don't use Floats for money (amazing that this still comes up!)
- Use consistent parameter ordering - note again that keyword messages solve this whole problem :)
- Avoid long parameter lists - long ones cause problems (going to doc) - especially bad - long lists of identical types (again, solved by keywords...)
- Avoid return values that demand processing - he says not to return null (Wrong!) - In Smalltalk, answering nil is a well understood and widely used pattern.
- Don't use exceptions for control flow, only for errors. Don't fail silently!
- Favor unchecked exceptions. Checked exceptions cause boilerplate. See Parcel loading in Smalltalk for examples of this and the previous...
- Include failure/capture information with the exception
The examples are showing the Collection hierarchy in Java as a replacement for the older Vector stuff. Another example shows a cleanup of some Thread code (replace Strings and keys with key objects).
Can be rewarding and valuable for companies and teams. Suggests that these rules are guidelines, not hard and fast rules. API design is not simple. "Perfection is unachievable"
Laura Hill and Bernard Horan of Sun (R&D group)
- Remote Door Bell - say you are working outside, doorbell rings. Nice if the doorbell muted the radio and rang itself on the radio (or on the mobile phone, etc). Not possible if all devices are using fully proprietary interfaces. Bernard showed his Bluetooth enabled phone controlling volume on the Bluetooth enabled notebook as an example.
- Elder hospice care facility to monitor safety/health of resident(s)
- Health stats
- Fire, etc
- Small scale home security syste
- Wireless, battery operated
- Elements discover each other on net
- Each item in system does its own task (video monitiring, etc)
- Nice if it could be set up to notice "normal" anomalies (a cat, for instance, should not set off the network)
- Being able to easily discover an available printer on an ad-hoc (WiFi) network
- Variable pricing, etc
A 40 minute team exercise - come up with a new service/idea that plays into discoverability. We came up with the notion of personal location identification cutting across devices and locations:
- Phone (land and mobile)
- Home and other locations recognizing you and configuring themselves to your known desires
- Privacy settings issues
First group - Jack Black finds himself in a strange city with a PDA, and may be in danger of sobering up if he does not find a bar. So his PDA should be able to have that critical information available and route him to the nearest bar:
- Local Customs (tip, etc)
- How late is bar open?
- How close? How do we get there?
- When Jack's blood alcohol level drops below a certain level it notifies him that it's time to drink. Also takes account of current monetary level, and which location is closest
- Environment needs to be able to deal with any local environment automatically. Not all locations will have services that work for this.
- Should be able to translate across language barriers
- Should have privacy, security, abiding by local laws
Second group - Intelligent Visitor Filtering doorbell
- Filters visitors based on context and learned preferences
- Time of Day
- State of House
- Who is present in house
- Contents of the fridge
- Learned preferences of the homeowners for visitors based on context
- Need for discovery of context of house and home owner
- Need for discovery of purpose of visit
- Comparison of visit purpose with context with preferences, assessment of significance of vist for homeowner/those present
Next step - how to create a solution - the two more general groups (ours and the intelligent filtering) will need to focus in more. They gave us a large handout with a whole bunch of descriptive technology refs and Discovery Protocols. I'm not going to describe all of them.
- Bluetooth Service Discovery Protocol
- Java RMI
- Service Location Protocol
- Web Services
For our scenario, we came up with Bluetooth as the best mechanism for initial broadcast of identity information - providers would then do additional queries through some other mechanism (Web Services, JXTA, whatever).
Intelligent Doorbell Scenario - doorbell is not a doorbell, but delegates the task to whatever service should find an appropriate person - it may end up being the ring by default. The person hitting the doorbell will be queried as to what they offer/want, and appropriate proxies will be notified. So with that, they went with Jini, mostly for the Pub/Sub capability. If BlueTooth did that, they would have considered it. If JXTA did that well, might consider it.
The Jack Black drinking system - Ended up with the business part (getting the alcohol) and the discovery part. Missing part - bringing up the network. Ended up a need for multiple services from the list - possibly BlueTooth, possibly Web Services, possibly OWL-S.
Notes - no one brought up security, although we did bring up privacy. There seemed to be an "assumption that it would be secure" - meaning that no one took responsibility for it :) Not that we've seen that before :)
It was a great conference - I really enjoyed it. The Robinson Centre was a very nice place to have a conference - the rooms were comfortable, the meeting rooms were very nice, and the central lounge area was comfy - nice couches, and WiFi provided by ThoughtWorks - that WiFi setup made all these posts far easier to make than they would have been otherwise. There was a lot of interest at the Cincom booth - lots of people seemed to be pleasantly surprised that Smalltalk was alive, kicking, and ready for anything.
I suppose I should mention my own session, which ran during the last time slot - I spoke about blogs and RSS. Martin Fowler had some good suggestions for me on the organization of the slides - I'll be revising them before I give this presentation again. The discussion was very lively - as it turned out, a lot of the audience (about 20 or so) didn't have a good grasp of what RSS was before the talk. I plan to be back next year - great show, wonderful time!
Interested in how tools are evolving in VisualWorks? Then you'll want to listen to Vassili Bykov's talk at StS 2004:
Inside the VisualWorks Tools
Vassili Bykov: Cincom
Tuesday 2:30:00 pm to 3:30:00 pm
Abstract: Over the past few years, VisualWorks toolset has undergone extensive changes and enhancements. They are not limited to user interface changes; a number of frameworks have been added that VisualWorks application programmers can build upon. This presentation will demonstrate some of these additions and show how they can be used in other applications.
Bio: Vassili Bykov is the Tools project lead for VisualWorks Smalltalk. Since joining Cincom in July 2000 he has been working on modernizing the look and feel of VisualWorks IDE. His interests range from information and graphic design to fundamentals of programming language semantics, and he finds a good balance between them in his current position. The focus of his current work is bringing the future VisualWorks user experience closer to the expectations of a typical user while retaining and enhancing the interactive and direct feel traditionally expected of Smalltalk environments. Prior to this, Vassili was an object technology instructor with The Object People and a member of Toplink/Smalltalk development team.
See you in Seattle!
You now have a situation where a simple unit test is only a couple function calls away from any bug. Compare to the Einstein case I mentioned earlier, and you'll see that complex repro scenarios are comparitively rare. You can reproduce the faliure in seconds - just run the unit tests.
When that cycle is so short, E&C doesn't help nearly as much.
The "Einstein" reference is in relation to an internal to MS view on various developer types; I'll have to post on that at some point. Here though, I see something interesting - MS is only just starting to support the kind of immediacy (edit and continue) that Smalltalk supports so much better than they do - and their developers just don't see the value. Amazing. I used a TDD approach when developing my MarkupHelper (for the blog posting tool), and it was so much easier to do since I could look at stuff in the debugger and change it right there - without having to run back to some different tool. Interesting difference in viewpoints at the very least...
Well, almost back home. I'm tapping this out in a cab while it crawls through rush hour traffic on the BW parkway - I arrived at DCA not too long ago. It's a rainy, nasty day; it was actually nicer in the UK (London) this morning when I woke up. That was 12:30 am local time, so I've been up a long while now as well - adding to the generally odd feel that these long travel days acquire. No luck with the wardiving while I've been stuck in traffic either - I've stumbled on one WiFi spot, and that was WEP protected. So much for moblogging from the cab :)
One thing's for sure; this ride back home shows me why I'm so glad I work out of a home office most of the time - I can't believe that people put up with this kind of traffic on a daily basis!
So I get home, greet the family, boot the laptop. It refuses to find the WiFi in the house. Check the other system that uses WiFi - yes, it sees the network. Pull the card in and out of the machine a few times, swear a lot, swap cards. Nothing. Disable the wireless card, enable it, pull it out, put it back in, nothing. Then, after 45 minutes, for no apparent reason, it finally spots my network. The maddening part? It was offering to connect to my neighbor's network the entire time. Grrrrrr.....