May the Fourth be with You!
UPDATE: GO HERE
I was introduced to WordStar many, many moons ago. I built myself a Ferguson BigBoard CP/M based computer (the system came with a board and parts. I had to buy my own soldering iron), bought a
Hazeltine 1400 Hazeltine Modular One terminal and two 8 inch floppy disk drives. The terminal is so old, I can’t even find an image of it on the Internet. That computer eventually fried… don’t ask.
The one thing I truly got from that system, was a deep love for WordStar from MicroPro. I took to the command sequences like a fish to water. Even after the BigBoard died, I stuck with WordStar and it’s command sequences. Turbo Pascal used the WordStar keys, one of the text editors I use today has a WordStar mode (joe).
I’ve even remapped my Caps Lock key to be a Ctrl key to make keyboard navigation easier. That being said, I do seem to have gotten into the habit of using the cursor keys for navigation. Hmmm.
I missed my WordStar. Oh, I always had a DOS or CP/M Emulator available that would run WordStar, but then I couldn’t print quite right. The files couldn’t be read by other apps for printing. It was generally a pain.
So, I decided to double my pain… I wrote a WordStar ‘clone’. It’s got most of the command sequences in it, it’s missing most of the dot commands, and has only rudimentary formatting support. Still, it’s getting there. I can pretty much read and write WordStar 4 and under files. Wordstar 5 and up is coming.
My next steps from here (once I get out of novel revision mode) is to
- complete printing
- complete the command keys
- complete the dot commands.
- add RTF read/write abilities (write for sure).
- read and write all WordStar files
Then I’ll look into adding macros. I’ve never used WordStar macros, so it’s a new one on me.
WordTsar (yeah, bad name) isn’t a WYSIWYG wordprocessor, but it does try make things look close. For example, the screen width is the printer width (hard coded to 8.5 x 11 for now). The screen shot above uses Times New Roman as it’s font, so variable width fonts are displayed correctly. Bold, italics, etc are displayed as is as well. The main code base can deal with font changes and display the correct font, but a user can’t change the font yet. These font styles do not yet follow the WordStar font table. I’m not sure if they will. I’ve added a full screen mode, since I hate distractions when I write. The program is UTF-8 throughout, except reading and writing of WordStar files, that’s still 8 bit ASCII.
It’s currently at version 0.0.1 Alpha, but it’s pretty stable and usable. It has one crashing bug that I’m working on (weird delete problem).
I use wxWidgets to code it, so it’s cross platform: Windows, Linux, and OSX. I currently only have the Linux version running, but next month, we’ll see.
Ahh, what I do to keep my programming skills up while I write! Fun fun fun.
I’m currently revising my fourth novel… one that I actually think may be good enough to send out.
Doing revision is tough for me. I prefer the feel of getting the first draft done. Taking my outline and getting all of the raw thoughts onto the page. Pieces of that first draft can be beautiful. Pieces of it can also be the hideous stepchild of the devil himself. That’s where revisions come in.
On my previous 3 novels, revision was the boring sludge I had to trudge through. I hated it. I didn’t want to do it. Why couldn’t I be on a sunny beach on a tropical island instead. Heck, -55° C with windchill was better than doing revisions. Novel 4 was quickly turning in to the same slog.
I figured this was getting pretty stupid. The work had to be done, so just f*cking do it. That didn’t work too well. What the heck was wrong? I’ve been a programmer for much of my working career, and finding/fixing bugs (revising) was part of that. Albeit with more immediate feedback on success or failure. What caught my attention though was the pattern of work. I’d already taken the programming process of requirements/architecture/design into my writing (all wrapped up in my outlines), so why not the bug fixing portion as well? The only problem was that when something doesn’t work in a program, you can make changes and immediately see if you’ve fixed the problem or not. In writing, whether the ‘problem’ is ‘fixed’ can be a matter of interpretation by the reader.
The end result is my current revision process, which seems to be working quite well… as long as I stick to the adage of ‘butt in chair’. Still, getting my butt into the chair has become easier, and at times enjoyable, using this process. Below are two sample pages. The first one is heavily revised (though not the worst example I had) and the second is lightly revised. The first page was roughly an hour and a half worth of work.
So what’s my process? As you can see from the image above, the first part is that I do my revisions on paper. I print out one chapter at a time, and then revise one scene at a time. But I’m getting ahead of myself.
Step 1: After I’ve completed the first draft and done some plot/storyline and major blooper fixes, I send the novel out to my Alpha readers. Alpha readers know they are getting what is essentially a first draft. Their job is to comment on the plot, the characters development, the pacing, does it all tie together, etc. Basically the big pictures items. To me, this is analogous to a peer review of the architecture/design on software.
Step 2: Once I get back the reviews, I sit down and look at all the comments. Do I think they are right? Should I make some changes? What kind of changes? All this is done in my head for the entire novel (with some note taking) before I sit and do any work.
Step 3: Sit and do some of the bigger stuff on the computer. The big change things I missed like hair color changing, different names, timelines problems if time is a factor in the story, etc.
Step 4: Print out a chapter, starting with chapter 1 and moving sequentially through the story. Take the first scene and look at the notes from the Alpha readers. Are there any specific comments I want to look at for this scene? If so, I’ll do that first, revising in pen as necessary. Once that’s done, I read the entire scene out loud. It gives me a sense of what the scene is about, the pacing, and the flow.
Step 5: I look at the scene and see if it makes sense in the overall story. Does the story advance because of the scene? This is a big yes or no question. If the answer is no, I put a line through the entire page (all pages for the scene). Then I double check what was cut when I did that. Is there anything I want to carry over to another scene? If there is, I write it down in a notebook and continue to the next scene.
Step 6: Okay, I’m keeping the scene. Is the scene a story in miniature? Does it have a beginning, middle, and end? Is there conflict or tension? Is the conflict resolved, for good or for bad? If it’s missing any of these, I re-arrange the scene so that I have them. I’ll move paragraphs, lines, whatever is needed. All in pen on the paper.
Step 6a: Does this scene reference anything I cut out earlier? If so, toss it or figure out a way to get the information in another way.
Step 7: Now I look for specific components in the scene. Is there dialogue? If not, why not? Would the scene be better with dialogue? I go through the same process for engaging the 5 senses. For a single scene, engaging all 5 senses can be too much for the reader. I’ll usually pick 1 to 3 senses and make sure I’ve hit them hard enough to make the scene feel real. I do this a paragraph or line at a time.
Step 8: Description. When doing first drafts, my descriptions are pretty weak. The car was black, or Her hair was wet. Sometimes, thats good enough. Sometimes you want more, you want that kick. The cars black exterior sucked the light right out the air, throwing everything around into twilight shades of blue. Her hair, still wet from the sudden downpour, dripped into her eyes, blurring her vision and making the car look feral. Can you kick it up like that every time? Only if you want your book to be put down while the reader rolls his/her eyes. But you still need it sometimes. A good place to think about kicking it over the top is when the character has a reaction to external (or internal) stimuli. If the stimuli warrants it, make the reaction visceral, and believable.
Step 9: Once I go through the whole scene, I go back to my notebook. Is there anything I cut out earlier that I want to (or could) place into this scene. Does the insertion work here?
Step 10: Repeat steps 7 – 9 for each paragraph.
Step 11: Read the entire scene out loud again, looking for the same things as in Step 4.
Step 12: Start at Step 4 for the next chapter/scene.
Step 12a: Sometimes I see (either by my reading or from Alpha reviewers notes) that I need a scene in between the one I’ve just finished, and the one I’m about to start. If that’s the case, I write the new scene in my notebook, by hand. Once the scene is typed in (after I’ve revised the entire novel), I’ll print out the scene and follow the above steps on it.
I look at each step as a bug fix. Find the bug, fix it. Make the fixes logical and in order. Just not to the point where the reader can see your process.
Once the novel is revised, I sit down and make the fixes on the computer. Sometimes I’ll make minor changes as I type in stuff, sometimes I won’t. Too much fiddling isn’t good either.
Once that’s all done, I’ll read the story (out loud) again, make any minor (or major) changes I see, and ship the draft out to my Beta readers.
Wash, rinse, repeat. Until you are happy with the work you’ve done.
I found this quite funny:
A commentary on todays use of language, beautifully set with typography and fonts.
I’d love to hear your comments on this.
I recently had a failure on my 4 TB RAID5 array. It happened when I moved the server from the rack to my office, in preparation for converting it to a desktop system. It would still host the RAID array, but it would no longer be running all the virtual machines.
During the move, I also upgraded the RAM. Shortly after powering the server on, I noticed that any access to my harddrives (RAID or not) was extremely slow. The kernel showed high load, with 98% being in system. Wow. Before I had time to realize it was the RAM I added, I lost a drive on the RAID array. I pulled the RAM, and things went back to normal. I added a new drive and started rebuilding the array. At 97.1% complete a second drive got a permanent read error. Good bye array.
I managed to get the array back up degraded, but I couldn’t rebuild it. Now I know I could probably have used dd to copy the disk to a new one, get another new drive, and rebuild that way. Oh well, hindsight is 20/20.
I needed to get my data off the degraded array. There was no critical data on it, so it had never been backed up. How am I going to back up 2+ TB of data anyway. It mostly contained over 1000 recordings from MythTV, some audio and video, and pictures. Still, if I could save the data, I really wanted to. So, I went out and purchased a Drobo. Drobo’s don’t really like Linux that much, so I hooked it up to my Mac Mini and started copying data over via rsync. Wow, was that slow!
It turns out the Drobo is a really. slow. device. Although it can handle watching live TV via MythTV, it barely keeps up. Anything else done on the Drobo kills the TV. Granted, the Drobo is a Firewire 800 device, but it still slower than that would imply. Knowing that I will be recording and watching 2 HD streams at the same time, I knew the Drobo wouldn’t cut it for me. For example, a Drobo rebuild could take days, and it’s all internal to the Drobo, no firewire used. But, during rebuild, live TV was impossible to watch.
I built a new 4 disk 2.8 TB RAID5 array under Linux, and started transferring live TV and recording to the RAID5 array. Things got much better I decided to do some tests.
The Drobo, connected via Firewire 800, writing a 16GB file took 628.89 seconds (10.48 minutes) ~25 MB/s
The Linux RAID 5, writing a 16GB file took 135.59 seconds (2.26 minutes) ~121 MB/s
25 MB/s is doable for two HD channels, except for the issue that nothing else could use the drives at the same time.
I then tested the connection via the network. My MythTV Server is a simple Pentium M 1.5 GHz system, and it uses remote Samba shares for it’s storage, over GB ethernet.
The Drobo via OSX SMB share, same 16 GB file took 1451.37 seconds (24.19 minutes) ~ 11.3 MB/s
The Linux RAID5 via Linux SMB share, same 16 GB file took 459.08 seconds (7.65 minutes) ~ 35.7 MB/s
Ummmm. Ouch! The Mac Mini is a Core2Duo at 2.6 GHz, the Linux is a Core2Quad at 2.6 GHz. Neither used any noticeable CPU during the file transfer.
Tweaking the OSX smb.conf file didn’t help any. What did help was specified here. That alone changed my speed to 16 MB/s. Still not good enough, but better.
The Drobo is a cool device, and has it’s place. But not in a media streaming type environment. I’ll use the Drobo to store my audio, pictures, and movies, but not my live TV recordings for MythTV.
The blog was being filled with Wordless Wednesdays, and no actual content.
We’ll see if we can remedy that. Wordless Wednesday is still around, just relegated to fewer time slots.