July 31, 2005
Some Weeks, Some Pictures
July has been pretty busy. Flickr has been my diary and it is likely to remain so. If you're trying to keep tabs on me maybe you should subscribe to my photostream? (PSS)
Early July I was in Palo Alto for a Socialtext all hands meeting. There was fun, learning, planning and most importantly: adventure. (PSU)
At the end of that I was lucky enough to hook up with Bloomington ex-patriates Scott and Rachel for a dash to Yosemite, which is one of the churches of my religion, also including Mt Rainier. (PSW)
It was much too hot for anything in Yosemite, but we did manage to climb two routes. I don't know their names or what area we were in. One was a terrifying near vertical, runout, bolted slab, somewhere around 10a or b, which I manage to onsight despite the burning in my hands and not knowing where the anchors were. Next was a top rope attempt on a 10c finger crack that Scott led. I eventually had to batman past the crux and into the section with good hands. I sweat away all my water, and soon fell asleep for two hours. (PSX)
I was back from California for a bit more than a day and then left for my sixth annual Lake Cumberland boat trip. Dr. Surly, who rescued me from near death mere inches below the surface has his version of events. The lake was beautiful this year and a very fine time was had, despite the usual technical difficulties. (PSZ)
Finally returned to Seattle, the month is nearly over, and I find parrots have invaded the neighborhood. This is exciting news to SB and me, and a case of "oh yeah, they're here every year" from the neighbors. (PT1)
The coming week I'm away at OSCON in Portland. If you're going to be there, let me know. (PT2)
| bl
| Categories:
journal
July 19, 2005
Links: 2005-07-19
- Presence? Mark Me Absent
I too wish to hide
Posted: 2005-07-19T16:41:29Z (categories: ftr presence )
July 18, 2005
Links: 2005-07-18
- Ross Mayfield's Weblog: The Things we Forget
Need to respond to this about the middle ground.
Posted: 2005-07-18T21:47:59Z (categories: blogthis engelbart ftr wikis )
July 09, 2005
Fridge as Philosophy of Everything: A Manifesto
Someday I'll rewrite this so it makes more sense. (PRC)
Summary (PRD)
If you lose track in the ramble below, here's the summary: Architect your hardware, your software and your life so your environment helps you out and you don't have to waste your brain deciding on things that shouldn't need deciding. (PRE)
The Meat (PRF)
In a conversation (in IRC, I haven't met Ryan yet but will next week) yesterday with my coworker Ryan, I was trying to convince him of the value of a service oriented architecture in systems design. While not entirely resistant to the notion, Ryan felt perhaps I was trying to impose needless boundaries that didn't provide any gain. So I tried a metaphor I've used before: (PRG)
part of the goal in having a multi-piece/service sort of solution is so you can write giant swaths of code that you then forget about for the rest of time (PRH)
because it is, in effect, encapsulated (PRI)
not in the dogmatic oo sort of way, but in the it's a refridgerator we never have to think about it kind of way (PRJ)
rking: you have a fridge, yeah? (PRK)
do you ever think about it? (PRL)
it does one or two things: it keeps food cool or frozen (PRM)
if it breaks you buy another and put your food in the new one (PRN)
you can do just a few things with the fridge: you can put some food in, you can take some food out (PRO)
smart soa is about creating systems of fridges, both in terms of your code and your hardware (PRP)
systems that are easy to replace, easy to maintain, and dramatically simple (PRQ)
My earlier uses of the fridge metaphor described hardware systems, not software systems. In the physical world the metaphor mapped nicely, but it seems to map just as well in the abstract world of software and maybe getting things done as well. (PRR)
If you have the fortune to live in the modern developed world you probably have a fridge and you probably rarely think about it. When you go to the kitchen you have a goal that's not directly related to the fridge. You're hungry or thirsty and want to change that situation. In the kitchen (the context of your experience) there is a suite of tools and appliances to help you achieve your goal. Tools like knives and forks augment you by extending your existing capabilities. Appliances like fridges automate certain process you either cannot or do not want to do. Elegant tools and appliances, like knives and fridges, do a small number of things (cut food, chill food) and present a small number of clear handles or activities for doing those things. (PRS)
My earliest experience with a fridge metaphor was as a system administrator at Kiva Networking. We had the time and resources to create a collection of systems, each performing just one service, taking a small number of inputs and providing a small number of outputs. We put them on the network and if we were lucky, forgot about them while they serviced several thousand users. (PRT)
We didn't call them fridges then. That happened with the re-architecting of the presentation side of Indiana University's Knowledge Base. A small army of cheap replaceable Debian boxes provides just one service: the front end to the KB. Boxes can be automatically installed and added and removed from the network. (PRU)
Small cheap front ends to data services is nothing new and the reasoning for it is pretty solid and well accepted. It's harder to convince people that we should use the same logic for building software and maybe managing our lives. (PRV)
In the software realm people develop a resistance to a fridge or service oriented mentality because some people have made those notions synonymous with the wordy, dogmatic, heavy-seeming worlds of multi-tiered Java and the mess of the WS-* standards. (PRW)
It doesn't have to be like that. You can be service oriented by having and using components that present narrow interfaces, provide simple and predictable outputs, are easily layered, and (ideally) are location independent. That's it. Nothing's being said here about SOAP, or REST, or J2EEE. Perhaps we perceive those things as noise because they are insufficiently mature? Imagine the noise if a detailed knowledge of how a computer worked at the electronic level was a requirement for use? (PRX)
What matters is the analysis that lets the designer or developer decide the points that are the boundaries between or chunks of automatable activity in the system. That is, which parts of the system can be described by theory given known inputs and require no additional inputs. For example, a wikitext to html formatter can be an independent automatic system given inputs of wikitext and perhaps a list of existing pages in the wiki system. We can reliably predict the output of the formatter, knowing the input. (PRY)
We cannot, however, know the input, so gathering input is a process that is augmented by presenting an interface to the outside (to the user through some system). We may know, given a certain set of circumstances which interface to present, but we don't know what the user will type. (PRZ)
A wiki formatter is a service we might wish to reuse or layer. Because we can know what it will take in and what it will put out, we can layer and reuse it in a relatively straightforward fashion. (PS0)
We can make it a fridge. Once that is done, it is possible to stop worrying about it, and move on to the harder and/or less predictable aspects of the system where being smart is required. Places like making an effective user interface or innovating a new exciting feature. (PS1)
Until the things that ought to be fridges are turned into fridges, they occupy an overly large segment of thinking in a developer's activity. There's a lack of foundation. Imagine how it would be if every time you wanted to eat you had to evaluate the fridge to make sure it is working correctly. All day long you would sit at work wondering, "Has the milk gone off? What am I going to do about dinner." (PS2)
Properly made fridges remove fear and uncertainty. (PS3)
Fridges do create boundaries, but those are a form of constraint that act as a form of external cognitive aid. The boundary lets you know what you don't have to think about: it keeps you in a limited space, focussing your thought on what matters in the current context. The boundary also lets you know what you can think about (related to the fridge): the boundary encapsulates a known and predictable space. You are not removed from your context: the fridge is contained, but not you. Constraints help you think about the stuff you need to think about. (PS4)
Spacing Out (PS5)
Hardware and software design don't matter much and do not a manifesto make. What's going on in the background here is a recapitulation of Doug Engelbart's (and others') ideas about augmentation fed through a filter of Landauer's descriptions of the differences between automating and augmenting systems. Those ideas are generally used to describe technical systems, but are really a way of looking at life. (PS6)
We waste a lot of time making decisions that don't really matter. A monk creates space for contemplation by automating away much of their life into a rigorous routine of daily sameness. Our liberty is experienced in the decisions we make that feel relevant. (PS7)
So how do we, and should we, figure out how to identify and automate into a fridge like state those decisions and concerns that aren't particularly relevant so as to maximize the experience of being relevant? There's more to it than being like the monk, but there's something there: routinize those things for which you almost always choose the same thing. Sure there's a cost to such behavior, but why waste time in the existentially alienating experience (for me) of wasting time choosing between a host of nothingness. (PS8)
Engelbart's goal, all along, has been to figure out ways to solve the complex and urgent problems that face the collective we. Automate (only) those processes which can be correctly automated, and augment (place tools at your hands to navigate the gaps between automated processes) the others, removing the irrelevant, so as to approach problem solving as effectively as possible. (PS9)
Automating and augmenting must involve a constant process of review and re-composition of the pieces that make up the system: When some collection of variables has become, after rigorous investigation, deterministic, you may, at your option, turn the system into a fridge and remove it from your concern. But only if you know the inputs. Most of the time you don't. (PSA)
At the individual level finding the meaningful life is a problem to solve. If I make some fridges, I might find some additional relevant space. Room to breathe and think and do what matters. (PSB)
Apologies to those who can't stomach geeking out about software and hardware with geeking out about life or take too seriously taking everything too seriously. Everything everywhere is a metaphor and it's all analogies to be learned, compared and connected. We want to remove fear and uncertainty in life at least as much as we want to remove it in software development. We want to think effectively about all sorts of problems. (PSC)
Thanks to Dave Rolsky and Ryan King for recently stirring this pot and providing some ideas and to Joe Blaylock, Kevin Bohan and Matthew O'Connor. (PSD)
| bl
| Categories:
philosophy
July 06, 2005
Links: 2005-07-06
- The Social Fabric
pda based social fabric management design
Posted: 2005-07-06T16:43:39Z (categories: innovation ) - lists:thingsyoucandowithrss [DokuWiki]
Nice list of things to do with rss
Posted: 2005-07-06T00:52:43Z (categories: ftr rss )
Everybody needs an angel
I spent my 4th up near Mt. Rainier, as some kind of I hate you America gesture, but I guess it wasn't that at all. The America I found on the mountain I like. (PR6)
Idolatry and patriotism do not a happy Chris make, so I hied off to the mountains for sun, sweat, solitude and photos. (PR7)
Flickr has the rest of the pics. (PR9)
I'd be riding horses if they'd let me Sleep outside at night and not take fright I would ride the range and never worry I would disappear into the night (PRA)
| bl
| Categories:
photo
July 03, 2005
Installing a Purple Numbered Kwiki
Kwiki-Purple, a project to implement most of the featurs of PurpleWiki in the Kwiki wiki framework, is far enough along to be worthy of some experimentation. I've put up some installation instructions. (PQO)
The latest trick is a networked shared supplier and indexer of purple numbers (the sequence) that allows content on a kwiki on one server to be transcluded on another server. It's a bit slow, but is fun, interesting, and possibility revealing. (PQP)
| bl
| Categories:
kwiki
