Tag Archives: computer

2017-03-07: Castle Knob website

The original CK website was hand-coded with HTML and CSS. It isn’t very good, and hasn’t been updated in quite a while. I intend to replace it with a new website based on WordPress. I will use as much of the original content as possible.

Tasks:

  • select a template
  • create basic pages from existing content
  • add new content
  • ?

 

2016-10-03: DreamHost

When I found that I could purchase the blackstone.name domain, I had to find a hosting service to actually run the servers. After looking at several companies, I settled on DreamHost (DH). Their plans seemed inexpensive, and they seemed pretty responsive to issues that came up in their systems. Of course, there were a lot of complaints (on the internet! imagine!) about their reliability, but the statistics didn’t seem too bad. I picked the cheapest plan, and have been pretty well satisfied since May 2007.

At this time, I have the following domains registered:

  • blackstone.name
  • castleknob.com
  • castleknob.org

For a couple of years I also registered castleknob.net, but decided it wasn’t necessary.

Within the domains, the following answer to http:

  • camino.blackstone.name – custom-coded to show Susan’s status updates and pictures from her walk on the Camino Frances to Santiago in 2007; I used a photo album organizer called Gallery (http://gallery.sourceforge.net) to show her pictures.
  • chris.blackstone.name – this is a WordPress blog set up by and for Chris to post descriptions and pictures from her trip to Southeast Asia.
  • mike.blackstone.name – a WordPress “blog”; you’re reading it!
  • castleknob.com – a custom-coded site to show the publicly available works published by Castle Knob. This will eventually be replaced by a more robust WordPress site.

In addition to the web services, DH provides email. The following addresses are active; several others are forward-only to one of these:

  • mike1@blackstone.name (also anything that has “mike” in it)
  • susan@blackstone.name
  • chris@blackstone.name (forwards to her gmail account)
  • mike1@castleknob.com

Other addresses are set for Mom and Dina, and someone named Steven Blackstone. When I set up blackstone.name, I offered email service to anyone named Blackstone; Steven is the only non-relative who took the offer. However, when I had a problem with email, I reset several passwords; shortly after, I heard from Steven that he was relying on the service. I restored his access, and he also requested addresses for other members of his family: Thijs, Hugo and Daphne. They seem to be in the Netherlands.

The administration of these services requires very little effort. The most predictable is annual renewal of the domains. Occasionally there have been glitches with email, which have been handled promptly by DH customer service. Administration is handled through DH’s web-based control panel at dreamhost.com (passwords available on request).

 

2016-08-24: Cyc

I first became aware of the Cyc artificial intelligence (AI) engine around 1984, while working for Unisys, and have followed its progress ever since. From time to time I have downloaded and fiddled with the OpenCyc version; this basically contains a relatively large ontology knowledge base. More recently I’ve learned that the more-complete ResearchCyc can be used for non-commercial purposes. According to Wikipedia, “In addition to the taxonomic information contained in OpenCyc, ResearchCyc includes significantly more semantic knowledge (i.e., additional facts) about the concepts in its knowledge base, and includes a large lexicon, English parsing and generation tools, and Java based interfaces for knowledge editing and querying. In addition it contains a system for Ontology-based data integration.”

I am interested in exploring these additional capabilities. One way to explore them might be to try to implement Asimov’s Three Laws of Robotics. However, I would start with more limited knowledge entry and query exercises.

 

2015-12-21: XinX

I first learned of Ted Nelson’s Xanadu vision from his 1974 book Dream Machines, one-half of a dual book with Computer Lib, and in the later (1981) Literary Machines. I don’t recall when I read these.

Eventually I realized that Nelson wasn’t getting anything into production, and started to fiddle with the idea of implementing something similar myself. I tentatively called my approach XinX. This was based on the cute notion of a recursive acronym, and stood for “XinX is not Xanadu”.

It’s a long shot that I will ever devote much effort on this project, but Nelson’s vision of a hypertext/hypermedia system still has a lot appeal for me. In addition to being a meme, it should support some interesting applications of memetics.

Status:

2015-12-21: vision only.

 

2015-11-27: Meta-Dimensional Inspector

MDI is my 3D graphics experiment. The idea is to take datasets that have several attributes, and define multiple mappings of their attributes into various forms of 3D spatial coordinate systems. Once the mappings are defined, the user can switch and transition among them and observe how relationships among data items change.

Status:

2015-11-27: The basic framework works for two mappings.

2016-01-31: The primary functions have been completed: multiple maps, saving & loading maps, saving & loading apps, attaching one background image to a map (with transparency). Remaining functions include picking objects, centering a picked object, displaying data for a picked object, editing data for a picked object.

2016-03-18: Susan demonstrated it on part of the turtle-tracking database at Jug Bay. Apparently it made a good impression.

 

2015-05-22: Becoming Steve Jobs

Becoming Steve Jobs:

The Evolution of a Reckless Upstart into a Visionary Leader (2015)

by Brent Schlender (1956-) and Rick Tetzeli (?)

This is not a biography in the same vein as Walter Isaacson’s Steve Jobs, but is in part a reaction to that work. Many people who knew Jobs well were disappointed in Isaacson’s book, and others (e.g., me) were disappointed in Isaacson’s lack of technical insight into the issues Jobs addressed in his career.

The focus is on the developmental journey that took Jobs from being a terrible CEO of Apple in 1985 to the preeminent CEO of our time after his return to Apple. Schindler was in a good position to observe Jobs over this period. He also had the cooperation of many people who worked with Jobs.

I recommend this book over Isaacson’s, although I didn’t find that book terrible.

There is an interesting quote at the end, from Jony Ive.

Steve loved ideas and loved making stuff, and he treated the process of creativity with a rare and wonderful reverence. He, better than anyone, understood that while ideas ultimately can be so powerful, they begin as fragile, barely formed thoughts, so easily missed, so easily compromised, so easily just squished. His was a victory for beauty, for purity, and, as he would say, for giving a damn.

This is an excellent description of my view of memetic and creativity.

2007-02-24: iWoz

iWoz

Computer Geek to Cult Icon: How I invented the personal computer, co-founded Apple, and had fun doing it (2006)

by Steve Wozniak (1950-) with Gina Smith (?-)

This is more interesting than I thought it would be. Though Gina Smith helped with the actual writing, the voice seems to be the authentic Woz, as I’ve heard him in interviews.

The best parts for me are the story of the stages by which he developed and learned the complex of ideas that went into the Apple II. The later parts are less interesting.

When he talks of his personal life, and his interest in cognitive development, I was interested in the “flying tours” he gave his infant kids (and other peoples’ kids), where he allowed them to determine the route through the house by looking and the muscle movements he learned to interpret.

 

2005-09-25: What the Dormouse Said

What the Dormouse Said

How the Sixties Counterculture Shaped the Personal Computer Industry (2005)

by John Markoff (1949-)

The premise of this book appears to be that the personalities of the people who moved computing from the glass-enclosed priesthood into the living room were shaped from the major currents of the so-called “counterculture” of the 1960s. Among these, Markoff emphasizes drugs (especially LSD), anti-war feelings (including avoiding the draft by working in defense industries), and general anti-establishment feeling.

The book is weak in building the case. Certainly some of the key participants shared the attitudes that were widely held in place and time they lived, but Markoff doesn’t really make a case that these “shaped” the industry. It is just as plausible that the industry would have arisen from mainly technical considerations.

The part I found most interesting was chapter 5, Dealing Lightning. This describes the “Mother of all demos” by Douglas Engelbart in 1968, where he showed his Augment system. The nature and impact of the demo are well known, but Markoff has documented much of the behind-the-scenes activity that made the demo work. He names the key people and describes their roles. This chapter alone made the book worthwhile for me.

 

2007-06-14: The Emotion Machine

The Emotion Machine

Commonsense Thinking, Artificial Intelligence, and the Future of the Human Mind (2007)

by Marvin Minsky (1927)

This is a preliminary report, because the book is overdue. I first reported on a draft version of this book in 2004. At that time it didn’t have a subtitle. Now that it’s out, I thought I’d read it again. Unfortunately, I’ve already renewed it the limit, and will have to restart it later.

I’m on page 83. The pages I’ve marked are upper 47 and lower 63.

On page 47, Minsky shows his six-level model of mental activities:

  • Self-conscious emotions
  • Self-reflective thinking
  • Reflective thinking
  • Deliberative thinking
  • Learned reactions
  • Instinctive reactions

These are fed at the bottom by “Instinctive Behavioral Systems”, and moderated at the top by “Values, Censors, and Ideal”.

This will bear thinking about (deliberative thinking, I suppose).

On page 63, he introduces the notion of public imprimers, an idea that helps explain the influence of celebrities on public opinion.

More later

 

2004-10-10: The Emotion Machine (draft)

The Emotion Machine (drafts 2003-2004)

by Marvin Minsky (1927-)

This book has not yet been published, or even written. However, Minsky posted early drafts and solicited comments.

The book is something of a sequel to his Society of Mind (SOM), but with a somewhat different aim. SOM was an attempt to describe the mind as a collection of facilities, each of which was in principle implementable in an AI framework; EM is more of a thoughtful look at the nature of the mind, more philosophical, but with an eye to implementation. Unfortunately, implementation is viewed from quite a distance.

The work is (at this time) organized in nine chapters. The last has been released with less than half of its content, judging by its table of contents. Nearly five months elapsed between the release of chapter 8 (and updates to most of the earlier chapters) and the first part of chapter 9.

I sent comments on the first batch of chapters, which seemed to be graciously received. Minsky seemed to appreciate my offer to proofread a later draft. However, it was not until reading chapter 9 that I felt like recording some notes for myself.

The title of chapter 9 is The Self, and he repeats his earlier position that the single-self view, while perhaps useful for ordinary life, is unsuitable for understanding how minds work. Not surprisingly, he believes a network of limited mind-like objects (perhaps I should suggest he call them mindlets), which he calls personae, capable of drawing on memory and formulating questions and answers to other personae, is a model on which to build a workable and working view.

Among the features of his view is the ability to learn Ways To Think, and to control the way we think. Reading this I was struck with the way in which my own thinking has grown disordered over the years, and inspired to attempt to correct this deficiency.

The point of the title is that our minds are largely ruled by emotion. Each major change in the emotional state of our mind as a whole is accompanied by the expression (even if only to one’s ‘self’) of a different sub-personality. For instance, I might be trying to work on my memetic work, and something reminds me of an emotionally painful episode from my past. The switch to attending to the memory is accompanied by changes in attitudes, even body attitude, related to the different state of mind in the two different kinds of thinking.

Minsky wonders about traits: why is there such a thing as personality traits? To start, consider a list he uses: disciplined, honest, attentive, and friendly. Society reinforces the recognition of these traits. If we value them in others, we also might try to develop them in ourselves. If I wish to be disciplined, to acquire the Ways To Think associated with being disciplined, I will examine that trait and find activities associated with it, such as keeping prioritized lists of things to do; the activities might include meta-activities, such as reviewing and updating the lists of things to do.

In fact this is just what I have decided to try. In the past I have dismissed the utility of such schemes as the Franklin Planner, with its orderly lists. However, the principles behind it are clearly conducive to developing disciplined Ways To Think. It seems worth a try.

I will create a new report with more material related to the content of the book after it comes nearer completion. At that time, I might also comment on the results of my endeavor to become more disciplined in my thinking.

Note that I also started reading the finished book in 2007:

2004-09-22: The Inmates Are Running The Asylum

The Inmates Are Running The Asylum

Why High-Tech Products Drive Us Crazy and How to Restore the Sanity (1999)

by Alan Cooper (1952-)

This book is about the value of the discipline known as interaction design. The value occurs when the discipline is applied near the beginning of the design process for software-based products.

Cooper heads a firm, Cooper Interaction Design. (He is also known as the ‘Father of Visual Basic’.) The book is very persuasive, and I have already recommended it to a few people. He wrote an earlier book called About Face, which I will also look for.

He opens with a set of riddles: What do you get when you cross a computer with a camera? An alarm clock? A car? A bank? Of course, in every case the answer is the same: A computer!  He goes on to describe a series of horror stories about failures of human usability of various products.

The feature that makes software-based products different from traditional mechanical or electronic products is ‘cognitive friction’ – the requirement that people have to think about what is going on in the product in order to use it effectively, and that the rules can change unpredictably. Much of the problem is traced to the different ways that such devices are seen by programmers and by ordinary people – homo logicus vs. homo sapiens. The joke is that design is what the programmers do in the 20 minutes before they start to code. Cooper promotes design that focuses not on what the screen looks like, or how the modules inside are connected, but at how users will interact with the product.

In the absence of a disciplined approach to determining the nature of a product, we get featuritis and whatever appeals to the programmers. Cooper calls this ‘dancing bearware’. It’s not remarkable for the elegance of the moves, but merely that it can dance at all. He describes a list of common faults with bad software:

  • Software forgets – every time you use a program, you learn a little bit about it, but it doesn’t learn anything about you: what features you use most, how you work, etc.
  • Software is lazy – programs don’t work very hard for their users. They might work very hard at things the programmers want them to do, even if they aren’t important to the user, but those are often unimportant to users.
  • Software is parsimonious with information – such as the ATM that doesn’t tell you how much is available in your account before it asks how much you want to try to get out. We often make pencil/paper notes about what a program is doing, because it isn’t putting that information where it would be useful to us.
  • Software is inflexible – they act the same when there are hundreds of items in a queue as when there is just one. (Programmers only know three numbers: 0, 1, and infinity.) Programs aren’t fudgable in the way manual processes are.
  • Software blames users – problems the programmer didn’t want to deal with are dumped in the user’s lap, via cryptic dialogs, or just crashes.
  • Software won’t take responsibility – they excessively ask “Are you sure?” when asked to perform simple tasks like deleting a file, when they really ought to be able to recover from situations where we simply change our minds.

On page 95, he gives a list  of programmer characteristics from Steven Covey, and then goes on to show how programmers build software according to their own ideas of what users should want, if only they were more like programmers:

  • Programmers trade simplicity for control – homo logicus desires to have control over things that interest them, and the things that interest them are complex, deterministic systems. Look at the Windows “Find File” dialog box; most users have no interest in the options presented, but programmers think everyone desires to have that much control over the search function.
  • Programmers exchange success for understanding – most programmers and engineers have disassembled a mechanical clock or similar device to see how it works, but are not too disappointed if they can’t get it working again – as long as they gained some understanding. He repeats a joke:

Three people are scheduled for execution: a priest, an attorney, and an engineer. First the priest steps up to the gallows. The executioner pulls the lever to drop the hatch, but nothing happens. The priest claims divine intervention and demands release, so he is set free. Next, the attorney takes a stand at the gallows. The executioner pulls the lever, but again nothing happens. The attorney claims another attempt would be double jeopardy and demands release, so he is set free. Finally, the engineer steps to the gallows, and begins a careful examination of the scaffold. Before the executioner can pull the lever, he looks up and declares, “Aha, here’s your problem.”

  • Programmers focus on what is possible to the exclusion of what is probable – if something might happen, however unlikely or unimportant, it is something the program must be built to handle. And such ‘edge cases’ generally leave their traces in the user interface. Programmers are “generous in their selfishness”: they give us lots of what they want.
  • Programmers act like jocks – just as high-school jocks dominated the locker room, the playing fields, and the social world, programmers dominate others by flaunting their ability to understand and manipulate the digital world that so many others depend on. This gives them enormous power to determine what features will or won’t be implemented, and the shape of the resulting interface.

The programmer culture values reuse of code and features (which is why there are APIs), so programs are built with the components they have (every problem looks like it needs a dialog box). Programmers love difficult problems, but don’t value difficulty for its own sake. If they see a non-programmer making decisions that require an unfamiliar and evidently non-useful effort, they will subvert the implementation to avoid it.

Cooper’s approach to interaction design is to discover the types of users, and what they want and need to do with the product. These are described as personas, given names and mini-biographies, and become the focus of the design effort. Usually one or two key personas are recognized as they key types, and the design proceeds by identifying how best to meet their needs.

Design is base don the goals of the key personas. Goals are personal, corporate, practical, or false. Personal goals include: not feel stupid; not make mistakes; get an adequate amount of work done; have fun (or at least not be too bored). Corporate goals include: increase our profit; increase our market value; defeat our competition; hire more people; offer more products or services; go public. Practical goals include: avoid meetings; handle the clients’ demands; record the client’s order; create a numerical model of the business. False goals include: save memory; save keystrokes; run in a browser; be easy to learn; safeguard data integrity; speed up data entry; increase program execution efficiency; use cool technology or features; increase graphic beauty; maintain consistency across platforms. Cooper mentions the concept of hygienic factors and goals, such as keeping a well-lighted workplace. This isn’t a primary goal, but without lights no one could accomplish their real goals.

The personal goals of users are usually emotional rather than rational, but strongly reflect human nature for a very broad cross-section of humanity, unlike the goals of programmers. To meet emotional needs, software should be polite to its users. As he says, “polite software is interested in me; is deferential to me; is forthcoming; has common sense; anticipates my needs; is responsive; is taciturn about its personal problems; is well informed; is perceptive; is self-confident; stays focused; is fudgable; gives instant gratification; is trustworthy.

The design process creates scenarios (use cases) of two kinds: daily use and necessary use. The daily use scenarios are primary drivers of the design. They need the most robust interaction support; must be supported by good, built-in pedagogy; and provide shortcuts as the user gets used to them. Necessary use scenarios need robust pedagogy, but less need for shortcuts, as users won’t encounter them frequently enough to get bored. Other types include edge-case scenarios that can be ignored during the interaction design (deferred to the program design).

He recommends a technique called inflecting the interface. Within any scenario, many features are irrelevant, and can be suppressed in the interface. Thus they won’t intrude on the user, and distract her from the interface features she needs to find and use.

Cooper makes a case for thoroughly documenting the interaction design, leaving no loopholes for the programmers. Surprising to me, he doesn’t mention the practice of using the scenarios to develop acceptance tests. This would give managers some leverage over programmers.

This book should have been more influential in the five years since it was written. I only stumbled across a mention of it by accident. I will probably buy it, and insist that others read it.

 

0000-00-00: Computers

Computers have been a part of my life since 1965. The very first computer I ever saw was the Semi-Automatic Ground Environment (SAGE). This was part of the air defense network to protect the U.S. from the Soviet Union’s nuclear-armed bombers. In 1965, my high-school class visited the installation at Norton AFB in San Bernardino, California. The computer was based on bulky and hot vacuum tubes, in racks occupying two floors of a very large concrete cube on the base. We actually walked among the racks, which towered over our heads. An off-hand remark by our guide alarmed us, when we were told the computer occasionally “crashed”. In 1965, the meaning of that word involved large pieces of stuff colliding or falling over. It made us very nervous. Wikipedia has an article about SAGE. A Google image search shows many pictures of the computer and building.

The list below is in approximately the order I was exposed to various kinds of computers; (W) indicates a work computer and (P) indicates a personal computer.

  • IBM 1401 (W)
  • IBM 7094 (W)
  • IBM 360/65 (W)
  • Univac 1108 (W)
  • DEC PDP-1 (W)
  • IBM 360/55 (W)
  • Varian ? (W)
  • Data General Nova (W)
  • MOS Technology KIM-1 (W)
  • Univac 3760 (W)
  • microcoded ? (W)
  • Univac 494 (W)
  • TI Explorer (W)
  • Sperry PC (P, W)
  • Unisys 2200 (W)
  • Apple Macintosh II (W)
  • Apple Macintosh IIfx (P)
  • Atari 400 (P)
  • Apple PowerBook 1400c (P)
  • Apple PowerBook G3 (P)
  • Apple PowerBook G4 (P)
  • Apple MacBook Pro (15″ late-2008) (P)
  • Apple MacBook Pro (15″ mid-2012) (P)
  • Apple MacBook Pro (15″ Retina mid-2015) (P)
  • Apple iPod Touch (P)
  • Apple iPhone 3GS GB (2 P)
  • Apple iPhone 4s 16 GB (2 P)
  • Apple iPhone 5s 32GB (2 P)
  • Apple iPad (P)
  • Amazon Kindle (models? P)
  • Hewlett Packard ProBook 6450b (also earlier model) (W)

A lot of my work has involved programming in a variety of languages. The list below doesn’t include languages used only in programming classes, such as Algol 60, Macsyma, and SNOBOL.

  • Fortran
  • IBM JCL
  • Univac 1100 Assembler
  • PDP-1 machine language and assembler
  • Varian ? machine language and assembler
  • Data General Nova assembler
  • KIM-1 assembler and 6502 machine language
  • 494 Assembler
  • Univac MASM (meta-assembler)
  • 3760 Assembler (MASM)
  • microcode Assembler and machine language (MASM)
  • PASCAL
  • Common Lisp
  • Knowledge Engineering Environment (KEE)
  • Golden Common Lisp
  • Basic
  • JavaScript
  • Visual Basic for Applications