I'll be watching the game later - friend down in Virginia wants us all to see the game in HD, and that should be interesting to see. I don't really care about the outcome of this game; my team (the Giants) forgot how to play football this season - mostly, they seemed to be playing "give the ball to the other team and watch". The Yankees, they aren't....
The super bowl was actually a very good game this year. Most of the first half was a defensive struggle - and then bam - the last 5 minutes was an adrenaline rush. The second half picked up where the first half left off - and didn't let go until Carolina lost with 4 seconds to go. And that's without the celebrity breast at halftime :) Great game, I think the best Super Bowl I've ever watched. Now if I can muster the motivation to finish off search folders for Bf...
PCWorld reports that the DDOS attack on SCO has taken them off the air. Now, as much as I enjoy watching SCO take hits, this isn't the best way to do it. In fact, it's liable to create sympathy for SCO in legal circles that we really, really don't want.
I've got an initial implementation of Search Folders done for BottomFeeder. What is this? Well, the search tool allows for searches of content you have already downloaded by title, text, or category (or all three). What I've done is allowed these searches to be saved as a synthetic feed. A synthetic feed looks just like a normal feed in the tool, but is organized into it's own search folder, and is updated on demand from within the tool - a re-execution of the search in question. It turns out that this is a feature I like a lot, so here it is! To have a look, grab the dev stream update
Joi Ito has an interesting take on ADD and psychiatry in general today - thought provoking, worth reading:
Now I'm back to trying to figure out what parts of my personality I should change and what parts of my personality are actually features and not bugs.
A valuable question to ask, I think.
Sci Fi reports that there's a possibility of less suckage in Star Trek: Enterprise soon:
Cinescape Online is reporting a rumor that an overhaul may be in the works for UPN's lackluster Star Trek: Enterprise. Citing an anonymous source, the site reported that Paramount Television Productions president Garry Hart may make changes to the show's production staff after February sweeps, including the possible replacement of longtime executive producer Rick Berman.
There's been some improvement this year with a consistent story arc - maybe if they ditch Berman and find some actual writers things could really improve. What I'd really like to see is a long term decline in the "second story line" problem. The second story line on Trek this year is at least consistent, developing a relationship between Trip and T'Pol. In year's past, the secondary story lines often sucked the life clean out of a show (especially on DS9 and Voyager; gads).
Sci Fi Wire reports that "Indiana Jones: The Geriatric Years" is going to start shooting. Thrill to Indiana in the rest home!
These bozo parents have hit on the perfect way to make their child's life miserable:
HOLLAND, Michigan (AP) -- Tacking Jr. or II onto a boy's name is too common, a new father decided, so the self-described engineering geek took a software approach to naming his newborn son.
Jon Blake Cusack talked his wife, Jamie, into naming their son Jon Blake Cusack 2.0.
The reality is, kids with "oddball" names suffer at the hands of other kids - you can call it unfair all you want, but it's the way it is. This is the sort of bozo decision that this poor kid will suffer with for years....
Workers at CSC's San Diego Regional Center (SDRC) found out that there will be no holidays or sick days allowed through the end of the fiscal year, according to docs obtained by The Register. The is the second year in a row that employees have been forced to give up their vacation days to meet lofty productivity goals, and the practice has left a bad feeling in the workplace.
"Apparently, the SDRC have made a bad business forecast, and we loyal worker bees are supposed to rescue them by forgoing vacation," writes one disgruntled employee. "They basically want everyone to take 2 weeks vacation and our 9 holidays and never get sick. Many of us acrue 3 or 4 weeks vacation per year."
That has to be one of the most clueless things I've read about in a long while - and having worked at ParcPlace back in the day, that's saying a lot. Reminds me of a gig I did at American Airlines (years ago) when I worked for Booz-Allen. One day, the project lead on the Sabre side had a meeting with the project lead from our side, and said something like: "I work 12 hour days - your people should work 12 hour days". So we were told to:
- Work 12 hour shifts
- Only claim 8 hours a day for billing purposes
Morale stank on that job. We all pulled 12 hour days - but a lot of that time was spent doing crosswords, playing computer games, drinking coffee, and just hanging out. It baffles me as to what managers are thinking when they decide that they can get something for nothing from their staff - there's always a price - it just might be delayed or deferred...
Brian Marick writes about the interviewer/interviewee problem:
The interviewee *believes* the interviewer has a perspective different from their own, or has an incomplete understanding of some of the areas.
This brought something else to mind for me - accuracy and what we believe based on what gets reported to us - through any outlet. Think about the last time you say any technical topic being discussed by a reporter (possibly even in the trade press). If it's on TV, radio, or in a general newspaper, it's highly likely that there were many slip ups and factual errors (my friend Mike likes to point to Consumer World reviews in this regard). So when we read these things, we laugh about the inaccuracy - and then move on to reading about subjects we don't know as well without batting an eye.
What the interview thing raised for me is this - just how accurate is the rest of the stuff I read? If the tech journalists can be so far off base, what about about the political, economic (etc.) journalists? Just how much of what they report is being filtered not through bias (about which one can read tons of material) - but through sheer ignorance? It's probably a good idea to look at all journalism with a very, very jaundiced eye...
The Register tells us why the scourge of viruses won't end anytime soon:
Was the vector some l337 0-day 'sploit? Nope. Was it a complex multi-layer program leveraging several unpatched vulnerabilities? Nope. It was -- wait for it -- an executable attachment in an email. What genius! The author of Novarg (or MyDoom, or whatever you want to call it) really put his noodle to the test when he cooked this one up, huh?
So long as we have users that will open anything they get sent in email, we'll have this problem. Even better anti-virus systems won't help much here - the sorts of users that will open anything are highly unlikely to install (and keep updated) an anti-virus system. Sigh...
One of the things that recently got a lot better in BottomFeeder is character and font handling. I have to thank Alan Knight for most of the improvement - his work on Web Toolkit has given him a lot of experience dealing with encoding on the web. Here's how things work in Bf:
- Download the XML (RSS or Atom) page from the server
- Parse the XML into Objects
- Display the feed data to the user
The difficulty came right there at the beginning. The HttpClient in VisualWorks will use the correct encoding to get the content from an Http response object - assuming that the encoding has been set in the header. If it's not set, what it does is assume (as per the standards) that the content has been encoded as iso-8859-1. The trouble comes in when the content is sent without a content encoding header, and is encoded in something other than iso-8859-1 - you'll end up seeing a lot of bad characters in the resulting stream of data
Well, that's the standard way of dealing with this, and so - in some sense - "correct". The trouble is, end users couldn't care less about following standards if it means crappy looking text to read. The upshot is, I had to start playing some of the same games that I suspect browsers play - looking for other encoding information in the text. At the moment, Bf looks in two places:
- Once I have the content, I scan through looking for <meta http-equiv="Content-Type" tags. If I find one, I go ahead and grab the encoding set there as the proper one to use
- I look in the XML attributes for encoding information - things like this: <?xml version="1.0" encoding=. Again, if I find that I grab the encoding information
Well, at this point we have a problem - the content has already been decoded as iso-8859-1, and, based on the new encoding information, we know that's wrong. What to do? Here's where Alan's tip saved the day. The following code snippet sets things right:
decode: text with: encoding ^[(text asByteArrayEncoding: 'iso-8859-1') asStringEncoding: (encoding asLowercase)] on: Error do: [:ex | text]
That undoes the iso-8859-1 encoding, and then decodes the text with the proper encoding information gleaned from the document. The results of this simple snippet of text have been really good - I'm seeing far fewer garbage characters in the text of the feeds I access. I still see some (especially in the Meerkat feeds), but I can't do a lot when there's no encoding information at all - iso-8859-1 is as good a guess as any in the complete absence of information.
This is the sort of thing any user-agent on the web is going to have to go through. For good or ill, encodings simply are not universally set in the http headers. Maybe they should be, but they aren't. I don't expect it to get better either - remote hosting services pretty much ensure that
Proving that politics invades every field, this development in the ongoing Atom/RSS imbrogolio takes the cake.
Cutting boards are another area of concern. Turns out that wooden boards are safer than plastic, because the cellulose in wood absorbs bacteria but won't release it. Plastic absorbs bacteria in a different way. "When a knife cuts into the plastic surface," said Professor Dean Cliver, of the University of California at Davis, " little cracks radiate out from the cut. The bacteria seem to get down into those knife cuts and they hang out. They go dormant. Drying will kill, say, 90% of them, but the rest could hang around for weeks."
Makes sense; that's why plastics that you send through the dishwasher often get dyed the color of things you wash - the plastic absorbs it all. This is the part that runs counter to lots of "conventional wisdom":
In one experiment performed by Professor Cliver, raw chicken juices were spread on samples of used wood and plastic cutting boards. Both boards were then washed in hot soapy water and dried, then knives were used to simulate cutting vegetebles for a salad. No bacteria appeared on the knives cut on wood, but there were plenty on the knives used on a plastic board.
We use glass, which I think obviates the whole issue. But I'm sure a lot of people use plastic thinking it's safer. Sometimes it's what you know that's not so that's most dangerous. Read the rest; fascinating story.
I might be able to make some progress on getting BottomFeeder packaged for the Mac this week. One of the engineers has gotten me VNC access to a Mac, and I should be able to get the packaging done - it doesn't look hard at all. I'll post again on this subject if/when I achieve something!
I've followed the packaging directions for OS X that come with VW (amazing what happens if you read the shipping documentation) - and I think I have a "proper" OS X packaging on the download pages now. I'd appreciate hearing about any issues this packaging has.
Lisp and Ruby users have a few words about J2EE as well:
J2EE applications tend to grow like cancer until all resources of the host have been consumed. At my day job we've written over one million lines of Java implementing a simple internet marketplace. We do use a code generator to do most of the grunt work, but only because we cannot create the necessary abstractions within J2EE. Using a code generator is like enumerating all the parts and assembly instructions for a house instead of just writing "home". Java has no meta.
The MS .NET crowd is in the same boat....
After a couple of suggestions from engineering, I went through my build again, and made sure that all the networking code that should be there is on the build. There were some Mac specific classes that I think may have been being stripped out of the build; in any case, I've got a new OS X build attempt posted. I've got it structured as an OS X application - something I can do without having a Mac. I'm in the process of getting access to an OS 9 machine (remotely) that should allow me to do a build for that platform as well. I'll gladly take any and all feedback on the latest OS X build I've posted.
I found this post via a Feedster search for BottomFeeder I use to see stuff I might otherwise miss. I noticed that there was a reported issue with the Atom support - and sure enough, it wasn't quite right. It turns out that the Blogger Atom feeds are set up slightly differently from the ones I tested against (off the Atom Wiki). This is what I love about early adoption of in-development specs - everyone goes their own way, and tool builders end up having to support all the variations. In any event, I just posted an update to the Atom support in the Dev stream for Bf; I may try to extract it for the normal update stream as well.
Picasso wasn't interested in becoming a curator. Meryl Streep is an extraordinary actress, but that doesn't mean she wants to or would be any good at running a studio. Why does corporate America insist on taking your job away from you if you're good at it and serve it up as a promotion?
It's not quite that simple; there are, in fact, people who want to move up the chain. For the most part though, this fits - we all know plenty of former tech people in management positions - many of whom don't belong there. Heck, this makes me wonder if the huge failure rates in IT projects is related to this problem. The problem is twofold:
- Convincing corporate managers that they can keep us happy without promoting us
- Convincing ourselves of this same fact
The latter point may be the hardest - the reality is, even with increased pay, many people would consider years in the same position as being stuck.
Ben Hammersley points to a summary of RSS by Mark Pilgrim, which documents the existence of 9 different (and incompatible) versions of RSS. This is one of the prime reasons that news aggregator authors continue to get mail asking something like this:
Your aggregator - (insert name here) - has trouble with this feed: (insert http link here)
Now, Atom was going to make this all better, right? Maybe it would have, if people hadn't insisted on deploying it before it was ready. I count myself among the guilty here - I've got Atom 0.2 feeds on this blog. In the wild, there's Atom 0.2 and 0.3 - and since the specs aren't done, there's slight variations in implementations, as different sites see the spec differently. Blogger is mandating that users pick RSS or Atom (why they can't do both is a mystery), so their take on 0.3 is likely to be semi-definitive. What does this mean? Look for the variance to get worse, and then worse again...
Tongue slightly in cheek, Charles Miller explains why Java programmers have it so hard:
We're surrounded on all sides, you see. To C programmers, we're children who can't handle real complexity. To Smalltalkers and Lispers, we're misguided souls groping towards a better way, but trapped in the wicked grasp of Sun's marketing. To Perl and PHP nerds, we're too busy over-complicating things to ever get anything done. To Ruby and Python hackers, we're already dinosaurs. And to everyone, we're apparently the COBOL of the 21st Century.
Pretty much every other language has its niche. You can point at it and say that it's useful for this, or it pioneered that, or you'd use it in this circumstance. The only people who say anything like that about Java are, well, already Java programmers. C# programmers might look on Java as a slightly embarrassing parent, except we're the competition, and it's better to just not mention us at all.
Heh. I wouldn't say trapped in the grasp of Sun marketing; I'd say trapped in the grasp of a bad type system...
I've been pushing builds of Bf for OS X for 2 days now, and I think I finally have it - although confirmation from someone with an OS X box would be appreciated. There were a few issues with my packaging:
- One of the XML manifest files listed the wrong name for the VM - I fixed that
- The OS X VM expects an image called 'resource.im', and I was shipping 'bottomFeeder.im'. I changed that
- There's a known issue with some OS X networking setups that can cause a socket error when trying to get the host address. Since this happens at startup, it's kind of a problem. I've got a patch that works around that in the build
I'm hopeful that I've got this working; if so, I can move along to fighting with OS 9...
Update: As youcan see from the comment below, the OS X build works. It doesn't have the Bf splash screen (I have no idea how to provide an image in the right format without access to a Mac - help welcome!), but it installs and works fine as a double clickable app. I'd like to thank Holger Kleinsorgen and Ralf Propach for their help this morning, and Roger Whitney and Bruce Bolden for their email help.
Program chair Alan Knight has pushed out another call for participation:
Smalltalk Solutions 2004 is fast approaching, and we need your participation! Smalltalk Solutions is a premiere venue for Smalltalk professionals, regardless of dialect, to meet and exchange ideas. We are currently accepting proposals for all varieties of talks involving Smalltalk technology and including presentations of other areas of technology from a Smalltalk perspective.
This year's conference is taking place in Seattle, Washington, May 3-5 2004. Presentations may be in the form of:
- Technical Presentations
- Experience Reports
- Technology Demonstrations
- Half-day Tutorials
Presenters receive a free conference registration (one per presentation). Tutorial speakers will also receive a small stipend.
To submit a proposal, please go to http://www.smalltalksolutions.com/participate/participate.htm or email Alan Knight
Proposals should be received by February15, 2004.
get those cards and letters in!
Salon has an interesting article on a show I've seen only once, but found interesting - "Bands Reunited". It's an interesting article, and a great show - catch it sometime if you were listening to music during the 80's....
Amtrak to offer WiFi at their stations. Now, if we could get it on the trains running up and down the Northeast corridor....
Ryan Lowe has reached the end of his rope on the (lack of) security in MS products. To be fair, newer revs of Outlook (etc) have most or all of the dangerous features off, and most people will never turn them back on. The main problem is the legacy of win98, winME - and even win95! - clients out there with dated software. Too many of these people are out there, running on DSL or cable modems, always on, and apparently always infected. I cut MS no slack on this stuff. It wasn't necessarily clear that these services were a problem when 95 shipped; but it should have been by the time 98 went out, and clearly was by the time ME shipped. And yet here we are, still in hackers paradise. Backwards compatibility is a big deal, I know - we try very hard to achieve as much of it as we can in Cincom Smalltalk releases - but for some issues, there are overriding concerns.
The Register points out that many, many office workers don't think that they have any role to play in security at all:
Two-thirds of the 1,000 people quizzed by market researchers TNS in January admit they are not aware of even the most basic virus prevention measures. Meanwhile a third of those polled in the Novell-sponsored study said they are too busy to check their emails before opening them.
Depressingly, nine in ten of the workers quizzed believe that have no part to play in preventing the spread of viruses, preferring to leave responsibility to "their IT department, Microsoft or the government".
This was in a survey of UK office workers; the rest of the report is even more depressing...
Rich has a few interesting thoughts on the way promotion and technical advancement work in large companies.
Everything you need to know about XML 1.1 can be summed up in two rules:
- Don't use it.
- (For experts only) If you speak Mongolian, Yi, Cambodian, Amharic, Dhivehi, Burmese or a very few other languages and you want to write your markup (not your text but your markup) in these languages, then you can set the version attribute of the XML declaration to 1.1. Otherwise, refer to rule 1.
Well, regardless of what people should use, rest assured that they will use 1.1. Now, we don't have a 1.1 parser in VW at this point (we likely will by the next release). In the meantime, after a couple of small hacks, BottomFeeder handles Mark's feed just fine. I've posted the update to the dev stream; I may back it down to the regular stream if I don't see any issues with it
This is one of the really nifty things about using Smalltalk, actually - anyone use Java or .NET, and using the shipping XML libraries, is kind of up the creek - you can't easily make small changes to these libraries, and even subclassing could be problematic (I have no idea if critical classes in these frameworks are declared final, but they could be). Meanwhile, I was able to deal with this in a work-around kind of way in minutes - and I'm no parser expert....
The Industrial Light and Magic folks won't be sleeping much if they have to stick with this schedule. Time to get that caffeine drip going!
One of the people now running a blog on this site asked me about improving the look and feel of the pages. I'll admit, I'm no whiz when it comes to laying out web pages - I settled on what's here now more out of exasperation than anything else. The upshot of the request was for a few new, convenient API's for getting content from the back end - allowing for a more flexible layout. That's where the power of Smalltalk helped me out again. I fired up the test server here, wrote some new code, tested it out (against the running test server) - and then versioned it off. Once I did that, I posted two things to the server
- The incremental changes I just made
- The new version of the loadable components
I didn't have to restart the server - it has a convenient patch interface. So I loaded up the patch, and now the new interfaces are available for use. No fuss, no muss, no restarts. That's what I love about Smalltalk
Vassili Bykov explains why seemingly "little things" can't always be fixed right now - no matter how small you think the change is, there's almost always a snowballing effect of related changes that have to be made.
This is actually one of the constant tensions that exist between product management and engineering. In my role as PM, I want to see the product become easier to use and more consistent. This can often lead to my asking for "a simple tool" over here, or a "cleaner interface" over there. What I'm not always seeing (until it's pointed out!) is the downstream effect of those "simple" requests.
This is also where larger projects - such as Pollock are born. In order to really fix the current UI, it's not enough to simply tweak and tune - a general overhaul is called for. That general overhaul has its own downstream effects - all the tools have to be changed to match the new UI.
I've always wondered about the efficacy of team building exercises; this morning, I see that Frank Patrick has some thoughts on the subject as well. This is something project managers should definitely pay attention to...
This post I made yesterday generated a couple of comments, one worrying that I'd end up with a less readable site. That's certainly not the goal. The issue with the current layout is one of screen turf - there's way too much of it taken up by the top of the page search forms, and the the links at the bottom are not laid out at all well. In any case, it's all an experiment - we'll see what happens.
I've just posted a BottomFeeder update that cleans the UI up. The button bar is gone; all of those options exist in the View menu anyway. The feed icon is banished from the main ui, instead living in the Feed Properties dialog. That also eliminates a background process in the main UI, the one that fetched the image. You get notified of alerts (assuming you've set any) in a part of the status bar now. With all of those cleanups, I moved the rest of the UI to take up all the screen turf - no more wasted space at the top. If you grab this as a dev update, you should not load it on the fly; it's best to restart after grabbing it
I spotted this complaint over on Dave Winer's blog:
"...programs will express compatibility in terms of products, not formats. Then you'd have to use one aggregator to read BBC feeds, for example, and another to read SF Chronicle feeds." Well I guess we didn't have to wait too long for that to happen.
Funny - I have Evan's Atom Feed (and boy, does it have a lot of errors!) and Dave's RSS Feed in BottomFeeder - no need to use a different application to read both. This, even though I've posted extensively on what a huge waste of time I think Atom is. The bottom line is, it doesn't really matter what I think. My users are going to want to read Atom feeds, so I implemented support back when the spec was at 0.2. I now support 0.2 and 0.3. Looks to me like Dave needs a better aggregator....
Patrick Logan spots a gathering storm in the world of static languages:
When a language is formed by piling feature on top of feature, you run out of gas sooner rather than later. Such is the case with "partial classes". Could one have foreseen the desire for "partial methods"?
What do you do when your language is not dynamic enough, but the next feature may be the straw that breaks the camel's back? You resort to code generators.
Mind you, the developers living in this world think all of this is great - they have manifest typing, so the larding on of tons of cruft - cruft that makes it incrementally harder to actually understand written code - is seen as a good thing. What these people need is a few months of Smalltalk, Python, or Ruby immersion...
There is clearly a performance aspect to it. One possible solution would be to say, "There are no value types. All types are heap allocated. Now we have representational identity, and so we're done, right?" Except it performs like crap. We know that from Smalltalk systems that did it that way, so something better is needed.
Anders solution - make the language immensely complex for the truly small number of cases where any of this matters. Yes, there are people doing maths in software where they need that level of performance on a day to day basis. And no, most people aren't part of that club. For most people, applications look like this:
- Pull data from the data store
- Massage data for screen display
- Allow user to modify data as needed
- Push data back into data store
Like it or not, the vast majority of developers are working on an application that looks, in rough terms, like that. Most of us aren't doing matrix manipulations or fast fourier transforms - but to hear Anders speak of it, we have to optimize for those few because... well, because he hasn't thought that deeply about the problem, that's why. When we do come across parts of our system that we have to optimize for those cases, we can call out to C (etc) - and that work-around is typically a much lower effort than having to deal with the world Anders wants us to live in. I know there are applications that have such strict optimization needs that this strategy is impractical - and I also know that such applications are not what most of us are building.
Here's another thing - as Patrick says on his blog, 64 bit implementations will erode the number of cases where that stuff matters even more - so the development time suckage of .NET and Java will persist, long after the supposed "need" for it has expired. Bonus question - I wonder when the last time guys like Hejlsberg or Gosling actually had to work on a real project for a real customer, so that they could see what they've wrought? I'd guess it's been a long, long time. Actually, that topic is worthy of a post of its own - developers who have been cut off from end users too long, and how easy it is for them to wander off the reservation...
Don Park comes up with a great phrase in the midst of a post on XML 1.1:
Another reason for not using XML 1.1 now is that next version of XML is likely to arrive before XML 1.1 is widely adopted. Why? Because engineers are like blacksmiths without a hobby.
Don has a definite way with the turn of a phrase....