Writing Samples


API Documentation

I have written Javadocs for Lunar Logic and API descriptions in the C++ language for the following companies: Microsoft, Redmond, WA; Rational, Redmond, WA; PortalPlayer, Kirkland, WA; xSides, Seattle, WA; and OPNET, Bethesda, MD.

Non-Fiction Writing

Track and Field Record Holders contains brief biographies of all athletes who held world and American track and field records from the beginning of 1946 to the end of 1995. Also included are the Olympic champions from the 1948 Olympics in London to the 1992 Games in Barcelona. The book has a total of 686 biographies.

Track and Field Record Holders is a history book as well as a reference book. Each chapter of the book tells the history of a particular track event. The progression of biographies helps the reader understand how the event developed from the end of World War II to the mid-1990s.

Creative Writing

I enjoy writing haiku and tanka. Occasionally I will write a senryu. I try to post at least five poems each week on this website (sometimes life gets in the way!). Click here for a few examples. Click here for Wordtreasure Diary. For more information about my poetry, contact me at daveb99@efn.org.


An example of technical writing for a general audience of computer users

EVENT-DRIVEN DESIGN IN INTERACTIVE COMPUTER PROGRAMS

In today's software industry, most interactive programs have event-driven designs. Event driven means the program reacts to specific computing events. Let's take a common example. Every user has some experience with the screen display on a computer monitor. At the time of initialization the program generates a display window for the user. As part of the display window, the program presents the user with various methods of interaction. For example, there may be menu bars, buttons, text boxes, and so forth. While the user has a display and the display contains interaction choices, there is one crucial point to remember about an event-driven design. The program essentially remains inactive until some event occurs. It always takes an event to activate the program.

One familiar example of event-driven design is a program where, upon initialization, the first screen display presents a text box for user login. Nothing happens until the user types something in the text box. Specifically, the program is set up to listen for an event occurring within the text box. When the user enters data from the keyboard, the underlying operating system figures out that keyboard data was entered and the destination of that data is the target program. The operating system then uses the information -- supplied by the program at initialization -- to route the keyboard data to the appropriate part of the program.

Another typical example of event-driven activity caused by human interaction is the mouse-click event. The user clicks the mouse. The operating system calculates the precise screen location of the x and y pixel coordinates of the pointer at the time of the click. Based on that information, the operating system determines which control on the screen has the system's focus as a result of the mouse click. The system then executes a predetermined action for the control with the focus.

Not all events are caused by human interaction. In addition to human interaction, other system events, such as from a network connection, might send a message to the program. However, whether caused by human or machine interaction, in all cases the program waits -- listens -- for the onset of an external event. When the event occurs, the program then performs an action.

-- Written at xSides Corporation in July 2002