python/ConsideringCommandRegistration written at 23:38:03; Add Comment
Thinking about the best way to handle command registration
Suppose that you have a Python utility program that does a number of
related things; it's invoked as '
Since I have been writing such a utility program, I have found myself wondering what the best way of doing this is (where 'best' means 'most natural, obvious, and easy to follow'). So far I've come up with a number of possible ways:
Naturally you can combine aspects of all of these together to create hybrid systems (for example, using the function's docstring for some of the user help text).
Of these, I suspect that the decorator function approach is the most Pythonic but is also the second hardest for people who are not experienced Python programmers to follow (introspection would probably be the hardest). Since that last issue is a consideration, I am leaning towards using the plain registration function approach.
(My current code mostly uses the simple dictionary approach, but it's not the clearest thing to follow.)
web/WhyCommentsLessAudience written at 01:59:18; Add Comment
Why your blog comments have less of an audience than new blog entries
Expanding on a remark in the previous entry: I think there are several reasons why your comments are likely to get less of an audience than new entries. First, in most blog setups new comments are less obvious to readers than new entries, as your readers have to go back by hand to look for them. This is especially so if people are only interested in a few comments.
It's possible to work around this with a different blog layout, but it does mean a moderately radical change from how people think of blog front pages and so on. I suspect that it would work better for a blog that already mingles quick links with regular articles, and I think you would want to promote only some of your comments this way, because many quick comment replies require too much context.
Second, I think that many comments are intrinsically less interesting than a new entry, because they are effectively expanding on some aspect of your original entry. They are thus for people who are so interested in the topic that they want even more, and not as interesting to people who were satisfied with your original entry in the first place. This isn't always the case, but to the extent that your comment replies are of general interest, you might as well make them full entries.
(And some comment replies are only going to be interesting to people who read the comment that you're replying to, since they're just correcting or reacting to those comments instead of expanding on your original entry.)
web/CommentTimeUsage written at 01:54:17; Add Comment
Another reason to avoid having comments
To go with my previous thoughts about the purposes of comments, here is another reason that people might want to not have them on their blog: they eat your limited time.
In a sense, comments on your blog carry with them an implicit duty to reply; while you can skip this, it may look odd and cause bad reactions. However, comments that you write will probably get less of an audience than a new entry. So if you only have a limited amount of time to write things for your blog, your time is better spent not having comments and just writing entries.
How true this is depends on how much of your time writing comments takes up. While many comment replies can be written quickly, I think that sooner or later you do run into comments that need about as much work as an entry. Sometimes those can be turned into actual entries (I do this a fair bit, although that's partly an interface issue), but not always; sooner or later you'll get comments that need replies that are too specialized or not interesting enough to make decent entries.
(This also ignores the time required to moderate comments, getting rid of spam and other undesirable things. Depending on the nature of your blog, this may be a significant time sink itself.)
* * *
Atom feeds are available; see the bottom of most pages.