I gave the BottomFeeder presentation at the NY STUG this evening. We had a small crowd, but they were interested in both the application and in the process I've gone through in building it. This was kind of my first take on the presentation I plan to give at StS 2004 this year; I'll be working more on the slides and presentation based on how it went. It's always good to catch back up with the NY crowd.
The Medicine.Net feed has the following message for every item this morning:
"The log file for database 'MNI' is full. Back up the transaction log for the database to free up some log space. "
Looks like someone has a mess...
I've got some travel coming up in the next few weeks and months. Next week, I'll be in Houston, TX on Monday and Tuesday, and then Dallas, TX on Wednesday and Thursday. I'll be visiting a bunch of customers - listening tho their concerns, and letting them know what's coming for CST.
Then in March I'm off to Europe from the 20th of March until April first. Two days at CEbit, visits to a bunch of German customers, and a meeting with the Frankfurt STUG. Then I head to the UK to attend and speak at ot2004.
May brings Smalltalk Solutions, May 3-5 in Seattle WA. That should be a lot of fun, and I'll be speaking about BottomFeeder.
Then in the fall, I'm hoping to speak at ESUG - haven't gotten a definitive answer yet though. Looks like my passport will get a lot of stamps :)
Looks like there are uses of atom as a module inside RSS 2.0 feeds - have a look here. I'll be taking a look at adding a module for that...
Via Scoble I found this article on the PR biz, and how blogging impacts it. Interesting read:
Public Relations is about communicating with audiences. Your job is to understand how to reach those audiences, how to deliver information to those audiences in a format that they find acceptable. We're not just talking about the media here. PR is about good communication to every audience, that includes customers, partners, staff, suppliers etc.
If you are not trying to reach and communicate with the relevant audiences for your organization or client, then in my humble opinion you're not doing you job.
This puts blogging in the proper light - it's not the solution for corporate communications, it's a solution. It doesn't replace anything completely, but it does add to the list of communication forms.
Dare points to the rising number of Atom feeds coming out of Blogger (the default choice over there now) - and laments that he can't read such feeds with RSS Bandit. I'm kind of surprised that he hasn't added suport; it was pretty simple to support Atom 0.2 (I added that months ago, because one of the users of BottomFeeder actually asked for it). I ignored Atom 0.3 for awhile, but then I got an email from someone telling me that Bf was handling 0.3 feeds oddly. I added a new handler for 0.3, and all was well again.
Here's why it's not that hard for me to add new formats, so long as they are relatively close in spirit to RSS - I don't keep the XML documents around. Bf parses the XML document, and then a framework originally designed and built by Dave Murphy maps all the relevant information to an object model. It turns out that the object model we built for RSS applies to Atom easily, so it was just a matter of mucking with the object mappings in a new handler class. When I finally added Atom 0.3 support, it took me about 20 minutes.
Back to the original topic. While Dave Winer assumes malice, Dare assumes the much older rationale - stupidity:
- Always and inevitably everyone underestimates the number of stupid individuals in circulation.
- The probability that a certain person be stupid is independent of any other characteristic of that person.
- A stupid person is a person who causes losses to another person or to a group of persons while himself deriving no gain and even possibly incurring losses.
- Non-stupid people always underestimate the damaging power of stupid individuals. In particular non-stupid people constantly forget that at all times and places and under any circumstances to deal and/or associate with stupid people always turns out to be a costly mistake.
- A stupid person is the most dangerous type of person
Unless Google does have something up their sleeve?. Who knows? In the meantime, I support the Atom format, regardless of how many bricks I throw at it....
I've posted a new set of change information on our Wiki - details the changes that have been made between VW 7 and VW 7.2. It's not complete; I did this only with a base image. However, the scripts I used are available for download - so if you want to look at the changes specific to a component (like, say, the Web Toolkit) - just grab the scripts and follow the instructions.
Jon Udell points to Dare's post on not being able to read Atom feeds in RSS Bandit - by saying "sure you can", and pointing to Atom2RSS:
How? Just search Google for atom2rss. There are a bunch of translators floating around. The one I picked comes from the folks at 2rss.com. Here is their translator: http://www.2rss.com/software.php?page=atom2rss. And they are kindly making this service available for free. You can go to the site, plug in an Atom URL, generate the corresponding RSS URL, and subscribe to that.
That glib "just follow these simple steps..." misses quite a bit. First off, here's what most people are going to do (assuming they understand aggregators, which is assuming a lot already):
The liklihood of your average aggregator user deciding to do a search in Google for format translators is too amusing for words. Heck, I announced this PR Feed internally, and got 2 emails from people in my group asking what they were supposed to do with an XML file that showed up in their browser as a DOM tree. I've been working on BottomFeeder for a long while now, and - even so - plenty of people in my own work group have no idea what a feed is. Expecting an end user to go find a conversion tool is a fantasy - other than a handful of highly motivated geeks, it's simply not going to happen.
The simple truth is, aggregator authors have to just buck up and support this new format. I've written more than once on what a colossal waste of time and effort I think the Atom syndication format is, but it doesn't matter what I think - my users don't care about the "inside baseball" aspect of all this. They want to read content when they find it, and would prefer not to have to care about any of the technical details. Expecting them to wander off in search of a conversion site is expecting them to know about details they shouldn't have to care about - and more importantly, about details that they just won't care about....
I'll remind Joel - and MS - that it doesn't have to be tradeoff between a linker and a runtime system. BottomFeeder is built in VisualWorks Smalltalk, which is a VM/Image based runtime system. And yet, I ship a 7 MB single executable for Windows - which is field upgradeable. It not only can be done, it has been done. Perhaps the MS engineers need to look up at the rest of the industry every so often...
I saw this comment on Planet Lisp:
I certainly agree that the mismatch between memory and CPU performance supports the conclusion of the paper -- tagged memory and micro-programming would probably be beneficial in a big way. (Of course, given how manystupid buffer overrun viruses there are these days, it's hard to believe that anybody can still think that not having manifestly-typed data is defensible.)
The term manifest typing must mean something different in the Lisp world than what it means to me....
shaykatc - and I'm sure other .NET developers - are drooling over this:
Ok - so what scenario would I use it in? Lets say you're writing some managed code. You're debugging your merry way through the code when voil, it crashes. Sigh. You see the little error dialog with additional information but to explore your code you have to dismiss it. As you go through your code, you wonder what that message said again? So you write a try catch and repeat the process.
Well, in Everett the debugger team put in a little feature called $exception. The next time you crash in C# or J# go ahead and dismiss the dialog. Open the locals window and take a peek at $exception there (chills are setting in right now). Expand it and you can see all the delightful things inside the Exception object - Messages, Stacktrace, Inner Exception etc - everything you would have gotten had you put a try catch around the code and caught the exception object. Is that cool or what?
Oh boy. You can see all that information? You mean, the sort of stuff that Smalltalkers have had for years and years? Here's the real question for shaykatc - can you go back through the stack in the debugger, change code and restart? It's always amazing when developers get excited about stuff that has been around in mature, productive tools for decades....
Derek found out that when it comes to college grades, you actually do have a "Permanent Record". As much as we laughed, it sounds like Mrs. Grundy wasn't kidding....
Don't think that blogs are a way to route a message around other media? The White House apparently believes it is. This led me to marketing - what if you are having difficulty getting your message out in the trade press? Blogging is a possible answer - and will has the ability to wind back around - as the above story did - into the major media. In the political world, this meant something like the WaPo. Here in the techie universe, it might be less trouble, since folks like Jon Udell and Dan Gillmor are already blog savvy....
Matt Croydon is more organized than I am - he's at least got a daytimer. me, it's all I can do to keep the whiteboard calendar up to date...
I was wondering how much space some of the caching I use in BottomFeeder uses. Now, I could have copied my feed data over to my dev directory, started Bf up in the dev system, and taken a look. However, that wouldn't have given me an accurate picture of cache usage in the real system - the usage of caching happens as a side effect of real usage. What to do? Well, this is Smalltalk, not some godforsaken curly brace language - so I went right to the application. It turns out that you can pop up inspectors in Bf if you know how. So up came the inspector, and I opened the workspace pane. This is one of the truly cool things about Smalltalk - the system is truly putty in your hands. Since the whole system is there (I don't strip out the compiler; it would not be possible to do the kind of runtime updates Bf does if I did), I wrote up a quick script:
| all feeds | all := OrderedCollection new: 1000. feeds := RSS.RSSFeedManager default getAllMyFeeds. feeds do: [:each | all addAll: each items]. all collect: [:each | each cachedHTML].
I inspected the results of that, and got a collection of all the cached HTML the application is hauling around. I had 8206 instances of them, and the aggregate total of characters was 300k - i.e., not worth worrying about. The nifty thing is, I was able to get a real runtime result, not an assumed result based on semi-real usage in test.
This isn't the limit of what you can do, either. Awhile back, I introduced a bug in the dev stream that resulted in the item cache sizes being set to absurdly small sizes for most feeds. That would have been painful to fix manually, so did this
RSS.RSSFeedManager getAllMyFeeds do: [:each | each feedLevelCache: 120]
Which reset all my feeds to a more reasonable level. Do I expect average Bf users to do this sort of thing? Heck no. On the other hand, it's certainly handy for me as a developer - I can get real world usage answers from the system instead of test answers that may not match up. Try that in .NET or Java :)
Bill Burnham worries too much:
The irony of RSS's success though is that this same success may ultimately contribute to its failure. To understand why this might be the case, it helps to imagine the RSS community as a giant Cable TV operator. From this perspective, RSS has now has tens of thousands of channels and will probably hundreds of thousands of channels by the end of the year. While some of the channels are branded, most are little known blogs and websites. Now imagine that you want to tune into channels about, let's say, Cricket. Sure there will probably be a few channels with 100% of their content dedicated to Cricket, but most of the Cricket information will inevitably be spread out in bits and pieces across the 100,000's of channels. Thus, in order to get all of the Cricket information you will have to tune into hundreds, if not thousands, of channels and then try to filter out all the "noise" or irrelevant programs that have nothing to do with Cricket. That's a lot of channel surfing!
There are a number of things wrong with this theory - first and foremost, it forgets the critical role of the end user. I subscribe to new feeds all the time. If the author of that feed keeps pushing out stuff I don't care about, I can do one of two things:
It may be difficult to find new feeds of interest - but the same problem exists in lots of other places as well:
The same sorts of things are happening in RSS. Why is this hard to figure out? There are already millions of feeds out there; I'm hardly paralyzed by that fact. This is much ado over nothing at all....
The first leg of my trip to Texas is coming up - I'll be leaving for Houston, TX as soon as the cab arrives. I'll probably have some posts queued up when I arrive.
For those of us who take the blogosphere way, way too seriously Sriram Krishnan has a few words of advice....
Typing terminology is one of the areas where developers end up talking right past each other - because we use the same terms to mean different things. Take the following descriptions of typing:
Now, go look in the archives of cls, or comp.object - likely other groups as well, but I'm less familiar with them. Try to get common usage for any of those terms. Take one that is bandied about between Java and Smalltalk advocates, for instance - "static". We typically use it to discuss whether variable types are declared manually by the developer in the source code. That seems simple enough... until you get a functional language developer in the mix. They'll talk about their language(s) as being statically typed - even though there are no manual declarations (or at least, no requirement for them). What they mean is that the types are not declared by the developer, but the compiler infers them and enforces them at compile time
This led me to start using the term "manifest typing" to mean manual declarations. That was fine, until I ran across this on Planet Lisp. Patrick Logan pointed out to me that Lispers mean this:
What this means is the object is inseparable from the type at runtime. The object always comes with a "manifest" that describes the type of object.
Whether that manifest is manually defined or dynamically inferred is apparently a separate issue. And heck, that doesn't even get into the more common confusions over Strong/Weak - many people equate manually declared type declarations with Strong typing (forgetting the way you can cast yourself into oblivion in C) - and also equate a lack of manual declarations with weak (forgetting that Smalltalk, for instance, gives you well defined behavior for a message that is not unnderstood).
The bottom line? You have to be extremely careful when you discuss this topic and start tossing jargon around - otherwise, you could end up making as much sense as a guy from Germany discussing Football with an American, each completely sure that they know full well what football means!
Brad Abrams quotes Chris Brumme on why you don't get a lot of info from a NullReferenceException (sounds like trying to send a message to nil in Smalltalk):
The NullReferenceException occurs because an instruction like call [eax 44] or mov edx, [esi 24] has resulted in an access violation. Â We don't retain nearly enough information to form a correspondence between a particular register being NULL at a particular EIP and the fact that a particular reference in the application was null. Â Especially since the EIP might be in a shared helper like a write barrier routine or an array helper. Â In those cases, we would have to perform a limited stack walk to get the effective EIP.
The machinery that would be required to improve this error message is huge. Â For the foreseeable future, you will have to rely on debuggers, or on FX code explicitly checking and throwing an appropriate NullArgumentException.
Fascinating. Contrast that with what I get when someone reports a BottomFeeder bug to me - I get a complete stack trace - with information on every object involved (arguments, senders, receivers - the works). All available in the runtime, dropped to a log file that can be sent to me. And that doesn't begin to explain how much better the information is in the development environment. This is one of those supposedly nebulous things about Smalltalk productivity - just about everything is simpler and easier to get to
Â
Bill Clementson talks about dynamically changing a Lisp Server - this is something Smalltalk does very, very well also. I do something similar with the blog server - but I don't (typically) have GUI access to it - it runs as a headless server, many miles from where I live. So how do I dynamically update it?
No fuss, no muss, no restart - and problem solved.
Steve Gillmor has an RSS problem. I can mark items persistent, so even if they are read, they hang around. I can also bump the cache for a given feed up to absurd levels to ensure that items don't go away. Hmmm. Maybe he has a tool problem...
I saw a couple of very cool customer applications today - a POS system used at restaurants, and a trading system for buying/selling natural gas. These are both very, very cool systems - and with the latter, our partner tells me that most of his competition is spreadsheets and PowerBuilder! It looks great, and I was very impressed with the work they've done - it's a great example of a VisualWorks application. I'll have more later, but I'm about to jump on a plane to Dallas - more customers to visit over the next two days.
CSS is being filtered by Symantec's content filter - probably because IE allows Javascript in CSS. Great, another useful tool ruined by the feature gnomes at MS....
PR Opinions has a story on RSS and tracking. I can understand why people want to know who is and isn't subscribed; subscribed readers are more committed, adn - in a sales/marketing context - may be more open to learning about the products and services you provide. It's interesting that outfits are starting to look at that, but the 'solutions' are amusing:
So when I read that IMN Inc (formerly iMakeNews) have announced (PDF only) a trackable RSS feed service I was intrigued. A way of tracking RSS success. Fantastic.
However, when I went to their site, and from the story in ClickZ it seems that all they do is publish your content to an RSS feed and count the hits.
"We've encoded all the links -- usually with an RSS feed you get a subject of an article and a link. Every link provided is a unique trackable link. When you open up the feed we know it. Every time you refresh the feed we count it. And when you click to read a particular article we register that," Goodwin said
Heh - that's just scanning logs and counting, something I do in my free time for entertainment value.
Bill Clementson outlines a plan for making money on Lisp; the same ideas are applicable to Smalltalk (or any development niche, for that matter). The ideas are spun off of this thought:
You sometimes hear people on c.l.l. complain that they can't find ads for Lisp programming jobs. Rather than bemoan the lack of Lisp jobs on the Monster job web site, it might be more useful to focus on what Lisp is good for and work out how those Lisp-specific qualities might help you make money. Fast Company recently pointed to a weblog posting by Dave Pollard about the 10 most important business ideas of 2003. Reading through this list, I was struck by how well-positioned Lisp is in some of the areas highlighted by Dave...
Smalltalk excels in the same areas.
Well, I'm off to more customer visits this afternoon in Dallas. Yesterday's visit to Tradewell was fascinating - as I said yesterday, they have an amazing system for dealing with energy trading. They demonstrated the system to us, and the visual display of deals made it very, very easy to understand and follow. This should be a killer app in that field. I'll be visiting Vialink and Adventa over the next two days - I'm already familiar with both of their systems, but it should be interesting to see what they are up to. As well, this gives them a chance to tell me what we are doing right, and what we are doing wrong.
Good news for HP customers - HP is throwing in the towel on itanium and moving towards the AMD Opteron. The good news for Cincom Smalltalk customers using HP? You'll get 64 bit support within the year!
Cincom will be at CeBit in germany this year - Helge Nowak, technical sales in Germany, and Claude Poole - our engineering manager - will be in the Cincom booth for all or part of the show:
Cincom Systems at CeBIT 2004
Interested in getting the latest news about Cincom solutions and services? Come and visit us at CeBIT 2004 in Hanover, Germany, from March 18 - 24.
At CeBIT 2004 Cincom will be hosting two booths:
In Hall 3 Booth # B19 our main themes will be Cincom Smalltalk and Cincom Manufacturing Business Solutions.
With the latest Cincom Smalltalk Fall 2003 release including .NET connectivity, Cincom Smalltalk now stands as a bridge between the two "separate worlds" J2EE and Microsoft's .NET. Being multi-platform compatibel has been enlarged to the mobile world: Cincom Smalltalk now also supports mobile platforms like Windows CE. The Cincom Smalltalk experts from Cincom and from our partner Georg Heeg are looking forward to meet you at the Cincom booth in Hall 3.Find out as well what Cincom can offer you as added value for your complex manufacturing environment, such as
- Interactive Selling Solutions,
- Enterprise Management,
- Quality Management.
In Hall 18 Ground Floor, within BANK-FINANZ-SYSTEME, at Booth # A24 - 2.6, Cincom presents Cincom Financial Services Solutions which help you identify and solve your issues in the following fields:
- Data Access and Integration for Sales and Marketing
- Improved Data Analytics
- Increased Customer Profitability
- Identification of Sales Opportunities
- Multi-Channel-Communications and Business Workflow
We will be happy to welcome you at Cincom on CeBIT. If you are interested to visit us please send an email to infode@cincom.com and ask for your complimentary guest ticket.
Kind regards.
Dr. Monika Laurent
Marketing EMEA
Cincom Systems GmbH & Co.
mlaurent@cincom.com
Come see what's new!
I'll be speaking at the Frankfurt STUG in a few weeks:
Cincom Smalltalk Product Manager talks on "Blogs and RSS" at Smalltalk Meeting in Frankfurt, Germany
Jim Robertson, Cincom Smalltalk's Product Manager, will take the opportunity of his CeBIT visit in Germany to give a speech at the monthly meeting of the Frankfurt circle of the German Smalltalk Users Group.
Subject Blogs and RSS - worth your time? Date and time Thursday, 25 March 2004, at 19:00 h (7 pm) Location Restaurant Au Mandarin, Chinarestaurant DG-Bank-Tower Westendstr. 1 DE-60325 Frankfurt Afterwards discussion and Q & A
All Cincom Smalltalk customers are welcome to attend this presentation. Please let us know when you will attend; please mailto infode@cincom.com.
Kind regards.
Dr. Monika Laurent
Marketing EMEA
Cincom Systems GmbH & Co. oHG
mlaurent@cincom.com
Patrick Logan explains some of the issues that would crop up in a hypothetical .NET that supported dynamic updating (as speculated by Gordon:
One issue that comes to mind is stack-allocated objects...
Imagine module A defines a stack-allocated and some system should load a newer version of A. Now imagine the newer version of A redefines the stack allocated object, e.g. gives it a new "shape". What does this do to the objects allocated on the stack and the code in other modules that manipulates them?
This is one of the key differences between the "everything is an object" as defined by dotnet, and the "everything is an object" as defined by Smalltalk.
Dynamic updating isn't just for servers either; BottomFeeder can have new versions of code downloaded and loaded without a restart. This is one of those power things where Smalltalk is just better
After I made this post yesterday, Douglas pointed to this MSDN article on something MS is calling "ClickOnce" - a framework for a unified install/update cycle. The article describes a more complete version of what I do now for BottomFeeder; it's also very similar to the ideas being worked on by our engineering group for this problem. It's good to see MS tackling the issue - I hope that Symantec adopts their scheme so that I don't have to reboot so often after their updates. That last thing is the main problem I have with most application updates out there now - I can do updating for Bf that takes place immediately - why do so many applications force an OS level reboot? Hopefully, this MS work will get rid of a lot of that...
Via Syndic8 - if you get asked what RSS is, this is a pretty good explanation. It keeps it all at a high level, for the non-geek crowd.
Ryan Lowe comments on Smalltalk for Eclipse (he attended the Ottawa demo last night). I'm always interested in seeing how ST demos come across to people who don't know Smalltalk - for instance this:
Part of the talk included a very interesting tangent on a concept called "doits" (pronounced "do its", not "doyts"). I'm not sure if it only applied to the Smalltalk Eclipse IDE or Eclipse in general though. The idea is to put a simple scripting language in Eclipse that you can use to perform quick tasks in the IDE. The example doit he gave was if someone else found a bug they could attach a doit to the bug report download the project from CVS, compile it and then highlight the line that refers to the bug. A scriptable IDE sounds really cool indeed. I don't think he mentioned a possible language it would use if they made it though. Maybe python?
This points to one of the classic failings of Smalltalk marketing - we don't explain our advantages at all well. The fact that Smalltalk is scriptable (even an end user app - see this post, for instance). It always has been - you can modify the way the environment works in ways that go well beyond the plugin capabilities of Eclipse, but we have not made that clear.
I think my attitude towards Eclipse for Smalltalk has changed though. I was somewhat leery, but I've changed my mind. We need to have things that operate as outreach to the file based, CVS style developers (they are the majority!). If we can't bring Mohammed to the mountain....
Joel Spolsky and many people on his forums are clearly confused about Closures and web apps. Looks like they need to visit Avi's blog....
|
| Subscribe to WebVelocity |
| Visit this group |
