Thursday, June 26, 2008

Maintenance club

Let's say you need to have a car. Maybe you have a job or something. Much of the cost of the vehicle is in the purchase price. One way to reduce the purchase price is to buy vehicles used. Another way is to own them longer. Either way, you have a vehicle that requires more maintenance. Need a reliable car? Have more than one. Since used cars often cost a tenth of new cars, you may be able to afford several.

I know something about that. I've changed an engine, fixed brakes, and so on. But i have a car in my garage that needs work, and i'm not doing anything about it.

But let's say you know nothing about car maintenance. What do you do? You need help. Get together with someone like me who knows what they're doing. You get help. But what do i get?

I've come to the conclusion that working on cars would be more fun, and therefore actually happen, if i had someone to do it with. So the great idea is the maintenance club. Each club member has some junk car. A club 'meeting' consists of descending on a club member's car for a few hours to achieve some goal. Everyone's junk gets some love in a sort of rotation. Maybe one of the junks is a '48 Chevy restoration project, or a 60's Jag.

But the thing that makes it work isn't that you get your car fixed. The thing that makes it work is that it's a social event. Bring out the pizza and beer, if that's what it takes.

Tuesday, June 24, 2008

Mortgage basics

I just read a two part bit on how mortgages work. This guy often talks about math or programming things that are esoteric and difficult. Worth the time to read, if the time can be had. And, most of my blog reading is about science. These two posts, but especially the first, are really easy to read. There's an error in the formula, but the example is right. It should be

Payment = P*(i/1-((1/1+i)^n))

where P is the Price of the house - or really the money to borrow, i is the interest rate: 0.0575 for 5.75 percent, and n is the number of payments - 360 for a 30 year mortgage. There are rounding issues, so this should be considered approximate. Payment is the payment per period, which is per month for most mortgages.

I learned that i accidentally picked a pretty good mortgage, and then five years later, did a pretty good refinance to lower interest rates. I made some very small mistakes (maybe tens of thousands of dollars), but have recovered from them, mostly in the refinance.

This is Detroit. A friend's folks died last year, and left him and his siblings a house. They all own houses, so they put it on the market. A year later, it's still on the market, but at less than 20% of what they'd started it at. It hasn't sold. Calling it a buyer's market is generous. It's foreclosure city. I assume it's impossible for at least three to five more years to sell my house.

But the banking industry is so greedy that they may have provided me an out after all. It used to be that getting a second mortgage was a last resort sort of thing. But now, banks are trying to sell these loans as "using your equity". And, they're quite aggressive about it. So, perhaps, i could suck all the equity out of the house as cash, and walk away from the house. My equity is probably enough to buy a similar nearby house (perhaps in foreclosure) outright. No loan of any kind.

Mark's articles talk about how there is a conspiracy in the finance industry. Short term profit greed drives it. But there seems to be something similar in the automotive industry. Why sell small affordable, high efficiency, low margin cars, when large high margin vehicles are selling? In fact, offering any small cars at all will just encourage people to buy them. Chrysler sells cars with hemi engines (big powerful engines). GM sells the Hummer. Ford sells the F-150, which was a small pickup when i was a kid. Then, gas went over $4 a gallon and for some reason people don't want to put $100 of gas into their tanks at a time. In the course of a month, gas hogs have gone out of style.

OK, so Ford has the Focus, a 4 door sedan, which if equipped with a 5 speed manual probably can get the kind of gas mileage that my car gets, assuming you drive it the way i drive mine. And sales have skyrocketed. They can't keep up with demand. This is a real problem. It takes awhile to get the pipeline moving. But the demand for the F-150 has dropped to the floor. Even luxury car sales have dropped. What's a Ford to do?

So, the automakers, not just Ford, have claimed that they didn't see this coming. Ford's solutions (available in Europe) won't be available in the states until 2010. That could mean summer of 2009. Chrysler made some investments last year that might pan out around then. GM makes noises, but i'm still waiting for product. This, despite the fact that my car was made in 2000 by GM. As far as i can tell, they don't sell it now.

But from my perspective, the idea that gas will go up isn't news. Maybe i was driving three times as far as anyone else, and so i noticed it sooner. But it was important to me twenty years ago. Well, total cost is also important. In a year, i'm currently spending $3,500 on gas, $800 on insurance, under $1000 on maintenance, and zero on amortization for my fleet. That's $5300 for 35,000 miles, or about 15 cents a mile. That's a quarter of what the government thinks people spend. Actually, it's less than that. My Saturn has increased in value, and maintenance has been much lower. But it freaks me out that i'm paying over a dime a mile. It's 60 cents to go to the grocery store. So i go on my way home from work, saving 60 cents.

Sunday, June 22, 2008

Can we go to a moive?

This weekend, i've been treating my son to several movies. He's been away at music camp. We went to see Get Smart, by accident. I can't read the ticket with my contacts in. I'll bring my reading glasses next time. So, it was theater 8 instead of 7. We'll have to see Indiana Jones later.

But he asked me if we can see The Happening, which is listed as Action/Adventure, Thriller and Politics/Religion, and rated R for violent and disturbing images. The trailer makes it look like deeply disturbing horror. I said, "no", and not just because it's rated R. I like to sleep at night too. He said, "Good".

Thursday, June 19, 2008

When i got the car, i looked it up in Kelly Blue Book and found that it's retail value was $1,450. I've put 70,000 miles on it, so i expected it's value had migrated towards zero. But one of the guys at work suggested it should be worth something. I looked it up again. It's now worth $3,560. That's right. I put 70,000 miles on it, and it's value has increased by two grand. I attribute this to increased fuel prices.

I talk about how cars don't have investment value. And you might think that this is a windfall. However, the car still works, and replacing it with something that gets as good gas mileage is unlikely. So it's not for sale.

I just did invest something into it. I bought a new windshield. Apparently it's not legal in Michigan to drive a car with a windshield cracked all the way across. It really wasn't much of a bother, as the crack wasn't quite in my direct line of sight. Still, i was never able to clean the inside of the windshield fully, probably a smoker in it's history. For now anyway, it's really clean.

But back to Michigan. No inspections in this state. So if you get pulled over, for anything, they notice your windshield and ding you with an extra fine. I got away with having to replace it, and going to a police station to have them sign off that i'd gotten it done. So, i got the windshield replaced right away. I'm really bad at the administrative stuff, but i did manage to get the signed ticket in the mail before the deadline. Also, the new windshield was cheaper than expected. Only $160 installed, with tax & everything. Still, it'd be nice if they gave you a list of what you need up front, like when you register it. I consider air conditioning to be more of a safety item in the summer than the cracked windshield. But i bet that Michigan doesn't care if you have it, or if it works. And so on. The windshield was number #3 on my priority list of repairs to do.

Tuesday, June 17, 2008

Acceptable Addiction

It's funny what is acceptable and what isn't. If it isn't acceptable to say that you're an alcoholic even on the wagon, it is acceptable to say that you're a caffeine addict on or off the wagon. What's the difference? You never get over either. Addiction actually changes the wiring of your brain. They're both legal (in the US). They both seem to be encouraged. Well, caffeine is encouraged for kids too. Both are an acquired taste. My 11 year old son has only recently breached the pop barrier, though he still prefers water. Coffee, beer and wine are still gross.

So, i tell people that i'm a caffeine addict, but on the wagon. They ask, "Why?" It's not why i got addicted, but why on Earth i'd give it up. Well, it has this feature that it flushes calcium from my body, and that affects my joints first, and gives me arthritis. "Oh." And i know they're thinking that it could happen to them, though it clearly doesn't happen to everyone, and they think maybe they'll get lucky, despite osteoporosis running rampant among the older population. Perhaps they think that they won't get older. I could happen, right? There is an alternative to getting older.

I know what you're thinking. Alcohol affects your mind, your judgment. That's what makes it different. Except that caffeine also affects your judgment. It makes you jittery. It make you buy more of that stuff you can barely tolerate. It makes you go to the bathroom more often. It also messes up your sleep patterns, reducing your mental performance. That's right. You took caffeine to improve your mental performance, but eventually you come out behind.

Monday, June 16, 2008

Parnas oopsla keynote podcast notes

David Lorge Parnas delivered a keynote speech on October 24, 2007 at OOPSLA in Montreal. The speech largely covers documentation, and communications required to build large projects. It touches on issues of building these projects, but mostly covers documentation.

I listened to it twice, and took notes. I haven't seen his slides. Sorry, this isn't prose, it's notes. Expect sentence fragments. And, they're somewhat organized together by topics, not notes in the order you'd hear in the show. Some repetition was removed. It hasn't escaped my notice that, as documentation, these notes of mine suck.

Listen to the show. It's one of the better talks about computing i've heard in the last decade or so.

Object Oriented: not a language thing. It's a description thing. Dykstra's THE does this in assembler. But OO languages have made it harder. Parnas has done this in Fortran. But younger people see this as a language issue.

  • Abstraction - what is the "more abstract than" relationship? Subsetability: sequence of virtual machines.
  • Information hiding, inspired by managers who wanted to break up a task into work packages, without incurring too much communication. (Parnas). Information hiding as a way to do composition.
  • Documenting module interfaces.
  • "Information hiding is an empirical result". - no. It's mathematical. It allows one to know if module A uses B, and knowing a limited amount about B, you can know if A needs to change or not.
  • Hence, Information Hiding Theorem.
  • So, you have the theory, but must also check it out in practice. Because "Theorectically" means "not really". "Theoretically, we can all run a 4 minute mile."
  • Unhappy with this definition: Modules are collections of procedures - invoked by procedure call.
  • Abstract datatypes. Instead of one data structure for each module, more than one.
  • Components - really about sellable bits. Modules aren't components.


Young people may have more energy. Older people have the experience to know what might change.

Documentation

How can you document a project so that if a manager gives it to three people, he'd get the same thing. When it fails, there's no one to blame. It was difficult, not in theory, but in practice.

Sometimes, combining modules is the right answer.

Mathematical relations.

Documentation for other engineering projects has multiple dimensions. There are multiple documents for a bridge, etc.

Coffee stain test - if the document is used, it's good. These days, it would be a document web hit count or something.

Design through documentation. Building a bridge: the documentation gets refined until the builders can use it to build the bridge. In engineering, these documents assist in inspection. Assists in maintenance. Enables systematic design review. Attitude is that the documents are binding. But in software - it's the program that counts - and the documents may be updated. In engineering, these documents are binding. Enables verification and inspections.

Documentation must be accurate - if it isn't right, people will stop using it.

Documentation must be precise. A precise document that is wrong is better than a vague document. A vague document is not even wrong. (One complaint i have for the talk is that it's more than a bit vague. It might be the slides i missed. He clearly wasn't reading from the slides, so it's gone.) Yet, the questions at the end were from people who clearly knew what he was talking about.

Documentation must be consistent. Free from contradiction.

Everything must be only in one place. Otherwise one will be changed, and you lose consistency.

Documentation must be complete. It must answer questions you have.

Documentation must be easy to search. You must be able to find the answers to the questions you ask. Search tools can help you find things in electronic documents.

Notation and Organization

Documentation must use simple, closed form mathematics.

No introductory sections. People will look at the introduction, and ignore the body, then misinterpret it. Extreme example: introductions were audio, and could only be played once. The goal was to help you understand the body, but were not referenceable. Of course, clever users figured out workarounds.

Source code isn't documentation for end users.

Documents show a separation of concerns. At least three views for a solid object. There is a set of documents.

Documentation is not a crisis: it's a chronic disease. Documentation needs to be a disciplined effort.

Documents should be good enough that you should not have to look at the code.

Documents are practical tools.

Documents must be authoritative. They must be organized so that you know where things go, or can be found. They are reference, like a dictionary, rather than a tutorial.

The test is that if you ask someone about a program, if they go to the documentation first, then it's good documentation. If they go to the code first, it isn't.

Documentation needs structure that avoids inconsistency.

Documentation needs to be better than "let's just try it".

Documentation needs to be used before you write the code. While you write the code, and after the code is finished.

All these documentation rules are easier said than done.

Each document should have a clearly defined role. Description, partial specification, full specification.

Three types of documents
  • Description: facts. Some facts are requirements.
  • Specification: only requirements.
  • Full specification: all requirements.

The same notation may be used by all three types. This means that there is no specification language.

If you look at a document, you can't tell if it is a description or a specification unless someone tells you.

It's not models. (!)

It's not formal documentation.

Source code clearly describes the program, but not the program's intent. It's not a specification. So it doesn't describe how the program might change. (On the other hand, specifications can change too. And, some programs do document intent via comments. One could argue that any other comments are pointless.)

The word 'theory' often means 'not really'. The program works, in theory.

All words are bendable (or ambiguous).

How to define what information should be in a document?
  • Must specify the content.
  • Each document is the representation of a mathematical relation.
  • Ordered pairs.
  • Programing proving. Preconditions and postconditions.
  • If you can start in x, it should end in y.
  • Lots of examples of format and notation. Must agree on content.
  • Need to know all the variables you sense and control.

Counter example: Document form vs. content.

Great anecdote. Manager offers prize for documents conforming to specification: Seven parts on A4 with 1 cm margins, pages numbered, etc., but without talking about content. Winner submitted document in seven sections that said the same thing. Description: the module copies data from here to there. Design: Bytes are copied from here to there. Detailed design: Byte one is copied before byte two... and so on. Manager never noticed.

Two are two relations:

The set of things that are possible without the system - nature. Describe the restrictions of cases that the system allows.

Document should be able to be checked for feasibility.

Software: modules, objects, components.
  • Distict but related concepts.
  • Module is a work assignment.
  • Component is a unit for sale.
  • There can be many copies of an object in a system.
  • The same kind of document techniques can be used for all of these.

Describing things operation by operation is natural to programmers. It's not very helpful to others.

A7 aircraft documentation project. Output by output - with history of inputs. You get this under these circumstances.

It's harder to write for managers.

Microsoft EU court case. $3 million a day fines. Anti-trust. MS was told to document what other vendors needed to do to interoperate. MS attempted to document their interfaces and failed. In Parna's opinion, MS tried. MS offered code, but other vendors refused. Intellectual property, but also that the code can change, and so, the spec.

Inability to write documentation is key to some of the big expensive problems today.

Specifications are not wish lists, or lists of features.

Documentation is not a list of facts about the code. In engineering, a specification is the requirements for the product.

Requirements should not be repeated. Else, inconsistencies creep in.

Describe the data structure. Describe how the data structure is interpreted: (interface) abstraction relation. Describe what each program on the interface does to the data structure.

Traces - history of what has been done. Commuting diagram. (More math references). If it commutes, then it can be implemented.

A document should be a description of a set of relations.

Documentation is inconsistent, and has errors.

Describe mathematical concepts in a readable way. Predicate pairs. But how to write it so people can read it?

Bad example:

21 pages of inconsistent and erroneous testing documentation. The testers ignored the errors. Following testing instructions is dangerous. Everyone preferred this bad document. The document was readable, but managers didn't know it was wrong because they never tried to use it.

These two things are needed for practical, sound documentation.
  • Tabular expressions. Better for math with if, and but.
    Discrete math.The tables parse out the dimensions of the problems.
  • Relational model of documentation. Tells you what information must be
    in the document.

Requires significant training. But not a PhD. Fewer mistakes. Requires an engineering background. Precise and checkably complete. Pilots can read it (for A7) likely due to engineering training. Can be used as a slow (non-real time) prototype.

Down on Zed, VDM, Alloy (British doc languages). Alloy is relational, but this is not the problem. Tabular notation is needed. These languages are translations of the code into other codes. May as well use a Turing Machine implementation. These tools are not practical. If it's easier to read the code, then the documentation isn't good enough. These tools are code. Should use engineering documentation as a guide.

Down on documentation extracted from source after the fact. For one thing, it's descriptive, not prescriptive.

Managers often do not have the engineering background needed to read documentation. Writing documentation for managers is harder than for programmers or users.

When you're done, the program should do what the document says it should. If you test the program from the document, they can't get out of sync.

Testing

Test coverage.

Reliability estimation via testing.

Mutation testing.

Test case generation. Interesting points:
  • Extreme values
  • Cross zero
  • Discontinuities
  • Equation solving for boundary values

Precondition/postcondition doesn't scale up as well as relational models.

Errors escape reviews. Must use the code to answer questions. What would you have to change in the code to do something?

Separation of concerns (Dykstra). Look at small bits of code at a time. Important for testing.

(more testing:)
A "display"
  • what it should do
  • what the invoked programs do
  • right or wrong on it's own.


Then, for large programs, testing uses lots of these displays. Scalable - lots of people can do little bits.

"The smallness of the human skull." - Dykstra "You should never look at a long program." Use divide and conquer. Precise documentation to hook things together. It's not stepwise refinement. In stepwise refinement, the program gets longer. Instead, keep it separate.

If it's an object and a component, use the trace function method. if it's a program within a component, use the display concept with documentation.

Tools for documentation:
  • Functional and imperative programming are combined.
  • Functional specs for imperative programs.
  • Don't worry about efficiency of functional programs.
  • Don't worry about illegibility of imperative programs.

Object orientation for hiding the right things.

To Change
  • Vague diagrams that don't answer the right questions.
  • Write the documentation first, to help build the programs.
  • From group reading to systematic inspection of the doc.
  • Test generation from the documentation.
  • Anyone who knows two language is a software engineer - a myth.
  • Need to train people in documentation.

Summary
  • Need to take a serious view of documentation.
  • It needs to be seen as normal, expected and effective.
  • Needs to be taught.
  • Think about why people don't do it. (ie: it's not taught).
  • Licenses for software engineering, including testing documentation skill.


Questions from the audience

In theory it will work everywhere.

Interpreting specifications, not executing them. Theorem provers, etc.

Deliberately introduce errors into program to find errors. Deliberately introduce errors into documentation to find errors - Mutation.

Movies: storyboarding. Rapid prototyping is similar. Knowing what you want by creating an approximation. Is the prototype a document?

The prototype should be bound by the specs, just as the real program.

Tables of documentation as an interface for talking to the customers.

Evolution of documents. The document evolves with the program. Use information hiding in the document as well as the code. Allows easier evolution.

User interfaces and complex database interfaces. - works.

Teach professionals the tabular notation? Need to focus on a method that works - not just about methods. Need to teach better fundamentals. The math - 'for all', etc. Lectures and labs. Lectures give theory. Labs teach why there's theory.

Questions i might have asked if i'd been there

  • So if the documentation is really good, is the code write-only?
  • What does Parnas think of use cases? Aren't they requirements?
  • Many ideas (like use documentation to show who's to blame) are wrong because the idea itself is shallow.

Sunday, June 15, 2008

Rod: part six of six - Coffee

Tie's coffee smelled really good. A short blond woman approached.

"Gail, why a café? You know I don't eat."

"Someone new. I'll introduce you, then take off. She's seriously creepy."

"Another hot date? You know it's doomed", remarked Tie.

"Yes and no. How did you manage to attend both the Nobel and Ig Nobel ceremonies? Time zones?"

"I had a new body built, and copied my bits to it. But afterwards, we couldn't merge experiences. Something's wrong."

"Here she is. Tie, meet Jean. Jean, Tie."

Jean gave a low gasp as she sat down. "You aren't a breather."

"No", Tie said tentatively. Didn't everyone know his story?

Jean went on. "Not like Nosferatu. And unlike those machines, you have soul."

"I'm not clueless."

"Dim ones never have strong souls. Which comes first is hard to prove."

"So my other body, the new one, may not adjust?"

"You might try to split your soul."

Gail got up. "Gotta go. Bye Tie. Bye Ms. Bank".

Jean said, "You were right, Ms. Force. Fascinating. Thanks."

Friday, June 13, 2008

Rod, part five of six - It's a Tie

"You won the court case and Earth Defense Fleet is giving you your back pay. How does it feel?", asked journalist Debbie Jameson-Peterson.

"And 4% interest and treble damages, said Acting Ensign Rod, Genocide, Retired", Rod replied with a smile.

"They said you are a machine, and not entitled to property."

"I was human enough for them when I signed up."

"They said more than half of your parts were replaced. You're a new entity."

"Ninth handle and 3rd blade, but the same axe. Most of your cells have been replaced too. My lawyer told me to use the 'Acting Ensign' bit. Never my first name."

"Your name's Rod?"

"That's my last name. First name's Tie."

"Ha! Sorry. Name Change?"

"Nope. Floe Rivers married Jack Hammer. Mom and Dad."

"At least it wasn't Barb Wire."

"That would be Grandma."

"Sorry I mentioned it. What do you do next?"

"Sweden, then upgrades."

"Sweden?"

"The Nobel Peace Prize. For killing billions."

"You ended the war. You saved countless billions."

"Buy one, get two free. I get an Ig Nobel too. No one ever got both."

Thursday, June 12, 2008

Rod, part four of six - Historian

No ships in sight. Shut down nonessentials. Set wakeup for a day and sleep.

Nothing here. Sleep. Nothing. Sleep...

"Where am I?", asked Acting Ensign Rod.

"You are on Space Station 666. I'm mission specialist Ray. Are you male or female?"

"Does it matter?"

"Many of your parts had to be replaced. Tough to get some of the older ones. And we guessed male."

"That's right. Uhm, what's your specialty?"

"I'm a military historian. I'm investigating the Battle of the Berg. No one knows why all the Berg ships blew up."

"They all blew up?"

"Including some on the Berg home world. Ship yards were near cities. More than a billion Berg vaporized. Led to the end of the war."

"So, I've outdone Hitler, Stalin, and everyone combined."

"Sorry?"

"Well, Hitler and Stalin only killed millions. Uhm. How long was I out?"

"We found you a couple years ago. It's been 76 years."

"Great. Acting Ensign Rod, Genocide. Over 200 years old and totally obsolete."

"But think of the back pay."

Wednesday, June 11, 2008

Rod, part three of six - Winders

Acting Ensign Rod, on breached enemy Berg ship.

Have power, but power meters are fried. That was some jolt! All batteries have something, so use them one at a time.

No shooting. The battle is over. Gotta get this hulk moving or stay here forever.

This looks like a computer terminal. What? It's Winders? I hate Winders. Wonder if it has that bug...

W00t! I'm in. And look, the Admiral's unexpired command codes! Can I self destruct every ship in the Berg fleet? Not much time.

Need his retinal scan. What's the Admiral look like? Where's the bridge?

Found him. Scan. Send it. Damn. Comms are down. Antenna damaged. Backup antenna in the hold. Set up a 10 second retry send loop. Get some wire for a tether. Out the breach and hook up the backup.

Here it is. Bolt this down. Plug this baby in.

Boom.

Opps. Forgot to tell this hulk not to blow up. Took lots of damage. Golly. Several nearby explosions, though. Maybe it was worth it.

Once again, Acting Ensign Rod, floating space debris.

Tuesday, June 10, 2008

Rod, part two of six - Adrift

Acting Ensign Rod, the largest intact piece from the Cruiser Chanuk, drifting in space. All systems nominal. Imagine that! Batteries at 15%. Don't need legs or arms. Can they be turned off? Yes. Four hours left now. Need to turn around to see. Uhm double over and twist, bend over backwards. Hot dang! Something big coming this way. What is it?

What is it?

Just great. Enemy ship.

Big breach, but mostly there. How long will it take to get there? Too long.

Shut down torso, hearing, taste, touch. Is it long enough? No. Ok, turn touch back on, and shut down vision. Power everything back up on contact. Seven hours. Long enough? Better be. Stop thinking. Laptop chips have low power idle mode. Think of nothing. Nothing.

Clunk. Power up. Grab something. Damn. Bounced two meters away. Toss the remote hard.

Fabulous. Boarded an enemy space ship. Six minutes to find a power outlet. What, no standard outlets?

Sparks! Jam those wires into the charging socket. Woot!

Saturday, June 07, 2008

Rod, part one of six - Battle

"Acting Ensign Rod, we still need officers for science and security. What do you want?"

"Tactical. I want to shoot enemy ships. Kill! Kill! Kill! Uhm, Captain Sook, Sir!"

"In case you hadn't noticed, we have no engines."

"But we still have one reactor, and a port laser."

"We're blind on our port side. You can't just shoot, you'll never hit anything."

"I'll do an EVA with a remote control, Sir."

"Sorry, all the suits were blown out in the breach."

"But i don't need a suit. No biological parts. Just a battery charge, Sir. I'm good for ten hours."

"All right, get down to engineering and see if you can get a remote working."

Half an hour later, Rod was outside. The rule was 'shoot anything unrecognized'. That's the enemy. Five hits in seven shots, and one was really good. Everything was going to plan, until the third torpedo hit the Chanuk. It exploded.

"Great", he thought. "Acting Ensign Rod. Ninety minutes of battery power left. Drifting in space without a ship."

Friday, June 06, 2008

Rod part zero of six

I wrote this seven part series for Burst Fiction. I thought it was a cool idea, and brand new. The idea is really short stories for those with short attention spans. Each story is about 1000 characters. Well, Eric posted my first story, but has been very slow to post part two. So here are all seven parts, about one per day. Eric has put alot of effort into the site. I read it with an RSS reader, and so don't get that formatting. His value add seems to be in picking stories he likes and releasing about one per day. I thought this idea was brand new. But, judging by the quantity of content, ficlets have been around for awhile.

One thousand characters isn't much. If words are on average 5 characters, and you need a space between words, it's only 167 words. That's really constrained. So you get story snippets that remind of a turning point in a story. Further, you get poetry in prose form. For example, each sentence might be purposely written ambiguously, and all meanings are intended. So, far from food for the impatient, these little stories can require significant study. So, AFAICT, not new, and not for short attention spans. Another trick is to play to stereotypes. That way you don't have to explain so much. Pick a Universe everyone already knows. I personally like the unexpected twist for an ending. Harder to do with a story that can be read at a glance.

Eric has also put alot of effort into the site. I read it with an RSS reader, and don't get that formatting. Honestly, i find it annoying. Yet another unique user interface that is barely discoverable.

The exercise is valuable. Write some. Leave them in the comments.

My first draft of "Rod" was from a preface or chapter one. But there wasn't much action. So it got moved to chapter three or four. To save space, the first draft omitted all character names. Without further ado, the story:

The first incoming torpedo destroyed Cruiser Chanuk’s main engine. Inertial dampers went down seconds later. The second hit slammed everyone who wasn’t strapped down into a wall. 90% casualties, including all bridge officers. The Chanuk would likely sit out the battle. Ensign Sook took command. She didn’t have to like it.

"Private Rod, why haven’t you reported to sick bay?" asked acting Captain Sook.

"I’m fine, uhm, Captain. Sir! And I have no biological parts."

"You’re an android? Your dossier says human."

"Yes, but my body rejects transplants. So as bits fail, they’re replaced by prosthetics."

"Not everything can be replaced, can it?"

"I suffered brain death two months before signing up for Earth Defense Fleet. No big deal. Most of it had been replaced already."

"Cyborg, then. Why doesn’t it say Cyborg?"

"There’s been no enhancement. Certified prothestics."

"Well, when did you first start getting replacements?"

"At about seven, my dentist put in two fillings."

Thursday, June 05, 2008

Bike to Work

It's 8 miles each way to work. So, it's 16 miles, round trip. The car gets 44 MPG, so that's about a third of a gallon of gas a day. Gas is currently about $4 per gallon, so that's $4 every three days, or a $1.33 per day.

But today, i rode my bike to work. One might think it was to save $1.33, but it actually saved over $80. That's because my car needed a new windshield. It takes about 3 hours to do the work, and the mechanics hours are the same as mine. So, it's 3 hours of work, which is unacceptable to my employer, as well as 3 unpaid hours.

There was an option. There's an outfit that will replace your windshield while it sits in the parking lot at work. They serve the town where i work. But, they're about $80 more.

The place that did the work isn't across the street. They're about 2 miles away. And, the optimal route from there to work goes by my house. In fact, i stopped at the house in both directions. In the morning, i stopped to pump up the tires and get my backpack. In the evening, i stopped to drop off the backpack. Instead of about 9 miles (the car route is a little more direct), it was 11 miles each way.

Since there is a shower at work, i could push it a little and work up a sweat. And the same for going home. It took an hour and fifteen minutes in each direction, so my speed was something around 7 MPH. I felt like i was flying, however. Perhaps if i get a battery for my bike computer, and do another ride, i'll know for sure. But last time i did something like this, it really was pretty slow at the start of the summer. Last time, it built to 22 MPH by the end of the summer.

That is, the speed tripled. Bike speed is limited by drag. Drag goes up as the cube of the speed. So if the speed triples, the drag force goes up by a factor of 27. Energy is force times distance, so the energy required goes up by a factor of 27. If one's calorie intake stays the same, it suggests that body efficiency can go up dramatically. And that's an hour or two per day for a hundred days.

It also means that i'm really out of shape at the moment. Well, i knew that.

I had a banana with lunch. I had one with dinner. I've just heard that they can help reduce the muscle soreness. No idea why that might be.

This blog post was written entirely using a Nokia n800 pocket computer while sitting on the downstairs couch. It's quite a bit cooler down here than upstairs where the desktop sits.