Wednesday, March 30, 2005
The rich get richer ... no, wait, they're already there
As a former Republican, remaining Libertarian, and once and future entrepreneur, I'm all in favor of the government getting out of the way of business and letting it get its work done because I know, at least for small businesses, it's frigging HARD.
That having been said, the distribution of wealth in this country shows signs that, at least for some folks, success gets easier ... or perhaps even out of control:
"It looks like two straight lines, but it's actually an astronomically steep curve that shows just how inequitably income, and power, are distributed in the US. And Alternet reports that the curve for wealth (accumulated income) is much steeper even than the income curve shown above. Five million US households possess over 60% of the nation's total wealth."
This sounds like a clear instance of Murdock's Law: "Once you become infinitely powerful, it is easy to find a way to win the game."
-the Centaur
That having been said, the distribution of wealth in this country shows signs that, at least for some folks, success gets easier ... or perhaps even out of control:
"It looks like two straight lines, but it's actually an astronomically steep curve that shows just how inequitably income, and power, are distributed in the US. And Alternet reports that the curve for wealth (accumulated income) is much steeper even than the income curve shown above. Five million US households possess over 60% of the nation's total wealth."
This sounds like a clear instance of Murdock's Law: "Once you become infinitely powerful, it is easy to find a way to win the game."
-the Centaur
// posted by Anthony Francis @ 8:37 AM Permalink (0) comments
Friday, March 25, 2005
Da Stand
Ya know, as one of the head-freezing set I'm normally not one to critique bleeding-edge science. For example, I'm all in favor of the atom smashing going on at the Brookhaven Relativistic Heavy Ion Collider (RHIC), where they're smashing gold nuclei together at greater than 99.99999% the speed of light, in an attempt to create "quark gluon plasmas" ... that *just* *might* have less than an 0.00001% chance of creating a new big bang and destroying the universe.
Why am I not afraid? Becuase of ultra-high-energy cosmic rays, which regularly bombard the Earth's atmosphere with far, far more energy than we can make in our measly human particle accelerators.
So if the universe could end over something like this, it'd be ending all the time.
I don't have such a cavalier attitude towards the attempt to mix bird flu and human flu, in which "what health officials fear most about bird flu ... acquiring genes from a human flu virus ... is getting under way in a high level biosecurity laboratory."
Why does this worry me, when news that the Brookhaven collider might have been spawning black holes does not? It's simple. The mixing of genes between pathogens, while it does happen in nature, is rare and hasn't yet happened between avian and human influenza. So while I don't worry about something dangerous that MIGHT happen relating to a phenomena that DOES happen all the time, as at Brookhaven, I do get worried about trying to create something that COULD but DOESN'T happen precisely because you are worried that something bad MIGHT happen. If you're really that worried that avian flu and human flu might combine into a world-ravaging pandemic ... why are you trying to make it happen?!?
Now, in reality, I'm not saying stop work. By all means --- if they can figure out how avian and human influenza tick and develop a proactive vaccine, more power to you. But ... haven't these guys seen or read The Stand?
I'm not joking around here. Tom Clancy's Debt of Honor included (spoiler alert) terrorists crashing an airliner into the Capitol building in Washington, long before 9/11. Ignore the crazy conspiracy theories --- the point is that what happened at 9/11 should not have come as a great surprise to anyone. We should have been prepared for this from the getgo, because a known failure mode had been examined and exposed. Or maybe the larger point is that speculative fiction enables us to wargame possible scenarios and prepare ourselves to deal with them --- or avoid them.
True, you can't live your life based on what you read in novels. For example, David Brin's Earth presages the kind of work going on at Brookhaven ... illustrating graphically the disasters that might happen if a man-made black hole fell into the Earth's core. I'm not worried about this, because I know that at the size range of the black holes we might create, quantum effects will dominate over gravitational effects and the black holes would evaporate before it had a chance to eat anything. This mental model of physics is helps me understand what's going on at Brookhaven and gives me the confidence to give them a walk on what they're trying to do. SO while fiction can spark our imaginations, it can't replace thought --- we need to develop mental models of the situations at hand and apply them rationally.
This is precisely the same kind of mental model that I use for my work in artificial intelligence --- knowing what artificial intelligence is and how it works enables me to realistically gauge the risks --- creating a superintelligent machine, for example (a very low probability event!) --- and to take steps to mitigate that risk appropriately --- namely, don't put any machinery that can take human life in the hands of your intelligent machines (much less Mankind's entire collection of nuclear weapons, as people seem to want to do in the movies)!
This is not because artificial intelligence researchers fear a superintelligent machine taking over a la Colossus the Forbin Project or the Terminator. Quite frankly, we'd be tickled pink if a superintelligent machine showed up, but we're not holding our breath waiting. No, the reason you don't put dangerous machinery in the hands of intelligent machines is because of the far more realistic --- and realized --- fear that so-called "intelligent" machine will make a stupid mistake because of bad programming and hurt somebody because, in reality, the machines we can make are just not smart enough to take over the world --- they're not even smart enough to even realize what they are doing.
So. Perhaps the workers at the CDC combining the avian and human influenza strains have a similar mental model of epidemiology which enables them assess the risks realistically and structure their work appropriately. Let's hope so.
Otherwise...
We're very concerned.
-the Centaur
Why am I not afraid? Becuase of ultra-high-energy cosmic rays, which regularly bombard the Earth's atmosphere with far, far more energy than we can make in our measly human particle accelerators.
So if the universe could end over something like this, it'd be ending all the time.
I don't have such a cavalier attitude towards the attempt to mix bird flu and human flu, in which "what health officials fear most about bird flu ... acquiring genes from a human flu virus ... is getting under way in a high level biosecurity laboratory."
Why does this worry me, when news that the Brookhaven collider might have been spawning black holes does not? It's simple. The mixing of genes between pathogens, while it does happen in nature, is rare and hasn't yet happened between avian and human influenza. So while I don't worry about something dangerous that MIGHT happen relating to a phenomena that DOES happen all the time, as at Brookhaven, I do get worried about trying to create something that COULD but DOESN'T happen precisely because you are worried that something bad MIGHT happen. If you're really that worried that avian flu and human flu might combine into a world-ravaging pandemic ... why are you trying to make it happen?!?
Now, in reality, I'm not saying stop work. By all means --- if they can figure out how avian and human influenza tick and develop a proactive vaccine, more power to you. But ... haven't these guys seen or read The Stand?
I'm not joking around here. Tom Clancy's Debt of Honor included (spoiler alert) terrorists crashing an airliner into the Capitol building in Washington, long before 9/11. Ignore the crazy conspiracy theories --- the point is that what happened at 9/11 should not have come as a great surprise to anyone. We should have been prepared for this from the getgo, because a known failure mode had been examined and exposed. Or maybe the larger point is that speculative fiction enables us to wargame possible scenarios and prepare ourselves to deal with them --- or avoid them.
True, you can't live your life based on what you read in novels. For example, David Brin's Earth presages the kind of work going on at Brookhaven ... illustrating graphically the disasters that might happen if a man-made black hole fell into the Earth's core. I'm not worried about this, because I know that at the size range of the black holes we might create, quantum effects will dominate over gravitational effects and the black holes would evaporate before it had a chance to eat anything. This mental model of physics is helps me understand what's going on at Brookhaven and gives me the confidence to give them a walk on what they're trying to do. SO while fiction can spark our imaginations, it can't replace thought --- we need to develop mental models of the situations at hand and apply them rationally.
This is precisely the same kind of mental model that I use for my work in artificial intelligence --- knowing what artificial intelligence is and how it works enables me to realistically gauge the risks --- creating a superintelligent machine, for example (a very low probability event!) --- and to take steps to mitigate that risk appropriately --- namely, don't put any machinery that can take human life in the hands of your intelligent machines (much less Mankind's entire collection of nuclear weapons, as people seem to want to do in the movies)!
This is not because artificial intelligence researchers fear a superintelligent machine taking over a la Colossus the Forbin Project or the Terminator. Quite frankly, we'd be tickled pink if a superintelligent machine showed up, but we're not holding our breath waiting. No, the reason you don't put dangerous machinery in the hands of intelligent machines is because of the far more realistic --- and realized --- fear that so-called "intelligent" machine will make a stupid mistake because of bad programming and hurt somebody because, in reality, the machines we can make are just not smart enough to take over the world --- they're not even smart enough to even realize what they are doing.
So. Perhaps the workers at the CDC combining the avian and human influenza strains have a similar mental model of epidemiology which enables them assess the risks realistically and structure their work appropriately. Let's hope so.
Otherwise...
We're very concerned.
-the Centaur
// posted by Anthony Francis @ 7:33 AM Permalink (0) comments
Comments:
Thursday, March 24, 2005
if (u.assume()) { u.make(a$, u && me); }
So I'm writing a new sorting function for OIDs. What OIDs are is not important right now ... the important things are that they're strings that hold dot-separated sequences of numbers, like 1.3.6.1 (the Internet OID) and because the sequence of numbers is significant, OIDs cannot be sorted alphabetically (because 1.1 should be followed by 1.2, not by 1.10 as naive alphabetic sorting would imply).
Now, there's a lot to be done to update our software to sort OIDs correctly, but, being trained as an AI programmer, I started by breaking the problem down into its smallest possible parts --- namely, an OID comparison function. And, being a good modern Java programmer, I started with a JUnit unit test which enabled me to check my comparison function.
For those who don't know, JUnit tests are functions in a software module that all start with the word "test", like testLengthOneOIDs or testOIDsVsBlanks. Initially I just had a few handwritten tests - 1 is less than 1.1, which is less than 1.2, which is less than 1.12, which is less than 1.100 but greater than 1.2.1, and so on. These tests are complicated little stanzas of code, and being trained as a good AI programmer, I kept breaking things apart, writing a validateEquality and validateOrdering functions that automatically checked two OIDs for the right ordering. The idea, you see is that once I've written one correct test, I now have a tool to write many more correct tests, and don't have to worry about typos causing failures in later tests.
But still, there were dozens and dozens of cases to test. Then I had a brainflash: rather than writing a whole bunch of tests, one for each pair I wanted to examine, why not write an array with a list of OIDs in the right order (1.1, 1.2, 1.2.1, 1.10, 1.21, 1.30.1, etc) and then write a simple pair of for loops that test each one for the right sequence?
So I did. The outer loop went through every OID in the given list, and the second one went through every OID preceding it in the list to make sure that the comparison worked. That is, for three OIDs, the outer loop would go through items 1, 2 and 3. On the first loop, the inner loop would just go through item 1, but on the second it would go through 1 and 2, and then finally 1, 2, and 3, testing all combinations of OIDs.
SO I wrote that, as well as three or four lists of OIDs. And everything passed with flying colors. So I added that code to my OID utility library, built my sorter exploiting Java's wonderful Collections framework, and sorted the OIDs to call it good. It even ran smoothly at first.
Until I added some new code to do searches. This changed the list of OIDs feeding into my sorting algorithm and --- BOOM! --- Java compains that I'm asking for the fifth item of a four item list. Bad Java juju. What gives?
Well, it's simple. My cute little validateOrdering function should have been called validateLesserThan, because it implicitly assumed that the first OID it was given was lesser and the second OID was greater. However, that test doesn't test all cases of the algorithm --- to do a sort using Java's Collections framework, you need to generate a *numerical* comparision: the compare function is not asking whether a is less than b, true or false, but instead asking for the *sign* of the *difference* --- so that compare of (1,2) is -1, compare of (2,2) is 0, and compare of (2,1) is +1. This is the mathematical signum function.
My test was testing only lesser than and equality --- two branches, not the three branches of the signum. And, sure enough, when I augmented my validateOrdering tester to include a "desired result" parameter so you could specify you wanted lesser-than (-1), equality (0), or greater-than (+1) --- BOOM --- I found an error with my unit tester. When the comparison algorithm checked to see if "1.2.3" was greater than "1", it had an off-by-one error, assuming the second OID had one more element in its list than it actually had. So Java fall down and go boom.
So the POINT? Don't assume. It's a great idea to write unit tests, and an even better idea to make them comprehensive. But when you do so, think carefully about what you're testing --- make sure that you're testing all possible branches of the function at hand, or it may blow up on you later when some new --- possibly entirely unrelated function --- rips the rug of your assumptions out from beneath your feet of clay.
-the Centaur
Now, there's a lot to be done to update our software to sort OIDs correctly, but, being trained as an AI programmer, I started by breaking the problem down into its smallest possible parts --- namely, an OID comparison function. And, being a good modern Java programmer, I started with a JUnit unit test which enabled me to check my comparison function.
For those who don't know, JUnit tests are functions in a software module that all start with the word "test", like testLengthOneOIDs or testOIDsVsBlanks. Initially I just had a few handwritten tests - 1 is less than 1.1, which is less than 1.2, which is less than 1.12, which is less than 1.100 but greater than 1.2.1, and so on. These tests are complicated little stanzas of code, and being trained as a good AI programmer, I kept breaking things apart, writing a validateEquality and validateOrdering functions that automatically checked two OIDs for the right ordering. The idea, you see is that once I've written one correct test, I now have a tool to write many more correct tests, and don't have to worry about typos causing failures in later tests.
But still, there were dozens and dozens of cases to test. Then I had a brainflash: rather than writing a whole bunch of tests, one for each pair I wanted to examine, why not write an array with a list of OIDs in the right order (1.1, 1.2, 1.2.1, 1.10, 1.21, 1.30.1, etc) and then write a simple pair of for loops that test each one for the right sequence?
So I did. The outer loop went through every OID in the given list, and the second one went through every OID preceding it in the list to make sure that the comparison worked. That is, for three OIDs, the outer loop would go through items 1, 2 and 3. On the first loop, the inner loop would just go through item 1, but on the second it would go through 1 and 2, and then finally 1, 2, and 3, testing all combinations of OIDs.
SO I wrote that, as well as three or four lists of OIDs. And everything passed with flying colors. So I added that code to my OID utility library, built my sorter exploiting Java's wonderful Collections framework, and sorted the OIDs to call it good. It even ran smoothly at first.
Until I added some new code to do searches. This changed the list of OIDs feeding into my sorting algorithm and --- BOOM! --- Java compains that I'm asking for the fifth item of a four item list. Bad Java juju. What gives?
Well, it's simple. My cute little validateOrdering function should have been called validateLesserThan, because it implicitly assumed that the first OID it was given was lesser and the second OID was greater. However, that test doesn't test all cases of the algorithm --- to do a sort using Java's Collections framework, you need to generate a *numerical* comparision: the compare function is not asking whether a is less than b, true or false, but instead asking for the *sign* of the *difference* --- so that compare of (1,2) is -1, compare of (2,2) is 0, and compare of (2,1) is +1. This is the mathematical signum function.
My test was testing only lesser than and equality --- two branches, not the three branches of the signum. And, sure enough, when I augmented my validateOrdering tester to include a "desired result" parameter so you could specify you wanted lesser-than (-1), equality (0), or greater-than (+1) --- BOOM --- I found an error with my unit tester. When the comparison algorithm checked to see if "1.2.3" was greater than "1", it had an off-by-one error, assuming the second OID had one more element in its list than it actually had. So Java fall down and go boom.
So the POINT? Don't assume. It's a great idea to write unit tests, and an even better idea to make them comprehensive. But when you do so, think carefully about what you're testing --- make sure that you're testing all possible branches of the function at hand, or it may blow up on you later when some new --- possibly entirely unrelated function --- rips the rug of your assumptions out from beneath your feet of clay.
-the Centaur
Labels: Webworks
// posted by Anthony Francis @ 8:29 AM Permalink (0) comments
Comments:
Tuesday, March 22, 2005
The Revised Reading List
// posted by Anthony Francis @ 12:48 PM Permalink (0) comments
Comments:
Wednesday, March 16, 2005
Life is short. Train hard.
One of my friends from Taido, Camron Wiltshire, has started a new martial arts class in Little Five Points. Camron is both an awesome martial artist, a great trainer and a really cool guy, so you all should check it out!
// posted by Anthony Francis @ 11:46 PM Permalink (0) comments
Comments:
Back from Mars, Back to Work...
Morning Pages. Work. Class. Webcomic. Novel. Sandi. Research. Development. Sangreal. Reading. Drawing. Writing. Houseshopping. Packing. Treadmilling. Waiting for arm to heal so I can go karate-ing. Coffeehousing. Klatching. Whining. Blogging. Sleeping.
Repeat.
Repeat.
Labels: Mission to Mars
// posted by Anthony Francis @ 7:49 PM Permalink (0) comments
Comments:
One Small Victory
As I write this I've just reviewed a mountain of unfinished work from the MDRS: stacks of papers, unfinished reports, uncollated photos --- and even the essay I planned to write upon ARRIVING at the MDRS.
This, for me, was one of the Big Lessons from Mars: You Can't Do Everything. I should have learned this from my days as an undergraduate at Georgia Tech --- when the same lesson was called Sometimes You Have To Punt --- but you learn this in force on Mars, even analogue Mars. There are too many tasks and too few hours in the day and, more importantly, people who depend on you to get up the next morning and refuel the generator, cook the food, or join them on an EVA --- so you can't even cheat yourself by staying up late to finish Just One More Task. You have to set a time, get done what you can get done, and go to bed so you can get up in the morning and tackle the next day's tasks, which are coming fast and will not retreat.
There are other Big Lessons from Mars --- such as Everybody Has To Learn To Get Along, You Don't Need So Much Stuff, All Leftovers Go Good In Tomato Soup, Duct Tape Solves Everything, and Everything You Pour Down The Drain Will Reappear In the Greenhab (aka There's No Away To Throw Things To) --- but You Can't Do Everything is the big one. You have to gather your punch list, prioritize, and pick the most urgent tasks. And there's no time for anything else ...
... almost no time, that is. The truth is, there's a dozen short moments during the day in which you're neither too busy to do anything and not tired enough to do nothing, and in those moments you can sit around waiting for your EVA partner to find his gaiters or you can sweep the stairs, organize the battery drawer, or tackle any of a number of small tasks that need to get done but fall off the punch list. The little things. The fit and finish.
So I felt unaccountably proud when, after finishing my packing, I had a few minutes to myself --- and took that time to clean up the Habcom desk, which gave me the space to move the Medical books from a scrap of floor onto a real shelf, which in turn gave me a place to put our supplies of UHT soy, which in turn FINALLY opened up the space on the floor at the bottom of the stepladder. And so then, after over 10 days, I was finally able to dig out the missing bottom stair of the stepladder and screw that sucker into place.
*the sound of a line being crossed off*
And with that, I crossed a punch list item that had been hanging around since Crew 34 left. It's not much of an accomplishment, I admit, but it's still an accomplishment --- one small victory against the forces of entropy, even if only for a little while.
-the Centaur
This, for me, was one of the Big Lessons from Mars: You Can't Do Everything. I should have learned this from my days as an undergraduate at Georgia Tech --- when the same lesson was called Sometimes You Have To Punt --- but you learn this in force on Mars, even analogue Mars. There are too many tasks and too few hours in the day and, more importantly, people who depend on you to get up the next morning and refuel the generator, cook the food, or join them on an EVA --- so you can't even cheat yourself by staying up late to finish Just One More Task. You have to set a time, get done what you can get done, and go to bed so you can get up in the morning and tackle the next day's tasks, which are coming fast and will not retreat.
There are other Big Lessons from Mars --- such as Everybody Has To Learn To Get Along, You Don't Need So Much Stuff, All Leftovers Go Good In Tomato Soup, Duct Tape Solves Everything, and Everything You Pour Down The Drain Will Reappear In the Greenhab (aka There's No Away To Throw Things To) --- but You Can't Do Everything is the big one. You have to gather your punch list, prioritize, and pick the most urgent tasks. And there's no time for anything else ...
... almost no time, that is. The truth is, there's a dozen short moments during the day in which you're neither too busy to do anything and not tired enough to do nothing, and in those moments you can sit around waiting for your EVA partner to find his gaiters or you can sweep the stairs, organize the battery drawer, or tackle any of a number of small tasks that need to get done but fall off the punch list. The little things. The fit and finish.
So I felt unaccountably proud when, after finishing my packing, I had a few minutes to myself --- and took that time to clean up the Habcom desk, which gave me the space to move the Medical books from a scrap of floor onto a real shelf, which in turn gave me a place to put our supplies of UHT soy, which in turn FINALLY opened up the space on the floor at the bottom of the stepladder. And so then, after over 10 days, I was finally able to dig out the missing bottom stair of the stepladder and screw that sucker into place.
*the sound of a line being crossed off*
And with that, I crossed a punch list item that had been hanging around since Crew 34 left. It's not much of an accomplishment, I admit, but it's still an accomplishment --- one small victory against the forces of entropy, even if only for a little while.
-the Centaur
Labels: Mission to Mars
// posted by Anthony Francis @ 7:19 PM Permalink (0) comments
Comments:
Friday, March 11, 2005
Testing Offline Blog Clients
I don't go to GDC every year just to futz around hunting old books and new games. Well, maybe I do, but another purpose is science --- extracting information about the state of the science of AI and programming from the giant kettle of effort that is the Game Developer's Conference.
There are a lot of big ideas to come out of the conference --- for example, new games require huge quantities of content and thus new methods and tools are needed to help generate that content. Develop Orthogonal, Interoperable Tools is one pattern to deal with this --- build tools whose parts all work with each other cleanly and flexibly so that a small amount of art and content can be composed together rapidly in many combinations to produce a vast number of different results. The Unreal 3 team demonstrated this idea with their game engine, as to a lesser degree the Halo 2 guys did with their AI.
But this pattern goes hand in hand with Reduce The Cycle Time To Zero. I should have already known this --- my co-workers Henry and Emily and my former boss David Cater have been telling me for years that their biggest win was reducing the compile time loop of their development as close to zero as possible, so that they could make a change, instantaneously see the result, and then make the next necessary change as quickly as possible. Reduce Cycle Time To Zero is critical for rapid development of game content --- to be efficient, artists and level designers need to see the results of their work Right Now so they can make changes As Soon As Possible.
This is now writ large in the Unreal 3 engine, which supports dynamic loading of content and dynamic editing of levels in real time. Artists and level designers no longer need recourse to text files; instead you can wander around in the Unreal 3 world and make all your changes in real time. Move a light --- the shadows move real time. Grab a character by the arm --- see him move around like a rag doll. Tweak the parameters of a particle fountain used to generate a special effect --- watch it change in real time, affecting the lights and the players around it. Heck, it's not even just Unreal 3 --- in a recent Game Developer column the author was hacking together his own game by himself and even HE used dynamic content loading.
So. Reduce cycle time. I can do this. What's one of the biggest bottlenecks in my current development environment? Let's see ... the need to write my Blogger blogs online, or to cut and paste out of another text editor. Hm. How can we make that delay go away, so I can blog thoughts as I have them?
Perhaps with an offline blogging client like w.bloggar (or ecto or the client of your choice).
Let's test that theory. Saving and trying to upload NOW.
OK. So it's not perfect --- I found an error and reposted and ended up with two copies of the same blog. But hey --- it's SOMETHING to be able to use a normal-looking text editor and just hit a button to see it fly up to the server.
-the Centaur
There are a lot of big ideas to come out of the conference --- for example, new games require huge quantities of content and thus new methods and tools are needed to help generate that content. Develop Orthogonal, Interoperable Tools is one pattern to deal with this --- build tools whose parts all work with each other cleanly and flexibly so that a small amount of art and content can be composed together rapidly in many combinations to produce a vast number of different results. The Unreal 3 team demonstrated this idea with their game engine, as to a lesser degree the Halo 2 guys did with their AI.
But this pattern goes hand in hand with Reduce The Cycle Time To Zero. I should have already known this --- my co-workers Henry and Emily and my former boss David Cater have been telling me for years that their biggest win was reducing the compile time loop of their development as close to zero as possible, so that they could make a change, instantaneously see the result, and then make the next necessary change as quickly as possible. Reduce Cycle Time To Zero is critical for rapid development of game content --- to be efficient, artists and level designers need to see the results of their work Right Now so they can make changes As Soon As Possible.
This is now writ large in the Unreal 3 engine, which supports dynamic loading of content and dynamic editing of levels in real time. Artists and level designers no longer need recourse to text files; instead you can wander around in the Unreal 3 world and make all your changes in real time. Move a light --- the shadows move real time. Grab a character by the arm --- see him move around like a rag doll. Tweak the parameters of a particle fountain used to generate a special effect --- watch it change in real time, affecting the lights and the players around it. Heck, it's not even just Unreal 3 --- in a recent Game Developer column the author was hacking together his own game by himself and even HE used dynamic content loading.
So. Reduce cycle time. I can do this. What's one of the biggest bottlenecks in my current development environment? Let's see ... the need to write my Blogger blogs online, or to cut and paste out of another text editor. Hm. How can we make that delay go away, so I can blog thoughts as I have them?
Perhaps with an offline blogging client like w.bloggar (or ecto or the client of your choice).
Let's test that theory. Saving and trying to upload NOW.
OK. So it's not perfect --- I found an error and reposted and ended up with two copies of the same blog. But hey --- it's SOMETHING to be able to use a normal-looking text editor and just hit a button to see it fly up to the server.
-the Centaur
Labels: Webworks
// posted by Anthony Francis @ 2:50 AM Permalink (0) comments
Comments:
Happy Donuts Eases the Pain
I'm blasting through the San Francisco Bay Area for the Game Developers' Conference, my annual pilgrimage to the place where artificial intelligence is really used by people to really make things that people really care about. While out here I've seen a lot of good friends, including Victor and Steve and Neil --- and especially including the Rubrick, one of my Edge buddies from high school and college.
As we were chilling after great dinner at E&O Trading Company in the City, Derek was horrified to learn that I planned to track down to Menlo Park and hit Kepler's Bookstore and Barrone's coffeehouse. "Dude! Don't go down to the peninsula. Find something new in the city!" And I did --- I took half a day finding bookstores in the City like Stacey's and MacDonalds Books, digging through Rasputin's used record store, and scouring leather shops like Stormy Leather, Mr. S and Madame S looking for new clubwear.
But then it was time to go down to my old haunts ... Menlo Park. Palo Alto. Mountain View. It was too late to scour the Stanford Bookstore, so I hit NOLA's New Orleans restaurant just off University Avenue instead, then trolled up to Megabooks (alas, also just closed) and the mega-Borders (mmm, good philosophy bookness) instead. But this, too, must close.
But not Happy Donuts.
An incredible congregation of donuts, students, and WiFi, Happy Donuts has slowly evolved from a quiet little donut shop (circa 1997 when I lived here) into the premiere place in the Peninsula for late night information exchange. The donuts are good. The Wi-Fi is free. And they're always open --- 24/7. You tell me where the studious (and, from the conversation at the table across from me, some not-so-studious) college kids are.
And here, at last, I begin to catch up on my blog. Even with my camera's power down I can still document the experience because I carry a phone with me. Yes, Mister Christian, it's the 21st century: we may not be on the Moon, but I just took a picture with a dang phone:
If you're too young to have taken apart your parents' AT&T-standard T phone and then put it back together by hand, you may not understand, but I just took a picture with a handheld phone that looks an awful lot like a Star Trek communicator! Captain Kirk never had it so good!
Mmmm ... rich creamery technology goodness. As Homer Simpson might say: Happy Donuts eases the pain.
-the Centaur
As we were chilling after great dinner at E&O Trading Company in the City, Derek was horrified to learn that I planned to track down to Menlo Park and hit Kepler's Bookstore and Barrone's coffeehouse. "Dude! Don't go down to the peninsula. Find something new in the city!" And I did --- I took half a day finding bookstores in the City like Stacey's and MacDonalds Books, digging through Rasputin's used record store, and scouring leather shops like Stormy Leather, Mr. S and Madame S looking for new clubwear.
But then it was time to go down to my old haunts ... Menlo Park. Palo Alto. Mountain View. It was too late to scour the Stanford Bookstore, so I hit NOLA's New Orleans restaurant just off University Avenue instead, then trolled up to Megabooks (alas, also just closed) and the mega-Borders (mmm, good philosophy bookness) instead. But this, too, must close.
But not Happy Donuts.
An incredible congregation of donuts, students, and WiFi, Happy Donuts has slowly evolved from a quiet little donut shop (circa 1997 when I lived here) into the premiere place in the Peninsula for late night information exchange. The donuts are good. The Wi-Fi is free. And they're always open --- 24/7. You tell me where the studious (and, from the conversation at the table across from me, some not-so-studious) college kids are.
And here, at last, I begin to catch up on my blog. Even with my camera's power down I can still document the experience because I carry a phone with me. Yes, Mister Christian, it's the 21st century: we may not be on the Moon, but I just took a picture with a dang phone:
If you're too young to have taken apart your parents' AT&T-standard T phone and then put it back together by hand, you may not understand, but I just took a picture with a handheld phone that looks an awful lot like a Star Trek communicator! Captain Kirk never had it so good!
Mmmm ... rich creamery technology goodness. As Homer Simpson might say: Happy Donuts eases the pain.
-the Centaur
// posted by Anthony Francis @ 2:07 AM Permalink (0) comments
Comments:
Welcome to Mars
On practically my first night I did something I'll not likely do when on a real Mars mission: stand out in the rain at 3 in the morning holding a flashlight.
The purpose of the MDRS is twofold. First is science: the MDRS station, and the Flashline and upcoming Euromars stations as well, enable us to test our ideas about living and working on Mars. Part of this is "analog science": How to build a habitat. How to staff a habitat. How to do geology in a spacesuit. And another part of this is "real science": Studying supernovas. Studying closed-quarters reaction times. Looking for life on Earth in places similar to that we can look on Mars.
But the second purpose is just as important: culture. We are engaged in an ongoing psychodynamic experiment in which the Mars Society is learning how to staff a Mars habitat. What kinds of people work together well. What kinds of people work together poorly. And, as we found out, how people react to adversity. Now, we didn't encounter any polar bears at MDRS, nor did major chunks of our habitat litho-brake into the ground when their parachute failed. HOWEVER, we've still had our own little adventures.
I already told the story of how we had wrong directions and coordinates for the trip down to MDRS, about how I nearly got the truck bogged in the mud, and how he then took over as an experienced offroad driver to PROFESSIONALLY get the truck bogged in the mud up to its hips.
So we arrived at the station at approximately 7am, about 12 hours late from our original arrival time and 6 hours later than our revised arrival time (prior to finding out we needed to pick up supplies and drop off a generator in SLC before we left). What got left out of that report was that the Engineering Refit Crew was NOT done when we arrived and the Hab was a gianormous mess. I got the feeling that the Mars Society could easily have put TWO refit crews on site for FOUR weeks and still they'd have had plenty of stuff to do for the duration, and after talking to the refit commander, Paul Graham (not THAT Paul Graham, mind you), about what he thought needed to be done to the site, I think my original estimate is conservative.
So two of the refit crew, Paul Graham and Artemis Westenberg, stayed on with us for several days trying to help out with a number of issues. Hugh threw the whole crew, with a few exceptions for Dr. Broering who had to leave early, behind the refit. And on the last day, after a whirlwhind of cleaning, the major issues at the Hab (like having power, drinking water, and the ability to take a dump) were all resolved.
Except ...
On the last night they were scheduled to be there, Paul burned the midnight oil trying to resolve a few outstanding issues. This involved running conduits (smurf pipe), running wire, and working his ass off on the most important part, the water pump. During all of this I followed everyone around with my clipboard and digital camera, basically pretending to be a handheld computer as part of my information system assistant project (when my hands were not needed running the aforementioned smurf pipe). The hardest task was the pump: Paul and Kevin Saka and the rest of the team worked for hours getting it right --- the wiring, the fittings, the remote switch --- and finally they got it.
Except ...
We threw the remote switch at the end of the day, trying to feed enough water into the GreenHab to keep our recycler (and thus our toilet) alive. But no water ran. Paul cursed. It had worked before! And he's not one to leave a task undone. And I'm not one to let someone go out into the night at 3am alone in cougar country, even if he is a 6 foot 4 marine who can take care of himself. So I picked up Little Blue (my giant Brinksman flashlight), grabbed my "Indiana Jones" hat, and headed out into the dark with Paul to fix the water pump.
Which returns us to something you're not likely to do on a real Mars mission: stand out in the rain at 3 in the morning holding a flashlight. On second thought, maybe you ARE likely to do that on a Mars mission, if not in the rain holding a flashlight, but in the sandstorms wearing a spacesuit, helping a friend fix part of the generator or recycler or airplant, doing what you need to do because it HAS to get done or no-one will survive.
But you do it. It gets done. And because you do what needs to be done without hesitation, everyone survives.
Welcome to Mars.
The purpose of the MDRS is twofold. First is science: the MDRS station, and the Flashline and upcoming Euromars stations as well, enable us to test our ideas about living and working on Mars. Part of this is "analog science": How to build a habitat. How to staff a habitat. How to do geology in a spacesuit. And another part of this is "real science": Studying supernovas. Studying closed-quarters reaction times. Looking for life on Earth in places similar to that we can look on Mars.
But the second purpose is just as important: culture. We are engaged in an ongoing psychodynamic experiment in which the Mars Society is learning how to staff a Mars habitat. What kinds of people work together well. What kinds of people work together poorly. And, as we found out, how people react to adversity. Now, we didn't encounter any polar bears at MDRS, nor did major chunks of our habitat litho-brake into the ground when their parachute failed. HOWEVER, we've still had our own little adventures.
I already told the story of how we had wrong directions and coordinates for the trip down to MDRS, about how I nearly got the truck bogged in the mud, and how he then took over as an experienced offroad driver to PROFESSIONALLY get the truck bogged in the mud up to its hips.
So we arrived at the station at approximately 7am, about 12 hours late from our original arrival time and 6 hours later than our revised arrival time (prior to finding out we needed to pick up supplies and drop off a generator in SLC before we left). What got left out of that report was that the Engineering Refit Crew was NOT done when we arrived and the Hab was a gianormous mess. I got the feeling that the Mars Society could easily have put TWO refit crews on site for FOUR weeks and still they'd have had plenty of stuff to do for the duration, and after talking to the refit commander, Paul Graham (not THAT Paul Graham, mind you), about what he thought needed to be done to the site, I think my original estimate is conservative.
So two of the refit crew, Paul Graham and Artemis Westenberg, stayed on with us for several days trying to help out with a number of issues. Hugh threw the whole crew, with a few exceptions for Dr. Broering who had to leave early, behind the refit. And on the last day, after a whirlwhind of cleaning, the major issues at the Hab (like having power, drinking water, and the ability to take a dump) were all resolved.
Except ...
On the last night they were scheduled to be there, Paul burned the midnight oil trying to resolve a few outstanding issues. This involved running conduits (smurf pipe), running wire, and working his ass off on the most important part, the water pump. During all of this I followed everyone around with my clipboard and digital camera, basically pretending to be a handheld computer as part of my information system assistant project (when my hands were not needed running the aforementioned smurf pipe). The hardest task was the pump: Paul and Kevin Saka and the rest of the team worked for hours getting it right --- the wiring, the fittings, the remote switch --- and finally they got it.
Except ...
We threw the remote switch at the end of the day, trying to feed enough water into the GreenHab to keep our recycler (and thus our toilet) alive. But no water ran. Paul cursed. It had worked before! And he's not one to leave a task undone. And I'm not one to let someone go out into the night at 3am alone in cougar country, even if he is a 6 foot 4 marine who can take care of himself. So I picked up Little Blue (my giant Brinksman flashlight), grabbed my "Indiana Jones" hat, and headed out into the dark with Paul to fix the water pump.
Which returns us to something you're not likely to do on a real Mars mission: stand out in the rain at 3 in the morning holding a flashlight. On second thought, maybe you ARE likely to do that on a Mars mission, if not in the rain holding a flashlight, but in the sandstorms wearing a spacesuit, helping a friend fix part of the generator or recycler or airplant, doing what you need to do because it HAS to get done or no-one will survive.
But you do it. It gets done. And because you do what needs to be done without hesitation, everyone survives.
Welcome to Mars.
Labels: Mission to Mars
// posted by Anthony Francis @ 1:46 AM Permalink (0) comments
Comments: