I should really know better than to book a flight this early in the morning. As I write this, it's just after 6 am - and I'm sleepy. It's a short hop to Charlotte NC, followed by a wait, followed by my flight to Orlando. I suppose I should be happy that I'll have a full day in Florida, but I'll probably want to sleep most of it away :)
Being offline does give me time to do something I need to do - "spring cleaning" on my feeds. I've crept up over 300 feeds again, and that seems to be my personal overload point. So here I am at 30,000 feet, deleting feeds. I have a pretty simple methodology for this - as a first pass, I just blow away anything that hasn't updated in the last 2 months. I suppose I ought to enable the Bf feature that tracks that and disables feeds in that state, but there it is :)
Of course, I ddidn't want to do that by hand, so I wrote a script in the workspace BottomFeeder provides:
| ts | ts := Timestamp readFrom: ('5/1/05' readStream). RSSFeedManager default getAllMyFeeds select: [:each | | all | all := each allItems. first := (all notNil and: [all notEmpty]) ifTrue: [all first] ifFalse: [nil]. shouldUse := first notNil ifTrue: [first pubDateString < ts] ifFalse: [true]. shouldUse]
It's a simple selection script, and it returned an inspector. With that, I could just walk through the list of feeds, and send the appropriate message to the UI when I wanted to delete one. Much nicer than walking through it manually. I suppose I ought to add this sort of "find the unupdated stuff" thing as a standard feed search. The end result? Back down to 286 feeds, which feels much more manageable to me :)
Ryan Lowe makes a great point in the course of noticing that the Eclipse foundation is trying to hire an Eclipse evangelist:
Not only would a project give the evangelist invaluable experience with the Eclipse platform and something to blog about but it would also help them sympathize with developers, the exact people they are evangelizing to. It would put the evangelist on equal footing with other developers -- the evangelist wouldn't just be some suit telling me to use a platform because of x,y and z.
Exactly. An evangelist who isn't living on the platform just isn't credible - how can he (or she) possibly empathize with real users and their problems? I can tell you from experience - I spent many years as a sales engineer, doing demos, writing examples - and while it was useful, it never really gave me the same experience that our customers have. Over the last few years as the Product Manager, I've written (and deployed) some real applications - both client and server. It's given me a much better perspective on the highs and lows of the Cincom Smalltalk platform - one I don't think I could have acquired any other way.
My daughter and I arrived in Melbourne Beach a couple of hours ago - she's visiting her cousins and grandparents for a few days - I head off to Orlando for StS on Saturday. In the meantime, I'll be spending some time on the beach. Ahh, relaxation....
I got this job notice from the ESUG mailing list - there's an English and German description for the job, which is in Switzerland:
netstyle.ch is looking for an experienced SMALLTALK DEVELOPER as a project team leader
In the context of client projects your key task is to develop demanding web applications with Smalltalk. Your assignment starts with the conception and analysis of customer needs and ends with the transfer of the application in the productive environment and the following maintainance. In conjunction with a small team you are responsible for the realisation of the projects. As a main developer you are directly involved with the technical realisation. You are managing the teams work and coordinate the realisation of the project together with the project manager.
We are looking for candidates with wide experience in the area of object-oriented applications in Smalltalk and the conception and development of such applications. You have well-founded education in computer science and several years of experience in managing and realising challenging projects. Preferably you also have know-how in the area of web applications. You may be characterised as highly autonomous and love to work in a young and dynamic team. As the leader of the project team you posess good communication skills. You speak fluent English, preferably also German.
What we offer:
We offer you a chance to lead innovative projects in a small ambitious company. Thanks to our openness for new and unconventional approaches and open source technologies you have the possibility to broaden you horizon continuously. An uncomplicated work atmosphere with good personal relationsships within a small team promote a pleasant work. Interested? Do not hesitate to contact us!
Please send us your CV per e-mail or snail mail to:
netstyle.ch sucht einen erfahrenen SMALLTALK ENTWICKLER als Projektteam-Leiter Ihre Aufgaben: Im Rahmen von Kundenprojekten entwickeln Sie anspruchsvolle Web- Applikationen mit Smalltalk. Ihr Aufgabengebiet beginnt mit der Konzeption und Analyse der Kundenbedürfnissen und endet mit dem Übergang der Applikation in den produktiven Betrieb und der danach folgenden Betreuung. In einem kleinen Team tragen Sie die Verantwortung für die Umsetzung der Projekte und sind als Haupt-Entwickler direkt an der technischen Realisation beteiligt. Sie leiten die Arbeiten im Team und koordinieren die Entwicklung des Projektes zusammen mit dem Projektleiter.
Wir suchen einen erfahrenen Entwickler mit ausgezeichneten Fähigkeiten im Bereich, Konzeption und Entwicklung von objekt- orientierten Applikationen in Smalltalk. Sie verfügen über eine fundierte Informatik-Ausbildung und Erfahrung bei der Leitung und Realisation von anspruchsvollen Projekten. Vorzugsweise verfügen Sie über Know-how im Umfeld von Web-Applikationen. Sie zeichnen sich durch eine hohe Selbstständigkeit aus und arbeiten gerne in einem jungen, dynamischen Team. Als Leiter des Projektteams sind Sie eine Persönlichkeit mit guten Kommunikationsfähigkeiten. Sie beherrschen die englische Sprache schriftlich und mündlich; Deutsch ist nicht zwingend erforderlich.
Was wir bieten:
Wir bieten Ihnen die Chance in einer kleinen, aufstrebenden Firma innovative Projekte zu leiten. Dank unserer Offenheit für neuartige und auch unkonventionelle Ansätze und open-source Technologien haben Sie die Möglichkeit, Ihren Horizont stetig zu erweitern. Ein unkompliziertes Arbeitsklima mit guten persönlichen Beziehungen innerhalb eines kleinen Teams erlauben ein angenehmes Arbeiten.
Haben wir Ihr Interesse geweckt? Dann zögern Sie nicht, mit uns Kontakt aufzunehmen! Bitte senden Sie uns ihre Bewerbungsunterlagen per E-Mail oder Post an:
I love technologically incompetent people attempting to say useful things about the IT space - here's Judge Penfield Jackson (of the MS case that settled in 2001) waxing nostalgic:
"Windows is an operating system monopoly, and the company's business strategy was to leverage Windows to achieve a comparable dominion of all software markets," Jackson said. "Nothing has changed, to my observation, in the five years that have elapsed since my decision...Microsoft has won the browser war in the United States. Netscape Navigator, if it is still available at all, has only a small fraction of the browser market."
Hey Penfield - while IE still commands a huge market share, the leading edge has been adopting Firefox for quite some time now - and Safari (on Apple) is showing up more than you might think. The market responded while Jackson was blathering. And in case anyone is still wondering what he was really after, have a look at this:
Jackson, who is now an attorney at the Jackson and Campbell firm, used Tuesday's appearance to fire back at the appeals court. "When the reversal of my consent-decree case rulings on the contempt petition finally came down, it became apparent to me that I faced a very real prospect of reliving the 'trench warfare' experiences of my colleagues who had handled the AT&T and the IBM antitrust cases."
He wanted his shining moment in the sun. Instead, he got more than his 15 minutes. Thank goodness he's not on the bench anymore.
Sometimes I forget just how many tools I've added onto BottomFeeder. Have a look at this post from this morning, for instance - where I went through a script I used to find feeds that had not been updated recently. I mentioned that after doing a few manually, I went ahead and wrote a script - to which Troy responded that I ought to have support in the tool itself.
Oddly enough, I did have such support (although there was a bug that could bite you on it, which I've just patched). Have a look at the System>>Feed Maintenance menu pick - it brings up a tool that looks like this:
It's a pretty simple tool - select the cutoff date, hit the button, and you get a list of feeds that haven't updated since the cutoff (by default, 60 days back, once you get the update). Select the feeds you want to delete, and then just remove them - boom, all gone. So Troy - the functionality is already there, I had just forgotten about it :)
James Governor makes a small error in describing a putative Eclipse evangelist:
I can easily imagine a really excellent Eclipse RCP blog that was not written from a developer perspective, but that of an end user. So Ryan makes a great point but I would probably not be so binary. Authority and credibility comes in many different shapes and sizes. It increasingly comes from communities of interest, rather than "top down high church you shall obey" certifiers (Pace Michael Lewis and Stephen Johnson). High priest geeks are still high priests, and those are the folks we need to keep on their toes, regardless of the field of authority.
Eclipse's end users are developers, given the nature of Eclipse. IMHO, any non-developer evangelist for Eclipse would not be useful at the end user level - what information of use would they convey?
Inspired by Daniel Horn's Obfuscated V contest in the fall of 2004, we hereby announce an annual contest to write innocent-looking C code implementing malicious behavior. In many ways this is the exact opposite of the Obfuscated C Code Contest: in this contest you must write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.
Heh. Unlike a lot of C code out there, it shouldn't be unintentionally evil :)
Cincom is having a customer/partner get together on Tuesday evening at the Wyndham (Smalltalk Solutions) - if you are a Cincom Smalltalk developer, or interested in our products and services, come enjoy the barbecue! We'll have flyers announcing the event at the show - see you there!
One question this raises is how does this markup survive a trip through an aggregator? I have done a little testing and found that Bloglines keeps class attributes intact. Are there exceptions? Do 'rel's pass through unmolested? What do other aggregators do?
Well, I certainly don't preserve the XML as it passes in BottomFeeder. As content is read and parsed, I create Feed and Item objects, and those are what get saved to disk. Keeping the original XML around would bulk up the save file size quite a bit, so I simply haven't seen a good reason for doing it. Unless the micro-content is in the description/content element, in which case it will still be present. What I ought to consider is some kind of user accessible extensibility system for defining things to look for...
I'm already in Florida ahead of the 2005 Smalltalk Solutions show - spending a few days in Melbourne Beach, where my parents live. My daughter is enjoying a visit with her cousins, who live in Texas. We went out to the beach today - as you'll see in these pictures, it wasn't a great looking day today. Warm enough, and the water was nice (good surf too). Here's a shot looking north, up the beach:
That looks a lot different than it did last year. The dunes were a lot higher. Have a look at the other view, looking south:
Now, compare that to the post-hurricane shot that my parents sent me last year:
That driftwood was mostly buried before the hurricanes, and we used to use it as a towel rack. Now it's just gone. The sea bottom is different too - the drop off is closer to shore than it was last year. In general, you can really see the difference. Another thing I found interesting - lots and lots of the houses are still damaged (nearly a year later!). Have a look at these condos that are beachside, and part of my parent's neighborhood:
Apparently, only three of the units there are in use right now - you can't see it in the picture, but many of those units have been completely gutted. Finally, a happier picture - my daughter and her cousins going into the water with my brother in law:
David Buck talks about a problem that can crop up when using Intellisense. I'd be curious to know how much this comes up. I don't use either of the auto-completion goodies in VW, and I don't do enough development in any of the environments with Intellisense to have a good notion.
I find this hilarious. Greasemonkey scripts work by effectively screen scrapping the website and inserting changes into the HTML. Stephen and others who are upset by Google's change are basically saying that Google should never change the HTML or URL structure of the website ever again because it breaks their scripts. Yeah, right. Repeat after me, a web page is not an API or a platform.
I'm getting a Spy vs. Spy (Mad magazine) visual here :)
Gartner's Office of the Ombudsman has launched its own blog. Written by two Gartner veteran analysts and Ombudsman program leaders -- Nancy Erskine and Larry Perlstein -- the weblog is intended to support "an open and frank discussion on topics related to Gartner's analytical independence, accuracy, and integrity."
In a snarky tone, he said "well then, there probably won't be many entries then - possibly none..."
Or even more snarkily: "Maybe there will be tons of posts, in order to explain the general lack of cluefulness..."
Real Tech News reports on a nifty gadget for the collector who has everything - of course, you have to be pretty well off to afford this as a gift:
“There is no greater anguish for a wine collector than to spend thousands of dollars on a 50-year-old bottle of Bordeaux, only to have it taste like vinegar when it’s opened. But now a New Jersey real estate developer and wine enthusiast says he has found a way to guarantee wine drinkers will never taste sour grapes again.
Like the Real Tech News folks said, you can file this under "problem solved that you don't have" :)
Apparently, MS is about to announce a few things about RSS and the way they are tying it into IE and Longhorn. There's also something of a controversy over a possibly violated NDA, but I have no idea about that - I certainly wasn't privy to any of that stuff :) CNet picked up the story here - and Paul Thurott (first link above) said that you should watch here for news. That last site has a feed.
Remember the legal ruling from the EU that forced MS to sell/ship a version of Windows XP without media player in Europe? Well, they have that version out there now, but it seems that the regulators are the only ones who want it:
Retailers in Europe report that there's no interest in the XP N versions. The problems are price and perception. Despite lacking a key feature of the mainstream XP versions, the XP N editions are priced identically to their non-N counterparts. Too, the lack of a media player means that XP N buyers need to manually download a media player, which, believe it or not, is still a daunting process for many people.
Some PC makers--notably Dell and Sony--have simply refused to ship the XP N editions. "From our experience, customers purchasing computers expect them to come equipped with the capability of playing back digital media files," a Dell spokesperson said.
Having fixed up more than one Windows installation in my time, I can verify that - I still recall my neighbors, who are not dumb by any means - but they couldn't get their printer installed, and it "only" required a download of the appropriate driver.
If you own a TiVo, or a Media Center PC, or a PVR from your cable company, you're part of an elite. A new research report from Accenture says that the percentage of U.S. homes with personal video recorders will increase by 500% in the next four years, but even in 2009 more than half of U.S. homes still won't have the equipment to record, pause, or time-shift TV.
To me, the problem is the difficulty in explaining a PVR to someone who doesn't have one. I get answers like "there's nothing good on anyway", or "we don't watch much tv anyway". The thing is, a PVR optimizes whatever you do watch - there are programs I watch now that I have no idea as to when they actually air :)
The bad thing is, the slow rate of adoption means that the current network tactic of starting or ending programs a few minutes early/late will keep happening :(
In a Slashdot story on cell phone use, an interesting side point got made about dealing with consumer complaints:
Also of note: Intelliseek's Pete Blackshaw 'says companies used to dismiss vocal complaints from one or two consumers as an aberration. But now, they have to pay attention because now those complainers may have blogs. '"
Steve Rubel points to a Gnomedex announcement - Audible is offering their audio content via secure (i.e., subscription) RSS:
They are making its wide selection of periodic audio content available via secure RSS. Audible customers can schedule automatic delivery of their periodic programming to their computers and to any one of more than 135 AudibleReady handheld devices.
BottomFeeder will deal with that nicely - you can use the Enclosure plugin to manage automatic downloads of the podcasts.
Cincom and Knowledge Systems Corp. are announcing a partnership around Cincom Smalltalk and services:
KSC to Provide Educational Services to Cincom Smalltalk(TM) Customers
CINCINNATI, OH -- (MARKET WIRE) -- 06/24/2005 -- Cincom Systems, a global leader in business process application development, announced today a strategic business alliance with Knowledge Systems Corporation (KSC), a leading provider of object-oriented services. KSC will provide training, mentoring, certification, and migration services to Cincom Smalltalk customers.
KSC, with expertise in the Cincom Smalltalk product line since 1985, is offering a variety of courses now available to Cincom Smalltalk customers:
- Object-Oriented Analysis and Design Workshop
- Introduction to Cincom Smalltalk VisualWorks®
- Effective Testing for Object-Oriented Programmers
- Advanced Cincom Smalltalk VisualWorks
- Tutoring in Smalltalk
"As the largest provider of commercial Smalltalk, we have the responsibility to provide the best product and services for the Smalltalk community," said Jim Hazel, Cincom, director U.S. services. "By partnering with KSC, we can enhance our Cincom Smalltalk user experience and continue to grow the Cincom Smalltalk community. KSC has the product expertise and Smalltalk course curriculum readily available to launch this relationship and services program immediately."
"Knowledge Systems Corporation is delighted to be working with Cincom. Cincom's drive and dedication for its Smalltalk products coupled with KSC's long history with Smalltalk makes for a natural partnership," said Allen Davis, CEO of KSC.
For nearly 40 years, Cincom's software and services have helped thousands of clients worldwide simplify the management of complex business processes. Cincom specializes in the five areas of business where simplification brings the greatest value to managers who want to grow revenue, control costs, minimize risk, and achieve rapid ROI better than their competitors: Data Management; Marketing, Sales and Customer Service; Application Development; Manufacturing; and Outsourcing/Hosting.
Cincom serves thousands of clients on six continents including BMW, Citibank, Boeing, Northwestern Mutual, Federal Express, Ericsson, Penn State University, Messier-Dowty, Siemens, Rockwell Automation, and Trane.
For more information about Cincom's products and services, contact Cincom at 1-800-2CINCOM (USA only), send an e-mail to email@example.com, or visit the company's website at www.cincom.com.
About Knowledge Systems Corporation
Established in 1985 and located in Cary, North Carolina, KSC is the world leader in Smalltalk education and services and has employed some of the nation's defining authorities on object technology. The bookshelves of programmers around the world reflect the contributions that KSC has made to enterprise software development. Used extensively in enterprise software development, Smalltalk is the best-supported, pure object-oriented programming language available.
KSC offers a longstanding success record and a wealth of technical expertise to its clients. KSC has worked with companies in numerous industries including: insurance, banking and financial, telecommunications, warehousing and distribution logistics, healthcare and manufacturing.
CINCOM, Cincom Smalltalk, VisualWorks, and The World's Most Experienced Software Company are trademarks or registered trademarks of Cincom Systems, Inc. All other trademarks belong to their respective companies.
© 2005 Cincom Systems, Inc.
Knowledge Systems Corporation
Cincom Systems, Inc.
SOURCE: Cincom Systems
Looks like MS has announced the big RSS news. The news? RSS integration into Longhorn (the OS) and IE. Apparently, the IE team is now the RSS team - you can see the Channel 9 video (warning - 1 hour long) here.
As usual with these channel 9 videos, the whole interview format just irritates me. I would much, much rather have a screencast showing me the cool stuff instead of an hour of blather that I really don't care about. Yes, it's nice to give the team some recognition. No, I still don't care :)
So what's new? Well, there's a roundup of links here, but the thing people are noticing is another RSS extension that allows for ordering of items. If I recall correctly, this was discussed on the Atom list, but I don't think they ever resolved it. About the time of the umpteenth "angels on the head of a pin" discussion, I tuned out. Anyhow - here's the Simple List Extension spec. I'm going to have to have a look see, and see what I'll have to do to deal with this in BottomFeeder.
In Longhorn, it looks like MS is trying to make RSS-centric development easier on the Windows platform. It looks to me like MS has given this some thought - but with Longhorn scheduled to be released sometime during the next millennium, it may not be that relevant.
I like Steve Rubel's writing, but this comment is just... odd:
However, Microsoft needs to be very careful not to push the technology too far so that it only benefits them. It will be interesting to see if the extensions they are planning to add to RSS are truly open to everyone on all platforms (e.g. Linux and Mac) - not just Windows. Otherwise, it could be a repeat of embrace and extend - which got Microsoft into a bit of trouble back in the heyday of the browser wars.
How exactly could a new spec be made Windows specific when we are talking about an XML format? It's tags in a namespace guys, not Windows library code :)
The new list extension MS announced looks pretty easy to deal with - if I wasn't going to be busy with Smalltalk Solutions next week, I'd have an update with support ready in a day or two. I'll plug away at it in spare moments, and should have something out before the end of the week after StS. The cool thing is that Bf already has all the sorting/filtering capabilities this extension requires; all I need to do is capture the meta-data and expose it.
StS 2005 starts on Monday morning - a bunch of us will be around on Saturday and Sunday - we have a semi-organized outing to the theme parks on Saturday and Sunday. We'll be back before 6 on Sunday - the coding contest finals are Sunday night. If you want to join us at the parks this weekend, contact me.
Interesting - Phil Ringnalda says he's going to have a few problems dealing with the new List element MS introduced:
That title element in the cf:sort element is the one with teeth. My SAX parser goes along, notifying me whenever an element is opened, and again when it is closed, and when the channel opens I say $in_channel = true;, and leave it that way until I see an item open. Then, when I see a title element, if $in_channel is true I use its content as the title for the feed, so I'll wind up calling that feed "The title of the item." And since I didn't invent that style of RSS parsing, I'm not going to be the only one getting bit.
Well, I don't think I run into that. I use the VW XML parser to create a document object, and I then walk through that to get the elements of interest. The only thing that causes me difficulty there is my own issues with understanding specs :)
Here's the weekly log scan - time to see what people are looking at, and how. The BottomFeeder downloads - a bit less than last week:
Platform BottomFeeder Downloads Windows 560 Mac 8/9 322 HPUX 314 Sources 312 Linux x86 172 Mac X 148 CE ARM 101 Update 80 Windows98/ME 17 Solaris 13 Linux PPC 9 Linux Sparc 7 SGI 3 AIX 2 CE x86 1
Just under 300 per day - still a good rate. Maybe adding support for the new list stuff will make a difference. I need to have a look at the new MS common feed support, and also at the COM level support for Podcast lists in things like iTunes. I could really use some help on that one though (hint :) ) In any event - the RSS access logs:
Tool Percentage of Accesses BottomFeeder 18.8% Mozilla 17.8% Net News Wire 13.6% Java 5% Safari RSS 5% Other 6% NewsGator 4.3% BlogLines 3.7% SharpReader 3.2% Liferea 2.8% BlogSearch 2.6% Lilina 2.1% Internet Explorer 1.9% Planet Smalltalk 1.8% Feed Reader 1.8% Feed Demon 1.5% MSN Bot 1.4% Feed Tagger 1.4% Magpie 1.3% RSS Bandit 1% Python 1% JetBrains 1% Google Bot 1%
There's a change - Mozilla access is down, and the use of dedicated feed readers is up. That's something of an anomaly - I'll have to see if that holds up. Finally, the accesses to the html blog pages:
Tool Percentage of Accesses Mozilla 52% Internet Explorer 35% Other 4.4% Java 3.2% MSN Bot 2.4% Google Bot 2% Opera 1%
Interesting results with the last set - aggregator access to the HTML pages (never that high, but there) is off the bottom, with Mozilla access still high. Now, as it happens, my pageviews went up this week, so maybe that's it - hard to say without a deeper analysis.
Despite Atom’s technical strengths relative to RSS [2.0], RSS has such momentum in the marketplace today that if the Atom folks came out and tried to bash their advantages around, claiming that RSS is legacy, that RSS sucks, that RSS is somehow closed and proprietary because it wasn’t developed using a community process, they’re going to come out on the loosing side of things. The people who support the Atom approach need to *demonstrate* the advantages of using Atom by deploying it side-by-side with RSS. Demonstrate the technical merit through example rather than evangelization and rhetoric. Show me the code, show me the benefit. Until you do, get used to hearing more and more people talk about RSS.
To which Danny states:
Ok, I’ll stick my neck out on a prediction or two. Some developers are bound to try producing/consuming RSS 2.0 including the various extensions: comments, Creative Commons, Yahoo Media, Microsost Lists. It won’t be easy to use such things in concert without a common language beyond XML syntax. If recent history is anything to go on, these folks will have their eyes glued to RSS 2.0 and blinkers on when it comes to the considerable work done around RDF/RSS 1.0 and Atom (which does have something of an extension mechanism). Expect ball of mud parsers and object models. An extension replacing the ill-specified escaping of content is likely to appear too. Before long, probably within a year, someone will propose an RSS Meta Format specification. By the year 2010 the “simple” RSS fork will have reached the point RSS 1.0 was at in 2000 (but everyone will be using Atom anyway, and no-one will notice).
I'll make a small comment here to Danny - Java and C# just suck compared to Smalltalk. And I mean suck. Technical merit doesn't always win the day, and James makes that point very well in this context.
I'm here at the Wyndham in Orlando, ahead of Smalltalk Solutions. I went to Blizzard Beach with Michael this morning (yes, he finally arrived). I also ran into Giorgio Ferraris, but he had to do some work for a client - he'll likely join us at one of the theme parks tomorrow. Planning to join us? We'll be in the Wyndham lobby around 9, and some of will be having breakfast as early as 8.
Yet the tale is true, at least most of it. Because on June 29, 1905 -- exactly 100 years ago on Wednesday -- Archibald Wright Graham made his lone appearance in the majors.
He never got to hit. Instead, he was left on deck. A late substitute in a lopsided 11-1 win, he played only two innings and there's no proof he ever touched the ball.
"Graham went to right field for New York" was his only mention in the local Evening Telegram's play-by-play account. And, just that fast, the 28-year-old rookie described in the sporting press as being "quick as a flash of moonlight" was gone.
No wonder it took quite a while for his story to get around -- and for author W.P. Kinsella to make Graham such a part of the poetry and romance that celebrate the lore and lure of baseball.
Wow. That movie is one of the flicks that really, really get to me.
We just got back from Magic Kingdom, and now I'm doing last minute prep for the coding contest - which starts in less than 2 hours! I'll have some pictures from the day posted later
Darrell Norton explains why dynamic languages - like Smalltalk - map so much better to the ideal design process:
designers, mentally and at lightning speed, were doing the following things:
- They constructed a mental model of a proposed solution to the problem.
- They mentally executed the model -- in essence, running a simulation on the model—to see if it solved the problem.
- When they found that it didn’t (usually because it was too simple), they played the inadequate model back against those parts of the problem to see where it failed, and enhanced the model in those areas.
- They repeated steps 1-3 until they had a model that appeared to solve the problem.
Now, look at what Benjamin Pollack does when using what he calls REPL in Smalltalk:
- Add or modify a few methods in a couple of classes
- Open up a Workspace (Smalltalk’s REPL) and print out the results of some arbitrary code that tests what you just wrote
- If you hit a bug, you can easily inspect any value in the entire system to find the error
- Once you find it, make the change, massage any “damaged” data back to pristine state by hand using the Workspace, and then resume execution where the breakpoint happened to see whether your fix worked
If you map steps 3 and 4 in the second list to step 3 in the first list, they are almost identical!
That's a very good point - the Smalltalk developer is solving domain problems while the static crowd is handling syntax issues :)
Earlier today, a few of us went over to the Magic Kingdom for part of the day - Blaine Buxton, John McIntosh, Michael Lucas-Smith, Niall Ross, Giorgio Ferraris and I headed over a bit after nine, and hit a few of the rides. We managed to get on Space Mountain, but Thunder Mountain was closed. We hit a few other things - I managed to get the most points on Buzz Lightyear, and we watched the parade. I snapped a few photos as well - Niall and Giorgio headed back early, so they don't appear in any of the shots. Here's a picture of (left to right) Blaine, Michael, and John:
Here's a shot I took of Cinderella's Castle on our way out - it's not that clear (I used Medium Res and a 2x zoom), but that pink shape in the middle is a changing image of looks they've given the castle over the years:
I'll post some pictures of the 3pm parade in the next post up
Here are 4 pictures I snapped of the parade at Magic Kingdom. We watched it from the base of Main Street, looking down towards Cinderella's Castle:
That last one is Belle (from "Beauty and the Beast") waving at the crowd. The kids love that :)
Dare Obasanjo just filed some notes from Gnomedex - I spotted this exchange between Bob Wyman (of PubSub) and an audience member:
A member of the audience responded that he used multiple formats because different aggregators support some formats better than others. Bob Wyman replied that bugs in aggregators should result in putting pressure on RSS aggregator developers to fix them instead of causing confusion to end users by spitting multiple versions of the same feed. Bob then advocated using picking Atom since a lot of lessons had been learned via the IETF process to improve the format. Another audience member mentioned that 95% of his syndication traffic was for his RSS feed not his Atom feed so he knows which format is winning in the market place.
That's about the size of it. Google is pushing Atom via Blogger, but outside of that, it's mostly RSS. You can whine, argue, fuss (whatever) - but that's the reality. In the end though, it doesn't matter that much to end users - most aggregators support all the formats (I certainly do in BottomFeeder), so we are going to end up in a place where users will subscribe, neither knowing nor caring what format they get.
"An interesting article from The Los Angeles Times questions whether readers are still interested in the Harry Potter books. The article wonders if the original fans, now teenagers and young adults, have outgrown the books and if the publishers, Scholastic, have a challenge in trying to keep the series compelling for the original readers who may now heading off to college and jobs." - I can tell you from my perspective that I'm more addicted today then I was a few short years ago. After my oldest daughter read the first three books I had zero interest. Then we took a long road trip and listened to the books on tape, the rest as they say is history. I'm completely addicted to Harry Potter as is my entire family.
I'm with Rob :) At our house, it's all out war over who gets first dibs on each Potter book as they come out :)
Well, what passes for action at a coding contest :) I have a few pictures though - here's Michael hard at work, in the last hour of the contest. Which I suppose I should explain - the final round is to code up a client that can play this game over the net to a server via HTTP. Alan Knight provided a manual GUI (and domain model) for the game - the contest finale is to come up with a client that plays the game against other players through a server. Here's the pic:
This next one is of Kevin Badinger. Andrei Sobchuk had placed third, but was unable to attend the show - we had announced that the top three (actually attending) contestants would be eligible for the final - so here he is:
This last one is of Blaine Buxton, asking Alan Knight a question. Alan came up with the final round contest, and provided the basic implementation that they all started with (as well as the simple server that their entries will play through on Wednesday).
Allen Davis of KSC - the goal is to run Smalltalk unchanged on the JVM. This thing compiles Smalltalk code into Java byte code (.class files).
- Java code from Smalltalk code
- Smalltalk callable from Java
- Java Subclassing from Smalltalk
- Execution in the Java environment
- Full support for Smaltalk blocks
- Support for JITs
- "Do anything in Smalltalk that could be done in Java"
They had to implement a metaclass layer, since Java classes aren't objects - to quote - "polymorphism is completely broken on the Java class side". So a Smalltalk class in this system is not a Java class - it's an instance of a Java class. Going back to the Blue Book, they recreated the same hierarchy of metaclasses that exists in Smalltalk. They had to do this for multiple reasons, not least so that you get real inherited lookup of methods on the class side.
So a few of the hard questions - how do you get performant blocks in this kind of system? One possibility (ugly) is inner classes. There are scope resolutions with respect to variables though - compilers will bark at modifying variables based on where they are declared. So, you could create Context objects to dodge around that issue - this allows values to be changed within the inner class. That gets complicated though.
For blocks defined in a particular method for a class, they defined as methods for that class and use Context objects to get around the issue above. The next problem - type constraints. Allen says that they have gotten around this problem, getting static behavior even within a dynamic environment.What they do is push method implementations up to a common implementor in the inheritance chain, using "synthetic methods" (a feature Java allows, and most tools hide). They didn't do anything with Java interfaces. The common nheritor has a #doesNotUnderstand: that sorts it all out.
There's a good question - what about #perform? Same thing as above - the common inheritor has a #doesNotUnderstand: implementation that sorts it out. In many cases, they can just inline those. They use reflection in other cases and then cache the results to improve performance.
What about exception handling? Here the ST on the JVM approach is using Java handling - so by the time it gets back up to the recovery point, you no longer have the stack (so, no Seaside on this implementation). This is more akin to the VA Smalltalk behavior, rather than the VW/Squeak behavior.
The main thing - they are making the code available under the LGPL (unless someone comes up with a better license to use - the choice of license was a hard question). Full crowd - interested audience for this one. "The code is self documenting" - heh. Questions? Send them to Allen.
9:15 - Thor Raabe of Unaxis, a semiconductor manufacturer based in Switzerland. These guys do wafer production. I'd take a picture of the wafer production cycle, but the glare would make it invisible, I think. They use ControlWorks to control a number of the processes in the manufacturing cycle. So - what do they do with ST?
- Develop and support control system software for automated production
- Development environment - ControlWORKS (Adventa) - currently VW 2.5.x, but it's moving up to VW 7.x
- Shipped their first system in 1996
- Total systems shipped: 400+
- Software team is in 2 locations, 10 developers, 6 support engineers, 2 managers.
Here's a shot of the cycle, highlighting the steps that Unaxis manages - I got this from the StS presentations CD (all of this will be posted after the show)
ControlWORKS comes from Adventa, which spun out of TI - it's a privately held software firm. The software provides:
- An OO model of a machine
- A set of frameworks that can be extended by manufacturers (which is what Unaxis does)
- Very large - approximately 450 packages, 3000 classes, 40,000 methods - i.e., about the size of the VW development environment itself!
It provides a simulator, which is critical given the cost ($5M and up) of actual hardware. They can use the simulator to help build the hardware along the lines of what they need, and the result can serve as a sales demo tool. The code that drives all this is 100% identical - running either the simulator or the hardware. Here's a framework overview:
There are a bunch of screenshots here of the ControlWorks software - here's a picture of one of those - in the picture below, "image" means a Smalltalk image:
One critical thing they can do quickly is come up with new "recipes" for production - this is changing all the time based on the R&D that's happening at the hardware/design level in the production area.
How do they do machine control? They interface down to the hardware using discrete I/O, ethernet, DeviceNet (CAN-bus), serial port access. They have to handle the actual material/machine movement, alarms that get raised by the hardware, etc. They use Finite State Machines for much of this. The framework started with lots of threads, and that made for a lot of thread management code - over the last four years they've switched over to finite state machines. All of this runs under a set of constraints that mirror Asimov's laws -
- Don't hurt any people
- Don't hurt the wafers
- Don't hurt the machines themselves
Finite State Machines:
- Each FSM has its own process
- provides template for behavior
- standardizes code, allowing for better browsing/development/debugging tools
- Provides asynchronous interfaces allowing for interruptible behavior w/o having to manage multiple processes.
- They use Trigger events for alarms
- Requires exception handling in each FSM, rather than one global handler (ironically, I've run into this issue in the post tool based on SwS thread usage)
They rely on reuse - they don't have time to create systems from scratch for each piece of hardware that wanders down the pike. They created configurable policy objects that can get plugged into their modules - see below:
- Small teams matter
- They are adjusting to Store, very used to ENVY
- Very big learning curve in this domain
- Class libraries are huge
- Testing is expensive (due to the hardware costs)
- Finding Smalltalkers with the right (real-time) background
- Perception that Smalltalk is slow (sales issue - not actually a problem)
- Non-Native UI widgets
- "Smalltalk isn't mainstream"
- Smalltalk enables a high degree of reuse
- Generic framework abstractions
- Smalltalk makes it easier to focus on the problem rather than language issues
- Debugging is much, much easier without having to go through a recompile and restart - due to the expense and difficulty of getting to the same state.
- Unaxis is pleased with VW and ControlWORKS, and has no intention of moving off
Interesting tidbit - Java may run on the phones, but the chips that run the phones are built with Smalltalk :)
Rajesh Jayaprakash makes a discovery about Smalltalk after plowing through an initial hurdle:
I am glad that I went ahead with Smalltalk because I am pretty sure the same effort in Java would have taken me much longer. The ease and benefit of incremental coding and testing (the Workspace really comes in handy for this) was really striking.
Once you discover this, everything else is just painful...
Looks like the Supreme Court has no clue about the "fair use" concept:
In a decision announced by Justice David H. Souter, the Court said: "We hold that one who distributes a device with the object of promoting its use to infringe copyright, as shown by clear expression or other affirmative steps taken to foster infringement, is liable for the resulting acts of infringement by third parties" -- that is, computer users using free downloading software.
By this "reasoning", the VCR is illegal. What utter Morons.
10: 30 am - Eric Evans on Domain Driven Design. Here's Alan Knight introducing Eric:
And here's Eric starting his talk:
Domain: the critical complexity of most recent projects is in understanding the business domain itself. Note: This isn't true of all projects - there are technically oriented projects where the challenge is simply to overcome a technical issue (scaling, etc). However, most projects don't live there (contrary to what your larger companies and consulting firms would have you believe).
We tackle complexity with models - "when I say model I don't mean a UML model". Eric popped a couple of maps up as an example - an ancient China map, showing China at the center, and everything else on the periphery. Then a modern map, with North America at the center. The point being, that maps are models that serve a purpose (the importance of China, or the need to navigate from London to the new world) - and they then get picked up as "good enough" for other purposes.
"A model not reflected in the code is irrelevant". It doesn't need to be as realistic as possible so long as it serves that purpose.
His example is a cargo container routing system - and the model he popped up is a common one (especially with non-Smalltalk audiences) that starts with the database and works back from there - rather than starting with a domain model and dealing with the business users. So:
"A cargo makes a series of stops. At each stop it is unloaded from a transport and loaded onto another."
So, after taking to a business person, you end up with a few choices - in this case, are we dealing with stops or legs? This is the kind of choice you get confronted with in any business project, and it's not necessarily clear which is better (in the cosmic sense). What you'll end up with, if you analyze it, is the one that works better for you - you need to choose concrete reference scenarios rather than abstract, theoretical exercises. In the example (cargo shipping), Eric pulled up a map to show the route of a block from LA to Hong Kong. No help there - either model maps to this well enough.
What about re-routing in transit? That's also a viable scenario. Say the customer calls and says "it turns out that I want one of my containers to go to Seattle instead (or Dallas)". Here we have a distinct difference between the two models. With a stop based model we can add itineraries as we go, by appending a new itinerary after truncating the old one. What about the leg based model? The re-route seems easier than the other one, so this scenario tips that way. In general, you need to examine more and score them. In general, you select for the models that make the hard problems easier (the simple ones can be solved either way).
You use models then as a reference for determining what models make your most challenging scenarios easier to solve. We need tools that let us express models without getting bogged down in technical detail. Many people try to make that equivalent to: "Need tools that allow less skilled developers to use parts made by smarter people".
That latter theory is what drives Java, .NET, and the entire mainstream. When I attended this talk at ot2004, that was Joshua Bloch's entire explanation for API design - he posited a pyramid, where most developers live at the bottom. In fact, when I spoke to him afterwards, he told me point blank that Java developers weren't smart enough to use tools like Smalltalk. This is the mindset of the people delivering tools to the mainstream.
Back from my min-rant - Eric doesn't have a lot of patience for that, or for visual programming, or for UML driven theories that try to raise the abstraction level up. Language is our fundamental abstraction tool - and Smalltalk is one of the best languages for expressing a model. Back when Eric started with Smalltalk in the 80's, he figured that we would have something better than Smalltalk by now - and instead, we have Java.
Ok - what are Eric's currently favorite modeling tools?
- Whiteboard (with digital camera) - post results to a Wiki. Or the smartboards that can push directly to the network
- Smalltalk browser
- Unit tests
- Mouths and Ears
Drive the Design from the Model. Models are distilled knowledge, not knowledge gleaned from some over-arching upfront analysis. Also - Smalltalk code is easier to manipulate and change after the fact, which is important - because we never get it all right the first time. [ed] - this is one of the reasons that I think "final" is such a terribly bad idea - it makes an early assertion of perfect correctness.
many problems arise when the model does not match the customer's way of thinking. A bigger problem is what Eric calls context matching. He showed a picture of the fastest human powered rowing - an 8 team boat (the kind used in competitions). The reason that larger teams aren't slower is the fact that people tend to get out of synch with each other. The same thing happens in software. On large projects, there are always multiple models.
You'll get this problem even on smaller teams - it's not unsolvable. Problems arise when teams try to come up with the "one true" model for everything (wherein everyone works with a sub-optimal design for their part of the problem. With multiple models, there is a translation cost.
There are many teams that live in what you can call an upstream/downstream state - one team depends on the work of another, and is actually - to a large extent - controlled by it. To get better coordination you need trust and communication (picture a relay race, where the runner in front runs fast, holds their hand back, and relies on the prior runner to place the baton in their hand). You need to build up a complex "anti-corruption" layer only if you don't trust the upstream team.
Important: Map the contexts as they are, not as you wish them to be. For more information:
It's the after lunch slump (2 pm), so of course I'm attending the talk that will require attention - Daniel Poon's talk on number crunching. So: (they are using what they started with - VSE)
What does Smalltalk have to do with Numerically intensive tasks?
- Conventional Wisdom - slow, out of date
- Daniel says - look at what we do
Romax has been building in Smalltalk since 1994, and they think that Smalltalk lets them model mechanical behavior in ways that other technologies would not allow. Their customers include some of the biggest manufacturers (looks like a lot of vehicular/parts corps). From their website, they specialize in gearbox design. Their tools model various shaft arrangements - parallel, vertical, planetary (those are apparently technical descriptions).
F (Force) = k (stiffness) * x (deflection). They are solving for x. Given:
- Stiffness (stiffness of components)
- Forces (produced by engine, transmitted by the gearbox)
- Solve for Deflection (how the design will distort under use)
They do what's called VPD (Virtual Product Development). Typical transmission design (with real models) can take 3-4 years, and costs money for the parts. They can reduce that to 12-18 months using simulations.
- Customers always asking for more complex simulations
- That puts greater demands on performance
- The market demands shorter and shorter development cycles
- Which leads to Smalltalk
The main advantage they get from Smalltalk is immediate compilation and late binding. Late binding allows testing even when the system is broken. This gives them a step change in their programming style. Things they make use of?
- Double Dispatch
- Bouncing GUI code to test behavior immediately
- Extending the language/libraries as needed
- No need for multiple callbacks
- Resumable exceptions, the ability to customize handling of any and all exceptions
Daniel thinks Smalltalk could be widely accepted in the technical market. The market is huge and growing. Smalltalk is designed for the analysts own use - and Smalltalk has fundamental goodness for technical computing:
- Arbitrary length integers and fractions
- BlockClosures (pass equations into solvers)
- "Immediate" mode (doIt)
There are obstacles though - you'll need a Smalltalk coach for things like syntax (operator precedence, array syntax), lack of native solvers, floating point performance, and mixed language support. So on Floating point - Smalltalk is 70x slower than Fortran. So they use a layered architecture -
- product Model in Smalltalk
- Engineering calcs done in Fortran
- profiling shows that 60% of the time is spent on shuttling data back and forth - this is difficult to optimize
What they do is write everything Smalltalk - once it works, they profile and move critical bottlenecks to Fortran. The layered architecture really needs to be designed by the same team - at the same time - so that they mesh properly. What they did was create a single cross functional team, and instituted pair programming between the Smalltalk team and the Fortran team. This approach helped both with old hands and newbies - the new developers rapidly picked up domain expertise this way. [ed] - this is an old model - the master/apprentice thing. They've been doing this pairing approach for four years now.
There are terms for the two possible development modes - seperate teams (Chassis/Body), and the unified team described above (Monocoque). Why use the latter? The increasing demand for complex analysis pretty much requires it.
Bottom line - they think that Smalltalk gives them a competitive advantage over the other guys who use "mainstream" stuff. What could the Smalltalk community do to help? Take technical programming more seriously. Here's a picture of Daniel giving his talk:
2:45 - Dan Antion of American Nuclear Insurance. Here he is:
He's pointing out that he discovered this rather than inventing it - he's sharing his experience and demonstrating their results.
They had a limited need for application protection, a greater need for tracking - which versions are running, and where they are. They needed a distributed, Smalltalk solution. The lessons they learned - Choose your enemy:
- Casual Sharing - you might be able to stop this
- Hacking of shareware or time bombs - harder to stop
- Cracking and distributing keys - you won't stop this without a large effort/resources
They use a number of tactics:
- Difficult to guess elements
- Transaction Information
- Version Information
The response depends on the threat level and risk of loss. They use a set of numbers (including base 26 primes, version tags, etc) to create the designator.
- First - base 36 large prime, selected from a table based on the serial number. They restrict the choices based on an algorithm. This results in a 5 character number.
- Next is the product code, can include some significance (where it was released, etc). # characters
- Next is a 4 character Nth prime generated on the fly (based on the serial number) - this could be anything
- Next is a one character number or code
- Next is a 5 character alpha-numeric from the username and serial number. It could fit any kind of mask pattern
- Finally, a 3 character minor version number - probably useful for the "About" box"
- Last step - they obfuscate it some to mix it up. They rearrange it (could be a shift, hash, etc).
They made this modular so that it could be modified over time, to allow for different sorts of keys for different releases, etc. Their primary purpose is tracking. Once nice thing is that automated support requests can include the key, so that support can tell where it came from (supported rev, demo, etc, etc). One simple technique to frustrate brute force attacks on a validation server (not that they do this) - insert a delay in the validation to hinder brute force attacks.
Very important - don't annoy real customers. Respond appropriately, but make sure you find out what's happening. Actually contact the user.
4:00 - Vassili Bykov on Pollock, APIs, and the toolset. His usability example is last year's Sony Dream Machine (which was in the rooms at last year's StS). Apparently, this thing is a usability nightmare requiring multiple button pushes to make things happen (in utterly inexplicable ways). He points out that the "API" to this device is awful :) Here's Vassili:
Here's a programming example:
specifiesPixelSize "Answer whether the font cares about its size" ^pixelSize notNil pixelSize "Answer the receiver's pixel size" ^pixelSize == nil ifTrue:  ifFalse: [pixelSize]
That's a thing of beauty :) Vassili: "Everything I needed to know about framework design I learned when I was 5". He gives an example of stacking blocks. "Simplicity takes work. Complexity happens". So what's cool about Pollock? Intelligently stupid widgets (as opposed to Stupidly intelligent :) ) So - on to demos. My camera phone won't really capture these, so no pics...
One of the big improvements coming is in layout of widgets - either with respect to the pane they are in, or with respect to each other. You can do some of this in Wrapper now (see this post), but Pollock and its tools are going to be a step up, making it possible to specify various layout options in a more obvious fashion.
Now he's talking about tooltips - doing these for Wrapper was real work, involving a 4 state finite state machine. There are 4 states - cool (start), armed (0.5s delay), reaper (tear down), and warm. The warm state pops a tooltip with no delay (i.e., after you get one, just move the mouse along a toolbar to see that). In the current implementation, there is one state machine for the entire system. The Pollock state machine is the same, but with a much cleaner API.
The entry assistant (auto-completion in text entry fields) is simpler as well. The Wrapper implementation requires an additional process (with the synchronization problems that entails) - in Pollock, it's all part of the keyboard handling process, so it "just works" (and is pluggable). He's also demonstrating Intellisense type help, which will appear in the Pollock tools. So much for the claim that "you need static typing" for that :)
Ahh - now he's talking about Splash - the planned GUI builder for Pollock. There's now an extra piece he's calling "Scallops" (fix a bug in Pollock and we'll explain that, he says) - it's the common bits that go between the Pollock framework and the Splash builder that would have use beyond the builder (specs, etc). One of the reasons for seperating this out is to more easily allow for programmatic (i.e., non-spec driven) GUI creation. Pollock will support both modes. The nice thing is, the tools will support moving back and forth - you can generate code from the spec, or an XML spec from the UI Spec - [ed] - I can imagine some Software With Style value adds there :)
Greg Bonadies - "transition manager" - just reiterated the schedule - EOL for VAST (from IBM's side) in April 2006. So, what is their answer to "Why?"
- Aligning with IBM's AD strategy (Eclipse, WebSphere)
- Protect VAST investments
- Allow sufficient time to transition
- Enable Transition strategy, tools, partners
- Provide extended support
- Define bridging and migration-readiness strategy
- Engage IBM services and partner expertise
"From a portfolio perspective, we are responding to the market". So, the options - All the paths lead to J2EE and WebSphere - you too can downgrade and become just as ineffective as your competition. I love the way they call it "modernization", btw. It has a marketing department approved kind of sound associated with it. Heh- Bruce Badger asked about .NET, and Greg said sure, you can move there too. In general, they are touting J2EE, Rational Rose tools, and Eclipse (Look, Eclipse is free! Never mind those WebSphere licenses behind the curtain).
"Sometimes technologies feel the weight of change around them, or their failure to move" - I could be snarky about that, but hey - fill in your own comment there :) They are offering an additional two years of support after EOS (End of Service) for customers who want it. This is being delivered through the existing support organization and their field service people. Now it's on to partners:
Synchrony Systems and CSC Solution Services, who they will be using to migrate people over to WebSphere and Java. He got to Instantiations last, which is who is providing ongoing support/development for VA Smalltalk. His real emphasis is on "Transitioning and Modernizing" with Synchrony and CSC (read: Move to WebSphere).
So - Instantiations gets VA licensed to them, allowing derivative works from the current product. "That might be appropriate for some customers" - boy, is he ever playing down any desire to stay with Smalltalk. The IP has not been transferred to Instantiations, and there are a few things that they will not be allowed to ship. Mike Taylor (Instantiations) said that it mostly involved an inability to sub-license or open source the product. Eric Clayberg (Instantiations) pointed out that the Smalltalkers left at IBM went out of their way to make this all happen - would have been easier on them career-wise to just let it die.
A positive note from John O'Keefe - he's pleased that Instantiations has picked up the codebase and is willing to work with it.
Synchrony - supposedly, 40+ successful migrations. Odd that the website only has 2, and those projects don't list any recent details. I rather suspect that most of those are Smalltalk to Smalltalk, and mostly involve VSE to VA. "These guys are *cough* Smalltalk bigots *cough* deep down".
And CSC - they bring the J2EE migration gnomes along.
Meanwhile - if you want actual modernization - go download Cincom Smalltalk, and see what it really looks like.
James Gosling inadvertently mentions one of the reasons Sun loses money while IBM rakes it in:
Then there was all the stuff about open sourcing of our app server, a project internally named GlassFish. It's all out there at glassfish.dev.java.net. We've been pricing the binaries at $0 for quite a while, now all of the source is out there for anyone to grab and play with. It'll be the place where we do our work on the evolution of Java EE.
IBM being there was wonderful: the contract negotiations had gone on for quite a while, and resolved to everyone's satisfaction. They've been great supporters for years and I'm very happy to have all the details clear once again.
Price for the IBM Application Server (last I checked, the most popular in the Java space) - big bucks. Price for the Sun entry in that space - $0.
Martin Kobetic, 8:30 am. We are talking about Opentalk, starting with Multicasting. Works in an IP range, using UDP. Range for multicasting is normally within a single network, but it can be extended via a router that can forward IGMP, ttl. Here's Martin:
There's code in VW that makes it easy to set up for sending or receiving messages from a multicast group. To raise this up a level from sockets (Martin just ran us through a set of slides with the registration code), there's Opentalk-Groups, which puts in an object layer. A group:
- brokers running on the same port
- brokers join the same mcast address
- receivers exported under the same OID (Object ID)
- group proxy #(mcast-address, port, OID)
- Remote Group Request - STSTOneWayRequest
To set all that up, you create a broker with the appropriate parameters (again, there's code up there that I can't type fast enough :) ). Basically, you set up a broker and advertise yourself to the mcast group. Once that's done, you can start broadcasting messages, like so:
group := broker groupById: #group. group show: 'Hello World!'.
Heh - no demo is complete without a debugger popping - Martin's first crack at showing a chat system had one. Simple fix and a multi-person chat - without a server - was up. Next - we are going to participate in a grid demo. Best example of a well known grid: SETI@Home. It handles:
- resource discovery
- resource configuration
- task distribution
- result collection
The demo? Code breaking of RC4_40_MD5, using a brute force methodology but with randomly selected ranges, ranges searched sequentially, and looking for a known pattern ('GET/'). I can't get my system to join, but 5 other clients have hooked up. The thing to keep in mind here is that we are - with 5 clients on the grid - breaking a 24 bit key.
The framework is pretty simple - there's a controller managing the entire task - distributes tasks and collects results. Then there are the drones, which get sent tasks, execute them, and send back results. I may well post the code for this demo when I get some time later - it was pretty cool.
9:15 (A little later actually - there's some initial set up to be done) - Charles Monteiro is about to demonstrate "Opentalk Matrix" - he's got multi-monitor at home, and that's causing a problem with the screen display. The joys of A/V :). Here's Charles fighting with his laptop:
What we have up now is a peer to peer technology demo. Somewhat similar to the grid idea. Charles is the guy behind the NYC Smalltalk User's Group - I've been up there to speak numerous times.
So - Opentalk fits pretty nicely for doing p2p stuff. He's setting up a three node p2p setup in here. The screen for sharing content looks like this:
Basically, you can register stuff as available to grab, and browse the p2p network for content that is available to grab. The three system demo is working here, and Charles is pushing content between systems. The demo worked, but there were network configuration issues (it's really hard to set up a network demo on the fly given firewall installations and Windows configurations differences).
The basic thing is this - OpentalkMatrix can do some pretty cool things, including downloading of VW parcels with all pre-reqs (including non-Smalltalk pre-reqs, such as image files, etc). I've seen this demo done in NYC, and it looks pretty cool when stuff is set up properly. For parcels and supporting resources, OTM sets up the proper relative path.
What else? There are configuration options for things security, resource support, pre-reqs, comments, and keywords. In terms of security, there's not much more than a pluggable area. Charles plans to add more.
He's created a bootstrap environment for an SRE (Smalltalk Runtime Environment) akin to Java web start. Charles is hoping to get some "well known" peers set up to bootstrap a network. There's support for having peers exchange index information in order to speed up searches, as it can centralize searches to the "super peers". This does require that information be kept up to date.
Combination to Create Ideal Partner for Customers and Systems Integrators Focused on Service Oriented Architectures (SOA)
SANTA CLARA, CALIF. and MONROVIA CALIF. -- June 28, 2005 - Sun Microsystems, Inc. (NASDAQ: SUNW) and SeeBeyond Technology Corporation (NASDAQ: SBYN) today announced that they have entered into a definitive agreement for Sun to acquire SeeBeyond. The acquisition of SeeBeyond, a leader in enterprise integration, with trailing 12 month revenues of approximately $167 million and 2,000 customers worldwide, will allow Sun to create what it believes will be the industry's most complete offering for the development, deployment and management of enterprise applications and Service Oriented Architectures (SOA).
They spent nearly $400 M on that. I'm sure the analysts will love it, but go find one and ask them this: "Please give me a concise definition of SOA". Then ask them how this acquisition helps :) At this point, I distrust any announcement that has the term "SOA" anywhere in it...
AMD filed an antitrust complaint against Intel for Intel's monopolistic and anticompetitive practices. In AMD's official complaint they cite many instances of Intel using its larger size and resources to push AMD out of the market. Examples include Dell (of course), IBM, Sony, Toshiba, HP, NEC, Fujitsu, EMachines, [...]
Jim Robertson had a writeup of the talk here . One interesting tidbit he didn't mention was a question about how much of the world's semiconductor production has been processed by machines running Smalltalk. His answer was that it was probably around 100%. Unaxis makes three different kinds of machines, and for one type (Mask etching, I believe) they have around 85-90% market share. And they're just one of Adventa's customers for ControlWorks. Other places have already talked about e.g. AMD's use of ControlWorks.
So - Java may run on the phone you have, but the chips running it were built with Smalltalk. A more important difference - Sun makes approximately $0 for the Java penetration there, while we actually make money from the Smalltalk use.
I just love this from Spielberg:
Oscar-winning director STEVEN SPIELBERG is baffled that fewer UFO sightings are made now than were made twenty years ago - because the technology to record would-be aliens is so commonplace today.
The 59-year-old film-maker has made a string of alien-themed movies - CLOSE ENCOUNTERS OF THE THIRD KIND, ET: THE EXTRA-TERRESTRIAL and WAR OF THE WORLDS - and is disappointed it seems he'll never get the chance to see evidence of a UFO himself.
What that means is that the Air Force is being a lot more careful with their test flights. Sheesh.
This is kind of interesting - last night's BOF was hosted by Greg Bonadies, who's the "Transition Manager" at IBM - this is the same set of slides, but hosted by John O'Keefe (IBM) and Eric Clayberg (Instantiations). One way to look at that is that Greg was giving the official IBM line, whether he liked it or not - now John has a chance to introduce Eric and let him talk to their future plans. Here's a picture of Eric and John, just before the talk:
Yep - that's it - John introduced the talk as "VA Smalltalk: going forward". Different message wrapper than last night :) First up - John explaining where IBM is, and what's going on at their end. Interesting - EOS for VAST is April next year, except for Z/OS (mainframe VA). That will stay supported. Makes sense - the customers who have that are likely big ones.
Reiteration of why IBM is doing this - Smalltalk doesn't fit in with their current development language/platform plans, and IBM is trying to get rid of products that don't fit. John is making sure to point out that it's a better idea to stay with Smalltalk (i.e., Instantiations) than to do a migration (i.e., Synchrony/CSC). That's a different spin than last night. Again - same slides, same information - different motivation. Another point difference - John is pointing out that the "migration" tools that Synchrony has are useful for dealing with Smalltalk, while staying in Smalltalk.
Bottom line - this is a much, much better message for VA users than what they heard last night, even though all the information is identical.
Ok - on to Eric, and the Instantiations plans for VA. Heh - interesting start - rocket launch with a humorous description of position. I can't possibly relay how amusing this is :)
Eric's bio (most of my readers likely know this) - saw Smalltalk in 1986, started serious work in 1991, helped found (the original ObjectShare). Went through PPD, helped found Instantiations. Has been a partner with IBM on VAST and Eclipse (et. al.) since then. In Smalltalk, best known for VA Assist and WindowBuilder Pro (as well as various GUI add ons). They sell a similar suite of stuff for Java - you can get the full rundown on that over on their website.
Important difference in point - in the transition strategy, Eric is making the point that they don't want people to move off VA - they want to help them stay on it. And what is the new VA going to look like? Current VAST, plus VA Assist, WidketKit/Controls and GF/ST. The list there is VA Smalltalk 7.0, due out in July. GF/ST will be delivered as a goodie.
- Finish ANSI support
- More enhancement of IDE
- More enhancements to Envy/QA
- Integrate the RB
- Support for more Windows stuff
- Enhance the web stuff (some)
- additional migration readiness stuff
- Longhorn support (Heh - that gives them a window, based on the MS schedule)
- More WS* support
- Investigate Namespace support
- 64 bit VMs
The migration readiness stuff - SMT tools from Synchrony. Everyone says this stuff is great, but have a look here. Two success stories, from 1995 and 1998. Both are VSE to VA stories, not a word about the story that Greg was pitching - Smalltalk to Java. Not a confidence builder, if you are insane enough to want to go that way. I'd advise more talk about Instantiations, and less (lots less) about that stuff. Eric went through pricing - that's on their website as well, just follow the link up at the top of this post.
And now he's running a set of demos on VA with the additions being added. Can't say I have a lot of experience with VA, but I did download a copy in order to look at submissions to the coding contest. The browser Eric is showing certainly looks better than the stock one I dealt with. The tools that are being bundled with VA certainly provide a much needed facelift.
Q&A, and the inevitable question: Can someone release Envy for VW? Instantiations did not get the code for that. Instantiations isn't about to do new development for that - 3-4 man years of development, and they aren't going to do it on spec.
Another one - VA on Mac? They don't sound positive on that either. They figure that it's a couple man years of effort to get there. Sounds like no.
2 pm, post lunchtime slump - time for Colin Putney to tell us about Monticello (version 2), a source code control system for Squeak. Here's Colin getting ready to start:
When they started Monticello, they realized that typical version control systems wasn't what they needed for their purposes. Merging was crucial, because - given the nature of the Squeak community - there's a big need to merge code from disparate sources. The first rev of Monticello didn't actually do a lot more than merges.
Colin is discussing the hard problem of merging branches of code, and the kinds of approaches that are possible. The problem gets harder, of course, as the branches diverge over time. They took an approach of recording the ancestry of methods over time so that they can merge at the method level in an image, rather than at the package level.
A Smalltalk specific issue for a version control system - how to update (safely) a running system. In Store, you can run into this issue if you save your package as source (rather than binary), and then load a package from PostGreSQL that modifies sockets. Whoops - the PostGreSQL connect uses sockets. Solution - save the package binary. The better answer is one that Monticello is moving to, and Store is also moving to: compile the code in a sandbox, and then do an atomic load.
They ran into the problem due to some performance issues inherent in the way they were versioning code. The basic stuff -
- Elements (code artifacts)
- Versions (of elements)
- Slice (A collection of elements)
Up now: The team programming panel. Eric Clayberg moderating, with Colin Putney, Niall Ross, and Bob Westergaard on the panel. The systems being discussed will be ENVY, Store, and Monticello. Each panelist has about 10 minutes to talk, followed by discussion. A few questions from Eric - one interesting thing is that most of the people in the room are working on teams of 10-20, a few bigger, a few smaller.
First up: Niall on ENVY. His first reaction to ENVY would have been better had he started with VA Assist. Assumption (correct, as it happens) - we all know what it is, how it works (etc). Small footprint, fairly easy to set up. At some level, you ran into the same divide you do with the VM/VI - you hit the C layer and can do nothing - and since the DB is proprietary, you can't get at it. Doesn't think that the version artifacts and system was immediately obvious. On the other hand, Store could benefit from having a config map equivalent. The base UI for configuration maps - appallling - especially in VW 5i.
The component ownership model - probably seemed like a good idea at the time. The existence of tools (like one Eric demonstrated) where you can become other users) is so common as to illustrate a problem inherent in the model. It tries to enforce a model of work (whereby the owner actually integrates) is one he's never seen in the field. Everyone always hacks ENVY to allow users to become anyone.
He likes the ability to export DAT files and have them remember where they came from and what they are [ed] - but.... if I publish a parcel with DB info kept, it does do that. At least mostly).
The raw toolset is very bad at tracking records. The future? Still thinks some people would like ENVY for VW. Apparently (pace James Foster), Dolphin has an ENVY-like third party tool.
Problems: Not good for remote work (chatty protocol). Always connected model is both good and bad. refactoring can be more painful given the ownership model, and the tools show their age (base tools). Lack of a merge tool, and the public/private divide is odd.
Next: Colin Putney, talking about Monticello. For some details, see the previous post. Monticello came out of a Seaside project with Avi, where they desperately needed tools (there weren't any for Squeak then).
With a versioning tool, you are trying to capture two things: Where you are now, and how you got there. Many tools impose a mode of work, and (for instance), ENVY's model wasn't appropriate for the Squeak community. In that world, you can't rely on any particular model, you have to take what you get and be grateful for it :)
Monticello is above all a merging tool, which reflects the usage model outlined above. At this point, most Squeakers use it, and the 3.9 distribution will be developed with it. The further development is really oriented towards not imposing a process model.
Next up: Bob Westergaard, on Store. There's a fair bit of history here - it goes back to Bernstein, an Eagle project "back in the day". The basic artifact is the package, with Bundles above that, where bundles can contain one or more packages or other bundles. The back end is an RDBMS. We support the major ones, and there are a bunch of community provided back ends.
Store has users, who map to DB users. Store is both loadable and unloadable, and you can develop disconnected. Store has a concept of Blessing Levels (names for published versions). Packages/Bundles can be stored binary (see the previous post again).
The user model is integrated into the existing browser via menu picks, etc. The old (pre RB) browsers are still around for when you browse the DB - that's an artifact of ongoing work which will repair that. Store really lacks a configuration map equivalent, and that's a real problem. We are aware of that, and we know that customers are rolling their own solutions. Another problem - a blown load can take out an image, forcing a restart. That should be fixed in 7.4 via shadow (sandbox) compilation.
Envy for VW 7.x?
Niall: It's a political/legal problem, not a technical one.
About Store - overrides are great. When you have multiple overrides in an image, which one reverts?
Bob: With parcels, they restored in order, but that's broken right now. It will be fixed for 7.4.
What about class versions in Store? We want that, not just package level
Store's model really doesn't support that, it's just different than ENVY
Eliot: That was a design decision
What commonalities are there between the various Smalltalk systems in this area? They all realize that method level tracking is important, and they all integrate into the environment. Others?
Colin: The lowest "unit of work" in the Smaltalk systems goes down to the method/class level - that's very, very different than the mainstream. The mainstream simply does not get the notion of diving down to that level instead of "the file". Integration with the system really begins at the change level.
Niall: The other thing that differs is the Smalltalk notion that everything is open (not true all the way down in ENVY). This means that users can write/modify tools against the system.
Harking to the keynote on modeling - on a scale of 1 to 100, how would you rate these tools as appropriately modeling workflow?
Niall: With regards to ENVY, ownership model awful, versioning too rigid (likes blessing levels). Otherwise not too bad - overall 70-75. Nothing you would scream about other than the ownership model.
Colin: The design of Monticello really followed the usage model in the Squeak community. Smalltalk is all about live objects, so versioning in and of itself introduces a divide - one which you need to be careful around. A number? 75-80. Pretty good, but room to improve
Bob: Store has some problems with respect to its model. As to a number? About 50. A fair bit of that is based on the legacy model we have (from the early 90's)
Georg Heeg, ObjectStudio integrated inside VW. This is an ongoing project, being doen both by Heeg and the Cincom Smalltalk engineering team. History: Cincom purchased ObjectStudio in 1994-1996, and VW later in 1999. Since then, OST customers have wanted many of the same features that exist in VW. Here's Georg:
VW goes back (as does Squeak) to Smalltalk-80 (and predecessors) at PARC. The image is a direct descendant of the original images at PARC (as are all the objects). ObjectStudio was developed as an "Enterprise Object-Oriented Development Environment", called Enfin. ObjectStudio can be bootstrapped any time. VW is fast, and has a solid meta-model. OST is oriented towards client side, enterprise development.
OST customers really want the speed of VW, as well as the tools. They really like the Enterprise integration tools in OST.
It's so commonplace it hurts: A press conference is called. The media is alerted. The top executives gather for much backslapping and multisyllabic descriptions of the synergistic opportunities abounding in this, a fresh new partnership. There's a champagne toast and then the most extraordinary thing happens...nothing! Nothing at all.
Jigsaw, many industry mergers, even a prior attempt to push the VW VM under OST (The HPSOS project). This time, the project was started without promoting it ahead of time to customers, and instead starting with a proof of concept modeling attempt. The idea: Model ObjectStudio in VisualWorks.
- Use Meta Modeling
- Use all reflection capabilities
Both OSt and VW live in the same image. Both share the same kernel and base classes. This allows for mixing and matching.
Heh - the first step started when Georg had a case of laryngitis, and couldn't speak for a week. Thus was started this project with a basic proof of concept. At that point:
- Smalltalk worked
- UI did not
- primitives did not
So, the next step was to have an intern take a swing at doing a DLL that would implement the MFC functions that are currently called from the OST DLL. He took that one function at a time. Over time, it started to work. The plan was to take it slowly, and not modify the VW VM until it was absolutely required. The things that might require speeding up would help all - OST and VW.
The issue - there are 450 MFC primitives, so doing one primitive per day was going to be really slow. So that approach would be way, way too slow - stopped that in January 2005. Instead - take the entire OST C/C++ codebase and make that a callable DLL. There is a pre-alpha ready, but it needs major shake-out work.
So OST is embedded in a single namespace, and it shares most of the VW base. Most OST classes are subclasses (with the requisite differences) of VW classes. There were some adaptations required - PoolDictionaries and Globals move to namespaces (as happened from VW 3 to VW 5i).
Also required - special readers for pulling in OST code, based on the code storage mechanism that OST uses. As well - a special parser, since OST syntax is slightly different. Some semantic differences in the libraries - #at:, #at:put: behave differently (in terms of what they return). So, the implementation substitutes OST specific methods in based on the sender. This technique has been used wherever necessary. The list is not small; there are 40+ of those now.
Another difference - OST has a thin border between Smalltalk and C; they call back and forth all the time. This is largely because OST is interpreted (no JIT), and is thus up to 30x slower than VW in most respect. There are 5 ways to call:
- Direct primitive
- Numbered primitives
- Named primitives
- Module/ENFINModule - programmatic creation of interface methods
- ExternalProcedures - programmatic creation of interfaces with C datatypes
Introduced a VW wrapper - uses regular VW DLLCC. And... There's natice widgets in this project, using MFC. Callbacks come back to VW. So - we can get native widgets now (on Windows).
Class Proxies - it works, but via file-in (so it's slower). Application loading also works, but again, is slow. However - an awful lot of this is due to refresh requests to the RB. A much smaller (but significant) slow down is from disk flushes (for the change file). Other issues in the speed of callbacks (Smalltalk/C)
So - the idea is to make it work, then - afterwards - make it fast. There are still OST packages to deal with (Modeling tool, Database stuff). The plan is to have a Technology Preview (pre-alpha) this winter. We hope to have product by the 2006 major release (winter 2006). Ok - and now a demo of what's there now. He started a stock VW image (Seemingly) - with an additional menu pick - "Start ObjectStudio". The ObjectStudio windows are using native widgets. It's still rough - you get exceptions from time to time.
Final presentation of the day - Rob Gayvert - wxSqueak. This project combines Squeak and the wxWidget set. This is a blend of wxWidgets and Squeak - it's Open Source, and brings native widgets to Squeak. Runs on win32, OS X, and Linux/GTK. Current version: 0.4.1, using wxWidgets 2.6.1 and Squeak 3.8. Here's Rob:
So, what's the motivation? The Squeak UI is cool, but a native UI is essential for many situations. It leverages an existing library (wxWidgets) - it's already been wrapped by other languages. Also, Rob has some experience with wxWidgets. The goal is similar to the goal for Chagall (native on Pollock) - native widgets, portable image. He also wants to be as minimally invasive to Squeak as possible. Ideally, provide a VM level plugin (not quite possible). As well, preserve the API style of wxWidgets.
What is wxWidgets? Cross platform C++ toolkit (goes beyond GUI). Has bindings for multiple languages (wxPython, wxRuby, wxPerl...). It's shipping now with OS X, and has been around awhile.
Challenges? Dueling event loops (wxWidgets, Squeak). Large API (400 classes, 3000 methods). Both Squeak and wxWidgets are fast moving targets. There are a lot of constants, and some vary by platform. Needs synchronous callbacks for event handlers and virtual method overrides. One of the big jobs was a Smalltalk to C++ object mapping. Other things:
- Squeak process polls a primitive looking for wxEvents every 5 ms
- synchronous callback to squeak may happen
- win32 - need to restrict ioProcessEvents
- OS X - need to single thread the event loop
- Linux - no changes, but slow (not responsive enough)
The plugin generator is Squeak based (not SWIG). At the Smalltalk level, he's done a fair bit of work to make the API simple to use for Smalltalkers, by including a bunch ofcenverter/helper functions to deal with C++ interfacing issues. There are around 2700 constants, mostly enums. These are loaded at startup to handle platform dependencies.
The event handling for wxWidgets has to be synchronous (which is different than normal Squeak). Had to allow event stacking because of that. Required help from one of the Squeak VM guys for parts of that.
Generic callbacks: Used for C++ virtual methods that may be overridden in Squeak. There's interest in this stuff - other Squeakers are working with it and extending it. Heh - looks like they'll get UI specs - wxWidgets is going to an XML representation for that. He's hoping to have it all production ready for Squeak 4.0. Unicode and Custom controls will come along the way.
I'm heading over to the Tuesday night event - we are formally announcing our services partnership with KSC. It had to be moved indoors due to the atrocious weather - we've had two days of pretty constant rain or threat of rain. The burgers should be good though, and a crowd of interested people will be there.