Four Fathers

For Father’s Day, let me introduce you to four fathers I have had. The last one will blow you away. (And that’s not just clickbait.)

Here they are, in order of when I learned of them.

(1) Paul J. Wilcox, Jr. Pictured with my adoptive mother Addie is my adoptive father. I met him when I was 8 or 9 months old. Dad was supremely practical. For example, when I was born I was diagnosed as retarded. He declared, “Well, if he’s not going to work with his head, we will teach him to work with his hands,” and for Christmas after my second birthday I got a toolbox with real tools (the toolbox and some of the tools I still have). Dad, a lifelong refrigeration technician, was skilled at repairing everything except modern home refrigerators and cars, and could build just about anything. He taught me many skills that I still use today.

My Dad and Mom, Paul J. Wilcox, Jr., and Rachel “Addie” Wilcox

(2) R Michael Frenchman. Pictured with one of the most loving people I have ever met, his wife Karen Crowe, is Michael Frenchman. He was labeled my father by my biological mother, who misled people in that respect. We met when I was in my 20s. Michael is indeed a Renaissance man, doing everything from working with UN programs, to being an independent reporter in Iran, to mentoring high school students in videography and animation, to producing live theater and video projects. Getting to know him has been one of the delights of my life. (He even inspired me to get my SCUBA certification.) Michael, along with my biological mother, made the prudent decision to place me for adoption, knowing their own lives were too chaotic at the time to raise a child.

R. Michael Frenchman and Karen Crowe

(3) George Fortini, also pictured with my Mom. A few years after my Dad‘’’s death, Mom remarried George when she was 80 years old. The next few years were wonderfully happy for them, although Mom outlived him as well. George was crazily in love with my mother, and fit in well with the family. He wasn’t Dad, but pretty close, except with an even better sense of humor and cooking ability. Most important, he was wonderful for my Mom.

Rachel “Addie” Wilcox and George Fortini

(4) Michael “Mickey” Rachlin. Well, this is the big surprise! After decades of searching, and over a decade of DNA sleuthing in search of my biological father, my cousin Audrey texted me last August and said, “I think I’ve cracked your case … but first, was there any reason you know of for your [biological] mother to have been in Texas?” I haven’t gotten to meet Mickey, as he passed away in July of 2020, before I was able to locate him. He never knew I existed, but, it is clear from other examples in his life that he would have loved to learn he had a son. He was the only child of Ezra Rachlin, who himself was a child prodigy pianist and conductor of, among others, the London Symphony Orchestra. I am still learning about Mickey through people in the family, but solving this mystery and expanding my known family has been huge, as you might imagine! I feel like I can only write in superlatives! I’m still learning what we had in common, but heard, from a stepsister, something I never was sure I would: “Oh my gosh, you look just like him!”

Michael “Mickey” Rachlin

It’s been quite a journey.

Fear

It is somewhere around 1:00 am. All but two of us are asleep.

I am hugging my daughter tightly as she sobs uncontrollably, her heart pounding with disappointment and fear.

There is nothing, really, I can say to comfort her. The best I can attempt is, “I will always fight for you,” as my own tears flow.

The Thoughts of One of Many

My name is David Isaiah Wilcox. I am black or African american or whatever you want to call me. I am also agoraphobic, but that will tie in later. I see all that is happening in the world, and I am hurt, not just because I am black but, because I am human. The blind eye that society has turned to the suffering of all those of different walks of life than the “majority” needs to stop. And it won’t be easy.

First I speak to those that are claiming to be ignorant of the atrocities of man, Then I speak to those that might hate or feel dirtied by my mere existence. First the virus known commonly as COVID-19 (called such because of the year it originated in)  Isolated us, forcing us to stay home or risk the lives of our loved ones that could be harmed or killed by the disease. Little did I know that twenty-twenty would be the year where another sickness would also be addressed, I of course speak of racism. It is odd for me to speak on this topic as I have been locked away in my home with little interaction with the outside world for much longer than the rest of you. I have been stuck at home for seven, coming on eight years now, due to a crippling anxiety disorder. I, when around people begin to ache through my whole body, this pain grows worse and worse until I just can’t take it anymore. In addition if I am outside too long I stop being able to think, and I do mean that in the most broad way possible.  If outside too long I begin to lose the ability to do simple tasks. Such as pace, five steps forward, turn, five steps back. On two occasions has it gotten this bad. Never again do I want to feel my brain turn against me to that extent.

I have strode a little off topic but I felt it was necessary to share what exactly I go through when I try to leave the boundaries of my home. Outside it seems the world has descended into chaos. When I heard what happened on May 25, 2020, I was appalled—sickened by what I was hearing. How could men, sworn to the protection of others, take the life of a man for the possibility that he paid with a counterfeit twenty dollar bill. For those that have not figured it out I am speaking of the murder of George Floyd. I found myself asking why aloud; I don’t know who I was talking to, perhaps God. Asking if all this is truly necessary, and if so to what end. Just end it already. I pleaded before and pleaded now “God, please end us all.” 

Racism is a disease, a plague that exists in the hearts of man, and can only be conquered if we as a whole acknowledge it, and strive to push past it.

Of course that would not work, we must rise above this adversity, this tragic condition that exists in far too many people. Racism is a disease, a plague that exists in the hearts of man, and can only be conquered if we as a whole acknowledge it, and strive to push past it. To make matters worse, we have a government that has decided that it is best to use rubber bullets, tear gas, and brute force to corral an unwarned and non-violent crowd of protesters. This reminds me of an event in our history, as a nation we once stood against tyranny, rallied together by the deaths of five and injuries of six. We were smaller then, and we had more problems, but how would we have responded had the very scared British Soldiers only used rubber bullets, avoiding the “Boston Massacre”? I guess we will never know. 

To close this session of writing, I should say there is hope. Not everyone is racist, for one reason or another. It doesn’t matter what pigment your skin is, if you notice you have a prejudice towards another, based on the pigment of their skin, stop, take a breath, and ask for help. It doesn’t matter who you ask, just talk about it, get it out in the open, and figure out where you picked it up from and how to get better from there. To those that deny that this is a rampant problem in our world, our lives, our souls, I ask you to look again, and ask someone about the pain that they have endured, just because they were born with a different amount of pigment in their skin.

Romancing the Code: The Literacy Narrative I Did Write

As noted previously, I had to learn the hard way about how to really focus in a good writing assignment. This is the finished product, the earlier draft of which is here: Romancing the Code: The Literacy Narrative I Wanted to Write.

This is the final version of a literacy narrative, originally written for UMass Lowell (online) College Writing I, Sec. 031, Professor Richard Keating, October 15, 2018. (Note to plagiarists: This has been submitted to the TurnItIn database, <sarcasm>so, by all means, copy away</sarcasm>.)

Douglas Wilcox
Richard Keating
UML College Writing I, Sec. 031
October 15, 2018

Romancing the Code

Phase 1: Literacy Narrative

In one of several clichés employed by twentieth century science fiction, computers are autonomous problem-solvers. They are almost never seen to be programmed by humans. The idea of a computer as a tool is refocused into its metanarrative, where the computer is an autonomous yet servile agent of its human master. A query is made, and the computer—via punched paper, data cards, audible output, or screen display—provides the answer to an enormously complex problem. Although I use computers to solve a vast number of practical problems in everyday life, programming itself, begun when I was in elementary school, provides the ultimate problem-solving experience.

The same year Star Wars was released, I met my first real computer: a Digital Equipment Corporation (DEC) PDP-8, at my town’s high school. Each terminal connected to this computer was a repurposed teletype machine. There was no screen display, only a nearly-endlessly spooling roll of paper. Each keystroke from the operator or each character output from the PDP was accompanied by a wonderfully complex sound of motors and servos moving the print element and its carriage across the platen, and hammering the right letter onto the paper (262LongRunner).

I was in love.

Through another school program, I got to play on a PDP-40, a massive device that would have made the PDP-8 weep with inferiority, had it been sentient. There I discovered the text adventure “Dungeon” (nee Zork) (Anderson, Kidder).

Creating my own text adventure game became my obsession. I had grand visions. I spent hours creating maps, and working to figure out subroutines that would be able to interpret user input, track inventory, handle world descriptions and actions, and even inject some humor while tracking hunger and thirst—“You would kill for a baloney-and-cheese sandwich.” There was no way for me to do a program this large on the DEC, but the Apple IIs that the junior high had would be perfect. They even had floppy drives, so I could store this creation on my own 5¼” diskette.

Not owning my own computer, I had to work offline—truly offline. I worked in notebooks, keeping the program flow in my head, and writing the code in longhand for later entry and debugging. I had the inspiration and functional model from other, better-written software, and a clear idea of what I wanted to do. I just had to figure out how.

A text adventure needs to provide a description of each location or room, and anything that might be portable in that room. The program needs to track the player’s location, and allow the player to move through the game world. My solution for handling this was effective, but contraindicated by speed and memory limitations at the time. The key was arrays—the computer equivalent of a numbered stack of index cards. I used an array of alphanumeric variables as a container, storing the description for each of the game’s locations by element number in the array. So, if the player moved to “location 104,” the description could be displayed by returning the description in “card” 104. That system was great for things which stayed in place, but what about portable items? For that I had to push further, but was still able to use an array structure. I invented a design where each portable item would be assigned to an item number in an array, and the data for that item would be stored in a predetermined portion of a text variable that contained, among other things, the item’s description. In the metaphor of the index cards, we might imagine that specific lines on each card record a specific kind of data, such as consistently having a title on the first line of every card.

Player movement could be controlled by setting the player’s location to a particular number corresponding to the description array and item locations. Switching the location was just a matter of coding which direction’s movement would take one to which location number and using that number to access the description and item arrays.

When I finally got enough of the modules coded and debugged, I ran it. It worked! It was slow—but it worked.

Now I work full time as a programmer, as I have for more than 15 years, and every part of my workday involves applying digital literacy directly to solving programming problems. I use my store of those skills and a variety software tools to accomplish this. The problems I solve are far more complicated—although they often still involve arrays—but they apply all the digital skills and literacy that began when I was smitten by the PDP-8, in all its teletype-driven glory.

Phase 2: Analysis

The rapid development of digital technologies in the digital era presents individuals in the emerging information society with situations that require them to employ a growing assortment of cognitive skills in order to perform and solve problems in digital environments. These skills are often referred to as “digital literacy” (Gilster, 1997; Inoue et al., 1997; Lanham, 1995; Pool, 1997), which is presented as a special kind of mindset that enables users to perform intuitively in digital environments, and to easily and effectively access the wide range of knowledge embedded in these environments (Gilster, 1997; Tapscott, 1998; EshetAlkalai, 2004; 2005) (Aviram and EshetAlkalai 1, emphasis mine).

The experience described in this narrative pertains to the phrase: “to perform and solve problems.” Problem-solving is the aspect of digital literacy that is most important in my life and career.

My first digital literacy skills were not very impressive, and many are now accessible by toddlers in today’s world of icons and GUIs: reading a directory, loading a program, running that program, and interacting with its prompts and output. Looking back over my computer literacy from childhood through the early days of my computer career, it is clear that my very meanest skills were a foundation of understanding that lasted for decades.

I worked in notebooks, keeping the program flow in my head, and writing the code in longhand for later entry and debugging.

Although the problems I solve are now more complex, the instant availability of explanations, sample code, and often complete example projects available online can make the level of problem solving significantly different. Given my skill level at the time, my limited access to computers, the nonexistence of the Internet, and a lack of established patterns, there was more room for innovation at a basic level. Innovation is still significant, but it tends to occur 

I spent hours creating maps, and working to figure out subroutines that would be able to interpret user input, track inventory, handle world descriptions and actions, and even inject some humor while tracking hunger and thirst….

It was somewhat surprising to explore this time period, and to renew my awareness of just how exhilarating computer tasks were. I was able to continually improve programming concepts and problem-solving by my sometimes weak attempts to replicate things I had seen. Writing my own text adventure was a wonderfully motivating force for improving my programming and the problem-solving that went along with it. I still advise those who want to learn a new platform on language to think of something that they really want to build as a first project.

That system was great for things which stayed in place, but what about portable items? For that I had to push further.

Although it is true that I knew far less, I was also working with a programming language that was more limited in its abilities, and accomplishing what I wanted often required a finer-grained ingenuity.  

The “growing assortment of cognitive skills” (Aviram and EshetAlkalai) is particularly evident in the development of problem-solving. Like any cognitive skill practice, problem-solving begets even more refined problem-solving, leading to gains in the complexity of problems that can be solved, and the ease with which they can be solved.

Works Cited

262LongRunner. “Teletype Model 33 ASR.wmv.” YouTube, YouTube, 16 Apr. 2012, www.youtube.com/watch?v=ObgXrIYKQjc. Online video.

Aharon Aviram and Yoram EshetAlkalai, “Towards a Theory of Digital Literacy: Three Scenarios for the Next Steps.” European Journal of Open, Distance and E-Learning. 2006. Retrieved from https://pdfs.semanticscholar.org/c680/679dc70baf4727cfd5f97b8535d62137914e.pdf?_ga=2.58484906.1842711008.1538448028-1659923920.1538448028. Document download.

Anderson, Tim. “The History of Zork.” The Wayback Machine, 1985, web.archive.org/web/20060427000213/http://www.csd.uwo.ca/Infocom/Articles/NZT/zorkhist.html. Web page.

Kidder, Tracy. The Soul of a New Machine. Little, Brown and Company, 2000. Print.

Feedback

Professor Keating’s Final Response:

Hi Doug,

As I read the final version of this exceptionally well revised essay, I reflect on how the vast majority of my students see digital literacy in terms of language, or a lexicon of terms common to a discipline. You see it in terms of a numerical logic, a binary code of understanding. That’s just as applicable, different cognition, same result!

Fine start to the semester, RSK


Romancing the Code: The Literacy Narrative I Wanted to Write

This was a relatively early draft and analysis of a literacy narrative, originally written for UMass Lowell (online) College Writing I, Sec. 031, Professor Richard Keating, September 30, 2018. The more concise version will be published separately. (Note to plagiarists: This has been submitted to the TurnItIn database, <sarcasm>so, by all means, copy away</sarcasm>.)

I loved writing this essay, but desperately needed to cut it down to a much smaller size and intense focus. (That was the hardest part of the work.) Still, this history of my first exposure to computers is something I wanted to publish. The final version of this essay is here: Romancing the Code: The Literacy Narrative I Did Write.

Computers in Digital Literacy: Problem-Solvers versus Problem-Solving

Phase 1: Literacy Narrative

When I was nine years old, the world of science fiction changed with the release of Star Wars. The film is, of course, merely space opera, and more fitting of the term science fantasy than science fiction, but it was remarkable for its technical presentation and fully realized worldbuilding, rather than for its originality or brilliance of story. (See Campbell, 2008.)

In much of twentieth century science fiction, computers are autonomous problem-solvers. They are almost never programmed by humans. A query is made, and the computer—via punched paper, data cards, audible output, or screen display—provides the answer to an enormously complex problem. The idea of a computer as a tool is reduced to its metanarrative: The computer is godlike—omniscient and often omnipresent—and not necessarily benign. Star Wars avoided this trope, turning sentient, autonomous computers into a digital underclass—droids—while presenting computers with which “humans” would directly interact in a way that was more akin to our current state of the art. The Star Wars world includes custom-purposed computer appliances, such as a “navicomputer” (Wookiepedia), as well as networked data storage and retrieval devices that would not be out of place in our own world. Although we use computers to solve a vast number of problems in everyday life, even commonly as our own navicomputer devices, it is the act of programming itself which provides me the greatest problem-solving experience.

The same year Star Wars was released, I met my first real computer: a Digital Equipment Corporation (DEC) PDP-8 (Fig. 1) at my town’s high school. Each terminal connected to this computer was a repurposed teletype machine (Fig. 2). There was no screen display, only a nearly-endlessly spooling roll of paper. Each keystroke from the operator or each character output from the PDP was accompanied by a wonderfully complex sound of motors and servos moving the print element and its carriage across the platen, and hammering the right letter onto the paper (262LongRunner). This sound was so iconic that we continue to associate it with the background noises of the era’s television newsrooms.

Fig. 1. Front panel of a PDP-8/e (Claessen).

At age nine, with no previous experience with computers, I was incapable of using them for anything beyond running simple math programs written by high school students. It is difficult to appreciate now, but in a world where pocket calculators were relatively rare, having a computer prompt for two numbers and then displaying their product or dividend was a marvel.

Fig. 2. A model ASR 33 teletype machine, like those used to communicate with the PDP-8 (Hudson).

Beyond such number-crunching, computers immediately proved to be greatly entertaining. I ran student-written programs such as “Guess,” in which the user would enter a number between 1 and 100, and the computer would respond with, “Too high,” or “Too low.” I printed text-based art, my favorite being a cartoon of Snoopy, shaking his fist and saying, “Curse you, Red Baron!” (Fig. 3). One could print banners of words where each letter in the banner’s text was composed of many smaller letters. I printed calendars for the current year, my birth year, and the unbelievably far-off year 2000.

I was in love.

This elementary-school experience did nothing to assuage my longing to use computers. Through another school program I got to play on a PDP-40 at a nearby enterprise, a massive device that would have made the PDP-8 weep with inferiority, had it been sentient. There I discovered the text adventure “Dungeon” (later and more commonly known as Zork) (Anderson, Kidder). I was enthralled with text adventures. I was determined to program my own.

Fig. 3. Snoopy ASCII art (Modified from asciiworld.com).

In my junior high years, we had access to Apple II computers repackaged by Bell & Howell to be nearly indestructible. We also secured access to the PDP-8 at the high school. By this time the teletype machines were gone, replaced mostly by dot-matrix printers from DEC, and supplemented by three glorious CRT terminals, VT05s (Fig. 4). DEC had donated these CRTs to my junior high school’s HAL (High Ability Learner) program, but I was the first to negotiate access to them. I stayed after school until 5:00 every day I could, just to get time on these. I began to learn BASIC, back in the ancient times when it still required line numbers.

Fig. 4. A DEC VT05 serial terminal. (Autopilot)

Not having a computer of my own presented a problem that might seem odd today. I had to work offline—truly offline—without even a search engine, and then try to code what I had done in the time I could get access to the computer. So, I worked in notebooks, keeping the program flow in my head, and writing the code in longhand that I would hope to later enter and perfect.

I tried my hand at a number of different programs, but creating my own text adventure game became my obsession. My first attempt at a text adventure was quite limited. It offered nothing more than multiple-choice prompts to make action choices, a far cry from the verb-object command-parsing that Zork could do. My program was shameful, borrowing scenes and catch phrases from Tom Baker’s incarnation of Dr. Who, and not much more complex than a choose-your-own-adventure book. One-quarter of the way through, I ran the program, and the computer spit out an inexplicable error. It was not the usual problem of a missing parenthesis or a syntax error, but something I could not diagnose.

“Doc” (Donald Harrison), the high school’s computer science teacher, helped me out. Although my program was tiny, it was too big for the execution space on the PDP-8. He taught me how to link multiple programs so I could jump to one from another, and I was able to complete my first adventure. It did teach me the basics of programming, even though what I wrote was not much more than a pile of print and goto statements, hooked together with the occasional numeric input. Even so, knowledge of programming meant problem-solving.

I had grander visions. My next adventure was more original. I spent hours creating maps, this time avoiding established fandom, and more time figuring out subroutines that would be able to interpret input, track inventory, handle world descriptions and actions, and even inject some humor while tracking hunger and thirst—“You would kill for a baloney-and-cheese sandwich.” There was no way for me to do a program this large on the DEC, but the Apple IIs that the junior high had would be perfect (Fig. 5). They even had floppy drives, so I could store my creations on my own 5¼” diskette. Innovation was exhilarating.

There were no obvious patterns to follow, and the BASIC language itself was somewhat limited. There were no premade frameworks. I had books, which were very limited, and often inapplicable to a particular system just when I needed to learn something advanced. (The deeper one went, the less universal computer languages with the same name became—radically different from today’s write-once-deploy-everywhere languages like Java.) I had the inspiration and functional model from other, better-written software, and a clear idea of what I wanted to do. I just did not know how.

Fig. 5. A Bell & Howell Apple II+, sporting the same floppy drives we used. (Mightyohm)

In a text adventure, one of the most important things is providing a description of each location or room, and anything that might be movable in that room. In that context, the program needs to track the player’s location, and allow the player to move in a specific direction, such as “move north.” My solution may have been clever, if contraindicated by speed or memory limitations at the time. I used an array (something like a deck of cards) of alphanumeric variables as a container, storing the location description for each “room” by element number in the array. So, if the player moved to “location 104,” the description could be displayed by accessing a function that would return the description in “card” 104.That system was great for things which stayed in place, but what about portable items? For that I had to push further, and I invented a design which was not dissimilar to what is now called a bitmap. Each portable item would have an item number, but the data for that item would be stored in a predetermined part of a text variable that contained, among other things, the item’s description. In a simple example, the first three characters of the text variable might contain the location number, which could even be a number showing it to be in the player’s own inventory. The description of the item would then be the fourth character in the text to the end of it. Now we use object-oriented languages to create models of such things, in a way that often mimics the real world. A car is often used to illustrate this. A car is a generalized object, and has properties such as color, model, size, number of passengers, make, year of manufacture, or VIN.

Player movement could be controlled by setting the player’s location to a particular number, and the same location number could be used to get the description of the location and then display any portable items that were there. Switching the location was just a matter of coding which direction’s movement would take one to which location number.

When I finally got enough of the modules coded and debugged, I ran it. It worked! There was one last problem: speed. Between entering a command and waiting for the program to do something was a pause of 5 or 10 seconds. But it worked.

More than a decade later, I encountered the published source code of Zork (and even got it to run in a Windows FORTRAN environment). I was blown away by the simplicity of Zork’s code. The huge, complicated processing modules I had created were not used. Zork had a simple data structure, with a number of pointers, in some ways similar to my array-storage design, but infinitely more elegant.

Now I work full time as a programmer, as I have for more than 15 years, and every part of my workday involves applying digital literacy directly to solving programming problems, ensuring our software is secure, and giving our customers new or better experiences. I use a dizzying array of software tools to accomplish this. The problems I solve are far more complicated, but they apply all the digital skills and literacy that began when I was smitten by the PDP-8, in all its teletype-driven glory.

Someday, we may indeed interact with our computers like much of our science fiction predicted. When that day arrives, however, it will surely include its own tangle of media literacy problems to be solved.

Phase 2: Analysis

The rapid development of digital technologies in the digital era presents individuals in the emerging information society with situations that require them to employ a growing assortment of cognitive skills in order to perform and solve problems in digital environments. These skills are often referred to as “digital literacy” (Gilster, 1997; Inoue et al., 1997; Lanham, 1995; Pool, 1997), which is presented as a special kind of mindset that enables users to perform intuitively in digital environments, and to easily and effectively access the wide range of knowledge embedded in these environments (Gilster, 1997; Tapscott, 1998; EshetAlkalai, 2004; 2005). (Aviram and EshetAlkalai, 2006, emphasis mine)

My experience, described in this narrative, tends to present two foci: “a growing assortment of cognitive skills” and “to perform and solve problems.” Although the two are intrinsically linked, problem-solving is the one that is most unique to my own narrative., and the one that is most important in my life and career.

So, I worked in notebooks, keeping the program flow in my head, and writing the code in longhand that I would hope to later enter and perfect.

My first skills were not very impressive, and are now accessible by toddlers in today’s world of icons and GUIs: reading a directory, loading a program, running that program, and then interacting with its prompts and output. Tracing computer literacy from childhood through the early days of my computer career, it is clear that my very meanest skills were a foundation of understanding that lasted for decades. (RUNH was the command used to launch a program, and I only recently learned that that it was used to launch a FORTRAN module on the PDP.)

I spent hours creating maps, this time avoiding established fandom, and more time figuring out subroutines that would be able to interpret input, track inventory, handle world descriptions and actions, and even inject some humor while tracking hunger and thirst….

It was somewhat surprising to explore this time period, and to renew my awareness of just how exhilarating computer tasks were. Computers were often about games. I was able to continually improve programming concepts and problem-solving by my somewhat weak attempts to replicate things I had seen. Writing my own text adventure was a motivating force for improving my programming and the problem-solving that went along with it.

There were no obvious patterns to follow, and the BASIC language itself was somewhat limited. There were no premade frameworks. I had books, which were very limited, and often inapplicable to a particular system just when I needed to learn something advanced.

Although the problems I solve are now more complex, the instant availability of explanations, sample code, and often complete example projects can make the level of problem solving significantly different. Although it is true that I knew far less, I was also working with a programming language that was more limited in its abilities, and accomplishing what I wanted often required a finer grained ingenuity.

Works Cited

262LongRunner. “Teletype Model 33 ASR.wmv.” YouTube, YouTube, 16 Apr. 2012, www.youtube.com/watch?v=ObgXrIYKQjc. Online video.

Aharon Aviram and Yoram EshetAlkalai, “Towards a Theory of Digital Literacy: Three Scenarios for the Next Steps.” European Journal of Open, Distance and E-Learning. 2006. Retrieved from https://pdfs.semanticscholar.org/c680/679dc70baf4727cfd5f97b8535d62137914e.pdf?_ga=2.58484906.1842711008.1538448028-1659923920.1538448028. Document download.

Anderson, Tim. “The History of Zork.” The Wayback Machine, 1985, web.archive.org/web/20060427000213/http://www.csd.uwo.ca/Infocom/Articles/NZT/zorkhist.html. Web page.

Asciiworld.com: Snoopy, ASCIIWorld.com, http://www.asciiworld.com/-Snoopy,512-.html.

Autopilot. “File:VT05.jpg.” The original DEC serial terminal, the VT05, Wikimedia Commons, 6 May 2012, https://commons.wikimedia.org/w/index.php?curid=19364852. Online image.

Campbell, Joseph. The Hero with a Thousand Faces. New World Library, 2008. Print.

Claessen, Simon. “File:Digital PDP-8F.Jpg.” PDP-8/F Front Panel, Wikimedia Commons, 25 Sept. 2014, commons.wikimedia.org/w/index.php?curid=63802103. Online image.

Hudson, Trammell. “Model ASR33 Teletype.” Model ASR33 Teletype – Trammell Hudson’s Projects, Trammell Hudson, 29 Oct. 2017, trmm.net/Model_ASR33_Teletype. Web page.

Kidder, Tracy. The Soul of a New Machine. Little, Brown and Company, 2000. Print.

Mightyohm. “File:Bell_and_Howell_Apple_II.jpg.” Bell and Howell Apple II+, Wikimedia Commons, 07 Jan. 2011, commons.wikimedia.org/wiki/File:Bell_and_Howell_Apple_II.jpg. Online image.

“Navigation Computer.” Wookieepedia, FANDOM, 25 Apr. 2015, starwars.wikia.com/wiki/Navigation_computer. Web page.

Astronomy from the Driveway

Took Sarah ‘s father out planetgazing (finally) to the exotic location of his driveway.

Fabulous viewing of Jupiter and Saturn tonight with his NexStar 130 SLT and the lenses our dear friends gave us (one advantage of driving to Indiana, I could bring more stuff).

I have finally, definitely, seen the Great Spot! In our view Jupiter was inverted as in the image just above, but the 2 major cloud bands and the Great Spot were clearly visible! (As were all 4 Galilean moons.)

Saturn and Titan made for a fine sight as well.

Bad Dog!

Juno, do you know what this is?

This is an animal warning card the US Post Office uses.

Do you know what it says about you?

Friendly.

The mail carriers believe you are friendly. Mail carriers, Juno. Think about it. A dog’s mortal enemies. Friendly.

Bad dog!