This is one of the times that I'm glad I didn't volunteer to chaperone my daughter's girl scout trip - to Hershey Park, PA. The forecast for the day there was a high of 62, and buckets of rain. I've been to Disney multiple times in dodgy weather, and it's never a great experience - cold and wet is just not a great way to spend an afternoon, IMHO. Of course, my daughter didn't mind - at 10, she was just looking forward to spending the day and evening at Hershey with her friends. Ah, youth :)
When I read movie reviews, I often wonder about some of the things that I read. Take this paragraph in a story about how scary the new "Harry Potter" flick is:
A description of some "scary moments" deepens her conviction. The transformation of a beloved character into a werewolf? "That's just one of the really hot buttons," she says: Physical transformations and monsters are especially frightening to children under 7 or 8, who can't distinguish between imaginary creatures and real ones. The fact that it's a sympathetic character who's suddenly howling and baring his teeth only makes it more disturbing.
Now, this comes from a mother (who admits that she hasn't seen the film) of some kids that age - but still, it made me wonder if she had ever met any kids that age. My daughter was in that range when the first Potter flick came out, and was that age when "Fellowship of the Ring" came out. She had no trouble - either with the books or with the film - separating reality from fiction. Neither did any of her friends, many of whom are absolute Harry Potter fanatics.
I'm sure that there are kids who shouldn't see these films - but the point is, you have to make a judgement call based on knowing your kids. Making a blanket statement that kids that age "can't distinguish between imaginary creatures and real ones" is just silly. It reminds me of the many newspaper articles I stumble across from child psychologists... nearly every time I read one, I wonder if the so called "experts" being quoted have ever met any actual children.
I guess I need to buy the soundtrack to "The Return of the King" - I kind myself scanning the beginning of the credits to hear the theme song, sung by Annie Lennox. There's something haunting about that song. It's used to very good effect in the film as well - if you pay close attention to the scene - just before the Rohirrim arrive - where Gandalf is telling Pippin not to fear death - you'll notice that Jackson used that song. This is one of the touches that I really, really like about these movies. The other one that still sticks in my mind is from the first movie. As the Fellowship walks through Moria, there's a point where Gandalf says that he'll risk some light - and he then introduces them to the heart of the Dwarrowdelf. The music that was playing then was perfect - somehow, it captured the sense of glory and loss perfectly. That's exactly the way the ROTK theme song is for me - it seems to capture the triumph and the loss of the victory in the War of the Ring perfectly. If there's another movie out there that has done the music this well, I can't think of it.
I don't normally talk about news or current events here, but I can't really let the passing of President Reagan go by unremarked. He was elected as I entered college, so my passage into adulthood coincided with his time in office, and with my first opportunity to vote in presidential elections. I admired him then, and I admire him now. I hope that he finds the sort of peace that the last ten years of Alzeimers took from him.
I've noticed that the Tablet PC is getting a lot of hype in some parts of the blogosphere. I was talking about this with a friend the other day, and he brought up something that I hadn't thought of - damage to the screen. What do I mean by that? Well, next time you are at Target (or any of the stores that have electronic credit card signing now), have a look at the screen you sign on. Notice how scratched up it is? Of course, no one is really caring for those screens, or trying to prevent scratching. Still - under constant stylus use, they take a lot of damage. Makes me wonder just what a Tablet PC screen looks like after a few months of active use. Anyone have any real experience with this? Admittedly, my thoughts here are only an educated guess based on similar technology in use....
This week, I'll be heading to Cincinnati for planning meetings - I'm meeting with the engineering team leads, the engineering manager, as well as parts of sales and marketing. Our goal is to take stock of where we are, and to look ahead to where we should be going.
This is actually more difficult now than it has been. Why? Well, to be honest, guiding the direction of the product was very, very easy from 2000 until the VW 7 release. With the chaos that had ensued in the endgame of ParcPlace/ObjectShare's life, the product had stagnated. As a sales engineer, I was always being told what the product lacked, and what we needed to to with it. That actually made life pretty simple for me when I became Product Manager - there was so much to do, and I already had a very clear notion of what things were lacking.
Now, we aren't done with all of that - Pollock and GLORP, for instance are still under development, and there are numerous tools/presentation issues to deal with. Still, most of the things in that area are moving in the right direction already for VisualWorks, and with ObjectStudio, we have decided on a tighter integration with .NET and the CLR as the way to go. These things are all in motion, and will be bearing fruit over the next few months and years.
That leaves business direction and general strategy. The technical issues are no longer the main things we have to worry about; we've caught up after the PPS stagnation, and, to my mind, gotten into a very good place vis-a-vis Java and .NET from a technical perspective. Unfortunately, the technical perspective is really not the biggest thing facing us. We are experiencing steady growth, and Smalltalk is a profitable business for Cincom - but we would very much like to make it more than that. That's what the meetings we are having are going to be about. I don't expect any grandiose changes or directions in the short term, but we are going to start talking about what should happen next.
As always, I'm open to suggestions.
Staffan Malmgren explains how the Stockholm Marathon was, kilometer by kilometer. Makes me wish I'd written down my thoughts on the two marathons I ran back in my twenties; my best time back then was 2:50.
In the comments to this post I got some good feedback:
My opinion, for whatever it's worth, is that the Smalltalk libraries have gotten pretty chaotic, not the base libraries, but all the add-ons. It's hard to know and to find what's available. This is partially a matter of organization, but even more a matter of missing documentation and the lack of appropriate documentation tools, especially indexing and searching tools.
Further along these lines, there are real gems that need to see the light of day. For example, a number of packages included in BottomFeeder would be of great help to customers if they were better formalized and documented.
That leads to a question - what packages that in the goodies are people finding useful? What packages in BottomFeeder would be worth generalizing?
Ed Foster explains why so many email newsletters get classified as spam.
I just noticed that this blog is the Feedster feed of the day. That's neat. I've been a happy user of Feedster for quite some time now - BottomFeeder was one of the first aggregators to support it. Half the reason I did that was for myself, actually - I have a number of feedster search feeds that I track in Bf.
One of the really nice things about Smalltalk is the ability to replace any method in any class - there's no concept of "final" or sealed". Typically, it's better to subclass an existing class and add the new behavior there (or use delegation). However, that's not always practical. For instance, in BottomFeeder, I need to do HTTP queries (to get the XML files that make up feeds). VisualWorks has HTTP client libraries, and the libraries have an easy to use API. I soon realized that I was going to have to create a wrapper library, because it wasn't going to be sufficient to do:
response := HttpClient new get: 'http://www.somesite.com/feed.xml'.
There were a lot of things I needed to deal with:
- Exceptions (Network errors, etc)
- Permanent redirection (update the url silently)
- Authentication (and keeping track of username/password)
- Compressed content
and tons of other small details. The HTTP client library in VW handles some of this, and wrapping it to provide the rest at an application level was easy enough. There came a point where I ran into a small problem though - I also use my wrapper library to handle POSTS from the blog tool that comes with BottomFeeder. Under some circumstances, an exception would be raised, and I'd have no access to the original HTTP response that was received - it had gotten nulled out by the library by the time my code got control again. Now, it's arguable that it shouldn't work that way, but hey - no library is perfect. Most developers aren't the Product Manager for the tool they end up using, so - unlike me - they can't go straight to engineering and ask questions. They have to go through support and maybe get a fix, someday. The nice thing about Smalltalk is that you can track down the issue yourself and deal with it in the meantime. I've removed numerous temporary hacks of this sort as the engineering team has dealt with them. Here's what I did in this case:
In the class HttpClient, there's a method #getResponse:. That's where the response is received from the server, before some post processing (and some of the exceptions raised here can result in the original response not being returned). Easy enough; I overrode the method, storing my version of it in an extension package that is part of my HTTP wrapper library. The part I overrode looks like this:
^[stream := self getResponseStream. resp := request headerOnly ifTrue: [HttpResponse readHeaderFrom: stream ] ifFalse: [HttpResponse readFrom: stream.]. resp log. self originalResponse: resp. (resp connection notNil and: [resp isConnectionClose ]) ifTrue: [ self close]. HttpException handleResponse: resp ]
The only addition is the #originalResponse: call. I also added an instance variable to the class so that I could store that information somewhere. My wrapper library looks there in cases where it receives a nil response, so that it can better report the actual problem that was encountered. Was this critical? Maybe not - I suppose I could have gone with just reporting a generic failure and been done with it. The point is, I didn't have to - I had the option of fixing what I perceived to be a bug. Why else is that useful? Well, it's not always the case that things you report to support get dealt with the way you would like. Some are put on the back burner, some are rejected as "not bugs". The point is, being able to muck with all the code gives you the ability to route around that issue. Support doesn't believe you? Fine, you can fix it yourself. Support says it's a low priority? See the above. Support agrees that it's important, and says that it will be fixed in the next release? See the above.
With Smalltalk, your level of control over the situation is just higher. Now, do you want to start overriding the class libraries willy nilly? Of course not. This counts as a "power tool" - it's a really good and useful thing to have, but you want to be careful when you pull it off the shelf. The nice thing is, with Smalltalk, it's on the shelf, ready to be picked up at need
Advantage, or "blowing in the wind?" - Alan Trammel, manager of the Tigers, claims that the Twins are changing the flow direction of the A/C blowers based on who's at bat:
"We almost made a comeback then and had the issue of whether or not those blowers were on," Trammell said. "It seemed like those air conditioners were blowing straight in our face in the top of the ninth. There was definitely a difference in the air conditioner in the ninth inning. There was no question that there was some air blowing in the ninth inning."
The Tigers said a flag in the left-field upper deck was flapping as though it were windy Sunday, and they saw a piece of tape stuck to a vent behind home plate that was fluttering while the Twins were hitting, implying that the Twins -- who scored all their runs on three homers -- were being aided on offense and defense.
The Twins, of course, deny it:
"It borders on the ridiculous and the absurd," Twins vice president of operations Matt Hoy said. "It's a romantic concept that we can materially affect the flight of the ball, but it's just not possible."
Ah, baseball controversies :)
You've likely heard us Smalltalkers saying how extensible Smalltalk is. Well, have a look at Travis' latest post and see what we mean by that.
Check out the BottomFeeder Review in PC World Magazine.
I'll be in planning meetings most of the next three days; I expect that blogging will be somewhat light (unless I get incredibly bored, which is always a possibility in a 3 day set of meetings). Part of this will be talking about "where we want to be" in 2-5 years - and a large part of that answer needs to come from our development community.
I've said this before, as have plenty of other people I know. But over at Strongly Typed, there's a great explanation of why data entry applications suffer when people are moved from text oriented screen apps to GUI apps (web or client/server):
Have you ever watched an experienced heads down data entry clerk do their job? With a green screen system they rarely look at the keyboard and in most cases ignore the screen. They are responding to audible feed back (key press clicks, console beeps, etc) with their eyes focused on the data to be input. They remember key sequences (press 1, A, down arrow 2 times, F2 to save) to navigate. A mental model of the screens become ingrained in theirs head. They SEE the application in their head and that vision is updated real-time. They know the system because it's predictable.
In the cases I mentioned above the primary source for the complaints was the mouse. It's unpredictable. It's next to impossible to remember the cursor's position at anytime - even worse, to know the exact movement. The mouse requires visual contact with the screen, an impediment for heads down data entry.
As a developer I used to think I was empowering the users by creating flexible user interfaces. Multi window applications with buttons and icons; to take advantage of a modern GUI was to deliver the best we had to offer. When the complaints rolled in about the entry screens I dismissed them "growing pains".
It took me some time to realize their dilemma. They WERE better off with the original entry screens.
Something to think about....
If you don''t think that software patents are out of control, have a look at this - Microsoft has patented the notion of an auto-generated to do list. Better not get too fancy with those grocery lists...
All I am looking for here is an API that allows me to create to save the state of execution at any point and then return to that in the future. If fibers aren't the way to do that, then give me something that will. Make it a nice supported API written by people who know the runtime well and understand all the pesky issues involved so that I won't run into a situation where 3 days before shipping a product some heinous bug becomes apparent.
Saving the state of a running system... Hmmm.. Where have I seen that feature before?
Still in CicadaVille:
So I came to Cincinnati this week for a set of planning meetings - leaving Maryland, which is currently filled with 17 year Cicadas. Imagine my surprise to discover that this brood comes up here as well - and in huge numbers! There were hundreds of the little buggers buzzing around the front wall of the Cincom building (all glass).
Adele Goldberg's and Kenny Rubin's book has gotten a new plug - good review and explanation of the subject matter.
It turns out that there is a silly (but annoying) bug in BottomFeeder 3.5. On the technical side, I transitioned from change/update to trigger events (in terms of event notification). However, in the process of doing that, I dropped one event by the wayside accidentally. As it happens, that was the event that toggles menus/toobars on a change from online to offline (or vice versa). The easiest way to spot that bug is to toggle the online state and watch how the toolbar doesn't change back. I've uploaded an update to both the normal upgrade path and the dev upgrade path to fix this; you'll need to restart in order to see this take effect. Of course, if you know how to dive into the running Bf application, you can just pop up an inspector, and execute this:
| viewer | viewer := RSS.RSSFeedViewer allInstances first. viewer feedManager when: #onlineStatusChange: send: #onlineStatusChange: to: self. viewer onlineStatusChange: true.
At which point, it will work properly.
I'm working on two new things for BottomFeeder:
- A synthetic GUID for all items, whether they have one or not
- A Newspaper view mode at the feed level
The first one is a little technical. Atom items have an ID, and (most) RSS 2.0 items have a guid. These items are (in theory) unique enough to compare across feeds (although they likely shouldn't be trusted outside a given feed). In any event, not all items have them, so I've taken to lazily generating them using an md5 hash. I need to do some testing on this before I roll it out; I don't want to have the current "is it new/old" code cause issues for users, as it has in the past.
The other thing is a new view mode at the feed level (possibly at the folder level as well). The idea here is simple - say you turn this on (either globally, or for a given feed). When you select a feed, all of the relevant items get displayed in the html view as a set of "Newspaper stories". The relevant items would be either
- All new
- If no new, all today's
This is a view mode that some of the other aggregators out there support, so I've decided that it's a good idea to add. It's basically done (at least for the purposes of the dev stream, even though I haven't pushed it yet) - but I'm not going to add it as a non-dev feature until the 3.6 release. Any thoughts or comments are welcome.
Brad Abrams talks about the (supposed) conflict between developer productivity and performance:
Well, today I had a heated discussion with some of the smartest people on the CLR about the balance between developer productivity and performance. The debate goes something like this:
Me: Feature X will make developers more productive, so we should do it!
Other Guy: Feature X will make developers apps so slow it will not matter, they will use something else...
Anyone want to take bets on the liklihood that "Other Guy" actually tested anything out and profiled it? Maybe the feature in question would be too expensive - but the all too common approach to this issue is argument by assertion
One of Sun's bloggers has an eye for the obvious:
Where this starts to fall apart is with the .NET and Mono libraries. The Java API writers have always been very careful not to introduce an API which does not make sense on all platforms. This makes Java extremely portable at the cost of not being able to do native system programming in pure Java. With .NET, Microsoft went ahead and wrote all kinds of APIs for accessing the registry, accessing COM objects, changing NTFS file permissions, and other very windows specific tasks. In my mind, this immediately eliminates .NET or Mono from ever being a purely system independent platform.
In other news, I hear that the sun rises in the east, and that politicians in opposing parties often argue....
For the development stream, I've released a newspaper view for BottomFeeder. How does this work? At the moment, there are 2 settings - one feed level, one global. If you set the global, then you'll get the newspaper view whenever you select a feed in the tree. If you set the feed level setting, you'll get newspaper view when selecting that feed. What's that do?
- An HTML summary is created for:
- All new items for that feed
- If there are no new items, all today's items for that feed
The summary will show the title, the date the item came in, the category (if any) it has set, and the conten in a page. Each item will be set into this page view, and the result shown in a zoomed HTML view. If you need to get back to the list of items, you simply toggle off zoom mode and select any item of interest. This is my first cut at this, so any and all feedback is welcome.
With some feedback from a few early testers, I've made a few adjustments:
- There are global and feed level settings for
- Having newspaper mode on
- Showing full content for items in newspaper mode, or just a short summary
- I've modified the way the items are displayed to provide a little more information
- If you have the global newspaper setting on, and you select a folder, you'll get newspaper mode for all feeds in that folder.
This stuff is only available in the dev stream; it's going to require documentation updates, and, in my opinion, more shakeout. It should be a really nice addition to the next release of BottomFeeder.
Second, he introduces us to a cool reflection tool called Lutz Roeder's .NET Reflector. However, he goes and says, "The .NET Framework introduced the world to the concept of reflection which can be used to examine any .NET-based code, whether it is a single class or an entire assembly." Are you joking? Java has had the Reflection API for years. They were the innovators there.
It gets better:
James also talks about the .NET build tool called NAnt and the .NET based unit testing tool called NUnit and doesn't even mention the original Java-based projects these bad boys were based off, namely Ant and JUnit respectively. Quite expectedly, he does mention Microsoft's upcoming MSBuild technology (which competes on a feature basis with NAnt) which will ship with Visual Studio .NET 2005.
I hardly know where to begin with this utter lack of knowledge. I suppose I could point to this paper on reflection in Smalltalk-80 - note the 1989 date on the paper. The Java guys were the "real innovators" here, eh? I think not. And JUnit was the "original" unit testing framework? You might have a look here - page down until you see the SUnit link, and read the description. These guys remind me of some of the people I went to college with - for them, if it was north of Manhattan, it simply didn't exist (or at least, it shouldn't have :) ). An awful lot of the Java community wears the same brand of blinders, and seems to believe that everything in computer science - and in OO in particular - was invented by Sun and Gosling. Sheesh.
I'm meeting with an important customer that is visiting Cincom in Cincinnati (from France), so blogging will be light to non-existant - I'm off immediately afterwards to the airport and home. In the meantime, try and wrap your head around this post on the nature of self from Steven denBeste. It's thought provoking, to say the least...
Over on Ralph's blog, the topic of sandboxing has come up. It's a great discussion, but there's one thing I don't always agree with:
The main bad thing that could happen is that imported code could change existing code. Smalltalk makes it easy to change code. "Obect compiledMethods removeKey: #copy" will remove the copy method from class Object. It would be very bad if imported code could do this to a running application.
While blowing away methods in base classes would be bad, blowing away methods in general may not be - in BottomFeeder, an update to the application can make major changes to base application code - and sometimes to overridden methods in various libraries. It's a complex issue.
Eric Sink makes an excellent point about positioning:
If you are #2 in your category, you want to be #1, right?
Wrong. You can't choose to be #1, but you can certainly choose to be #3 or #4. The worst thing you can do is to try and beat the #1 player at his own game. Instead, realize that not everyone in the market wants to play that game. Offer those people an alternative.
Me-too-itis won't ever widen your market. You need to give people a positive reason to look at you, not a laundry list of reasons that point out how you are "just as good as" the other guy.
Matt Croydon notes that Maryland (where I live, as it happens) is rolling out WiFi at visitor centers on the highway. That's very cool.
science is the modern world's new superstition
This is truer than many people would like to admit, especially highly educated folks. I saw this a lot when I was an undergraduate. There were various members of the faculty at MIT that would loudly proclaim their understanding and mastery on various aspects of natural science. I always viewed this with some suspicion, and I always appreciated the professors who would get to a certain point and say "and we just don't understand how it works here"
Very much the case. Watch coverage of various "hot button" political issues that look to science for their backing arguments (from any side of the spectrum; this seems to be an equal opportunity thing) - and watch for arguments you might call "Scientific Argument by Assertion", or "My Expert is better than Your Expert".
I've been working on things related to the new (dev only) Newspaper view. I made it possible to select a folder and get a newspaper summary of all new items (or all recent ones) in a feed. That was easy. The complexity came in when I decided to add folders into the mix. I currently track 264 feeds, so selecting the top level folder could result in a huge mass of HTML - too much to display reasonably (not to mention the memory impact :) ). So, I've added paging links (next/prev) into those views. That wasn't too bad - but I still have some consistency issues with the way the keyboard navigation works with the new functionality. Even so, I've pushed it to dev - that way, I have a better shot at finding out what's still broken quickly.