February 28, 2004
Thursday in Muscatatuck
Matt and I took a Thursday journey down to North Vernon to do some bouldering in MuscataTuck. (3A0)
It was our first time there. The weather was a brisk high 40s but we were in the sun nearly the entire time. A pretty much perfect day. There was some easy climbing, some hard climbing, some shit "I'm too high off the ground", some bleeding and some pleasant satisfaction. (3A2)
More pictures: MuscatatuckLateWinterContents (3A5)
Eventually some climbing info: ClimbMuscatatuck. (3A6)
We're thinking about going often. (3A7)
February 21, 2004
So In Sand
A typically brief spurt of nicely mild weather gave Sabrina and I a chance to go walkies amongst some nice icy cliffs. (32E)
To the southwest of Bloomington the area's limestone karst gives way to sandstone hills. Near the town of Shoals the White River passes through these hills, creating the occasional cliff-line. (32G)
Several years ago Shoals was a fairly good place to do a little climbing. Nothing great, but given the lame offerings of Indiana, pretty good. Over time each of these regions fell out of favor. A visit to the most recently popular place, known as Hindostan, results in the occasional tire slash. (32H)
So people don't go there much anymore. (32I)
The Bluffs of Beaver Bend are on a parcel of Nature Conservancy land managed by the Indiana Department of Natural Resources. We had spied it the previous Saturday during a Valentines Day drive. It's a lovely place, but I had ulterior motives: I wanted to know if there's any climbing there. (32J)
Climbing on DNR land is big unknown for me. Anyone know? (32L)
We took along the camera to get pictures of what was there, for later reference and because we missed having when we were there prior. The whole set is linked from Shoals200402Contents. (32M)
Access issues abound with climbing around Shoals. Some of that info, along with pictures pulled in from the above collection at ClimbShoals. (32N)
We also met ShoalsLlama and a thing we think is TheDeadFox. (32O)
February 17, 2004
Learned Horror
ArthurSilber has posted part one in a series of articles he is calling "Roots of Horror": (2VF)
I have discussed these two stories to make one point above all: in our current cultural climate, people will do almost anything to distract themselves from the issues and the facts that ought to matter. The great majority of people spend almost all their time discussing issues about which it is close to impossible to obtain a complete version of the facts, issues which are largely irrelevant in any case -- when facts which are staring them in the face, and which carry unmistakably significant implications, are completely ignored. (2VG)
He appears to be headed in the direction of repression of childhood pain as the source of much that is ill in modern culture. I suspect there are ties between his ideas and the issues with learned helplessness, brought up by DavePollard, that I mentioned earlier. I'm curious to see where it goes. (2VH)
Idioms in Development
The following is part of a document I wrote to evangelize the value of layered idiomatic software interfaces to people at work who might be able to encourage this sort of behavior in the future. This versions leaves out some of the specifics of the project (creating a lightweight interface to the Knowledge Base). Much of it is speculative extrapolation and interpolation that needs a tune up. I welcome your tuning comments, (2UN)
Introduction (2UO)
Complex systems development is a synthesis of technical understanding, tool and language use, creativity and serendipity. Improved development processes can be achieved by enhancing and amplifying these areas. (2UP)
Little can be done, by definition, about serendipity. We can make room for it by not overcrowding development schedules, but beyond that luck is luck. (2UQ)
Creativity results from a synergistic pairing between an individual or team and their environment. People know when they are in the groove: they understand the tasks at hand, they have good tools and they have the skills to do what can be done. Creativity is enhanced by the presence of usable tools which make themselves present-to-hand on initial inspection but quickly become ready-to-hand with use, turning the user into a fluent creator. (2UR)
This document, in its subtext, describes how tools, when combined, are language; language that can be made more expressive through attention to grammar, idiom and reusability. (2US)
The SOAP interface to the KnowledgeBase (KB) developed for the Sakai Educational Partners Program demonstrates a style of tool use that may be beneficial to future KB development. The interface: (2UT)
- Attempts to be decoupled from the rest of the system. (2UU)
- Layers code to expose only that which is necessary, granting an idiomatic interface to behavior. (2UV)
- Places control into the hands of the developer and the client system (whether it be local tool or remote client). (2UW)
- Provides data in a flexible, but straightforward, standards compliant fashion. (2UX)
Coupling (2UY)
When object oriented programming reached the general public it was touted as the solution to many programming ills. At the forefront was the belief that objects, especially their ability to be inheritied, would allow and encourage reuse. (2UZ)
To a limited degree, especially in closed systems, this has proven to be quite true. However, over large systems, or throughout or between organizations, code reuse has proven a challenge because inheritance is a quite static and all or nothing function. (2V0)
Inheritance and its partner, complex object hierarchies, sets up a system of tight couplings between objects in a system. Small changes in one area can often imply large changes throughout the system, either to method signatures or data structures. (2V1)
Loose coupling is spoken of in two fashions: One is the management of strong contracts in code through the use the Interfaces. The other is through the use of separate services, especially web services, to provide an application. While the former is worthy of attention in the KB environment, understanding of such is left as exercise for the reader. (2V2)
A service based architecture for application development modularizes the various functions of an application into discreet chunks. Each chunk has a set of responsibilities and a well defined public interface that it presents to the rest of the world. Information sent in response to method requests should be as complete as possible and require little to no return to the service for continued operation. This results in an encapsulated environment (much like a robust object model, but on an action rather than object scale) wherein the details of the operation of the service can change without impacting the interface. The boundary between the service and the client is solid, permeable only in controlled and known ways. (2V3)
Traditional monolithic applications pass information within themselves, with little regard to boundaries between subsystems. If more information is required, a simple dive into the system is all that is required. While this is initially convenient, changes in the details of operation can have cascading effects throughout the system. (2V4)
Layering (2V5)
Walking hand in hand with coupling (coupled with coupling) is layering. Layering wraps an existing monolithic code base with interfaces to features that act as services. Code external to the wrapping layers can rely on the stability of the wrapper that hides complexity underneath. The layer itself deals with complexity, providing a simple facade. (2V6)
Layers play a primary role in the creation of idiom (we use idiom here to mean short turns of phrase in a language which capture a large body of meaning: a shortcut of large expressiveness) because they can be used to create a unified method that aggregates what traditionally have been multiple methods. For example analysis may reveal that the following set of methods is a common thing to do in the KB (for the KB programmers in the audience this is not meant to be accurate): (2V7)
my $search = new Search(); $search->doSearch($query); my $docids = getDocuments(); $docids = cullDomains($docids); $docids = cullArchived($docids); $docids = cullVisibility($docids, $visibility); my @titles; foreach my $id (@$docids) { push(@titles, Document->new($id)->getTitle()->getTitle()); } (2V8)
An idiomatic method of doing the same could be to provide a layer containing a doSearch() method that works as follows: (2V9)
%docInfo = KbIdiom?->doSearch($query); (2VA)
Idioms in software code are valuable because they perform two, somewhat opposite functions: (2VB)
- They allow one to express a great deal in a small amount of space by hiding complexity in a safe fashion. Safe because the inteface they use is well established. A developer using KbIdiom? can rely on the interface it presents regardless of changes elsewhere in the codebase because 1) KbIdiom? is a contract and 2) doSearch has a grammar which is simple and does not rely on the rest of codebase for its data typings: primitive or relatively primitive types are used. (Consider for example the issues that might occur if $query were a QueryObject? and the signature for constructing a QueryObject? changed.) (2VC)
- Idioms in code also do not prevent access to complexity. A truly flexible language must allow the speaker to get down to the fundamental core of the language to be able to express all that they need. Idioms do not simply detour complexity: they contain it, which means that complexity can be studied, understood, and used, if (and only if) necessary. It is important to emphasize this container notion: Idioms do not replace complexity and the power and flexibility that complexity implies. Complex systems are required for solutions to complex problems. Idioms in code hide, and provide a marker for, complexity, where necessary or valuable. (2VD)
The rest of the document goes into specifics on how the created tools help to achieve the desired decoupling and layering and the implications this has for implementing future services. I can provide some details on these things, upon requent. (2VE)
February 13, 2004
Courageous Thoughts
DavePollard is having the courage to say some unpalatable things about overpopulation: (2QJ)
I am increasingly and reluctantly coming to the conclusion that the only answer -- if there is an answer at all -- is coercive. Not in the political sense -- people are already doing all the unnatural things they can bear, and no political edict to reduce population could ever succeed. We must sabotage the system. We must run the careening SUV off the road before it crashes and kills us all. (2QK)
Drastic change is often far easier to think about than to make happen. There is usually a dramatic cost of some kind. For instances, one's free to be you and me shine beomes severely tarnished when considering solutions to overpopulation that might work. And any complex system has so many variables that it is hard to prioritize. (2QL)
A similar balance comes into play when considering "anyone but Bush in 2004" versus supporting the development and validation of third parties. (2QM)
Port 80 syndication
Apparently some folks are unable to reach syndication files (LiveJournal? folk, for example) on this server with their aggregators because of it all living on port 8000 and some tools (LiveJournal?, for example) not being willing to use "non-standard" ports. My good buddy Stan cooked up a nice little script that will proxy syndication requests through the soon to be doomed firewall box. (2QF)
will retrieve my RSS 2.0 full feed. If some other format is desired, please let me know. (2QH)
February 12, 2004
PurpleWiki 0.9.1 Released
I posted the following to a couple of mailing lists today. Figured I better copy it here. (2PQ)
I'm proud to announce the release of the latest version of PurpleWiki: 0.9.1. (2PR)
This release fixes several bugs, notably a problem with viewing previous versions of files, and adds a few new features: (2PS)
- Searching is provided by a set of pluggable modules that can be extended. Modules are provided for searching the wiki, bloxsom and MovableType weblogs, Google, Arts repositories and irclogs in wikitext format. (2PT)
- Support for WikiWhiteboards?. See http://www.xml.com/pub/a/2003/11/19/svgwiki.html (2PU)
- Transclusions can be retrieved as plain text in addition to the usual HTML and, if necessary, can be retrieved from sites requiring HTTP Basic Authentication. (2PV)
Additional bug fixes and features are listed in the ChangeLog?, which can be found at: (2PW)
http://www.blueoxen.org/tools/purplewiki/ChangeLog (2PX)
More information and links to the download can be found at (2PY)
http://www.blueoxen.org/tools/purplewiki/index.html (2PZ)
and at the PurpleWiki PurpleWiki: (2Q0)
http://purplewiki.blueoxen.net/ (2Q1)
If you are upgrading an existing PurpleWiki installation, there are a small number of changes you will need to perform, described in the UPDATE file in the distribution. New installations should follow the instructions in the README file. In either case please check the ChangeLog? file to see what's new. (2Q2)
If you are using PurpleWiki or interested in helping out with development please subscribe to the mailing lists described at: (2Q3)
http://purplewiki.blueoxen.net/cgi-bin/wiki.pl?MailingLists (2Q4)
The developers have already started on the 0.9.2. Features in the works (only some of which will make it into 0.9.2) include: (2Q5)
- Abstraction of the wiki page database (to eventually allow other storage formats) (2Q6)
- Support for WikiRPCv2? (2Q7)
- Server independent NIDs (to allow transclusions between servers) (2Q8)
- Better handling of the transclusion database (2Q9)
- Fully compliant XHTML output (2QA)
- Better syndication of RecentChanges (2QB)
- HyperScope? view driver (2QC)
- Template support (2QD)
- Improved documentation, better tests, cleaner code, and much more (2QE)
February 07, 2004
Idiom is Important
I've just returned from a lecture given by DouglasHofstadter? here at IndianaUniversity. The title was "Can Computers Understand Language? A ten-year booster shot against Searliomyelitis." (2LF)
Back in 1980 JohnSearle? published a paper, "Minds, Brains and Programs", describing the now famous ChineseRoom? problem. Hofstadter believes the paper is full of errors, wrong, and akin to a virus in the way it infects otherwise right-minded folk with poor thinking. (2LG)
Prior to the lecture I assumed Doug was going to give us a highly controversial refutation of Searle's thesis. I was prepared for an event--a painful inoculation. I didn't get that: at the end of the presentation simply asked that Searle and his cohorts lighten up and make room in their world for the simple idea that understanding of meaning exists not on an absolute black and white scale, but instead is a continuum on which progress--in the realm of computers understanding language--can be made: even if that progress thus far has been tiny. (2LH)
I can get behind that. However, I think Hofstadter made some generalizations that were convenient for his argument when not explored but disruptive when considered more deeply. (2LI)
When we ask if a computer is understanding language, we are asking more than whether it understands what we've said. A computer can give back reasonable responses to queries, so some kind of understanding is going on. The real question is: Do we believe there is meaning inside the machine. Are the symbols being manipulated by the computer related to "real things" with "real meaning". (2LJ)
Hofstadter asks the same question of humans. When a human uses symbols when are they associated with "real meaning"? If a person uses baseball idioms without ever playing baseball, do they have a right to use the idiom? People use the idioms and we understand them when they do, so meaning is transmitted in some fashion. (2LK)
I think Hofstadter misses the important question here. The question is not whether the idioms have meaning, but rather how do we know when a particular idiom is the right one to use? How do we judge or interpret the context in which we exist when we are communicating? (2LL)
Hofstadter seemed to imply, although he may not have intended to do so, that children are programmed in much the same way as computers. Children, he said, know the difference between abstract and literal because we tell them. An audience member disagreed with this, saying there was far more subjectivity involved in the human child's judgment when compared with the computer. (2LM)
The primary thrust of the criticism of Searle is that Searle's model of understanding is absolute, black and white and thus smacks of religious sacred-cowness. Hofstadter's alternative is a scale he calls semanticity from no understand to complete understanding. This is reasonable but it too has degree of absolutism. It assumes that there is only one dimension of understanding, and one ultimate peak of understanding which is the right one. We should certainly strive to improve understanding, and getting away from sacred cows is a good step, but let's not build another in the process? (2LN)
Finally, throughout the presentation I was constantly reminded of what I consider to be a very important distinction: Behavior that is based on rules, such as programs, no matter how complex, can be decoded, eventually, by stepping backwards (perhaps in multiple dimensions) through the rules that were used to generate the behavior. It may be that the behavior can't be repeated, because of randomness in the system, but it still can be described by what amounts to programs. It's an article of apparent faith in some circles of the AI and/or cognitive science worlds that the complex behavior of the human brain is theoretically describable. I find it advantageous to disagree with this, not because I'm attached to meat as the only possible source of real intelligence but because believing it makes us emphasize the wrong problems, which I hope someday to describe at ClassesVersusCategories?. (2LO)
Literary theorist should read more cognitive science. And vice versa. There's religion on both sides. (2LP)
February 06, 2004
How I Handle Email
The mailing lists associated with the BlueOxenCollaboratory have lately received a lot of mail. Participants have complained about the volume and their inability to cope in a productive fashion. This prompted JackPark to describe how he filters his mail. Others, including me, followed up with their own strategies. What follows is a revision of what I posted to the mailing list. (2KH)
I'm posting this to the blog because I'm sick of people whining about email volume when it is clear they've made no investment in managing their email. While it may be true they shouldn't have to, the flip side of that argument is that I feel like I shouldn't have to clean my house, but I do it anyway because I want to live there. (2KI)
My strategies for dealing with email are dependent on a luxury of resources. I have a fast connection, my own mail server and (for the most part) the skills to manage it. Someday I may distill my thoughts on why I think everyone should be in charge of their own presence on the internet and why it should not be mobile (the interfaces should be). (2KJ)
I like to think of myself as an email handling expert. I don't know if this is warranted or not, but as a former sysadmin I used to handle upwards of 10,000 messages a day in some form or other, most of it automatically, while still handling several hundred to my face, per day, and generating about 2000 outgoing messages per month. (2KK)
I don't do that sort of thing anymore, so the quantity of email is way down, but the skills learned then make life better now. (2KL)
First off, information handling is not an arena where the poor craftsperson may blame their tools and be scorned. Most, if not all, email clients suck. Some just suck less than others. Many are good for email browsing (I generally use Apple Mail for casual browsing these days), few are good for email processing (replying, deleting, searching, filtering, moving). I've yet to meet a GUI mail client that is good for email processing. (2KM)
My environment: (2KN)
- An IMAP server with essentially unlimited space (I can add disk if I want to) (2KO)
- shell access on that server where I can maintain procmail, Spam::Assassin and filters of my own design. (2KP)
- Pine, on multiple machines, accessing a remote configuration (over IMAP) (including addressbook) stored on the server, configured to allow URLs to open in my browser, and images and other attachments to open in the correct application. (2KQ)
Pine provides a feature that allows you to have multiple INBOXes. This is different from having multiple folders to which mail is delivered. In the latter, I have to remember, think about and act upon selecting these special folders. In the former, when I get to the end of one INBOX, I may, at my option, continue to the next one with a single keypress. (2KR)
Incoming mail is filtered at many stages before it sees me: (2KS)
- Every message is copied and stored in a backup folder for that day. I keep 4 days of backups. (2KT)
- Spam::Assassin scores the original message as spam. If the score is high, the message is deleted. If the score is middlin' the message is stored in a trash folder (which is an INBOX, because I'm curious about spam, it entertains me and gives me an eye on the zeitgeist). (2KU)
- Automated messages to root and other service accounts are filtered to an INBOX for such things. (2KV)
- Email to lists in which I participate are filtered to INBOXes associated with that group. Some busy lists, associated with groups in which I do not have immediate cares or responsibilities, are not filtered to an INBOX, but rather a standard folder, so they are not in my face all the time. (2KW)
- Anything left after all this is sorted as follows: (2KX)
- It is checked against a personal blacklist filter and trashed if it is from an address in that blacklist. (predates spam assassin and still catches some other things) (2KY)
- If it is not addressed to me (I'm identified by one of several email addresses) it goes to an INBOX called filtered (2KZ)
- It is checked against a personal "do I know you" filter. If I know you, the mail goes to my primary INBOX (the first in the list of INBOXes). If I don't know you, the message goes into my secondary INBOX. (2L0)
My process of reading email is designed to avoid gaffes such as providing an answer to an email that has already been answered or that landed in a different INBOX for some reason. (2L1)
Rules for reading email (2L2)
- Read everything (all INBOXes) before responding to anything, deleting irrelevant or redundant messages as possible. If I delete something incorrectly I always have the backup and any mailing list that isn't broken has an archive (this should be emblazoned on high somewhere). (2L3)
- Check for new mail in all INBOXes again, still, before responding. This is easy to do because I can simply hit <tab> and that will take me to the next new message in any INBOX. (2L4)
- Respond or otherwise process stuff in my primary INBOX. This assumes that if it is in there it is from somebody I think is special in some form and the message needs primary care. (2L5)
- Check for new mail (press tab). (2L6)
- Go to the INBOXes associated with work or projects and process stuff there. This assumes that any work or project related email should go to a group mailing list, or to put it more brashly: any work or project team without a group mailing list (that is archived) does not exist, is fundamentally broken. (2L7)
- press tab (all day long) (2L8)
For those few folders which receive new mail but are not INBOXes, visit them as time allows, read everything (or at least skim for relevancy), delete as much as possible. What's left is stuff worth dealing with. Deal with it. Delete once dealt with: there's an archive out there somewhere. If not, and it's important, refile. (2L9)
Any folder that has incoming mail that has more than 20 messages in it is a problem that needs to be dealt with, soon. (2LA)
I have pine configured to use roles. That means that I can have it automatically use the blueoxen.org address when I respond to mail to a blueoxen list. Or indiana.edu for work stuff. I get different sigs and other fun things like that. (2LB)
I use vi as my editor, rather than the built in pico. This is because pico sucks most of all. I use vi because I am faster with it than I am with emacs. (2LC)
I'm, these days, generally using Pine in an xterm under X11 on Panther. Sometimes I'm using Pine directly on the mail server through an ssh client. Those times that I use Apple Mail are generally in the morning when I'm feeling a little blearly and I have no intention of responding to anything, I just want to see what's there. If I discover something to which I need to respond, I quit Mail and start Pine so I can be back in the fast realm of the keyboard. The mouse is handicap unless you also happen to have a chording keyboard (thought about it, too much money). (2LD)
What do you do? (2LE)
