Wednesday, December 04, 2019

Servants of Spiders

No, not people who are servants of spiders but robotic servants made up of spiders. That’s what we need.

I was thinking about the kind of robot servants that might be coming our way in the not-too-distant future. For many uses around the house, the best shape and size would be pretty much humanoid. After all, our houses are designed for humans of average size. However, for some purposes, such as cleaning nooks and crannies and finding small objects that manage to roll under the refrigerator, as they are wont to do, small spiders would be far more efficient. Swarms of spiders would be efficient for so many other tasks, too: finding and eliminating pests, checking for damage in hidden places and repairing it, etc.

So we could have two main types of servants: humanoid and spideroid. (Is that a word? It should be.) But with technology only somewhat advanced beyond what we now have, we could combine the two for convenience. We could have swarms of robot spiders that would assemble themselves into human shapes, to the human eye indistinguishable from actual humans. For example, you could have a perfect butler serving you dinner, and if you dropped a pea and it escaped and rolled under the fridge, the butler would calmly dissolve one hand into a swarm of spiders that would retrieve the pea. Meanwhile, one of his ears would become a swarm of spiders, scurry into the kitchen, and assemble into some convenient shape to check on something on the stove.

Unfortunately, all of this is too much like scenes from various horror movies to have much appeal to consumers.

Monday, October 21, 2019

Publishing and Buttons

Switching to self-publishing has had an unexpected and beneficial effect on my attitude about writing.

When I started out, long before self-publishing was an option, I was writing for the sheer pleasure of it, for the happiness it gave me, for the delight in the act itself. I wrote what I liked, and I liked what I wrote.

That changed as soon as I became traditionally published. I started focusing on writing what a commercial publishing house would accept. I became almost obsessed with pushing all the right buttons. It hampered my creativity and it certainly limited the fun. Much of the time, writing wasn't fun at all.

After I switched to self-publishing in 2009, that near-obsession stayed with me for a while, but it started to fade, and then it evaporated entirely. In time, I stopped worrying about those buttons and reverted to writing to please myself again. It's been wonderful, liberating. This attitude isn't likely to result in bestsellers, but it does result in a happy writer.

And so, after all these decades and 29 books out there, I have come full circle. Once again, writing means to me being a man alone in a room happily pushing his own button.

So to speak.

Sunday, September 22, 2019

The Day I Was a Whacked-Out Hippie on a Bus in California

Being a random memory from the Space Age.

From 1971 to 1974, I worked on the Viking Mars lander program at Martin Marietta in Denver. I was part of a small team (three men most of the time, with two to three other people added for brief periods) developing the software that would be used to determine the timing and duration of the Viking lander’s deorbit burn when it was in orbit around Mars.

The orbit would be known(ish), Mars gravity would be known(ish), the atmosphere would be somewhat known(not-very-ish), and the desired landing site would have been specified. Make some assumptions, turn on the deorbit rockets, and head down to Mars! With the assistance of a few gazillion lines of code.

Which we developed in FORTRAN on a CDC 6600. The original plan was for the software to be run on that machine during the actual mission. However, Jet Propulsion Lab, JPL, in Pasadena, California, exerted its considerable political weight and it was decided that during the mission, the software would instead be run on a Univac 1108 at JPL.

We shipped our software to Pasadena and told them to load it onto the 1108 and have at it. However, what had worked just fine on the 6600 failed miserably when transferred to the 1108.

We tracked down the problem and made the changes.

Or so we thought. JPL said it still didn’t work. (As was always their way, they made it clear that all would have been just hunky dory [or copacetic, as people in the Apollo program used to say] if the software had been written at JPL in the first place.) (Yeah, right.)

Time was getting short. Time is always getting short in the aerospace biz. A few of us were sent out to JPL to track down the bugs and run simulations and verify that all was well. Quickly.

I was out there, on the very edge of civilization, for three weeks, getting too little sleep, spending my days and much of my nights at JPL, reading printouts, writing my changes on the printout, changing punch cards, submitting card decks, waiting for new stacks of printouts, repeat. By the end of the three weeks, desperate to get it done and go home, I spent a few days without sleep, working around the clock.

Finally done with my part, I went back to the hotel like a zombie, packed, checked out, and took a bus to the airport.

This was in 1974 (or just possibly late 1973). I had long, red hair, worn in a ponytail, and a full, rather bushy red beard. I was wearing a t-shirt, jeans, and sneakers. My eyes were gruesomely bloodshot and had huge bags under them. I sat in the bus swaying from side to side, falling forward, drifting into sleep, then snapping awake again.

I don’t even remember what the bus was. Some short of shuttle between hotels and the airport, I suppose. I don’t even remember getting on it. I do remember that it kept stopping to pick up tourists at hotels and once, oddly, at the Hearst Castle.

Most of the tourists seemed to be older English couples dressed formally informally. They kept turning to stare at me and then turning away again quickly when I met their eyes. Very British. I imagined them whispering to each other that they had heard that the drug problem was bad in California, and here was living proof. Just look at that poor young man, his mind destroyed by drugs. Shocking.

The rest of the story is anticlimactic. I got to the airport, got home, went back to work, got laid off once all the work was done and the company had been paid by NASA—a typical aerospace story.

But I’ve sometimes imagined myself trying to reassure those tourists that I wasn’t on drugs. My words slurred, mumbling incoherently, swaying, my red eyes open wide in earnestness, waving my hands about, I would have tried to tell them that I was working on sending stuff to Mars. And before that, you know, moon, men, men on the moon. Mars, people. Moon.

For years afterwards, they would have bored their grandchildren with tales of their trip to California and the wild-eyed, hairy hippie they saw there, his mind destroyed by drugs, ranting about Mars and the Man in the Moon. “Tragic. Probably long dead in the gutter, the poor young man. Let that be a lesson to you, children.”

Writing this reminds me of the time, years earlier, when I was in graduate school and drove down from Indiana to Mobile to visit Leonore and her family, my first time in the South, through the heat in my un-airconditioned Volkswagen. Then, too, I had a beard and wore my hair in a ponytail (ya know, grad student). I was dressed in shorts and sandals. I was so na├»ve. I had no idea why the locals were glaring at me. I smiled at everyone. It must have been a year or two after Goodman, Schwerner, and Chaney were murdered. In the parking lot of a grocery store in Mobile, a well-dressed white woman glared at me through the windshield of her expensive car and tried very hard to run me down. But that’s another story.

------------------------------------

See below for some of the nasty details. They’re not indispensable to the story, but they might be of interest to some. Keep in mind that all of this work was done using punch cards.

Yes, FORTRAN is always all caps. At least, in this household. It was THE language for scientific computing! With GOTOs, as God intended! (Not that there was a real alternative, although I did later run into mercifully short scientific programs written in COBOL, gasp.)

The CDC 6600 was a great machine for scientific computing by the standards of the time. One of its best features was its 60-bit-word architecture, meaning that we could do the job without bothering to double-precision any variables.

At a later job, I programmed on a Univac 1108 extensively and liked it, but it used a 36-bit word. The difference was important for this story. The calculations done by our software were long enough and iterative enough that too much precision was lost on the 1108 compared to the 6600. That was why the code gave erroneous results after it was transferred from Denver to JPL. After a few iterations, the values of a lot of the variables in the program were, in effect, random numbers. To fix that, we had to go through the code and convert everything to double precision. Gazillions of lines of code meant zillions of variables that had to be changed in many, many places. Inevitably, we kept missing some of them and having to go searching through the code again..

In addition, we had used a nifty but dangerous FORTRAN thing called Block Common, also called Unlabeled Common, which was a way of transferring variable values between subroutines and functions without putting them in argument lists. It meant that many more places where variables had to be declared double precision and more opportunities for overlooking them. We finally decided that we had to break our enormous block common into numerous (jillions) of separate labeled common blocks. It was ghastly.

Tuesday, July 16, 2019

Just published: My memoir of working on the Apollo project

Just in time for the 50th anniversary of the Apollo 11 landing, I've published my short memoir of my time at NASA working on the Apollo project: http://www.dvorkin.com/moonland/

Thursday, October 18, 2018

KDP Print Cover Templates–Beware of This Glitch

We recently finished a client’s book that’s 91 pages long. I downloaded the KDP cover template. Because those come in ten-page increments, I was given the template for a 100-page book. The template includes space for text on the spine, so as usual I put the book’s title and author’s name there.

When I submitted the book for publication, it was rejected because a book has to have at least 100 pages in order for the cover to have text on the spine. Fair enough, but KDP apparently doesn’t have an appropriate template for a book of 91-99 pages in length. Instead, you get the 100-page template with space for text on the spine, which causes an error.

So be aware of this problem. If your book is under 100 pages but the template shows a space for text on the spine, don’t put anything there.

Saturday, September 29, 2018

Wednesday, September 26, 2018

Did your CreateSpace book(s) get moved to someone else’s KDP account?

Of course that shouldn’t happen, but I just encountered a case where it did. If there’s one such case, there surely are others.

A while ago, I went through the process of transferring the print editions of all of my books and my wife’s books from our CreateSpace accounts to our KDP accounts. This was before Amazon started doing anything automatically. The process went smoothly. For a few hours, the books were no longer listed on CreateSpace but hadn’t yet shown up on KDP. That was disturbing, but eventually, the books did show up where they belonged.

As part of our self-publishing services, we upload our clients’ books to both CreateSpace and KDP. I have moved some of our clients’ books from CS to KDP, also without any problems. I’ve been checking other client accounts to see if Amazon has done the move itself.

Yesterday, I checked the CS account of Client A, who had one self-published book listed there. The book was no longer listed on CS. Because of a password problem, I couldn’t check Client A’s KDP account to look for the book there, but I assumed all was well. Later, I checked the CS and KDP accounts for Client B, who also had one self-published book on both. The print edition of that book was no longer on CS, but it is now on KDP, as it should be. Amazon moved it correctly. However, Client A’s print edition, which had disappeared from CS, is also on Client B’s KDP account! Amazon moved the print edition of Client A’s book to Client B’s KDP account.

Client A will contact KDP in hopes of sorting this out.

Not only is this awful, it’s also a remarkable coincidence. Given how many self-published authors use both CS and KDP, the chances of some kind of software/database error accidentally moving one of our client’s books to another client’s account must be minuscule. Is it possible that Amazon’s software has stored cookie information from two different logons from my computer? It seems extremely unlikely, but if so, this is alarming for people who use any Amazon sites on shared computers.

I’ve been wondering how Amazon knows which KDP account to move a CS book to. It can’t be using login information. You could be using the same e-mail address to log into both CS and KDP, but not necessarily. Both sites should have your Social Security Number or other tax ID, so those could be compared. Either comparison should have avoided the error I described above. So how did this happen? And how can anyone be sure it’s not happening to many different writers?

Check all of your books on KDP carefully once the dust has settled from this move. That’s not very useful advice, but it’s all I can think of.