This Calvin and Hobbes cartoon should be the blogger's manifesto :)
More evidence that the USPTO should get out of software - this Burst.com suit against Apple's iTunes:
After being approached by Burst.com in late 2004, Apple had filed for a declaratory judgment in January that it isn't infringing on Burst's patents, but Burst is going ahead with its lawsuit, filed Monday in federal court in San Francisco. Burst is asking for royalties as well as an injunction, it said in a press release.
Yeah, because those bits that happen to be music download so very, very differently than the bits that happen to be an HTML document.
Update: Is this what you call "Innovation by lawyering?"
Burst.com is represented in the action against Apple by San Francisco law firm Hosie McArthur, who also represented Burst in its successful litigation against Microsoft Corporation. In March 2005, Microsoft settled that litigation by paying Burst $60 million for a non-exclusive license to Burst’s patents. Burst has also expanded its legal team in the Apple litigation to include attorneys from the Seattle office of Susman Godfrey, LLP, as well as Houston-based intellectual property firm Heim, Payne & Chorush, LLP. Also representing Burst is Palo Alto-based intellectual property firm Carr & Ferrell, LLP.
When you see "expansion of the legal team" in the headline, you can be pretty sure that there's a lot of horse hockey being tossed around...
I just love the way newish technology seems to impede logical thinking. Take the movement to make cell phone usage (without a headset) illegal while driving:
Addressing what safety experts say can be a deadly distraction, states are scrambling to impose restrictions on cellphone use by drivers. Twenty-six states and the District of Columbia have written legislation on the issue, mostly since 2003. This year, other legislatures are tackling the subject, and two states have passed laws on it.
The guy with the cell phone in his ear bothers me a lot less than a number of things. For instance, the guy one lane over eating a Big Mac. Or the other guy doing 70, but who seems to be reading a book. Or, the woman coming up from behind who's applying mascara. Or the guy two lanes over who's shaving.
What I want to know is, in what way are cell phones worse than any of the examples I just gave? Or tons of others I'm sure you can think of?
Dare Obasanjo thinks that Dave Sifry is playing fast and loose with blog numbers. I don't know - it's understandable that Dave wants to limit discussion to what he has facts on; it might be nice if he added a few caveats, sure. Dare's biggest beef:
It's now general knowledge that services like MySpace and MSN Spaces have more blogs/users than Technorati tracks overall.
I'd be interested in knowing why Technorati doesn't track those services.
We are still looking for feedback on the location possibilities for the December (2006) User's Conference. It will be held in Europe, but the specific location is not determined yet. Let us know what you think! If you tried the survey last week, there was a bug - that's been fixed, and your answers will be looked at.
One of the nicer things about Smalltalk is the consistency of the object model. A fair amount of that is due to the fact that everything is an object, and that dynamic typing allows for developers to just "do what works". I have a pretty simple example of this - let's look at the method #factorial
result := 10 factorial.
That gives us:
Ok, that doesn't seem exciting - we ended up with a SmallInteger object. However, now let's try this one:
result := 100 factorial.
The nice thing here is that we didn't have to do anything special - in the process of getting the answer to the second question, the SmallInteger object got promoted up to a LargePositiveInteger, and I didn't need to do anything - no setting up of interfaces, no casting, no need to ensure that all factorials produce LargePositiveInteger objects - they get created when they are needed. Developers can do that themselves, btw - the library does this kind of thing with numbers, you can do similar things with your own objects as needed.
The bottom line - Smalltalk stays out of your way, and lets you solve the problem at hand. Instead of having the satisfy the anal retentive needs of the compiler.
Over the weekend, we tought we had lost an audio cable and an S-Video cable in our family room A/V hookup - sound was getting distorted, and the picture was gone for both the DVD player and the Replay feed to the TV. As it happens, the audio cables did need replacing - one of them had problems. The video? Just loose.
However, there was still the standard fun of unplugging the cables and trying to figure out why audio worked for the VCR, but not for the DVD (or vice-versa). Mind you, it's a unitary DVD/VCR player, and why the output labelled "DVD/VCR out" plays audio for the VCR, but not for the DVD - while a separate "audio out" does play the DVD audio - is a complete mystery to me.
It's even worse than what a bunch of us talked about over the weekend, when we noted that no one could understand anyone else's A/V setup anymore. Heck, I have problems with my own :/
Smalltalk Solutions at LinuxWorld/NetworkWorld is coming up fast - there's still a few days to save money with Advance Registration, which will buy you access to all the tutorials and sessions. Smalltalkers can save more by contacting Suzanne Fortman and getting the STIC discount code. There's a lot of great stuff this year, like Martin Kobetic's talk on Cryptography in Smalltalk:
This presentation will introduce cryptographic hash functions and public key algorithms and discuss some of their applications and practical aspects of their use. It will continue in the spirit of an earlier talk about secret key ciphers presented at Smalltalk Solutions 2004. The talk will include demonstrations using the VisualWorks security library.
See you in Toronto!
The Guardian (UK) notices that bloggers are becoming a societal tipping point for news:
Bloggers and internet pundits are exerting a "disproportionately large influence" on society, according to a report by a technology research company. Its study suggests that although "active" web users make up only a small proportion of Europe's online population, they are increasingly dominating public conversations and creating business trends.
Malcolm Gladwell wrote about the disproportionate power of "influencers" years ago in his book "The Tipping Point". What's happened between now and then is easy access to the power of publishing. Becoming an influencer is a lot less difficult now that anyone can grab a megaphone. The liklihood of any one voice rising above the cacophany is still small, but they are far better than they used to be. Glenn Reynolds wrote about this in "An Army of Davids" recently:
"That's exactly right," said Glenn Reynolds, author of An Army of Davids, which explores the explosion in web punditry. "Bloggers and blog-readers are 'influentials' - the minority that pays attention to events outside of political and news cycles. They also tend on average to be better off, better educated and, more importantly, employed."
Just consider the positive impact Scoble has had on Microsoft - or how bloggers have managed to keep various political stories alive long enough for the mainstream media to feel forced to cover them.
For corporate PR and marketing people, this is a brave new world - and that has both positive and negative impacs. Only a few years ago, you could see bad news coming a fairly long ways off - a negative media story would be prepared well ahead of time, and you would often get wind of it before it hit the press (muckraking TV was something of an exception, but most PR people never had to worry about TV). Now, it can be minutes or hours, and a failure to respond quickly can make you look very bad (consider Jef Jarvis' "Dell Hell" posts).
You may not need your own set of influencers, but you certainly need to be tracking what the ones who follow your industry are saying.
If you use the comment tool in BottomFeeder - and use the preview function - you'll want to grab the Blog-Tools update that I just posted (4.2 dev stream only). There was a namespace resolution issue that prevented the tools from opening, and that's been resolved.
I was exchanging emails with a BottomFeeder user who was having trouble getting the application to run on her Mac. I should be embarrassed - she diagnosed the problem (which is a base VW issue) before I did. If you try either vwnc or BottomFeeder on a Mac running OS 8 or 9, and it crashes without coming up, here's the answer:
According to a bug with the VisualWorks own Help files, if the display color depth is set to anything greater than 24bits, a similar "primitive has failed" error occurs. Well, I changed the depth to 256 colors and...voila!
So there you have it - do I have hard working users, or what?
This story caught my eye - a case of Bubonic Plague in LA:
A woman is in stable condition with bubonic plague, the first confirmed human case in Los Angeles County since 1984, health officials said Tuesday.
The woman, who was not identified, was admitted to a hospital April 13 with a fever, swollen lymph nodes and other symptoms. A blood test confirmed the bacterial disease, and she was given antibiotics, officials said.
It caught my eye for two reasons - last night's episode of "House" dealt with a plague case, and I've just started reading "The Black Death" by Philip Ziegler. I seem to be in a disease pattern; I just finished "The Great Influenza: The Epic Story of the Deadliest Plague in History". That was a disturbing book, what with all the Avian flu stories floating around the media.
The plague book seems interesting - I read "The Doomsday Book" by Connie Willis awhile ago - it's a time travel book about researchers going back to learn about the past - one of them accidentally ends up in the middle of the plague hitting the UK. It was fascinating, but very, very sad. I'll have to see how the actual history tomes on the subject look.
Avi posted a number of links to conferences he'll be attending and speaking at over the next few months. If you've heard a bit about Seaside and/or DabbleDB, and would like to know more - check his itinerary.
I'm starting to see a trend in syndication feeds that I don't much care for - the inclusion of 1x1 pixel graphics in each item. The theory being to find out how many people are actually reading the items, I suppose. Meanwhile, it adds an extra - and of absolutely no value to the end viewer - http fetch to each item viewing. It's getting to be enough to tempt me to take BottomFeeder offline before reading news.
Only a few more days to register in advance for Smalltalk Solutions 2006 at LinuxWorld/NetworkWorld. There are lots of great talks, and the fee will get you into all of them. Contact Suzanne Fortman if you're a Smalltalker - there's a STIC discount you'll want to find out about. Here's an example talk - Bruce Badger is giving a talk on the OpenSkills Smalltalk server:
The OpenSkills SkillsBase system runs using an application server that has the advanced features one would expect but with several unique properties. Demonstrations will be interleaved throughout the talk. The following is a small selection of the topics Bruce will include:
- No impedence missmatch when persisting objects
- Huge numbers of instances of the application are possible
- No HTTP session affinity required (i.e. apps can be RESTful)
- A cache of unmodified objects shared by all instances
- One language throughout the system
- Application code is executed in the databases processes …..
- The DBMS *is* the application server
- Premier IDE from which code is injected directly into the app server ... though we do use a staging area for production changes
See you in Toronto!
The software development field is filled with bad ideas. For instance, have a look at this - "debugging 101", which advocates against using a debugger. I wonder if he thinks the compiler is a crutch too, and that "real men" just use ASM. It's too bad, because the rest of the article is pretty good, and filled with good advice. Here's the bad fixation:
In general, I recommend you avoid symbolic debuggers of the type that have become standard in many IDEs. Debuggers tend to produce a very fragile debugging process. How often does it happen that you spend an extended period of time carefully stepping through a piece of code, statement by statement, only to find at the critical moment that you accidentally "step over" rather than "step into" some method call, and miss the point where a significant change in program state occurs? In contrast, when you progressively add trace statements to the code, you are building up a picture of the code in execution that cannot be suddenly lost or corrupted. This repeatability is highly valuable - you're monotonically progressing towards your goal.
Yeah, print traces are so much more useful, and so much easier to deal with. We couldn't possibly do a progressive narrowing of scope with breakpoints. Heck, I finally tracked down a bug in the network library we use in BottomFeeder yesterday - by progressively narrowing the scope of the search with breakpoints. I have no idea why this guy thinks debuggers are bad - I'd guess it's just that in his experience, the tools suck. Maybe he should find his way all the way into 1980's era technology, instead of hanging around in 1975. Here's what he advocates most of the time, with a few caveats about debuggers maybe being useful under some circumstamces:
This is the principle debugging method I use. A trace statement is a human readable console or log message that is inserted into a piece of code suspected of containing a bug, then generally removed once the bug has been found. Trace statements not only trace the path of execution through code, but the changing state of program variables as execution progresses. If you have used Design By Contract (see below) diligently, you will already know what portion of the code to instrument with trace statements. Often it takes only half a dozen or so well chosen trace statements to pinpoint the cause of your bug. Once you have found the bug, you may find it helpful to leave a few of the trace statements in the code, perhaps converting console messages into file-based logging messages, to assist in future debugging efforts in that part of the code.
Interestingly enough, the article is otherwise filled with good suggestions. If you get past his fixation on debuggers being a problem, it's worth reading.
Ars Technica gives a good summary of what's going on between the RIAA and the EFF in the current copyright fights in the courts - and it's stranger than I thought. Take this, for instance:
As far as the courts are concerned, the issue of distribution and digital transmission is significantly murkier. The EFF's brief illuminates just how murky the issue is, with some courts taking for granted that digital transmission does constitute infringing distribution and at least one lower court hewing to the letter of the law and ruling that it does not. The EFF therefore urges the US District Court to be the first court to explicitly tackle the issue of digital transmission and distribution, and to define "distribution" so that it requires the exchange of a physical object.
The part that's fascinating and somewhat ironic, at least to me, is that the EFF is now in the position of arguing in favor of an outmoded, pre-Internet concept of "distribution," and one that runs directly counter the plain sense of the way that both the language and the concept of "digital content distribution" is currently employed in just about any online venue where the topic is discussed. Would anyone argue that Apple is not, in fact, in the business of distributing music now? (Actually, that's a bad example, because Apple may be arguing exactly that in their ongoing dispute with Apple Records. Still, you get the point.)
I hadn't given that much thought - but the existing law depends on a physical transfer of a copyrighted work. As I vaguely recall, copy machines introduced a monkey wrench that took awhile to sort out - a lot of "fair use" precedent derives from the case law that resulted from that invention. So here we have the internet, which - as Ars Technica notes - throws a huge wrench into the entire (legal) of distribution. If I upload a copyrighted work, have a transferred it? What if that upload isn't to a public system, but simply to another device I own? What if the upload is to another media format? That's what's at stake here, and it's all up in the air at the moment.
Tim Bray answers a question asked by James Governor: "IS AJAX expensive?". Tim is correct - the question, as asked, is unanswerable. A CSS reference could conceivably be expensive, if the resulting CSS is huge. Heck, a bunch of image references could be expensive, depending on how they are retrieved (static files, blob lookups in a database, dynamic image generation - you get the idea).
In and of itself, AJAX is simply a way of making asynchronous requests. Whether those requests are cheap or expensive is a separate - and unrelated - matter.
The other day, I pushed up a post on the simplicity and power of Smalltalk, using the #factorial method in class SmallInteger as an example. Here's the entire implementation within the superclass, Integer:
factorial | tmp | self < 0 ifTrue: [^self class raise: #domainErrorSignal receiver: self selector: #factorial errorString: (#errFactorialInvalid << #dialogs >> 'Factorial is invalid on negative numbers')]. tmp := 1. 2 to: self do: [:i | tmp := tmp * i]. ^tmp
So ignoring the error handling, the basic code is 3 lines. In one place. Sure, it relies on the ability of SmallInteger objects to auto-promote themselves - but the point is, as a developer, I don't need to worry about those details - it just works, and gives me the right answer. I also made the point that developers can create code that has the same kind of power - a quick look at #become: will explain what I mean. It's not a method to be used lightly, but - when you need it, it's invaluable.
If I wanted to write #factorial in Java, would I be able to write one method in one place? Would the issues of correct type get in the way, and force me to consider utterly irrelevant implementation details? That was the point I was making. The fewer "make the compiler happy" issues I need to deal with, the better off I am. At the end of the day, the compiler isn't my customer.
Update: Here's a Java implementation. Sadly, it won't work with numbers bigger than 20. Kind of makes my point, I think.
There are only 3 days left before the conference - if you have open Smalltalk positions that you would like to promote, contact Suzanne Fortman - the STIC booth will have information available from interested employers. Get it in now - time is short.
There's still time for Advance Registration though, and a quick email to Suzanne will get you the discount code for Smalltalkers. Registration gets you access to all talks - both Smalltalk and LW/NW main tracks - and all tutorials. One great talk - new STIC director Bob Nemec is going to explain why Smalltalk is a great fit for financial applications:
Managing large portfolios that hold complex financial instruments requires software that can deal with the complexity without overwhelming the development team. Northwater Objects uses Smalltalk as a tool to manage that complexity. We show how specific business requirements were well served by our use of object oriented design, Smalltalk development tools and an object database.
See you in Toronto! And make sure to stop by the Cincom booth - we'll have a lot of new information on upcoming Cincom Smalltalk stuff, and a number of new success stories - including an update to the Key Technologies story.
I spoke at SPA 2006 recently, and I have a couple of other engagements coming up:
- Smalltalk Solutions 2006: I'll be talking about my blog server, but in a technical case study kind of mode. The Abstract:
- In 2002, James implemented a web log server in Cincom Smalltalk (VisualWorks) and has been posting to that blog, building a community of fellow Smalltalk bloggers, and enhancing the Smalltalk server. James will guide you through the process of building, maintaining, updating and scaling a Smalltalk web application server and show the ancillary areas of the technology XML, RSS, XML-RPC. He will show the ease of modifying a Smalltalk server in place, without taking it offline and the transition from single user to multi-user -- all without downtime.
- Syndicate Toronto - I'll be speaking about the implications of blogging and syndication technology for PR/Marketing professionals. The Abstract:
It’s a new, unfamiliar world for marketing and PR people. Until fairly recently, marketing communications were tightly controlled, and mostly one-way. Where there was a need/desire for two-way communication, it was done on terms set by marketing and PR – focus groups, market surveys, analyst briefings (etc.). The emergence of the blogosphere has changed all of that, in ways that are every bit as profound as the sea change wrought hundreds of years ago by Gutenberg’s printing press.
I’ll be talking about the need to keep track of the ongoing commentary that’s taking place, outside of the control of PR professionals. It’s no longer enough to have a consistent message; you now need to be aware of what’s being said about you, your products, or your client’s products at all times. I’ll give a few examples of companies not paying attention fast enough, and how that’s impacted their public image. I’ll also explain how I, in my role as a product manager, track references to the products I work with.
- The Toronto Smalltalk User's Group - I'll be talking about upcoming releases of Cincom Smalltalk.
Should be a fun set of talks.
Rowan asks what we're all thinking - is Michael getting close to Toronto yet?
Assuming Michael hasn't been struck with some sort of voodoo travel curse like he came up against last year, he should be on an Air Canada 767 starting on its way across the Pacific by now. Fingers crossed that he makes it to Toronto on schedule without any undue hassles.
If I walk into the lobby of the hotel and find a dazed Michael wondering what day it is, I'll know it's happened again :)
There are only a few days left to get the Advance Registration (and Smalltalk - contact Suzanne Fortman for the code) discount for Smalltalk Solutions 2006 at LinuxWorld/NetworkWorld. It's going to be a great show, and signing up gets you access to everything - like Michael's talk on UI Building with WithStyle:
For a long time there has been a divide between Web Interfaces and classic Desktop interfaces. This divide is being closed by the WithStyle user interface platform. This session will demonstrate how to build hybrid User Interfaces using the WithStyle technology featuring Pollock widgets and Web-like content defined using XML and CSS. Behavior is linked directly to Smalltalk objects. The entire Look and Feel of the interface is switch able simply by swapping CSS. ynamically changing a live user interface on the fly by altering widgets, XML content and CSS stylings will be demonstrated. The full power of the Smalltalk environment blended with browser-like rendering technology is finally at our fingertips. This presentation is targeted towards Smalltalk programmers, user interface developers, XML users, Web developers and advocates of open standards. Prerequisites: Smalltalk, HTML, XML, CSS
See you in Toronto!
Well, this is kind of discouraging. There's a Father/Daughter girl scouts "sports extravaganza" this afternoon, and here's the forecast going into the evening:
It looks like it could be a wet day for outdoor activities :/
We have a set of online tutorials for people who download Cincom Smalltalk non-commercial, but it turns out that they are slightly out of date. They were last updated for VW 7.2, but there have been a fair number of interface changes since then - primarily, the incorporation of packages/bundles into the base. What that means is, for neophytes trying to work through the tutorials, the instructions are no longer accurate.
So, I've been updating them. I'm roughly half done, and I'll be getting the entire set of stuff back to the web team for posting soon. Stay tuned - a more up to date set of tutorials is on the way
Paul Thurott explains why I'm not worried, using the kind of argument I've brought up before:
Microsoft has made some mind-numbing mistakes. It (illegally, as it turns out) artificially bundled its immature Internet Explorer (IE) Web browser so deeply into Windows in order to harm Netscape that it's still paying the price for the decision--a full decade later--in the form of regular critical security flaws that have taken away time from developers that might have otherwise been spent innovating new features. The company itself has turned into that thing it most hated (read: IBM), an endlessly complex hierarchy of semi-autonomous middle managers and vice presidents of various levels and titles, many of whom can't seem to make even the smallest of decisions. The company is too big and too slow to ship updates to its biggest products. It's collapsing under its own weight.
To make a long story short, Microsoft has become Gulliver, tied down by a million tiny threads. Unlike Gulliver though, their personal Lilliputians all work in Redmond, endlessly creating more thread. Which is not to say that Microsoft will disappear; you'll notice that IBM isn't gone. It does mean that MS faces some very rough seas, and their level of industry influence is on the wane - and I very much doubt that it will cycle back up anytime soon - if ever.
Hat tip Keith Ray.
A California court in San Jose on Thursday is scheduled to hear a case brought by Apple Computer that eventually could answer an unsettled legal question: Should online journalists receive the same rights as traditional reporters?
Apple claims they should not. Its lawyers say in court documents that Web scribes are not "legitimate members of the press" when they reveal details about forthcoming products that the company would prefer to keep confidential.
Here, let me translate:
"We liked it a whole lot better when we could wow a handful of journalists with gifts and pre-release briefings. This nonsense of anyone with access to a computer having an opinion has got to stop!"
I may give MS a lot of crap, but at least they aren't out there trying to shove rubber balls down my throat. Let's hear some more of Apple's words of wisdom:
"Unlike the whistleblower who discloses a health, safety or welfare hazard affecting all, or the government employee who reveals mismanagement or worse by our public officials, (the Macintosh news sites) are doing nothing more than feeding the public's insatiable desire for information," Kleinberg wrote at the time.
I'd have something snarky to say here, but I'm too busy giggling. What do these clowns think the media does, if not feed the public's desire for information? The only difference is that there are fewer print people covering Apple, and they feel like they can control them better. They don't like the idea of the "unruly mob" of bloggers expressing opinions.
Hey Steve - I have a message for you: Stuff it. I'm looking forward to buying an intel based Mac, but believe you me - this kind of attitude is going to make me think twice.
I just got this from LinuxWorld/NetworkWorld:
Final Week to Save $350 on the Smalltalk Solutions Conference This year, attend the premier forum for Smalltalk users, developers and enthusiasts, hosted by LinuxWorld & NetworkWorld Canada. Three days of over 20 educational sessions from the most renowned members of the Smalltalk community—from Canada, USA, Australia, Germany, Italy, Switzerland and England—covering technical issues, new ideas and concerns.
That's $350 CDN - contact Suzanne Fortman for the registration code.
I was all ready to blast the idea of Star Trek 11 - it's going to be about the young Kirk and Spock, coming out of the Academy. That was before I saw this:
This brings to the fore the new boss at Paramount, Gail Berman's promise to give the franchise a new and fresh look and revitalization. She has hired a whole new production team and leadership to headup the project as well. The old crew of Rick Berman and Brannon Braga, as far as we know now, will not be involved. Their primary duties will be taken over by Damon Lindelo and Bryan Burk. They are J.J. Abrams' production team behind the hit ABC show "LOST."
Well. If Berman and Braga are gone, then it might not suck. We'll have to wait and see, but there's actually some hope here :)
When the RIAA's lawyers don't get their way, they get very, very thuggish. Can't win a suit against one family member? Just keep suing. What utter tools.
Pass out the cigars! It's finally happened! I am pleased to announce the birth of the Croquet SDK, a software developers toolkit for use in developing deeply collaborative appliications using the Croquet technology. We just made it available for download from the newly redesigned Croquet website . Thanks to everyone who provided us with their support and patience as we worked to bring this technology to the open source!
It turns out that I was double counting source downloads - obvious once I took a look at my reporting script. So, the weekly downloads have likely been 70-80 lighter per day than I've been reporting. The problem? I never updated the script after I updated the names of the source download files, and I was catching some graphic file accesses. There's an easy way to inflate a number :/ Here's this week, at a more accurate 152 per day:
On to the HTML page accesses. The daily logs have been up and down for total hits, but fairly constant for unique IP addresses. Either I'm getting fewer crawler hits, or some spammers gave up after I dropped trackbacks. The details:
|Tool||Percentage of Accesses|
Finally, on to the RSS tool usage:
|Tool||Percentage of Accesses|
|Net News Wire||12.1%|
|Google Feed Fetcher||3.8%|
Dare Obasanjo posted some skepticism about the Technorati blog counts, partly because of this:
As usual for this series of posts, Dave Sifry plays fast and lose with language by interchangeably using blogosphere and number of blogs Technorati is tracking . There is a big difference between the two but unfortunately many people seem to fail at critical thinking and repeat Technorati's numbers as gospel. It's now general knowledge that services like MySpace and MSN Spaces have more blogs/users than Technorati tracks overall.
It seems he might have spoken too soon - looks like the Technorati Top 100 is tracking Spaces on MSN, at least. It looks like a lot of the "first movers" in the blog sapce are being pushed down (or even off) the top 100 list by personal blogs of various sorts. As Publishing 2.0 says:
There are many implications to this phenomenon, all of them fascinating and deeply disruptive to U.S. West Cost-centric view of the blogosphere
The blogosphere is not one thing, and never was. And the divide is bigger than political/other. It's really a huge set of partially (and non) overlapping niche audiences of various sizes. Just as cable TV has allowed for a more diverse range if special interest channels, the unlimited nature of web space has enabled a nearly infinite diversity of conversations.
Update: Dare notices the trend.
I think User Friendly captures the feelings of an awful lot of fans with today's strip :)
The second edition of Caylus is out - they've got real coin tokens now, instead of the bozo stuff that wen out with the first edition. In that printing, the coins were all the same color, there were no printed numerals, and the way to differentiate fives from ones was size. Ick.
More importantly, we played a game last night and I didn't bring up the rear - I won. It took me awhile to get a feel for the game, but in the late middle of the game you really have to have progressed up the building favor chart and acquired gold - so that you can build one of the big blue buildings. Along the way, of course, you have to have built at least one green building.
It's a very cool game, but it does take longer to play than Puerto Rico. There's more good news too - it looks like you can play on BrettSpielWelt now. Cool.
The RIAA continues to be a first rate group of tools - witness their latest lawsuit:
A federal lawsuit filed this week in Rome by the Recording Industry Association of America alleges that Carma Walls, of 117 Morgan St., Rockmart, has infringed on copyrights for recorded music by sharing files over the Internet. The lawsuit seeks an injunction and requests unspecified monetary damages.
There's a small problem with the allegations:
This came as shocking news to the Walls family, who were notified of the lawsuit Friday afternoon by a newspaper reporter. James Walls, speaking on behalf of his wife and family, said they have not been served with legal papers and were unaware of the lawsuit.
After being shown a copy of the court filing, Walls said he found the whole thing bewildering.
“I don’t understand this,” Walls said. “How can they sue us when we don’t even have a computer?”
Like much of the other stuff the RIAA does, facts simply don't matter. The idea is to scare the crap out of anyone within range of the press release. I rather suspect that they have some moron who thinks he tracked an IP address to the house in question - never mind how recent it was, and never mind the possibility of unsecured WiFi (very common) being used by someone in a nearby house. Heck, before I bought my latest router, my notebook sometimes found the neighbor's setup before mine - and I wouldn't notice until I tried to access something on the LAN.
It seems that there's been some confusion over the term "Conference Hotel" at Smalltalk Solutions - especially with references here on the meetup Wiki page. Just to be clear, that means the Renaissance Hotel. So, the 7:30 meeting to get out to Pure Spirits means the lobby of the Renaissance. I'll be in the air at that time - I'll be arriving late.
While everyone throws roses at Sun and Redhat - for being "champions of Open Source" - not too many people are paying attention to what they are also funding - an expansion of the DMCA that would have made circumvention of Sony's rootkit DRM a felony. Thanks a lot guys - I'd rather you had obnoxious EULA's and stayed the heck away from the really anti-competitive stuff. Maybe someone could ask Jonathan Schwartz about this, for instance. His passion for open source in Brazil is nice, but it would be a lot more helpful if he stopped making the world worse.
Interesting. Scoble is exhausted, seemingly. Dave Winer says he's going to retire. And here's Russ Beattie, hanging it up. Looks like a lot of the early adopters have hit a wall of sorts, and decided to move on. I'm still having fun, so don't expect a let up of any kind here. It's interesting though - writing does take work, and I think I understand why most syndicated (print) columnists only write 1-3 times a week.
In the meantime, the coming week will be filled with posts from Smalltalk Solutions. It sounds like there won't be net access in the conference area (other than a very early '90's style "email garden"), so the posts may well appear in bunches early in the day, and again late. Maybe I'll be pleasantly surprised, and find WiFi - stranger things have happened :)
Wow, I haven't flown on a Dash 8 in years. I'm taking Air Canada Jazz into Toronto from BWI, and I was surprised when there it was at the end of the jetway - down the stairs and out to the turbo-prop. I'd also forgotten just how loud these things are. Fortunately, my wife got me decent headphones, so I'm enjoying Lileks' latest podcast as I sit here and tap this out.
Anyway, we got out of BWI before the thunderstorms that were supposed to head in - and the rain in Toronto looks like it shouldn't be a problem (until I try to stay dry in it, but that's a problem for later).
We had quite the crowd at the restaurant - more than double the number of people expected showed up. That gave the waiters some stress, and made the billing interesting, but we got it all sorted out. It was great to see so many people, including quite a number who I don't know - a good sign, as far as I'm concerned. Now it's off to Michael's room - he's promised us Tim-Tams :)
So I'm at LinuxWorld/NetworkWorld - at an Expo center near the CN tower. You would think there would be WiFi, and you would be correct. However, the only way to gain access is to have the show pay the (egregious) fee in order to get a code. Has the convention center considered the wild idea of offering access on an individual basis for a fee? Nah, that would bring in revenue, or something.
Sigh. A day without network access...
Scoble definitely has a passion for his work, but his post on the angst at Microsoft illustrates one thing to me very clearly: Mini-Microsoft has one thing very right: the company needs to be smaller in order to get better. Either they'll fix that themselves, or the market will it for them. Like IBM back in the late 80's.
Longtime Star Trek writer and producer Rick Berman, who joined the franchise at the feet of creator Gene Roddenberry, will not be involved in the proposed 11th Trek film, to be directed by Mission: Impossible III helmer J.J. Abrams, SCI FI Wire has learned.
The movie might be good :)
9 AM on Monday morning, and I'm at Travis' Efficient Smalltalk presentation. I could have gone to Alan's GLORP talk, but I've spent many, many years trying to ignore databases - no need to change that policy now :)
Travis started in Smalltalk in 1992 - he left a Fortran job to get away from a bad boss. Taught himself Smalltalk from the Digitalk tutorials "back in the day", and has been Smalltalking ever since. He moved to Key Technology in 1996, and has been there ever since. In distribution terms, the audience is pretty heavily on the VW side, which is cool.
The idea Travis has for this tutorial: dispel the "Smalltalk is slow" myth. Plays into my talk which will come up later this week - I've yet to hit a scaling problem with Silt that wasn't a problem with my code specifically. What it's not: VM optimization, or "Smalltalk is faster than language (x)" thing.
Travis: Smalltalk has one of the best "thought to code" ratios" - you can get the code you are thinking of out very quickly. It's easy to throw a prototype together very quickly - the downside being that it's also easy to write some very inefficient code. The good news: it's just as easy to fix a bad design, and to improve performance relatively easy. That fits my experience - I've never had much trouble getting rid of the bad spots in my blog server. The motto:
Make it Work, Make it Right, Make it Fast
Early optimization is truly the root of all evil. A well designed system optimizes easy. An example: "Flogging the Logging", where Travis says he didn't actually examine the problem before diving into it.
Performance tricks aren't always reusable
"The problem is the system isn't running the Sieve of Erathosthenes" - Alan Kay. So you need to review each gain in context - do they really matter given the larger issues? You have to be willing to look at old assumptions and throw stuff away. Something too few of us do: Diagnose first, code for speed second. I know that my guesses about where the problem is in my own code are frequently disproved by the profiler.
Unit tests can help - you can verify the working nature of the code as you optimize. I can certanly say that a lack of tests can make for deployment surprises.
Where does the "Smalltalk is slow" myth come from?
We don't make time for the "make it fast" part. We get working code so quickly that we tend to just ship it. Throwing faster hardware at the problem is oftena cop-out - Project managers need to allow time for optimization.
Time millisecondsToRun: 
Run it many times, and watch for simple things that throw things off - Large Integers, memory allocation. In VW specifically, dotted references (namespaces) can be an awful lot slower. Make sure to figure out the profiling overhead, because a presumed improvement may not actually exist. Make sure that you use consistent measuring methods across tests.
Good tool to get familiar with. Nice if they can be used programmatically and from a UI. Nice if they can dump to a UI and a file. Multiple ways to view results is good too. One thing I've noticed in multiple visits to customers is how few people have ever looked at the profiling tools. I've often showed up and asked "have you profiled?" and gotten the answer "we know what the problem is". I've yet to see that be the case :/
There are different tools across implementations - VW has five, measuring time and allocation, in one process or multiple - and a VM profiler. Squeak has two options. VA ships with a very complete profiler that does sampling and tracing. It also supports some nice graphical output. You can use it interactively or programmatically. Michale Lucas-Smith points out that the Instantiations goodies includes another profiler. Smalltalk/X has some basic message tally tools. Only does sampling, and doesn't have a nice UI. Also some memory tools. Dolphin has a goodie from Ian Bartholomew that is interactive only. Has a nice UI with lots of detail.
Bruce Badger brings up the Code Crawler (VW and Squeak). It pulls out tons of metrics and has good reporting tools. Somewhat reminiscent of the old Arbor Probe tool.
Patterns for Performance
This is a set of examples that illustrate a theme (or category) that overlap. While few performance issues are exactly like another, they often share the same general problem. While Travis includes numbers here, he's saying to take them with a grain of salt: YMMV.
The first thing - recalibrate your expectations. Optimization tricks are often not reusable:
- Not across different VM's
- Not across different versions
- Not across different OS platforms
- Not across different contexts
All of which explains why early optimization is such a bad idea. So some "old chestnuts": "Everyone" knows that string concatenation is slower than dumping to a stream. It turns out that concatenation is actually faster now, because it's been rewritten. You can get faster with streams by properly sizing up front, but it illustrates the power of old assumptions.
Another example: Many people thing that #at: would be faster if it offered an unsafe version. So Travis wrote a faster #at: in Smalltalk/X. In Smalltalk/X, you can inline C code - so you can do "primitives" directly. So into a demo - remove the bounds check, remove the small integer check - and then test. It turns out that making that change doesn't actually speed things up that much - which has to do with changes to the underlying hardware. Again - when doing performance testing, you have to be willing to toss old (possibly outdated) assumptions.
Use a different algorithm
Chisel away at the profiler results - difficult to see the forest from the trees that way. Big gains are usually found in new algorithms, not in small tweaks. Smalltalk's thought:code ratio makes that easier. If the algorithm itself is slow, then the profiler won't help much.
An example: #indexOfSubstring:at: - in VW, the library uses the simple, direct algorithm. There's a publically available algorithm (Boyer-Moore) that's faster.
Similar idea - use a different (data) representation. The RB does this with a replacement for a dictionary that does linear searching - since the data sets are small, it's a win over the overhead of dictionary hashing. Sometimes, the "slower" CS answer is faster.
Another example: OrderedCollection can grow from both ends. What if all you need is a Stack? He implemented a Stack class that only uses #lastIndex. It's 2X faster for normal use, but is slow if you do need to add at the front.
Use a real object - don't just keep a dictionary, or a collection around and start adding helper methods to the wrong classes - create a real class so that you can isolate problems. There are simple wins too:
somePerson name is slightly faster than somePerson at: 1 - and it reads easier, which is probably more relevant in the long run.
Sometimes it's a win to do the new algorithm in Smalltalk rather than trying to optimize down in C - the C code is harder to write, so production of a new algorithm is so much easier. If you can get it to be "fast enough", you can just stop.
And we're back after the coffee break - much needed, since I'd only had one cup before this all started. So back to the examples.
Transcendental math is great (I blogged about this last week). The VM and image take care of problems for you, either via double dispatch, or via failure/coercion/retry. There is a performance hit for this convenience. So in general, SmallIntegers in Smalltalk are highly optimized, and are no work for the collector. In most Smalltalks, putting the higher generality number on the left can be much faster. i.e.,
100.0 * 10000 is around 4x faster than 10000 * 100.0. So even in Smalltalk, knowing your implementation issues helps. [ed - I had to get iterations up to a million to see a difference in VW]. Fractions are very cool, but they are also very expensive. If you don't need them, don't use them. So for instance:
(a/b < c) is much slower than (a < (b * c))
simply because of Fraction math. Division is expensive in software math in general, not just in Smalltalk.
In math issues, zero is "special" - Nothing is slower than a UHE. An #isZero check is much faster than catching the ZeroDivide exception.
In some cases, limiting the production of new objects (in order to not create GC need) can help. In particular, this can be a big win in graphics work, like translating rectangles. Coding a specific rectangle move method that doesn't create objects as a side effect can end up creating far, far less garbage to clean up.
This also comes up in working with collections - most of the extant methods return new collections instead of changing in place. If you need to work with large collections, creating your own versions that modify in place can be a big win. Examples:
someCollection asSortedCollection first (or #last)
instead, try: someCollection fold: [:a :b | a min: b].
You save the creation of a throwaway collection. With the test data, it probably doesn't matter. With real data, it can make a huge difference. Side note: Martin Kobetic and Michael brought up this post from Alan, which uses streaming as an alternative approach.
Another thing: using simple file "database" access, over-use of Filename>>construct: might be expensive. Hmm - I'll have to examine that in my blog server.
There's always the old standby - caching. For large objects this can be a nice win based on the way the VM stores large objects. Along the same lines - don't do expensive things over and over again. Sometimes, this will result in ugly code that ought to be commented. For instance, in VW, RBScanner>>scanToken:
scanToken "fast-n-ugly. Don't write stuff like this. Has been found to cause cancer in laboratory rats. Basically a case statement. Didn't use Dictionary because lookup is pretty slow." "code omitted"
Another interesting thing: in general, using a MessageNotUnderstood handler is faster than asking the object if it #respondsTo: Although, if you are using this for backwards compatibility, you probably have other problems.
Collections often have a "lifecycle" - i.e., you add things once, you sort once, and then you're done. Quite frequently, the code keeps switching collections based on early needs - you'll know you have this if you see lots of #asOrderedCollection (etc) in your code.
Simple minded standbys (cache a computation in a temp variable, for instance) can often have big impacts as well. This goes back to the fact that implementing in Smalltalk is very easy, so it's easy to an inefficient piece of code into production.
Skip Framework overhead
Don't swat flies with howitzers! Use the simplest object that could possibly work. An example - ExternalRead/WriteStream is a general solution for most needs. You can use an IOAccessor directly if you write enough files that there are performance concernns - and it can be faster. Another example: ComposedText does a lot, Label does a lot less. Label is tons faster if you don't actually need any of the features of ComposedText.
Another example: The XMLParser. The parser framework does everything you would ever want, and builds up a document. If all you need is to find a tag or tow, a simpler string search might suffice (iirc, the Web Toolkit does a fair bit of this).
Inlining can make code easier to read, and can also turn up chances to optimize in other ways. This brings to mind Terry Raymond's defactoring tools. It can make a difference whether you use #isNil instead of #ifNil: - small, but noticeable. Someone points out that the when IBM started inlining #ifNil: (and friends) in VAST (quite awhile ago now), it broke a number of proxy frameworks. Back to the howitzer comment.
Down to the "metal" in Smalltalk. There's variance amongst primitives, especially in the graphics area across platforms. So an example: say you need to draw diamonds. Obvious: #displayPolygon: Not as obvious: create a mask and draw that. The results between these two vary a lot between X11, other platforms, and VNC (and likely things like Terminal Server). You need to be aware of your platform in cases like this.
As a last resort, you can make your own primitive (noting that this makes code harder to develop. install, and share).
Make it look faster
Users don't like being left out - include them. Get feedback, and be aware that fast is in the eye of the beholder. An example: The Windows "flying folder" copy is 20% slower (Win 2k test) than XCopy. Most users think it's faster, because they are getting feedback.
Smalltalk doesn't have to be slow - it's usually misuse of tools that cause problems. Check your assumptions, and look at the algorithms you use.
There was a contest between the Seaside tutorial and lunch, and since I didn't get breakfast, lunch won. I think I'll try to get into the second half of it; I might have a bit to post on it in awhile.
I walked into the Seaside tutorial halfway through - which isn't bad, as it happens - a goodly proportion of the audience is non-Smalltalkers, so a fair bit of what I missed was an intro. With that out of the way, I'm getting the actual Seaside/Ajax part of the talk. I can't unzip the Scriptaculous library at the moment - I played Civ4 over the weekend, and haven't rebooted yet. Par for the course; the Windows file dialog is hosed.
So - a brief warning about what Ajax is, and how over-use could slam a server, and then it's off to the races. Back after a reboot, and I was able to extract the files. Stupid game :/ So here's a screen shot of the Squeak browser, with a view of one of the callback methods - it's handling one of the asynch calls back from the browser, and rewriting the appropriate pieces:
Side note at this point - all of this Seaside/Scriptaculous integration is available in the VisualWorks port (big hat tip to Cincom's Michel Bany for that).
Question about persistence: there's nothing specific for Seaside, but people use a variety of things. Object dbs (Omnibase, for instance), or GLORP, or a number of other things that are available from vendors and the community.
A question: What about the "classic" approaches? Ruby on Rails is a nice, clean way to approach the old fashioned style of web app - works very well, is very clean. You end up writing a lot of state machine style code in your application though, and it gets harder and harder to maintain. Seaside removes all that overhead from you. So RoR will serve you well if you have a simple "db to web" app to build. If you need to manage state, then Seaside is easier.
Another question: What about having "clean" URLS? Not easily possible for an entire Seaside application. You can have bookmarkable sections that slam extra stuff in the URL that will deal with that.For instance, DabbleDB is built on Seaside, and does have "clean" urls as entry points.
Still, if we meta-meta-developers are doomed to build a poor replica of the development platform we work with, I'm happy to be working with a platform that knocks seven shades of spots off the one the MS team has to use. Could that be the reason MetaEdit+ is 100 times more compact, runs on 5 times more platforms, is 10 times faster starting up, and 5-10 times faster to use ? :-)
That might have something to do with the platform that MetaEdit+ is built on.
We have a general STIC meeting on tap now, and Bob Nemec is introducing himself to interested Smalltalkers. As Bob says, STIC needs input and help from interested Smalltalkers, not just from the vendors.
First up, the explanation for why we're at LW/NW - we want to get a presence beyond the existing community - get people who don't know us yet to see what we're about. We'll be back at this venue for 2007 for sure, and we'll see how things go from there.
So what do we intend to do? First off, revamp the STIC websites (stic.org and whysmalltalk.com). The idea is to give something of a better cross vendor view of what's going on in Smalltalk. Bob pointed out that - "back in the day" - comp.lang.smalltalk was the main forum. USENET has feaded, and there are now tons of disconnected forums - mailing lists, wikis, blog sites, etc.
On to Monty Williams of Gemstone, who handles our finances. Most of our revenues have been from hosting StS, and then waiting to see if enough people sign up. What we want to see now is people getting the individual memberships (which gets you access to the 25% discount code for this show). One of the big helps of being at LW/NW brought up from the audience is this: it's easier to get corporate to pay for attendance of StS at LW/NW.
Back to Bob Nemec - he'd like to see STIC help hook up user groups and interested speakers - from vendors and elsewhere. Good question from the audience - for the interested Rubyist (etc - this is an example) - what does Smalltalk have that a Rails developer would be interested in looking at? That's one thing that the STIC website should have information on. Here's where I interjected something simple - we cannot do this without people in the community stepping up to the plate.
Another question - why LW/NW? Why were they interested? We got in to a large extent via the sheer persistence of Suzanne Fortman, and her efforts to work with the LW/NW people. They were willing to work with us, but this year was year one - we'll have more going on next year after having worked with them now. We'll be back here in Toronto next year, and after that? We'll have more ability to get things lined up with a full year's run-up time. To get a keynote, we needed to get someone speaking at a non-technical, C level whose schedule lined up.
Another question: "What does my $40 membership buy me?" In past years, it bought you a $75 discount for StS. This year (and rolling forward), it will buy you a $300 discount on StS. We intend to do more (revamping the websites, etc) - but the discount is a good buy all by itself. Or as Bob Nemec puts it, you're buying marketing dollars for STIC.
Good suggestion from Bruce Badger - there are Linux groups (schools, universities, etc) that always need speakers. One easy thing to do is to volunteer to speak. Many publications are just as hungry for content - what you need is a good angle (a company that solved a problem, etc) - not a technically oriented "why Smalltalk is great" piece.
Scott McNealy has stepped aside (or been kicked upstairs). I'd say there's hope for Sun, but the new CEO is "give it all away and make it up in volume" Jonathan Schwartz. Someday, there has to be some revenue brought in from the software they spend so much money developing...
Adriaan van Os has some pictures from the first day (and the weekend, I think) of Smalltalk Solutions.
The title is actually from Oscar Wilde - he is reputed to have said that when he first entered the US and he was asked what he had to declare.
With static type checking, it's like trying to declare that no shot on goal is possible, and thus there's no reason to even play the game. Heh - Brian apparently started in on this talk at customs, after they asked him what he was speaking about :)
We are in are in the era of "Architectural balkanization in the post linguistic era". Brian says there are three ideas that have come out of OO and Smalltalk:
- Dynamic Polymorphism - dynamic dispatch - easy as pie, great for wrapping stuff. With dynamic compilation, you can replace things at all levels - module, application, component.
- Callipygian Compilation - JITs - hotspot VM's, the work of Deutsch and Shiffman.
- Reflection - grew out of Lisp. self representation, introspection/intercession.
Smalltalk-80 - "Everything I know about OO I learned from the Image" - browsers/IDE, Windows/GUI, JITS, building up from objects. The notion that the program was built out of mutable objects was what really stuck.
With reflection, you can have a manifest (which, to Brian's mind, explains XML's popularity). You end up with user configurable code. You can cope with things at runtime that you haven't seen before with ad-hoc reflection.
Last summer, Brian worked on MOP and multi-methods in Smalltalk - produced a paper on it, which reflects his particular style of humor - there's a segment on whiskey consumption :)
Asynchronous messaging is only now coming into vogue. Brian asserts that this was prefigured by Actors.
One of these is true (the second)
- Meta Considered Harmful
- "Meta" Considered Harmful
The Vision: Languages built out of objects instead of text. Open Languages, Open JITters, A framework for languages. Compile time is anytime. A part of the Smalltalk vision early on was Linguistic Imperialism (to be fair, Java has this going too).
Utopian moncultures are good idea incubators, but not actually workable. We live in a pargmatic, heterogeneous, polyglot world. We need to work and play well with others. As Brian puts it, there was a schism in 1997:
They all retreated into their own conferences and languages. Heh - "Of Slugs and Bugs" - a tale of types, or "How Star-Crossed software lost the Mars Climate Orbiter". So you had a perfectly good spaceship, with perfectly good software - and yet it dove into the ground as it was told to do by the software. The culprit: A "Simple" unit conversion.
The carpetbaggers came in with their own pet theories as to how it happened - no testing, bad methodology, bad management, bad integration, bad testing.... lots of text got written. The root cause: using English measurement units in a software file that was input into something that expected metric units.
The previous Mars probe that used the same software worked fine, but they changed the number of solar panels on the MCO - so they had to use the thrusters more often to compensate for the way it ended up moving. They had software to track the changes this introduced. When they reused some old code to compensate for all this, the developers assumed that the English-Metric conversion was already in the system. It wasn't, so the frequent use of the thrusters ended up introducing a larger and larger error into the landing scheme.
There were plenty of papers at OOPSLA that said that having units added to Java would have prevented this. Sadly, paper is not executable. The bottom line was that the code for MCO was a hatchet job: "Faster, Better, Cheaper - pick two". There was no end to end testing - the programs were late. Managers trying to save money don't win games - the players still have to suit up. The reused code was trusted because it had worked before (in different conditions).
In the end, it blew because reading code is, in general, hard. Large bodies of code are unreadable (we are all in denial over this.
The Olfactory Method
If it stinks, change it. Code Smells are a subtle indication of a problem. The end-to-end principle applies to programming languages too. You can just leave the goalie in at runtime instead of pretending that type theory disproves the need.
The program model is the central thing. Programs built of objects can be changed. That lets you use dynamic polymorphism to swap things out. Software isn't like "real" engineering. We can't type each line of code three times, for instance :) What we can do is leave the goalie in. We can engineer our objects to test themselves. The network and databases are slower than reflection. Runtime type errors? Welcome to the 21st century - we have to learn to deal with them.
Static languages throw away all the information we need at runtime. Why? It's not 1982 anymore. No one is infallible, and we have to realize that bugs will continually exist. This is a lesson I've learned with BottomFeeder - generally speaking, I ignore runtime errors and let the program run. And somehow, it does :)
Randy Coulman with Key Technologies is going to talk about Acceptance testing with Fit, FitNesse, and FitLibrary. This is going to be more of an overview of the tools than anything. Randy: Working for Key and doing Smalltalk for afive years.
The example we'll use - the game "Mastermind". Basic idea - you set up a "code" (colored pegs in sequence), and your opponent tries to break the code. Randy broke down the rules into a set of Fit tests using the Fit Wiki server (FitNesse). Fit is the acceptance testing framework from Ward Cunningham. FitLibrary is a set of additional fixtures. Available for:
- VW, VAST (port in progress)
- et. al.
Randy is the maintainer of the Smalltalk (VW) port. The idea is that you write the tests in HTML pages, and then run them on any back end - thus making the acceptance testing live above the implementation lavel. The developers create fixture code that runs the tests themselves. The writing:
- Subclass the desired fixture class (ActionFixture used directly most times)
- implement #signatureFor: to provide type adaptor information
- Implement the necessary instance variables and methods
This is the simplest one - each row is a different scenario. Each column is either and input or an output. The expected outputs are compared to actuals, and then the test is marked red (fail) green (pass). Rows and columns refer to the HTML table used for presentation.
You create "workflow" type tests with this. There are actions to deal with - start, enter, press, check - you create a helper class to implement. This one can be brittle.
This is used to check a collection of results (eg - results of a query). The order of the rows doesn't matter, it's smart about matching up rows. It will show missing/surplus rows.
Then there are a set of extension fixtures - DoFixture, SetUpFixture, SetFixture/ArrayFixture, CalculateFixture (and more). Randy has a few implemented, is doing more.
Must be the first one on a test page - it's a "workflow" fixture. Takes over execution of remaining tables. It's less verbose than an ActionFixture.
Used to set up data for a test. Similar to givens in a ColumnFixture - no feedback in the table
Similar to RowFixture, but easier to write. You just create a set and it gets auto-wrapped. In SetFixture, order is irrelevant, in ArrayFixture, it matters.
Similar to ColumnFixture - no header markup needed to distinguish givens and expected values.
Now a demo of the way it works - I'd take a picture, but it turns out that I can't email myself pictures from here - which means that I need a real camera :) You can download all this stuff and try it out:
- In the public store
- Questions for Randy? Email him or hop over to the IRC channel - he's usually on during PDT work hours as "randy"
"How do I debug a test?" Well, in Smalltalk it's simple - you use the debugger that's right there, and slap in a breakpoint. It's a little more complicated over in curly-brace-ville.
I arrived a bit late, or Blaine started early - on with the talk. Where does pain come from? Tight schedules, fragile design, inexperience, unclear vision, poor coding practices, broken contracts. Despite your best intentions, some of this creeps in. You end up building up a "software debt" where you least expect it. The Tools? SUnit, Reflection, Version Control. There are the ancillary things you get from reflection (MethodWrappers, etc).
SUnit can be used to help "enforce contracts". It helps the team remember decisions that might otherwise be forgotten. Using reflection, Smalltalk makes it easy to check existing methods for various things - calls to things that should not happen at runtime, etc (eg - #halt left in the code).
Dumb Bugs Detection
SUnit and Lint are your medicine for finding stupid stuff. Helps you find code smells that have arisen via poor coding practices. The nice thing about Lint in Smalltalk is that it has a programmatic API - you can set up ad-hoc Lint runs that are scripted, without having to use a UI. The RB, of course, has a UI for it.
MethodWrappers can raise flags when contracts are broken. They are a good way of checking legacy code - you can add before and after blocks to methods, which can check pre/post conditions. You'll want to make sure that you unwrap the method wrappers afterwards, of course.
I'm missing some of the flavor of this talk - Blaine is moving from the presentation back to his Squeak image to show code and tests, and demonstrate. So bear in mind, with each thing (like Method Wrappers), he's showing live examples.
Broken Window Detection
SUnit and Metrics are your "canaries in the legacy code mine". You don't want to use these as sticks to beat people with; rather, you want to find out what's happening. Blaine recommends these three:
- Cyclomatic Complexity - good for finding spaghetti code
- Average Message Sends - lower scoring ones turn up data only objects
- Coupling - take all your message sends, and compare it to the methods your class actually implements. You end up finding "god" objects.
Keep the metrics simple, because complex metrics will just add complexity to your process.
SUnit and Source control interrogation- exposes volatile objects and code smells in the system. It can turn up possible objects for code review. Pragmas allow you to add meta data to methods. Helps pinpoint "private" violations, and class to deprecated methods. It's better than relying on method protocols.
Selling Reflective Testing
You need team consensus for metrics - what will you use, and how. You want to start simple, so you can get early success. Be positive instead of using it as a stick. Start encouraging refactoring sessions.
I took a break for the 3 pm session - up in the vendor area, there were customers that wanted to talk to me. So now, I'm back downstairs, and attending a talk on one of the things I've warned against - technology migrations. Karen hope, late of USF&G (which itself was bought out) is giving the talk. Karen started with Smalltalk in 1992, and has worked in VW, VSE, and VA. She worked in Smalltalk continuously until 2004 - with 1994 - 2004 being with the insurance company. She's now an independent consultant.
The application she spent time on was an insurance policy writing system (commercial, small business liability). It won a number of internal and external awards and kudos, including a Smithsonian Innovation award in 1997. The application also won early adopter awards from an insurance industry consortium between 2001 and 2003 (ACORD).
There aren't any code examples here, or consultant bashing. The decision to translate the app was made by corporate, not by the developers or application architects. The actual migration dates from 2004 - and the recurrent theme here is simple: Smalltalk good, Java bad. [ed: I'd modify that by again stating my general theory that technology migrations are almost always a very bad idea, and always spend huge wads of cash in order to stand still).
Karen's opinion after this experience: She would not want to work in Java, and would always recommend Smalltalk.
Heh - Karen adds an acknowledgement to Jeff Sutherland for a 1995 talk called "Smalltalk, C++, and OO Cobol: The Good, the Bad, and the Ugly". That appeared in Object Magazine in May of 1995.
There were over 2000 domain classes (describing the insurance domain). It used an O/R framework (TopLink), homebrew UI/MVC frameworks, and included a workflow management system. They were one of the early adopters of the ACORD XML system, which allowed them to do comparative pricing quotes in 3rd party systems. The application architecture:
- 4 Smalltalk multi-processor servers (hardware). 6 edits/rating Smalltalk image clones, 4 domain Smalltalk image clones, and 2 XML translator Smalltalk image clones.
- 2 additional servers - downstream/extractor Smalltalk clones
- Bootstrap Java code NT service managed groups of clones on Smalltalk servers. Each ran as an independent Windows process. Each clone had independent caching strategies, but had access to a shared cache.
- Round Robin dispatching initially, went to a more sophisticated load balancer over time.
The system ended up having over 99% uptime statistics. The average real-time edit/rate took 8 seconds. The average number of rates was 200/hour, and they had 75 developers on average. Between 1996 and 2006, they had over 40 production code base releases. So in 1996, what was at stake? There was a total redirection of IS resources (they actually started in 1993). At start, they had 2 Smalltalkers. They went on a massive training/hiring cycle. They created an unprecedented partnership between the business and IS.
In 1993, they chose Digitalk (VSE). At the time, Windows was not predominating, so they wanted to keep their options open - recall that Digitalk did create a Mac port early on. What about 1997 (ParcPlace-Digitalk merger era, VSE was taken down by PPD management). They decided to stay with Smalltalk, even though they were on a moribund product. They were able to push 4 production releases a year - they did not believe that they could do this with a different technology. They started moving parts of the application to VAST.
Then in 1998, USF&G was purchased. This changed things. The new management team also had a policy writing system, and the new CIO had been a part of that. They ended up with years of political infighting over which system would prevail. This was also when the depths of "Smalltalk is dying" and "Java is the future" was out there. Simultaneously, the fat client application was getting fatter, so they did need to make some kind of change to address that. Moving parts of the application to a server looked like a win in maintenance and deployment terms (no need to deal with variant clients, etc).
In 1999-2001, they started moving to a SOA based architecture as they converted code from VSE to VAST. They needed to respond to competitive pressures to allow for browser based rate quotes. They also made the database less application specific, allowing for more general reporting. It also simplified their O/R mappings, and made asyncronous processing easier. They also tightened the UI/domain separation, which had creeped away from MVC over time. At this point, they were adding Java components as part of the server-side WebSphere deployment. In 2002, the VSE client was retired, and all Smalltalk code was now server-side VAST.
Then management decided that they should transfer the whole thing to Java [ed: this is the point where I'd call what they did a mistake. VSE was moribund - a migration was necessary. VA --> Java? Lots of money to stand still].
They started with a "throw the code over the wall" service - a North Carolina based company. The project was cancelled after they had a partly working system. The test cases they had delivered to the vendor allowed them to do a VA Java based system that ran and reproduced their test cases (and found errors in a few test cases and in Smalltalk code). There were some Java patterns in use that they didn't like, and they worked with the vendor to change them.
So here they were with a cancelled, partly working system. Management again decided that they wanted to go to Java anyway. In 2003, they employed a NY based company to do the translation. They worked hands on with the project team, and the company had to devote resources to the job full time. As with the prior effort, this was late, but not unreasonably so. The new code replaced the Smalltalk server with a WebSphere server. An additional task was to change from using DOM (XML) objects to actual domain objects on the back end. So that had to move into the new server as well. This worked, and was deployed (partially) in 2004. It looked like it worked, was robust, and stable.
There was still the downstream processing to translate - at this point, yet another insurance company bought them out. So between 2004 and 2006, the entire application was announced to be dead, with the new company's .NET/VB system being the incumbent.
Now onto the migration efforts from Karen's perspective. She has nothing bad to say about them. The code delivered for translation was very large, and beyond what they initially expected. Interestingly, BFS is still running at this point - the company in question hopes to sunset "soon".
What were the bad things? Moving from dynamic typing to static. It made the developers vastly less productive. There were things that were hard to translate:
- Blocks (not iterators) - areas where they passed blocks around. These were very hard to migrate, and had been natural to Smalltalkers. The resultant Java code did not look at all like what they had started with.
- Java Dates suck. Rates are date driven, and this gave them a lot of trouble. They had to spend a lot of time to correct discrepancies between processing differences between Smalltalk dates and Java dates. They had to re-engineer the whole area.
- Heavy use of Class behavior and Class Instance variables. You just cannot get the same kind of behavior between the two languages - you solve problems differently
- In Smalltalk, methods would have multiple return types - systems could return domain objects, or error objects. This required major re-engineering efforts. Again, you solve these problems differently in the two languages.
- Primitive types or Java Objects for magnitude type things. The Smalltalk code makes assumptions that Java cannot satisfy easily.
The Smalltalk code was "too Smalltalky" for the translation (again, design is language specific IMHO). They had DNU handlers, descendants from nil, #perform, etc. Then there's the whole utility class issue - final classes in Java (String,
Date) that would simply be subclassed in Smalltalk. Joshua Bloch, call your office :/
There were problems dealing with marshaling errors on the Java side - these were easy to debug in Smalltalk, but a near impossibility to deal with on the Java side (something Brian Foote spoke of this morning, actually - the Java side has thrown the information away). Then there are casting errors. RMI was slow, especially with ST to Java (and vice versa) marshaling. maintaining parallel Smalltalk and Java domain objects made forward progress on code hard to do. The new system was not an improvement for users - the values they were getting from the existing system was different than the ones from the new ones (the problem was in the test cases, but the users didn't care).
Specious reasons to translate:
- "Smalltalk is dead" - not correct
- "No one knows Smalltalk" - teaching someone Smalltalk is trivial. The learning curve is not steep, and the big problem is at the domain level, not the language level. The Smalltalk code was easier to understand and maintain
- "Write once, run anywhere" - So is Smalltalk
- "Java is free" - The amount you spend on the IDE/tools is trivial compared to the productivity costs
- "Java is State of the Art" - When they translated, it was simply Smalltalk in Java. It didn't use any "bleeding edge" stuff
- "Get it translated and you're done" - the basic translation is hardly the end, as outlined here. You ten need to maintain the new Java code, which is more Smalltalk-like than stock Java developers will like
You'll need more RAM to develop in Java and simultaneously looking at the Smalltalk. Lots of the normal Smalltalk code will end up being unreadable Java. The bad Smalltalk code will be awful on the Java side. If only a few people understand the Smalltalk, no one will understand the Java code.
What would Karen do differently? They should have just re-written the entire ratings module, and possibly taken advantage of (now available) off the shelf components. Possibly would look at Web Services. Would examine other things than just Java. The reality is that these decisions are never made by the developers, they are political decisions made by management. A question came up about how they would have improved performance in Smalltalk - bearing in mind that she would have had engineers who were busy with migration to attack that - and architectural changes (to a server based scheme) would have helped regardless. [ed: I'd also refer to Travis' talk, which is my experience as well - an algorithmic change is quite frequently the right answer).
What about the good? The new system was faster (rate processing went from 8 seconds to 2) - but it's not an apples to apples comparsion. The Smalltalk system was a fat client, and the Java system was a server based system. They also ditched an EJB component that they had been using with the Smalltalk system. They ended up with higher up time and better processing of large (complex) policies. And, of course, the executives were happy. The business partners were tolerant at best... (lots of money was spent).
Here's my take - They started translation efforts in 2001, and kept at it - one way or another - until late 2004. So that's over three years of churn that could have been spent on actually solving problems that had value to the business. It also involved large sums of cash flow on two levels: Consulting fees to two different firms, and the soft cost of retraining a large number of developers who were competent with the Smalltalk tools, and had to ramp up on new stuff. Useful quote from Karen in this regard: The users didn't care that they were migrating - they wanted the same behavior.