I had forgotten how much fun - and how much work - teaching an intro class is. Today's the last day of class. It's been a good, invigorating week - I hope the students have enjoyed the class as well. Next week may be Thanksgiving, but it's also a "try and get the next release out the door" week as well. Should be busy.
It looks like the next release will probably miss November, and slip into early December. Why? There were some problems with the latest build, and Thanksgiving is coming up fast - for the most part, November ceases to exist as a productive month after next Tuesday. So, look for the CST release in early December.
Here's an interesting article on starting up a new company - it advises against using venture capitalists.
The Mythical Man Month was written a long time ago now - 1975, specifically (re-released in 1995). Nothing much has changed. Managers still think that you can add more cooks and get broth sooner. Outsourcing - offshoring in particular - shows just how little we've learned. Can't get the job done with 3 developers in New York? How about with 20 in Bangalore then? Have a look at this ComputerWorld item:
as IT shops apply "brute-force programming techniques" with low-cost coders from India and elsewhere. That's the observation of Tom Bigelow, CEO of Performance Software Corp., a Phoenix-based developer of custom software for the aerospace industry. Bigelow says companies that hire offshore developers in bulk eventually hit a wall. That's because, as Frederick P. Brooks Jr. revealed in The Mythical Man-Month, his classic book on software engineering published nearly 30 years ago, you can't compress the time it takes to complete software simply by throwing more bodies at it -- not even in the Internet age. Most IT managers have been "mandated to cut x percent from their budget," Bigelow contends. So, many have grasped at the straw of offshore development with the hope of saving money and still getting big development jobs done. The frequent results, he says, are late projects, bad projects and dead projects. While upper management is busy updating its spreadsheets with lower-cost programmers from abroad, many midlevel IT managers are foundering as they try to control workgroups overseas, Bigelow says.
Boy, what a shocker - we throw requirements over a 12 timezone wall, and gadzooks - it doesn't work any better than when we threw them across the glass wall to IT.
Here's a related article by Thomas Nolle of Network World:
Software development, hardware engineering, project management, accounting and many other jobs are just as vulnerable to cheap labor if the work offshore employees or contractors do can be coordinated inexpensively and efficiently with the on-shore company personnel and its customers. Companies might resist having software developed 8,000 miles away because they'd feel they were losing control of the process. Would they feel the same way with real-time video links to those remote resources? With instant data collaboration? All that holds back that level of techno-integration is the cost of the networking - the same cost that's falling like a rock in today's market. The better we make networks, the less network services cost, the lower the barriers to exporting technical jobs. Sad, but true.
Clearly, he has a point. But he leaves out one very critical thing - those guys you want to set up video links with who are 8000 miles away? When it's noon there, it's midnight here (and vice versa). Who's going to work late shift? US based project management? I'll be astonished when I see senior managers doing 1 AM conference calls. Sure, you can try and have the overseas staff work night shift - but that's not going to be possible for long. There's a burgeoning internal market in India (and China, etc) - how many staffers will work late nights when they don't have to? This all sounds very simple when all you look at is a spreadsheet. Life is more complicated than that.
Hmmm - maybe it's time to apply a cluestick to senior managers.
I think IBM is smoking way, way too much of the bad code flavored weed. Have a look at what Peri Tarr of IBM research says while discussing Aspect Oriented Development:
The idea is to manage "concerns" such as security policies, password schemes or internationalization rules, separately from the code to which they apply. In object-oriented software, it's difficult to add features that weren't initially planned for, because each update to the application impacts so many parts of the code, said IBM's Peri Tarr, a research staff member who works with Chung. At the same time, it's virtually impossible to anticipate every change you will want to make going forward. "AOSD lets you go back and say, 'I know now what I didn't know then. How can I modularize this software so I can add new features?'"
Ummm - if you do a decent OO design, this isn't that big a problem. OO is all about separating concerns, properly done. Maybe AOD helps there; I haven't looked that deeply into it. But you know what? If your application can't be easily modified to add new features, I seriously doubt that the magic bullet called AOD is going to help - you have other problems.
We have to face that there are two types of American programmers who are doomed to extinction. First, the bad ones. Traditionally, there have been more exceptionally bad programmers than exceptionally good ones. It's well known that there is something like an order-of-magnitude gap in productivity between the very best programmers and the very worst, but it's less known that the distribution of talent is quite asymmetrical, with a long "tail" toward the less-than-competent. The untalented have long survived by coasting in larger teams and being the "only game in town" for smaller concerns. These are exactly the scenarios that the offshore shops already have firmly in their sights and where the "How much worse could offshoring be?" seed is most likely to find fertile soil.As the "tail" of unproductive-but-employed programmers is chopped off, the productivity demanded of an employed programmer is going to increase dramatically. Programmers complacent in their skills and tools because they've met programmers who are less productive will quickly find themselves on the edge of the cliff.
That's a good point.
Dare Obasanjo quotes Adam Bosworth at XML 2004:
What has been new is information overload. Email long ago became a curse. Blogreaders only exacerbate the problem. I can't even imagine the video or audio equivalent because it will be so much harder to filter through. What will be new is people coming together to rate, to review, to discuss, to analyze, and to provide 100,000 Zagat's, models of trust for information, for goods, and for services. Who gives the best buzz cut in Flushing' We see it already in eBay. We see it in the importance of the number of deals and the ratings for people selling used books on Amazon. As I said in my blog, My mother never complains that she needs a better client for Amazon. Instead, her interest is in better community tools, better book lists, easier ways to see the book lists, more trust in the reviewers, librarian discussions since she is a librarian, and so on. This is what will be new. In fact it already is. You want to see the future. Don't look at Longhorn. Look at Slashdot. 500,000 nerds coming together everyday just to manage information overload. Look at BlogLines. What will be the big enabler' Will it be Attention.XML as Steve Gillmor and Dave Sifry hope' Or something else less formal and more organic' It doesn't matter. The currency of reputation and judgment is the answer to the tragedy of the commons and it will find a way. This is where the action will be. Learning Avalon or Swing isn't going to matter. Machine learning and inference and data mining will. For the first time since computers came along, AI is the mainstream.
There's a difference between the flood from email and the flood from syndicated content. For the most part, I have no control over how much email I get - it comes at me whether I like it or not. With RSS/Atom, I have complete control - I can cut back or increase the flood anytime I feel like it.
The Open Source community has not been entirely happy with the quips and barbs from McNealy and Schwartz; Newsforge has an interesting article examining their claims and the facts.
In the comments to this post this question came up:
But do you have control over your feed subscriptions? It's a little like saying that smokers are in control of their cigarette intake. Of course you can delete subscriptions but can one overcome the desire and addiction to new information? It's worth reading about pseudo-ADD, a non-clinical form of attention deficit disorder that modern society seems to foster.
Well, I can't speak for anyone but myself here. I've read about Scoble's 1000 or so subscriptions (and it sounds insane to me). I was adding feeds regularly until I got to where I am now - 284 feeds. I've had within 5 subscriptions of that number for months now - I got to a point where the volume was high, but not unsustainable - and stopped. Are there people who can't stop? I suppose so. Like other addictions, I doubt it's a majority.
- A system for determining if two operands point to different locations in memory, the system comprising: a compiler for receiving source code and generating executable code from the source code, the source code comprising an expression comprising an operator associated with a first operand and a second operand, the expression evaluating to true when the first operand and the second operand point to different memory locations.
- The system of claim 1, wherein the compiler is a BASIC-derived programming language compiler.
- The system of claim 1, wherein the operator is IsNot.
- The system of claim 1, wherein the compiler comprises a scanner, a parser, an analyzer and an executable-generator.
Hmm - The #~~ message in Smalltalk certainly predates any MS implementation here. Not to mention prior art in various assembly languages that aren't coming to mind right now. I guess "stupid" has no bottom at the US PTO...
Sci Fi Wire reports that Amy lee of Evanesence will be writing music for the upcoming adaptation of The Chronicles of Narnia: The Lion, The Witch and The Wardrobe. I'm a big fan of both, so that's cool news.
Sriram Krishnan unloads on the XML weenies (you know who you are). I have to say that I agree with him:
Turn the clock back to some 5 years ago when everybody and his neighbour had a personal homepage in AngelFire or Geocities. If all they had seen was an error message complaining of a tag that hadn't been closed - would they have persisted? I doubt it. Geeks would - but your average geocities homepage guy wouldn't have. If browsers aren't as forgiving as they are today, most of the customized templates on Blogspot wouldn't work. I cringe every time I see someone flaming someone else for not being XHTML compliant. Tim Bray - if you're reading this, I want to know something. Why is XML case-sensitive? No human-being ever thinks in case-sensitive terms. A is a. End of story. So now, I have a situation where writing <html> </HTML> wouldn't be XHTML compliant. And what do I get out of XHTML apart from geek-bragging rights and this strange idea of 'standards-compliance'? Does it give me more freedom? Does it help my viewers? My customers?
Put that in your aggregator and smoke it :)
If you follow the dev builds for BottomFeeder (scroll down past the first set of links), I've got a new build up with all the latest code loaded. If you grab this build, you can delete all the .pcl files in the 'app' directory. I've also added a small new feature - internal searches can now use a Regex (there's a checkbox in the "Search BottomFeeder" dialog).
There's a trojan horse program for cell phones that can force you to reset - and lose all your custom settings (phone numbers, address book, etc). The story indicates that this isn't the first such attack. Sadly, it won't be the last either.
So my in laws call us to let us know that their basement is flooded, and they are carting out water by hand in buckets. My father in law is 81, btw. So we ask the simple question:
Us: Have you called for a plumber?
Them: Yes, we can't get one to come out
Us: And you've called how many plumbers?
Gah! Did I mention that there's rain in the forecast, and they live in a low lying area? As I wander off in search of a cluestick...
In this arena, Scoble just doesn't get it. Is this protecting anything? Now to be fair, MS is simply following the rest of the industry here, and building up a portfolio of defensive patents, ready to be deployed should another Eolas pop up to do damage. That doesn't jive with what Scoble is saying though:
Our patent system is in place to encourage investment in new technologies. And, despite how you feel about Microsoft, Microsoft's 57,000 employees are a real investment in new technologies. The same system protects the investments that Apple, Yahoo, eBay, IBM, Google, and scores of other companies are making in their software.
This is protection of the sort offered by gangsters in 30's flicks. Would it be asking too much for a company with as much clout as MS to take something that vaguely resembled a leadership position on this?
Scoble still thinks that the pen is mightier than the keyboard for many people:
Jeremy Higgs demonstrates how geek centric we all are: "I'd hazard a guess most people can type quicker than they can actually write.
Um, Jeremy, most people on earth have never had their hands on a keyboard, so how do you know that's correct? My mother-in-law, who only speaks and writes Farsi, for instance, can not use a keyboard. She can, however, use a pen very well.
That's not "geek centric" - it's true for anyone who's been exposed to keyboard (possible exception - people writing is syllabary based languages). Hand someone a keyboard, and within a few days, typing will be preferable to longhand.
Scoble then goes into meeting etiquette:
But, there are many situations when using a pen is more appropriate. In business meetings, for instance. Many people think it's rude to open a notebook and start typing. But it's perfectly acceptable to use a pen on a screen. Why? Because it's similar to writing on a pad of paper.
Also, there's no physical block between you and the people you are meeting with. Also, when I'm in meetings I like to brainstorm. Or take notes of associations. Or, draw pictures. Quick show me a mock up of your new prototype in ASCII text. But I can draw one out in seconds on my Tablet PC.
I'll grant the point about pictures - there are ways to work around that, but they are work-arounds. As to typing at a meeting? It's been a long time since I've been in a meeting where that mattered. And in meetings where it matters, I rather suspect that a Tablet would be viewed as a faux pas as well. When I'm taking notes in a meeting, I want my keyboard - trying to write stuff out longhand is slow, and I'm far, far more likely to miss something.
Ever wonder why there are a seemingly infinite number of mustard varieties, but only one (Heinz, with a few second tier competitors) ketchup? Malcolm Gladwell can tell you. It's a fascinating look at segmentation in the food industry. I suspect that the same thing applies elsewhere as well. Via Ted Leung
"Enterprise" seems to have improved this season - and I think it's because they've purposely pulled back from season long story arcs to multi-episode story arcs. Sustaining a single story line for an entire season is hard - even on shows I like, with generally strong writing (like Buffy) - it's possible to come up with entire seasons that are stinkers. In the BuffVerse, seasons 1 (The Master), 3 (The Mayor) and 5 (Glory) were the strongest. Season 2 (evil Angel) was ok, but 4 (Adam) and 6 (evil Willow) were pretty bleak - the overall story arcs simply couldn't sustain 22 episodes. That's where Enterprise went wrong with the "Temporal Cold War" arc - the writers spent most of their time painting themselves into corners, with the unsurprising result being that the final resolution was just silly. They are doing much better now with mini-arcs of 2-4 episode duration. The only issue I have with the current arc is the need to tie into the future that is already owned by earlier series (original Trek, etc) - there would be a lot more flexibility without that. I can hardly fault the writers for that though; it's a constraint that they simply have to live with.
Buffy was probably the best series that attempted season long arcs; "24" has to be just about the worst. Season 2 jumped the shark early on, and season 3 was just absurd by the end (you know it's time to stop watching a show when you are reduced to yelling at the TV). It takes a really strong author to sustain a long story arc - based on the evidence, I'd also say that it requires a single author (think Babylon V). "Enterprise" should fare better now that they've decided to stop trying that.
Ed Foster shows us what the kind people of the MPAA might be dreaming up for us. The sad thing is, it's too uncomfortably close to what they want to really laugh at...
One of the interesting questions that came up when I taught a Smalltalk class last week was on "uniqueness" - the students wanted to know about things that Smalltalk was capable of that would be hard (or impossible) in the languages they knew. Most of the students were Java/C/C++ developers, so it wasn't hard to find a few things that stood out:
- Classes are just objects
This one often throws people. When all you see is constructor code, realizing that a class is just another object can be an epiphany. I was able to get that point across by showing them class instance variables - and pointing out that they are simply instance variables for the class. This isn't a hard idea to get across - but it demonstrates the differences between the Java notion of a class object and the Smalltalk notion of a class object quite well.
Most people come into a class expecting to learn about a fixed set of reserved words that define control structures. When you get to blocks in Smalltalk, it's just a little different. One of the things that really helped here was the debugger - I was explaining how #whileFalse: worked, and I used the debugger to show the power of blocks. Walking through the code in the debugger really explained things - and made it clear that blocks allow you to define your own "control structures" in Smalltalk.
It's not that you can't do the kind of message dispatch that #perform: allows for in Java - it's that in Smalltalk, it's simpler and more convenient. That's a mixed blessing, of course - every Smalltalker I know (including me) went dynamic message creation crazy sometime during their first year or so of Smalltalk - before realizing that over-use can make code impossible to follow. Every language has landmines you can step on - this is one that most developers run into fairly early in Smalltalk.
In any event, these topics engendered a lot of good conversation in the class, and I think they helped demonstrate the power and flexibility of the language to the students. One other thing I found to be a great help - the workspace created by Ivan Tomek that we ship with the NC product. It has a lot of great examples that helped quite a bit. I should probably talk to Dave Buck about this stuff - he's got a lot of experience teaching Smalltalk, and offers training classes now.
I was talking about dangerous power in this post, and I got an email comment on another doozy you can get enamored of - #doesNotUnderstand:
The first time you realize that you can implement #doesNotUnderstand: in your own classes (or in any class), it can lead to some truly dangerous (and hard to follow) Smalltalk code. Here's an example - something I used to do a lot of when I first learned Smalltalk:
update: anAspect with: aValue from: aModel [anAspect isKeyword ifTrue: [self perform: anAspect with: aValue] ifFalse: [self perform: anAspect]] on: MessageNotUnderstood do: [:ex | ex return]
The intent here is to handle an inbound event (sent via dependency) - and let events we get (but don't care about) fall on the floor. Why is this dangerous? Well, notice that the "let the events we don't care about fall" mechanism is a MessageNotUnderstood handler. That means that if any MNU is raised downstream from the #perform: (i.e., not in trying to perform the event, but in trying to handle it) - it will get swallowed. This leads to errors that are nearly impossible to diagnose (trust me - I've written myself into this corner). In general, you want to think twice (or more!) before you decide to handle an MNU in "normal" code....
Looks like someone set up a planet Smalltalk site. I don't see a feed for the aggregated site, but there are subscription links to all the blogs that are listed - including a few I had missed.
This sounds like outsourcing taken to a bad extreme:
The reader was in the market for new Veritas Backup Exec software and was exploring his supplier options. "Dell offers a product called the Dell PowerSuite Veritas Backup Exec Server," the reader wrote. "It appeared to include several of the Backup Exec options we needed at an attractive price. Unfortunately, my quest to find out exactly what it includes proved to be an exercise in futility. I spoke with four different representatives at Dell, three of them sales reps and the other from tech support."
While some of the reps he spoke with had thick accents, the real problem was that none of them seemed to have any information. "What did I learn from these four people?" the reader wrote. "Absolutely nothing. I spent 90 minutes on the phone on hold and got nowhere. The sales reps just read the website to me over and over again. I guess they assumed that I couldn't read it myself. I explained to them exactly what I needed to know in terms a child could understand and they still could not grasp what I was saying. I got so aggravated that I finally hung up. Miraculously I got a call back five minutes later and spoke to another rep, but he turned out to be no more helpful than the others. After fifteen wasted minutes he told me he would research it and call me back."
The thing is, it's very, very dangerous to push a core function (like sales) out. Why? In order to sell, you need to have committed people who want to sell your product, not time-fillers reading from a script. There's a secret underbelly to outsourcing support as well - it makes all your post-sales customer contacts suck, which in turn lowers the liklihood of a future sale. There are at two companies that have hurt their chances of selling me a new product because of that - the outfit that now owns Replay TV and Symantec.
With Symantec, I wanted to renew my anti-virus subscription, so I went to their website. As it happens, I made a mistake on the form and got a renewal key for the wrong product. I was willing to cut them some slack since it was my error, but I ended up talking to people who I could barely understand - and it was also clear that they could barely understand me. Once it became clear that I had the wrong key, they got me a good one. The entire experience would have taken minutes (instead of over an hour) had I been speaking with someone who understood what I was saying
I'm sure that outsourcing tech support saves money in the immediate "balance sheet" way. What I'm also sure of is that it costs future sales to existing customers, as they get frustrated and angry dealing with a communications problem they didn't ask for.
The music industry has reached bizarro territory - killing its own young in the quest to ensure that all music fits into their box. Have a look at this from Joi Ito:
"I thought it was a new kind of fraud," said Naoki Kasugai, who runs Daytrip, a nightclub that offers live music in Nagoya. He received a letter from JASRAC in summer 2003 along with an invoice for a monthly charge of 28,350 yen in copyright fees, covering the entire time his bar has been open since 1997. It totaled a whopping 2.32 million yen.
Kasugai was shocked and puzzled. He had never heard from JASRAC before. He figured someone was trying to con him.
But after receiving a second invoice from JASRAC, he called to find out what was going on. A JASRAC official came by in person to explain: "The bands you hire have likely played covers of songs by other composers. We want you to pay the copyright fees on those songs."
"How many cover songs does this account for?" asked Kasugai.
"We don't know how many copyrighted songs were played here," the official replied. "So we are not charging for each of them. Instead, we are charging on a monthly basis."
Now stop and consider this for a moment. Let's say that bands playing there did, in fact, play cover songs. Well then - the audience heard a bunch of music which they might then be interested in buying. Instead, the morons from the music industry would like to ensure that only original music gets played (because that's what bar owners would do, rather than have to pay an extra fee). What' the end result of that? A less diverse range of music heard by the audience, which will result in fewer experimental sales.
The music industry has moved beyond protecting itself, and straight on to suicidal behavior.
It turns out that you can not only change font definitions in VisualWorks, but you can save those definitions out to disk and reload them. I've added some basic support for that to the development upgrade path in BottomFeeder. After you grab the update, restart - there will be a new menu option under 'System' that allows you to define and save fonts. I'll be modifying that to allow newly defined font definitions to show up in the (short) list of defined fonts on the settings page, but I haven't gotten to that yet. Stay tuned. A few caveats - the underlying support in VisualWorks for this is not complete - on some platforms you won't see a full list of all available fonts.
With the fall release almost in the bag, it's time to ask the community what's important to them. So, please fill out our latest survey and let us know what you think!
Here's a way that you don't want to start the day before Thanksgiving - you know, the day when your plan is to do a lot of prep cooking. My wife was going to head off to the gym, so I had to fetch the clean laundry from the basement - that's where all the clean bathing suits were. That's when I found today's nasty homeowner problem - basement flooding.
It's been raining, but not too heavily - so my first thought was some kind of leak. That wasn't the case, and it was unlikely anyway - we had installed a fairly large scale drainage system two summers ago outside. When I walked past the washing machine, the problem became clear - it had been on "rinse" all night (specifically, the fill portion) - and water was pouring out. Turning it off stopped any further damage, but there was water all over. For extra fun, the sump pump is on the other end of the basement, and the floor near the laundry area slopes away from it.
The water was maybe a tenth of an inch deep in places, so a pump was out of the question - $45 later I had a shop-vac. I sucked up the water while Jackie looked at the washer - which wasn't broken (a good break there). The upshot is, we now have scads of damp clothes to wash, and a potential mold problem to deal with. Lovely way to slide into the holiday...
One of the tensions that comes between Product Management and engineering is component importation. The people who build infrastructure would (generally) prefer to do the work in-house. No, it's not all an NIH problem - there's a rational reason for it. You need look no further than the current version of VisualWorks to see what I'm talking about. We've imported a bunch of tools over the last few releases:
- The Refactoring Browser
- The Professional Debug Package
- The ICC ADvance Tools
Now, look at the various inconsistencies in the menus, keyboard shortcuts (etc.) between these tools and things we've built internally (like the new inspectors and the workspace). That's the downside of bringing in third party tools - there's a fair bit of adaptation to make them "fit" with everything else (not to mention underlying framework issues that might crop up). On the other hand, doing all the work internally isn't an answer either - you get marvelously consistent tools, but they appear a lot more slowly. As to resource constraints - it's never easy to "just hire enough people" to build tools. There are constraints in any business, and Cincom Smalltalk is no different from any other here - we have to live within our means, just like everyone else.
So where does that leave us? I'm making this post in part to ask the community. Importing tools from the community into the product (even free ones) adds functionality quickly, but at the cost of adding inconsistency to the tools (and adding back-end cleanup work to our team's queue). Not importing tools has a cost as well - the question is, which way do you, the end users of our products prefer?
Scoble has hit on a key part of the disconnect between the entertainment industry (movies, tv, music) and the rest of us:
David told me that his friends in the movie business really don't like the long tail. They hate it, in fact. They hate that they can't manufacture a hit movie anymore with awesome marketing. They hate it that Steve Jobs, with Pixar, is kicking their behinds by making movies that people talk about in the word-of-mouth networks.
I see it in my aggregator. The Incredibles is STILL being talked about on blogs. Many of those blogs only have 10 to 100 readers. Maybe even less. But, that's where the profitability comes from. Every blogger that talks about a movie makes that movie more profitable.
I told David that blogs are only the tip of the iceberg. Blogs are only the part of the word-of-mouth networks that we can see. So, for every blog that talks about something, there are probably 100,000 conversations that we can't see. Blogs just give us a fuzzy picture of what really is being discussed person-to-person in IM, email, on the phone, or over turkey dinner tomorrow at Thanksgiving.
This actually explains a lot about the legal approach that they've taken to p2p. Instead of creating their own electronic markets (with price points that work), they have been trying to shut down the entire space - with intimidation suits and new law. What they want is complete control of the information channel, and they are in complete denial about the fact that it's impossible.
Young people just aren't interested in reading newspapers and print magazines. In fact, according to Washington City Paper, The Washington Post organized a series of six focus groups in September to determine why the paper was having so much trouble attracting younger readers. You see, daily circulation, which had been holding firm at 770,000 subscribers for the last few years, fell more than 6 percent to about 720,100 by June 2004, with the paper losing 4,000 paying subscribers every month.
Imagine what higher-ups at the Post must have thought when focus-group participants declared they wouldn't accept a Washington Post subscription even if it were free. The main reason (and I'm not making this up): They didn't like the idea of old newspapers piling up in their houses.
Don't think for a minute that young people don't read. On the contrary, they do, many of them voraciously. But having grown up under the credo that information should be free, they see no reason to pay for news. Instead they access The Washington Post website or surf Google News, where they select from literally thousands of information sources. They receive RSS feeds on their PDAs or visit bloggers whose views mesh with their own. In short, they customize their news-gathering experience in a way a single paper publication could never do. And their hands never get dirty from newsprint.
I have news for the media - that rationale goes beyond young people. It's why I stopped subscribing to newspapers a decade ago. I can get the NYTimes, the Post (and lots of other papers free in my browser - with updates coming at BottomFeeder hourly. These numbers (pdf) can't be encouraging either:
The Post experience merely mirrors the results of a September study (.pdf) by the Online Publishers Association, which found that 18- to 34-year-olds are far more apt to log on to the internet (46 percent) than watch TV (35 percent), read a book (7 percent), turn on a radio (3 percent), read a newspaper (also 3 percent) or flip through a magazine (less than 1 percent).
This is going to be a wrenching change for the media, and - thus far - they seem to be in denial over it.
It's a blustery Thanksgiving here, but we won't notice at all with the food we've got ready to go. Plenty of Turkey, stuffing, and other assorted goodies. Happy Thanksgiving to everyone!
I've got a solution on the blog that seems to be dealing with spam - I just discovered some attempted comment spam sitting in an archive folder - exactly where I expected to find it. I haven't had a serious issue with spam on this server anyway; I'm not running one of the well known blog systems like MT, so I don't attract as many attempts. Having a homebrew system seems to deter a lot all by itself, but the extra checks I've got in place seem to be catching the rest (so far).