A. Jesse Jiryu Davis

Category: Review

Moraff's World

A long-quiescent memory got knocked loose. I recalled that I'd played Moraff's World obsessively as a kid, sneaking out of bed at night to play it on my mother's Tandy 3000. So I downloaded the game and played it for a few hours this week in a [...]

A long-quiescent memory got knocked loose. I recalled that I'd played Moraff's World obsessively as a kid, sneaking out of bed at night to play it on my mother's Tandy 3000. So I downloaded the game and played it for a few hours this week in a DOS emulator.

Moraff's World is a fantasy role-playing game from 1991. It has the usual mechanics of the genre: You choose a race and a class like Fighter or Wizard, explore dungeons, and gain money and items by killing monsters. But Moraff's World is distinguished by its insane complexity. Characters can be one of eight races and seven classes. Killed monsters drop money in seven currencies. There are over a hundred distinct spells, and they come in books, scrolls, wands, and papers. Some characters can learn wizardly or priestly spells, some can learn both. The main UI looks like the bridge of a nuclear submarine:

Moraff dungeon

You look in all four directions at once. There is also an overhead map, like this section of town:

Moraff town

It is the player's job to memorize that yellow squares are temples, red are inns, and so forth.

In a modern role-playing game like Diablo, the town feels alive: music plays, rain patters down, random characters walk around and talk. Moraff's town is vacant and still.

Moraff town 2

It is not characters who speak to you in Moraff's World, but the programmer Steve Moraff himself. When you enter a bank, the options include PRESS 4 TO ROB BANK. Do so, and the game replies, COME ON! DO YOU REALLY THINK I'D LET YOU ROB MY OWN BANK? PRESS ANY KEY TO CONTINUE.... You are not immersed. You are explicitly in a game designed by a single programmer.

The experience does not resemble a fantasy movie like Lord of the Rings as much as it does reading a fantasy book. When I see a balrog in the movie, I see its fiery skull and its whip, pretty much the same as other viewers. How different from reading Tolkien's description: "a great shadow, in the middle of which was a dark form, of man-shape maybe, yet greater; and a power and terror seemed to be in it and to go before it." I make my own balrog from these words. In the same way, in the absence of any sound or animation, I supply the missing life to Moraff's static world.

This is not to say that the game lacks charm. It is incredibly idiosyncratic. The monsters seem drawn in MS Paint by an exuberant child. Consider this werewolf, and what appears to be a Hawaiian zombie:

Moraff monsters

The game's engineering is as primitive as its art. Graphics are drawn in layers with the Painter's Algorithm. With each step your character takes, the views in all four directions are re-rendered. The walls are slowly drawn on screen from farthest to nearest. Even on my modern laptop this can take some time when looking down a long hallway. But the technique lends itself to fun effects, like the translucent Shadow Minidragon, partially drawn over the walls behind him:

Moraff minidragon

Moraff applied a similar method to the Wilderness. You may climb a ladder out of town to reach this randomly-generated landscape. It takes several seconds to calculate. (It took several minutes on my mother's Tandy.) If you hit H for Help, Moraff tells you that there's no point exploring the wilderness. It only leads to other dungeons which are all the same. It's a sightseeing expedition.

Moraff wilderness

When I downloaded it this week, my first impression of this Shareware-era game was nostalgic. Back then, games were envisioned by a few people or, in the case of Moraff, one programmer-auteur. There was room for a folk genius to succeed with a very weird game. Nowadays he'd be drowned out by games with hundred-million-dollar budgets like Grand Theft Auto V.

But on second thought, the industry is simply more mature, with a bigger audience and a broader range of games. There's still a place for avant-garde titles developed by small teams, like Braid or Sword & Sworcery. Both use the vocabulary of the simple video games we played as children to evoke grown-up ideas.

Braid is a platform-jumping game, explicitly an homage to Super Mario Brothers. There's even a princess to rescue. But the protagonist has mysterious powers to slow or reverse time, and the game asks: if you had these powers, what would you be? Does the princess want to be rescued? Are you playing the good guy or not?

Braid

In the iPad game Sword & Sworcery, the graphics are deliberately archaic and pixellated, but the themes are innovative. The game makes surprising demands regarding its place in the player's life. After you beat a level, for example, Sword & Sworcery pauses for a minute and suggests you take a break and do something else. There are levels that can only be played near a full moon, or a new moon. I changed my iPad's date so I could play them immediately. The designers' goal—to make me aware of my addictive game-love—was accomplished.

Sword and Sworcery

The other striking idea of Sword & Sworcery is that one's character does not level up. Instead, with each victory she is weakened. She must keep fighting the same monsters but they grow tougher as the protagonist becomes more vulnerable. At the end, she beats the final boss, but she is retching blood, and flings herself into the river to die. By comparison, role-playing games where your character gains godlike powers seem like childish wish-fulfillment. If you were really a warrior come to save a town, this would be how you'd end up.

Review of "MongoDB Applied Design Patterns" by Rick Copeland

There's a lot of bad advice out there regarding MongoDB. As I wrote in my last review, even smart sources can encourage risky methods. Soon, I hope, there will be as much good MongoDB instruction from experts outside 10gen as there is good [...]

There's a lot of bad advice out there regarding MongoDB. As I wrote in my last review, even smart sources can encourage risky methods. Soon, I hope, there will be as much good MongoDB instruction from experts outside 10gen as there is good third-party SQL instruction. For now, know that you can trust Rick Copeland.

Copeland's new O'Reilly book on MongoDB complements O'Reilly's other five: the majestic Definitive Guide (due for a second edition in June), Scaling MongoDB, 50 Tips and Tricks, and the MongoDB books for Python and PHP.

After you've read the Definitive Guide, a good candidate for your second MongoDB book is Applied Design Patterns. (Disclosure: I was paid to critique an early draft.) Copeland's intended audience has basic MongoDB competence and wants application examples that optimize either for scalability or maintainability, plus the principles to guide new designs. Copeland also assumes basic SQL knowledge, and presents most examples in contrast to conventional SQL solutions, a method I find distracting and irrelevant. He identifies some common application types (product catalog, CMS, analytics, etc.) and provides for each a schema and application logic. He goes far beyond prior works when he discusses performance, consistency guarantees, and sharding considerations for every application.

MongoDB Applied Design Patterns

In Part 1, Copeland discusses the basic questions about MongoDB schemas. Right away, he identifies what makes nonrelational design different:

There is no longer a "garden path" of normalized database design to go down, and the go-to answer when faced with general schema design problems in MongoDB is "it depends".

MongoDB requires optimization up front, more often than SQL schema design does. (Armin Ronacher noticed this too a few months ago.) Most often the question is whether to embed or to link, and what data should be normalized or denormalized. Copeland uses an extensive description of disk seek times to explain the motivations for embedding and denormalization, better than prior MongoDB schema-design materials have.

Many presentations, my own included, have claimed that you can migrate your schema lazily with MongoDB: your application can start writing data in a new format, and read data in both new and old formats, while a batch job slowly migrates old data. MongoDB Applied Design Patterns finally presents a complete example of lazy migration, including example code (in Python) for reading data in both formats while the migration is in progress.

Without general-purpose transactions, MongoDB requires new techniques to guarantee that a series of changes is atomic: that is, to guarantee that in the long run your data either reflects all the changes or none of them. The simple approach is to put all related data in one document and use update operators to modify all the data in one shot. If there's no way to restrict your atomic operation to one document, your next best bet is optimistic concurrency control: try to complete the operation, check if another process overwrote your changes, and if so retry them. There are a number of examples of this in the wild (the MongoDB Manual, Dan Crosta, Scott Hernandez); Copeland's contribution is unusually complete, with example code for handling every case that can arise.

Part 2 of the book is much longer, and covers six kinds of application in depth, both conventional (a social network) and unusual (a role-playing game). Here Copeland excels. Where he covers well-tread ground his designs are more detailed and better thought out than prior authors', and where he innovates he chooses interesting problems to solve. In the Operational Intelligence chapter he explains compound indexes clearly and correctly. He presents a complete design for an analytics application using the MongoDB aggregation framework, and covers the interactions between aggregation, indexes, and sharding.

The final example of the book is an online Zork-style game. This is less widely applicable than E-Commerce or content management, but way more fun. Copeland chooses to radically denormalize his schema: when a player enters a room, the room's entire data structure is copied into the player's document so the game can display the player's state without querying for the room again. As with the other examples, this application is considered in depth: each query is carefully indexed, and when a player picks up an item, Copeland's code prevents another player from picking it up concurrently. Most of the game's intelligence is expressed in Python code rather than in MongoDB queries. Developers using Oracle or Microsoft SQL Server tend to push all the logic and complexity into their schema, their queries, and stored procedures. With MongoDB's simpler feature-set, coders have to move more logic out of the database and into their application. If a SQL refugee hasn't yet learned this lesson, the gaming chapter will drive it home.

Review of "Building Node Applications with MongoDB and Backbone"

Mike Wilson's O'Reilly book from December 2012 introduces some hip web development techniques by building a book-long example of a social networking app. Besides introducing MongoDB, Backbone, and Node, he shows the beauty and [...]

Mike Wilson's O'Reilly book from December 2012 introduces some hip web development techniques by building a book-long example of a social networking app. Besides introducing MongoDB, Backbone, and Node, he shows the beauty and remarkable concision of Jade, Require.js, and Mongoose. He demonstrates good patterns for organizing your code in an application of substantial complexity, covers a lot of ground in few pages, and concludes with an unusually feature-complete chat-server example that weaves together all the layers of the stack. Wilson has some dangerous habits readers shouldn't emulate, but on balance his book teaches well.

Building node applications

By necessity, the book jumps frequently between Node and Backbone, models and views, HTML and Javascript. It's the nature of web development that each new feature requires changes in many places, and it's hard to stay oriented. Wilson maintains a corrected version of each chapter's code on Github; use that instead of relying entirely on the examples in the book.

I've built one large front-end Javascript application with Backbone, and I floundered at organizing it. Although Backbone is rigorous (hence the name) about separating models and views, higher-level questions are underspecified: how should the code be split among files? Whose responsibility is it to create the models and views? Wilson uses Require.js to neatly slice code into files and to declare the dependencies among them. In his example application, the Backbone router is responsible for instantiating all models and views. As the book progresses and his example application grows, the routes, models, and views remain focused and decoupled. It's a compelling design. I wish I'd known.

Wilson spends an early chapter building a login system for his example app, before implementing any features. He even salts his password hashes to defend against rainbow tables. An author less secure in his convictions would fear losing his reader's attention, but Wilson insists on doing the right thing. And rightly so: readers will paste his examples and put them into production, so the examples should be complete.

On the other hand, Wilson's introduction to MongoDB misses some marks. It's only 12 pages, so why did he spend two of them on MapReduce? MapReduce has always been intended for big batch processes, not web applications. MongoDB books and talks have long over-emphasized MapReduce, which should be confined to a niche. The aggregation framework, on the other hand, is general-purpose and was released months before Wilson's book; it should have been covered instead.

Wilson also shows a MongoDB pattern that risks losing updates and is needlessly slow: When a user adds a contact in his social-networking site, Wilson's code fetches the whole user document, adds the contact, and saves the whole document back:

app.post('/accounts/:id/contact', function(req,res) {
  var accountId = req.params.id;
  var contactId = req.param('contactId', null);

  models.Account.findById(accountId, function(account) {
    models.Account.findById(contactId, function(contact) {
      models.Account.addContact(account, contact);
      account.save();
    });
  });

  // Note: Not in callback - this endpoint returns immediately and
  // processes in the background
  res.send(200);
});

(I've edited for brevity; the whole code is on GitHub.) Note that if two requests are updating the same account, the first one's updates are lost. $addToSet would have solved this, and would be more efficient too.

Equally worrisome is Wilson's tendency to drop errors on the floor instead of reporting them to the user, as shown at the bottom of this function. He argues "we are accepting the small but rare inconvenience in order to serve the majority of requests at an accelerated speed." This is a terrible argument for silencing errors, especially since the front-end framework needn't block the user from interacting with the UI while it waits for the server response.

A book like this seems intended to show best practices, and patterns that encourage correctness. Some of the hardest patterns to learn are error-handling in Node and concurrency control in MongoDB. I wish Wilson had devoted half the attention he placed on security to these two topics.

But I'm only mad at these flaws because the book they mar is a good one. As Wilson builds up his architecture piece by piece, the patterns appear both usable and elegant, and capable of staying clean as the app grows. Wilson uses Backbone custom named events like "app:loggedin" or "chat:start" to coordinate his front-end code, instead of letting views directly call methods on other views. A novice Backbone user might not see the tremendous value of decoupling views this way, but take it from me—it's a great idea.

The book concludes with a long chat example. Chat examples with Socket.io and Node are legion—indeed, obligatory—but the completeness of this one, including its integration with Backbone, is a tour de force. If you plan to use either Node or Backbone this book has excellent recommendations for structuring a large app, and even if you're not building with any of the frameworks Wilson covers, his examples can inspire you to write more concise and decoupled code.

Review of Roman Vishniac Rediscovered

Today I saw the International Center of Photography's big retrospective, "Roman Vishniac Rediscovered". The show opens with Vishniac's Berlin street photography from the 1920s and 30s, in which he concentrates on form: shafts of [...]

Roman Vishniac, Salesmen

Today I saw the International Center of Photography's big retrospective, "Roman Vishniac Rediscovered". The show opens with Vishniac's Berlin street photography from the 1920s and 30s, in which he concentrates on form: shafts of light in a train station; a workman on a diagonal ladder amid diagonal shadows; four boys admiring a motorcycle, all dressed alike. The beauty and the visual coincidences he catches are delightful. The scene darkens as the Nazis rise to power, and the impact of the photos, unfortunately, wanes. Vishniac's photo of his daughter wearing a cute beret, standing in front of a Hitler poster, is ominous, but not particularly good.

Vishniac's most prominent achievement is his photographs of Eastern European Jews in the late 1930s. The project was commissioned by an American Jewish relief fund to highlight the poverty of Jews in Eastern Europe, much in the same way (and at the same time) as the FSA commissioned Dorothea Lange and Walker Evans to photograph the Dust Bowl. ICP displays the work in fine new inkjet prints from Vishniac's negatives, and sometimes shows images Vishniac had originally edited out: Jewish women in secular dress, for example, or a prosperous-looking Jewish shop. The exhibit demonstrates how Vishniac selected his photos to accomplish a narrow view of Jewish life: poor, religious, medieval. When this world was wiped out by the Nazis a few years later, Vishniac's record of it became a twilit elegy, but the work as we've known it is not the whole scene Vishniac saw.

Roman Vishniac, Beggars

Propagandistic, too, are Vishniac's 1939 photographs of a Dutch "agrarian training camp" that prepared Zionist youth for emigration to Palestine. The images are posed, with clear inspiration from Socialist Realism. They're of their time: the age of statism, when individuals everywhere were subsumed in one ideology or another.

Roman Vishniac, Zionist Youth

It makes one nostalgic for the pictures made before all the polemics, when Vishniac was satisfied just to photograph stylish figures in slashing light. Unburdened by any message, these images are light, and the best in the show.

Roman Vishniac, Train Station

"Collapse" by Jared Diamond

If you worry at night about the end of human civilization, 550 pages of small type by Jared Diamond should be enough soporific to knock you out for a month of bedtimes. If, on the other hand, you enjoyed "Guns, Germs, & Steel" and you're [ ... ]

Collapse

If you worry at night about the end of human civilization, 550 pages of small type by Jared Diamond should be enough soporific to knock you out for a month of bedtimes. If, on the other hand, you enjoyed "Guns, Germs, & Steel" and you're looking for another stimulating quest through ancient history, "Collapse" is more of a slog.

Diamond sets out to apply a "five-point framework" to ten example societies. The five factors he sees contributing to societal collapse are environmental damage, natural climate change, war, weakened allies, and the ways societies choose to respond to these pressures. The ten examples range incredibly widely, from the ancient Maya to medieval Japan to modern China and Montana. Diamond's breadth is awesome, but alas his thesis is so diffuse as to be useless: sometimes outside forces are too powerful, or people's responses too ineffective, so societies collapse. Otherwise, they survive. The obvious question is, will our civilization collapse due to global warming? Or will we stop it before it kills most of us and leaves the rest miserable? Diamond's answer is what we already know: it depends on our choices. "Collapse" is a long journey that covers no ground.

So is the journey any fun? The first leg is a comparative history of Polynesian island cultures. This is close to Diamond's expertise (he studied the ornithology of New Guinea before turning to more popular subjects) and, as in "Guns, Germs, & Steel," the Polynesian section is the most successful. The examples are the most convincing support for his ideas, and the most entertaining to read.

Everyone knows a few things about Easter Island: small island, big statues, vanished people, a mystery. But current research tells a surprisingly detailed and certain story. The Easter Islanders arrived around 900 AD, bringing chickens, along with sugarcane, taro, and some other standard Polynesian crops. When they settled the island it was generously forested with the largest palm trees in the world, with trunks over seven feet thick. By 1500 AD, islanders had felled every palm tree. They had used the wood to build canoes, to haul and raise the famous statues, and they simply burned wood for fuel. Once the trees were gone, Easter Islanders couldn't build canoes for fishing, and the best soils for farming eroded away. Most of the population starved. Perhaps in anger at the gods, perhaps in revolt against their chiefs, the survivors toppled every one of the statues. Europeans arrived in the 18th Century to convert the islanders to Catholicism, and in the 19th Century, Peruvian ships sold most of the Easter Islanders into slavery, to die in Peruvian guano mines. Easter Island once had a population of up to 30,000, but had fallen by 1872 to only 111 people.

In contrast, the 1200 inhabitants of the tiny Polynesian island of Tikopia have lived sustainably for 3000 years. Instead of cutting down their trees, they farm trees: nearly every tree in the Tikopian rainforest is cultivated for its nuts or fruit. By maintaining a thick forest, Tikopians ensure a supply of timber and prevent erosion. In the 17th Century, Tikopians chose to abandon pig farming, realizing it was too inefficient to support their population. Their oral tradition preserves stories of killing every pig on the island. Instead of allowing the human population to grow past sustainable numbers, Tikopians practiced coitus interruptus, abortion, and infanticide. Only when they were converted to Christianity in the 20th Century did their population grow. Emigration now relieves population pressure and allows Tikopia to maintain the same population size it has had throughout its known history.

Compared to the extensively researched and retold story of Easter, Diamond spends too little time on the Tikopians' example. Was abortion really as humane as he tells it, and how did medieval Tikopian couples make the choice to abort? How did all the clans come together to decide to kill their pigs? In a book evidently not concerned with brevity, more details would be welcome.

When Diamond turns to modern examples, on the other hand, he is overwhelmed with the availability of data and goes on far too long. His China chapter is a recitation of facts either awful or banal: a quarter of Chinese cities experience acid rain on half the rainy days each year, the Yellow River is so depleted that it did not flow at all on 230 days in 1997, and in the last two decades the Chinese have increased their use of washing machines by a factor of 34,000. There is something spent within the reader while absorbing each giant statistic about China. Diamond makes the typical observations about rising Chinese living standards and failing natural resources; your resources will be exhausted before the end of the China chapter.

The most pressing question of all is nicely summarized as, "What was going through the mind of the Easter Islander who chopped down the last palm tree?" Diamond has a list of reasons why societies destroy themselves, or fail to save themselves from exogenous threats: we don't perceive problems until it's too late, or we don't try to solve them, or we try and fail. As with his five-point framework, Diamond's four categories of failure cover all the bases and leave us without new insight. In his analysis of irrational behavior, Diamond cites Barbara Tuchman's "The Proud Tower" and "The March of Folly" so frequently, you'd be tempted to read those books instead if you weren't so close to finishing "Collapse" by now.

So "Collapse" is a long trip, and it turns out to be a round trip. Was it anything to write home about? The best stops on the journey were indeed worth it: Easter Island, Tikopia, the starvation of the Norse in Greenland, the vanishing of the Anasazi. The same way that a long plane ride and a pricey hotel are redeemed by the sight of Mount Fuji, you can close this huge book with satisfaction. Just don't open it without knowing what you're getting in to.

"The Middlesteins" by Jami Attenberg

I can't objectively review Jami Attenberg's latest novel, The Middlesteins, because I've known Jami for a couple years and I'm rooting for this book. It is, it turns out, gratifying to root for, because it's a best-seller and was the cover [ ... ]

The Middlesteins

I can't objectively review Jami Attenberg's latest novel, The Middlesteins, because I've known Jami for a couple years and I'm rooting for this book. It is, it turns out, gratifying to root for, because it's a best-seller and was the cover of the New York Times Book Review last week. Here's what I'm telling you as a fan: The Middlesteins is a fun and absorbing read. It's compassionate both to the main character, Edie, a Jewish woman in the Chicago suburbs who's eating herself to death, and to her family, which is riven and united by Edie's pathology. It's everything it's cracked up to be. Go read the Times review and then read the book.

Regarding Warhol

I saw "Regarding Warhol: Sixy Artists, Fifty Years" at the Met today. I've always enjoyed Warhol: his every work makes a clear, prescient statement, and there are days I just want to go to a museum, understand what the art is saying to me, and [ ... ]

I saw "Regarding Warhol: Sixy Artists, Fifty Years" at the Met today. I've always enjoyed Warhol: his every work makes a clear, prescient statement, and there are days I just want to go to a museum, understand what the art is saying to me, and agree with it.

At the Met's show, Warhol's huge silkscreened images of Marilyn Monroe, Jackie O., and Mao are monumentally silly, precisely like the mass culture they parody. Less interesting works like the Coke bottles and soup cans are mercifully rare, but an early painting I hadn't seen before, his 1962 "Baseball", is on display.

Baseball - Andy Warhol

Warhol's the big star, but the show is dominated by those artists whom he influenced. The standouts for me were two prints from Matthew Barney's "Cremaster 3" series, circa 2002, one a self-portrait as a murderer, the other a showroom of Chryslers in a bizarre temple-like room that I take to be within the Chrysler building. The images are staged with immaculate precision—even the highlights on the cars' fenders are exactly mirrored from one side of the image to the other—and although it is cliché to say so regarding photography viewed in a museum, Barney's prints are glorious and must be seen in person.

Cremaster 3 Matthew Barney

Jeff Koons's hideous sculptures ambushed me every few rooms, looking like toxic mutations of porcelain figurines from the Home Shopping Network. In his 1988 wood-carved sculpture "Ushering In Banality," a pair of cherubs lead forward a pig as a boy in a track suit pushes it from behind. Also from 1988, "Michael Jackson and Bubbles" is in the style of a kitschy saint figurine or something from a churchyard crêche.

Michael Jackson and Bubbles Jeff Koons

After such horrors, the show's last two rooms are a relief. First, a big wall papered in Takashi Murakami's laughing daisies. I don't care if he is critiquing the Hello-Kittification of Japanese culture or not; his daisies makes me smile. And finally, a room full of Warhol's big mylar pillows floating to the ceiling and gently descending again. Tourists, art students, and museum guards alike stroll around knocking the pillows upward and waiting for them to fall again.

Review of "Let Us Now Praise Famous Men" by James Agee and Walker Evans

"Let Us Now Praise Famous Men" by James Agee and Walker Evans, 1941. I give up. I can't finish this nor ever will. Walker Evans begins the book with a few dozen photos, most of which are mediocre at best, a handful of which are among the best [ ... ]

Walker Evans, Let Us Now Praise Famous Men

"Let Us Now Praise Famous Men" by James Agee and Walker Evans, 1941.

I give up. I can't finish this nor ever will.

Walker Evans begins the book with a few dozen photos, most of which are mediocre at best, a handful of which are among the best photos ever taken. Agee's text, too, is a mixed bag, although the avalanche of dross so completely mires the gems that I found myself flipping through ten pages at a time, looking for a paragraph worth reading. Agee goes through convulsions of angst, trying to find some way to tell us about the lives of three poor tenant farmers' families without being condescending or romantic. His response is a mountain of maudlin prose, reams of lists of the contents of every shelf and closet, whole chapters of poetic drivel about the divinity of man and the wheeling stars and god knows what else besides. Predictably, the Harvard-educated liberal spends the whole book trying not to make the story about himself, and ends up writing an autobiography. I have no sympathy with his dilemma. Agee should have either grown up in a hurry, taken responsibility, and actually written a book about tenant farmers, or he should have made an honorable exit.

Inside this monstrous stillbirth is a magazine story crying for release: 10 great photos, 20 graceful pages of reporting. I hope some day an unawed editor will produce it.


CORRECTION: An earlier version of this review had called Agee an "overeducated coastal liberal," but the reviewer's mother pointed out that "coastal liberal" is a tired slur and that Agee was born in Knoxville. Agee is now attacked as a "Harvard-educated liberal" instead. We regret the error.

Review of "Opening the Hand of Thought" by Kosho Uchiyama

Highly recommended, but don't feel bad for skimming the second half. The book's early chapters offer the most specific and practical guide to zazen that I have read—the method, its goals, and what the meditator can reasonably [ ... ]

Opening the hand of thought

Highly recommended, but don't feel bad for skimming the second half.

The book's early chapters offer the most specific and practical guide to zazen that I have read—the method, its goals, and what the meditator can reasonably expect to achieve. It clarifies the relationship between zazen and thinking beautifully. Any Zen student learns early that meditation isn't about "trying to stop thinking," but Uchiyama's explanation is by far the best.

After that, Uchiyama Roshi heads off into the weeds. He offers chapter after chapter of opinions on modern life and religion, the state of Zen in Japan, overprotective mothers, on and on ad nauseum. Old Uncle Uchiyama sits on the couch and grumbles at the television. Kids these days. No one practices real Zen anymore.

Be patient with the old man's gripes, and don't take them too seriously. Read his instructions on zazen and your sitting will be transformed.

Review of "The Social Organization of Zen Practice" by David L. Preston

"The Social Organization of Zen Practice" by David L. Preston, 1988. I read this in 2003, while I lived at a Zen monastery. I recall the book focused on the social pressures exerted on lay Zen practitioners during meditation retreats. Zen [ ... ]

The Social Organization of Zen Practice

"The Social Organization of Zen Practice" by David L. Preston, 1988. I read this in 2003, while I lived at a Zen monastery. I recall the book focused on the social pressures exerted on lay Zen practitioners during meditation retreats.

Zen rituals—eating, chanting, bowing—are sufficiently subtle and complex that a relaxed, mindful state is required to correctly perform them. Preston argues that since we all watch each other during these rituals out of the corners of our eyes, practitioners know each others' degree of mindfulness. Since we know we are being watched, it motivates us to practice mindfulness diligently, if only so we don't slip up in public.

When I read this, I found it insightful. I was twenty-four years old, I'd practiced Zen for two years, and I was vigilant that I not be seen as a fool by my peers. I strove to eat, chant, and bow in exactly the right way. These days, I think what Preston describes is just an early phase in a Zen student's career. Preston's vision of Zen is Calvinistic: because outward behavior implies inner salvation, everyone tries to act like they're saved. But in my experience, I don't spend much time watching others during a Zen retreat, and I don't worry any more what they think of me. The mark of my spiritual attainment isn't how much I impress others, but how little I judge them.

The motivations Preston felt are useful early on; they push us to pay attention. In particular, when I sit with a group I sit more still, and this is useful to focus my mind. But I think we need to relax as quickly as possible. We should just perform the rituals well for their own sake. The benefits of practicing with a group go far beyond the social pressures Preston describes: we support each other and drive each other on. When we stop being afraid of what the group thinks of us and practice with the group instead, then the sangha takes hold and ferries us to the other shore.