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...
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?
- Test a patch on a local version of the server so I can verify that it works
- File the code out (i.e., push it to a file that can be loaded and compiled into the server
- Version the new code off into the source code control system, and drop a new version of the loadable component that the patch belongs to. This is so that I can get the server going with the correct code the next time it gets restarted
- FTP the code up to the server, and into the appropriate directories
- Using a defined remote API, kick the server so that it will load the patch
No fuss, no muss, no restart - and problem solved.
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
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
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!
For those of us who take the blogosphere way, way too seriously Sriram Krishnan has a few words of advice....
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.
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:
- Apply filters at the client (aggregator) side to eliminate the things I don't like
- Just unscubscribe from the feed in question
It may be difficult to find new feeds of interest - but the same problem exists in lots of other places as well:
- Books. There are loads of books published every year. How do I know which ones to look at? To a large extent, experience (looking for new works by authors I already like) and word of mouth. The same thing happens in feed-space - BlogRolls and links do the job.
- TV shows. Not as many new ones as books, but lots every day over digital cable. We have the Replay doing what amounts to keyword search, and we talk to friends.
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....
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 :)
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...
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....
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....
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....
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....
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...
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):
- Try to add the feed from the page in question to their aggregator
- Watch it fail
- Move along, figuring that either
- The feed is broken
- Their aggregator is broken
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'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.
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....
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.
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...
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.
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 :)
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 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.
I'm on my way to NYC to speak at the NYC STUG about BottomFeeder. Like any speaker, I'm doing my slides at the last second (on the train!). I actually had various parts of the presentation "lying around", but they weren't really in a coherent whole for a technical presentation yet - so I spent mch of the ride doing that. That's one of the things I really like about taking Amtrak to the city; I have time to get work done - and I still get to Manhattan faster than I would by flying. I was kind of hoping to find some WiFi on the trip, but I expect that I'm moving too quickly, and too far away from residential areas to boot...
Via Scoble comes news that intel has cried uncle in the 64 bit market - they are unveiling a 64 bit x86 chip:
Intel Chief Executive Craig Barrett said today the chip maker will offer a new version of its Xeon chips for the low-end computer server market that will mimic the capability of chips from rival Advanced Micro Devices.
The company said the new chip currently code-named Nocona, offers the 64-bit capability found in AMD's Opteron family of chips for servers. This spring Intel will offer both a Xeon for low-end servers and a 64-bit version of its Prescott Pentium 4 chip for workstations with single processors.
I like the attempt to salvage their pride over the itanium by claiming that this is only for the "low end" server market...
India's Linux for You magazine spotlighted Smalltalk in the January edition. I can't get a link to that month; their archives seem to be confused. Here's a quote from the article:
If one peers around the Smalltalk classes written entirely in Smalltalk, you would notice the strong Unix base that carries through. For instance, in the sockets code you have a complete re-implementation of the BSD sockets, and process creation is the very familiar fork calls with the simplest threaded call implementation. This makes the language a lot more familiar for the Linux user.
Being platform independent, nearly all dialects of Smalltalk support Linux. The major ones include:
Smalltalk X: A commercial version having an efficient compilation system that can compile to a C level binary code once the development is done.
- VisualWorks: Currently the most aggressive Smalltalk platform. It is supported widely by both enthusiasts and corporate development and is now positioned as a 4th generation application development platform
- VisualAge: The IBM version that has been the industry favourite for over a decade but is now taking a back seat to IBM 19s Websphere.
- Squeak: For open source enthusiasts, academics, and especially school kids, this is the best. It lacks features for corporate level multi-user, scalable solutions but touts the new Morphic UI architecture.
- GNU Smalltalk: An efficient, mature and contemporary implementation.
Very cool to see more trade press notice!
Blaine Buxton has a few words to say about the all too common perception that developers are interchangeable:
I've always been bothered with the notion that programmers are interchangeable parts. Technical managers that I have had seem to think we are all the same. Cut from the same tree if you will. Am I the only one that thinks this is hog wash? Like anything in life, there will be people that rise to the top of their field and be the best there is. But, it seems people think that programmers are all the same. I find this bothersome. I've known managers that thought they could pull anyone off the street and in 6 weeks have a good programmer. Would we expect to do the same with musicians? Just pick anyone off the street that knows nothing about music and expect them to play a mozart concerto flawlessly after the same period of time? I think the answer would be no! Would we expect to take even a first year english student and expect them to write poems the caliber of William Shakespeare? HELL NO WE WOULDN'T! So, why do we expect the same from programmers?
Blunt, but very much on point. Maybe we should start assuming that senior managers are interchangeable. When that gets the obvious objection, let the other shoe drop...
I saw this in cls and the Camp Smalltalk mailing list - Camp Smalltalk near Portland, OR:
I'm pleased to announce that we will be holding a Camp Smalltalk from July 18-23 2004 in the vicinity of Portland, Oregon, USA.
To finalize our space reservation, we need to place a deposit on a minimum of ten sleeping room reservations. We expect more than that to attend, but we need at least ten definite attendees to step forward and send in a deposit now. We must receive the minimum number of deposits BY MARCH 5. If you want to make a reservation, see below for details.
Camp Smalltalk. Smalltalk enthusiasts spending several days in small groups collaborating on a number of open-source projects to benefit the Smalltalk community. All Smalltalk dialects welcome. For more details, see http://campsmalltalk.com
Smalltalk enthusiasts. All experience levels are welcome, from "Using Smalltalk for more than 20 years" to "Fascinated by Smalltalk, but never really used it."
Afternoon of Sunday, July 18, through midday Friday, July 23
Troutdale, OR, USA
The main cost is the lodging and meals package at Edgefield. You're responsible for getting yourself there. All prices given include room, meals, gratuities, and tax for all five nights, and are in $US.
Single-occupancy King or Queen or Double Queen room: $600 Single-occupancy King or Queen or Double Queen Suite with bath: $952.50
Double-occupancy King or Queen or Double Queen room: $530 per person
Double-occupancy King or Queen or Double Queen Suite with bath: $787.50
There are very few rooms with two beds -- if you want one of these rooms register soon.
We're looking into high-speed internet access, which would have some additional cost. We will not commit to additional cost without the approval of those who have registered.
McMenamins Edgefield, Troutdale, OR, USA
A 15 minute drive east of PDX, the Portland Airport
It's right on the edge of the Portland Metro area, five minutes from the hiking and waterfalls of the Columbia River Gorge. It's easy to reach by public transit from either PDX or downtown.
A private brewpub-based resort at a lovingly and quirkily restored historic campus of buildings -- lodgings, restaurants, brewpubs, winery, gardens, movie theatre, and more. Even a little golf course. Filled inside and out with interesting artwork http://mcmenamins.com/Edge/art.html). Even a working hot glass studio on the grounds. Hillside location with views across the Columbia River.
We'll be in the main ballroom, which is generously sized (36x68 feet, 11x20m), on the second floor of the main lodge, with many windows on three sides and a huge mural on the walls. The view is away from the river.
Mostly European-style rooms, with private baths down the hall. Some suites with bath are available at a higher rate (see above). Most rooms have one bed. A few two-bed rooms are available -- send in a deposit soon if you want one of these.
Meals are included with room. If we eat in fairly small groups in their restaurants, they'll give us vouchers good for up to a specified amount for each meal. The Black Rabbit Restaurant (http://mcmenamins.com/Edge/brabbit.html) is very good, and the Power Station Pub (http://mcmenamins.com/Edge/pub.html) also has good stuff. Voucher amounts will be $10.50 for breakfast, $16.95 for lunch, $26.25 for supper.
On-site: Golf, evening movies, wandering around looking at interesting stuff (brewery, winery, distillery, artwork).
Fairly short drive: The Columbia River Gorge
(http://www.fs.fed.us/r6/columbia/forest), with hikes and viewpoints for amazing waterfalls and volcanic cores, Bonneville Dam, mountain viewpoints and more hikes. About the same distance to downtown Portland.
Longer drive: Mount St. Helens, Mount Hood, boardsailing or kitesailing on the Columbia, etc., etc.
To register, print out the registration form available at http://wiki.cs.uiuc.edu/CampSmalltalk/Camp Smalltalk Oregon 2004 and send it with your deposit to:
1260 NW Waterhouse Ave, Suite 200
Beaverton, OR 97006 USA
To help us reach our minimum, and to guarantee you a room, we must RECEIVE your deposit by MARCH 5.
For details, check the FAQ below, or the latest info at http://campsmalltalk.com
FREQUENTLY ANTICIPATED QUESTIONS ABOUT REGISTRATION
Can I pay by credit card or purchase order?
We are using Edgefield's special "midweek retreat" package, so they cannot accept payment directly from individual participants. We must make lump payments, so an individual is coordinating the payments.
When will the remainder of the payment be due?
Final payment must be received by July 12. Again, check or money order in US$.
What if I can't make a commitment now, but I decide later that I can attend?
We will have a reserved block of sleeping rooms for only the deposits received by of March 5. Some rooms will probably be available until sometime in May or June. After March 5, check http://campsmalltalk.com about room availability and how to send a deposit.
Is my deposit refundable?
If we cancel the planned event on March 5 due to lack of deposits, all deposits will be refunded. If you have to cancel after March 5, we will try to transfer your registration to someone who registers later. If that is possible, you'll get your deposit back. If not, you will not get your money back.
Can I participate in the Camp Smalltalk sessions without staying at Edgefield?
Yes, provided we have enough people in paid sleeping rooms. If you are not staying at Edgefield, you can still buy meals at the Edgefield restaurant or pub. If you plan to attend but not stay at Edgefield, please send email to Martin.
What if I have more questions?
Get the latest info at http://campsmalltalk.com
ISerializable is writing a series on adding scripting to an application. The reasons he gives for it are good ones:
Adding scripting support to your application is one of the most valuable things you can do for your client, letting them add value to your software, and keep it current over time with little or no overhead from the developers. Your users will be able to modify behavior at runtime, change business rules as the market changes and fix subtle bugs as they appear until better fixes come along in the form of compiled code. It is one of the most powerful techniques today employed my many varied business applications. But guess what? Its not very easy to do in .Net.
Now for the punchline - BottomFeeder has scripting support - on all supported platforms - in the same language the application was built in. And I didn't need to do anything to add it. All I had to do was deploy the application without removing the compiler. Here's how you can use it at startup - create a Smalltalk script, and save it in a file called ".btfrc" - put that in the same directory with the application. At startup, that script will be loaded.
I don't have a nice way to pop up a runtime workspace, but it can be done - Vassili explained how. So yeah, adding scripting support is a very nice thing - take a look at what Bob W does with it, for instance. I'll be interested in seeing how one does that in .NET
This article goes a long ways towards explaining what's so cool about Smalltalk, without ever even mentioning it. After talking about the Dorado and the Star (and what differentiated them), this example explains it:
At best I think most people ask "What could people do with this computer". That's a very different question from "What people will people do with this computer"... there are so many nifty features that if people pushed themselves they could use, but have a high enough barrier to entry that people don't bother.
Example: I have a nice thermostat in my apartment. Its fairly well designed and has quick push buttons for "Daytime", "Night" and "Vacation". It was even straightforward to set these to my preferred temperatures for "In the apartment, awake", "Out of the apartment or asleep", and I haven't bothered with the vacation button. Now I have noticed that I don't like to get out of bed in the morning because it is sort of cold. In fact, sometimes I'll lie in bed for 30 minutes because its cold, which is a big waste of time (I'm not very rational when I'm waking up). I have noticed that my thermostat supports scheduling changes between day and night temperature. I even looked at the instructions beneath the faceplate, and it looks like it'd be fairly easy to program. But I haven't done it. The device is usable in the sense that if I wanted to, I could program it, and probably get it right on the first or second try. Its not hard to use. But its a little too inconvenient, because I'd have to special case my weekend schedule, I'd have to set several different times using the fairly slow "up", "down", "next item" interface for setting time (on most alarm clocks etc). The point is, its not hard to figure out, but its stills too much hassle. So while I could program the thermostat, I won't. There's always something that seems better to do with my time, and I can't be bothered (even though rationally I know it'd be better overall if I just program the silly thing).
In a nutshell, that explains the difference between the way Smalltalk or Lisp developers work, and the way C, C++, or Java developers work. It's hard to create tools for the environments that curly bracers work in (excepting Emacs - many people working there write elisp macros to help themselves). Sure, you can create Eclipse plugins - but how many developers actually do it? It's a fair bit of work, and takes effort that most people won't expend (like the thermostat). It's not a matter of can't; it's a matter of won't. Smalltalkers are always making little tweaks and additions to the environment - because the barriers are low. This is one of the reasons I favor image based development - it lowers the barriers for productive twiddling.
There's a 3.3 stream and a dev stream update available for BottomFeeder. I ran across a bug report from Peter, and found an issue in the display logic for feed items that came from Atom with only the summary object filled in. I issued a bug fix, and now his feed can be viewed just fine. Thanks for reporting the bug!
Patrick Logan makes some excellent observations about security, closed source, and open source, ending with this:
Open source that is poorly designed is not safe. Closed source that is poorly designed and then released in the open is even less safe.
That's an excellent point, and - in a nutshell - the problem that MS faces with Windows
Here's a nifty Smalltalk article in JOOP - covering concurrency and how to build new control structures using the BlockClosure class. This is all in the context of the ControlWorks framework, a real-time process control development toolset sold by Adventa. Smalltalk is used in the most amazing places :)
It's too bad I'm not in the Triangle Research Park area - I'd love to attend this talk on the Roller architecture - especially the "lessons learned" part. I'm going to be giving a similar talk at Smalltalk Solutions and at the upcoming NYC STUG meeting. I'll be talking about BottomFeeder, but will likely have notes on my blog server as well. I'd be very interested in hearing another blog server author talk about the issues involved in building and deploying a server. Sounds interesting!
Scoble worries about outsourcing:
Anyway, Rajesh Jain's weblog points to the New York Times analysis. Do we really need to analyze this? Let's see. Average Chinese worker gets paid about $1000 a year. Yes, that's right. In Bejing the number goes up to $2500 per year. How much are you paid? I am paid a lot more than that. Is there pressure to send my job over to China? You betcha there is.
There's an interesting counterpoint to some of this in the latest ComputerWorld. To answer Scoble's assertion that there's pressure to move a job like his overseas - all I can do is chuckle. He's in a communications heavy job - he's meeting with customers, reporters, and fellow MS staff on a day to day basis as part of his (as I read it) evangelical job. It's far more likely - if MS is successful in India and China - that they'll nee local equivalents of him someday. I rather doubt that a guy in China, many, many timezones away, is hoing to be able to keep up the same communications schedule that Scoble does. Even in the universe of "grunt development" there are issues many people forget:
- Transitory cost increases - from severance costs, declining morale, people jumping ship, travel costs.
- Long term costs - travel to the outsourcers location. If that's China or India, it's not the same thing as a "quick" cross country trip. There's also a soft costs here - what are the spouses of your staff going to think about 2 and 3 week jaunts to the far side of the planet?
- Contract management - if getting agreement on requirements was hard with people a building over, how hard will it be to manage with people 12 time zones and a culture away? Language will not be the only issue here - just the most obvious.
This is not to say that savings don't exist; they do. They aren't going to be as much as most people think though, and there will be communications issues that crop up. Like other trends in the industry this one is no silver bullet - not to mention the fact that we've seen this all before - textile jobs, for instance, went from New England to the south and then overseas. The main difference today is the speed of the transition - software matured and started moving faster than things like textiles did.
Larkware News has the following rant:
Unification Policy - Alan Shi explains one of the fine points of the CLR's binding policy. I fear I've reached the same point with this stuff that I did with Godel, Escher, Bach: I understand it right after I read it, but my brain can no longer hold on to it. I think .NET has replaced DLL Hell with a binding policy so complex that it might as well be a purely random selection of which DLL to load, for all that an average developer understands what's going on. It is not at all clear to me that this is an improvement so much as just a different set of problems. Or perhaps my brain is just too puny to work at Microsoft.
First, let me state up front that I've not looked at the binding policy in .NET - I will say that the referenced explanatory page is hard to digest. This is not a problem limited to the CLR though - we are in the process of trying to address these issues in Cincom Smalltalk, and it's not a simple set of problems. We are hoping to have the beginnings of an answer out with VW 7.3 (fall 2004)
We have an update on the keynote speakers for StS 2004 - George Bosworth, one of the architects of the CLR at Microsoft. I'm sure that lots of people in the Smalltalk community would like to hear about the design decisions that have been (and are being) made in the development of the .NET CLR - come on out to Seattle to hear all about it. This year's conference is May 3 - 5 in Seattle, at the Crowne Plaza. Register today - the early registration discount will be expiring soon.
The Red Sox can't close the deal - the Yankees grabbed A-Rod. I love this commentary in the Times sports section:
But what chance do the Red Sox really have of winning on the field? Sure, the teams have to play 162 games, but the Red Sox could lead the Yankees for 161 games and still lose to them. They could have a three-run lead and be five outs from going to the World Series and - oh, right, that happened last October.
Heh. Pack it in, Sox fans :)