Category Archives: experience

WordPress as Content Directory: Getting Somewhere

{I tend to ramble a bit. If you just want a step-by-step tutorial, you can skip to here.}

Woohoo!

I feel like I’ve reached a milestone in a project I’ve had in mind, ever since I learnt about Custom Post Types in WordPress 3.0: Using WordPress as a content directory.

The concept may not be so obvious to anyone else, but it’s very clear to me. And probably much clearer for anyone who has any level of WordPress skills (I’m still a kind of WP newbie).

Basically, I’d like to set something up through WordPress to make it easy to create, review, and publish entries in content databases. WordPress is now a Content Management System and the type of “content management” I’d like to enable has to do with something of a directory system.

Why WordPress? Almost glad you asked.

These days, several of the projects on which I work revolve around WordPress. By pure coincidence. Or because WordPress is “teh awsum.” No idea how representative my sample is. But I got to work on WordPress for (among other things): an academic association, an adult learners’ week, an institute for citizenship and social change, and some of my own learning-related projects.

There are people out there arguing about the relative value of WordPress and other Content Management Systems. Sometimes, WordPress may fall short of people’s expectations. Sometimes, the pro-WordPress rhetoric is strong enough to sound like fanboism. But the matter goes beyond marketshare, opinions, and preferences.

In my case, WordPress just happens to be a rather central part of my life, these days. To me, it’s both a question of WordPress being “the right tool for the job” and the work I end up doing being appropriate for WordPress treatment. More than a simple causality (“I use WordPress because of the projects I do” or “I do these projects because I use WordPress”), it’s a complex interaction which involves diverse tools, my skillset, my social networks, and my interests.

Of course, WordPress isn’t perfect nor is it ideal for every situation. There are cases in which it might make much more sense to use another tool (Twitter, TikiWiki, Facebook, Moodle, Tumblr, Drupal..). And there are several things I wish WordPress did more elegantly (such as integrating all dimensions in a single tool). But I frequently end up with WordPress.

Here are some things I like about WordPress:

This last one is where the choice of WordPress for content directories starts making the most sense. Not only is it easy for me to use and build on WordPress but the learning curves are such that it’s easy for me to teach WordPress to others.

A nice example is the post editing interface (same in the software and service). It’s powerful, flexible, and robust, but it’s also very easy to use. It takes a few minutes to learn and is quite sufficient to do a lot of work.

This is exactly where I’m getting to the core idea for my content directories.

I emailed the following description to the digital content editor for the academic organization for which I want to create such content directories:

You know the post editing interface? What if instead of editing posts, someone could edit other types of contents, like syllabi, calls for papers, and teaching resources? What if fields were pretty much like the form I had created for [a committee]? What if submissions could be made by people with a specific role? What if submissions could then be reviewed by other people, with another role? What if display of these items were standardised?

Not exactly sure how clear my vision was in her head, but it’s very clear for me. And it came from different things I’ve seen about custom post types in WordPress 3.0.

For instance, the following post has been quite inspiring:

I almost had a drift-off moment.

But I wasn’t able to wrap my head around all the necessary elements. I perused and read a number of things about custom post types, I tried a few things. But I always got stuck at some point.

Recently, a valuable piece of the puzzle was provided by Kyle Jones (whose blog I follow because of his work on WordPress/BuddyPress in learning, a focus I share).

Setting up a Staff Directory using WordPress Custom Post Types and Plugins | The Corkboard.

As I discussed in the comments to this post, it contained almost everything I needed to make this work. But the two problems Jones mentioned were major hurdles, for me.

After reading that post, though, I decided to investigate further. I eventually got some material which helped me a bit, but it still wasn’t sufficient. Until tonight, I kept running into obstacles which made the process quite difficult.

Then, while trying to solve a problem I was having with Jones’s code, I stumbled upon the following:

Rock-Solid WordPress 3.0 Themes using Custom Post Types | Blancer.com Tutorials and projects.

This post was useful enough that I created a shortlink for it, so I could have it on my iPad and follow along: http://bit.ly/RockSolidCustomWP

By itself, it might not have been sufficient for me to really understand the whole process. And, following that tutorial, I replaced the first bits of code with use of the neat plugins mentioned by Jones in his own tutorial: More Types, More Taxonomies, and More Fields.

I played with this a few times but I can now provide an actual tutorial. I’m now doing the whole thing “from scratch” and will write down all steps.

This is with the WordPress 3.0 blogging software installed on a Bluehost account. (The WordPress.com blogging service doesn’t support custom post types.) I use the default Twenty Ten theme as a parent theme.

Since I use WordPress Multisite, I’m creating a new test blog (in Super Admin->Sites, “Add New”). Of course, this wasn’t required, but it helps me make sure the process is reproducible.

Since I already installed the three “More Plugins” (but they’re not “network activated”) I go in the Plugins menu to activate each of them.

I can now create the new “Product” type, based on that Blancer tutorial. To do so, I go to the “More Types” Settings menu, I click on “Add New Post Type,” and I fill in the following information: post type names (singular and plural) and the thumbnail feature. Other options are set by default.

I also set the “Permalink base” in Advanced settings. Not sure it’s required but it seems to make sense.

I click on the “Save” button at the bottom of the page (forgot to do this, the last time).

I then go to the “More Fields” settings menu to create a custom box for the post editing interface.

I add the box title and change the “Use with post types” options (no use in having this in posts).

(Didn’t forget to click “save,” this time!)

I can now add the “Price” field. To do so, I need to click on the “Edit” link next to the “Product Options” box I just created and add click “Add New Field.”

I add the “Field title” and “Custom field key”:

I set the “Field type” to Number.

I also set the slug for this field.

I then go to the “More Taxonomies” settings menu to add a new product classification.

I click “Add New Taxonomy,” and fill in taxonomy names, allow permalinks, add slug, and show tag cloud.

I also specify that this taxonomy is only used for the “Product” type.

(Save!)

Now, the rest is more directly taken from the Blancer tutorial. But instead of copy-paste, I added the files directly to a Twenty Ten child theme. The files are available in this archive.

Here’s the style.css code:

/*
Theme Name: Product Directory
Theme URI: http://enkerli.com/
Description: A product directory child theme based on Kyle Jones, Blancer, and Twenty Ten
Author: Alexandre Enkerli
Version: 0.1
Template: twentyten
*/

@import url("../twentyten/style.css");

The code for functions.php:

<!--?php /**  * ProductDir functions and definitions  * @package WordPress  * @subpackage Product_Directory  * @since Product Directory 0.1  */ /*Custom Columns*/ add_filter("manage_edit-product_columns", "prod_edit_columns"); add_action("manage_posts_custom_column",  "prod_custom_columns"); function prod_edit_columns($columns){ 		$columns = array( 			"cb" =--> "<input type="\&quot;checkbox\&quot;" />",
			"title" => "Product Title",
			"description" => "Description",
			"price" => "Price",
			"catalog" => "Catalog",
		);

		return $columns;
}

function prod_custom_columns($column){
		global $post;
		switch ($column)
		{
			case "description":
				the_excerpt();
				break;
			case "price":
				$custom = get_post_custom();
				echo $custom["price"][0];
				break;
			case "catalog":
				echo get_the_term_list($post->ID, 'catalog', '', ', ','');
				break;
		}
}
?>

And the code in single-product.php:

<!--?php /**  * Template Name: Product - Single  * The Template for displaying all single products.  *  * @package WordPress  * @subpackage Product_Dir  * @since Product Directory 1.0  */ get_header(); ?-->
<div id="container">
<div id="content">
<!--?php the_post(); ?-->

<!--?php 	$custom = get_post_custom($post--->ID);
	$price = "$". $custom["price"][0];

?>
<div id="post-<?php the_ID(); ?><br />">>
<h1 class="entry-title"><!--?php the_title(); ?--> - <!--?=$price?--></h1>
<div class="entry-meta">
<div class="entry-content">
<div style="width: 30%; float: left;">
			<!--?php the_post_thumbnail( array(100,100) ); ?-->
			<!--?php the_content(); ?--></div>
<div style="width: 10%; float: right;">
			Price
<!--?=$price?--></div>
</div>
</div>
</div>
<!-- #content --></div>
<!-- #container -->

<!--?php get_footer(); ?-->

That’s it!

Well, almost..

One thing is that I have to activate my new child theme.

So, I go to the “Themes” Super Admin menu and enable the Product Directory theme (this step isn’t needed with single-site WordPress).

I then activate the theme in Appearance->Themes (in my case, on the second page).

One thing I’ve learnt the hard way is that the permalink structure may not work if I don’t go and “nudge it.” So I go to the “Permalinks” Settings menu:

And I click on “Save Changes” without changing anything. (I know, it’s counterintuitive. And it’s even possible that it could work without this step. But I spent enough time scratching my head about this one that I find it important.)

Now, I’m done. I can create new product posts by clicking on the “Add New” Products menu.

I can then fill in the product details, using the main WYSIWYG box as a description, the “price” field as a price, the “featured image” as the product image, and a taxonomy as a classification (by clicking “Add new” for any tag I want to add, and choosing a parent for some of them).

Now, in the product management interface (available in Products->Products), I can see the proper columns.

Here’s what the product page looks like:

And I’ve accomplished my mission.

The whole process can be achieved rather quickly, once you know what you’re doing. As I’ve been told (by the ever-so-helpful Justin Tadlock of Theme Hybrid fame, among other things), it’s important to get the data down first. While I agree with the statement and its implications, I needed to understand how to build these things from start to finish.

In fact, getting the data right is made relatively easy by my background as an ethnographer with a strong interest in cognitive anthropology, ethnosemantics, folk taxonomies (aka “folksonomies“), ethnography of communication, and ethnoscience. In other words, “getting the data” is part of my expertise.

The more technical aspects, however, were a bit difficult. I understood most of the principles and I could trace several puzzle pieces, but there’s a fair deal I didn’t know or hadn’t done myself. Putting together bits and pieces from diverse tutorials and posts didn’t work so well because it wasn’t always clear what went where or what had to remain unchanged in the code. I struggled with many details such as the fact that Kyle Jones’s code for custom columns wasn’t working first because it was incorrectly copied, then because I was using it on a post type which was “officially” based on pages (instead of posts). Having forgotten the part about “touching” the Permalinks settings, I was unable to get a satisfying output using Jones’s explanations (the fact that he doesn’t use titles didn’t really help me, in this specific case). So it was much harder for me to figure out how to do this than it now is for me to build content directories.

I still have some technical issues to face. Some which are near essential, such as a way to create archive templates for custom post types. Other issues have to do with features I’d like my content directories to have, such as clearly defined roles (the “More Plugins” support roles, but I still need to find out how to define them in WordPress). Yet other issues are likely to come up as I start building content directories, install them in specific contexts, teach people how to use them, observe how they’re being used and, most importantly, get feedback about their use.

But I’m past a certain point in my self-learning journey. I’ve built my confidence (an important but often dismissed component of gaining expertise and experience). I found proper resources. I understood what components were minimally necessary or required. I succeeded in implementing the system and testing it. And I’ve written enough about the whole process that things are even clearer for me.

And, who knows, I may get feedback, questions, or advice..


Actively Reading: Organic Ideas for Startups

Been using Diigo as a way to annotate online texts. In this case, I was as interested in the tone as in the text itself. At the same time, I kept thinking about things which seem to be missing from Diigo.

One thing I like about this text is its tone. There’s an honesty, an ingenuity that I find rare in this type of writing.

  • startup ideas
    • The background is important, in terms of the type of ideas about which we’re constructing something.
  • what do you wish someone would make for you?
    • My own itch has to do with Diigo, actually. There’s a lot I wish Diigo would make for me. I may be perceived as an annoyance, but I think my wishlist may lead to something bigger and possibly quite successful.
    • The difference between this question and the “scratch your own itch” principle seems significant, and this distinction may have some implications in terms of success: we’re already talking about others, not just running ideas in our own head.
  • what do you wish someone would make for you?
    • It’s somewhat different from the well-known “scratch your own itch” principle. In this difference might be located something significant. In a way, part of the potential for this version to lead to success comes from the fact that it’s already connected with others, instead of being about running ideas in your own mind.
  • grow organically
    • The core topic of the piece, put in a comparative context. The comparison isn’t the one people tend to make and one may argue about the examples used. But the concept of organic ideas is fascinating and inspiring.
  • you decide, from afar,
    • What we call, in anthropology, the “armchair” approach. Also known as “backbenching.” For this to work, you need to have a deep knowledge of the situation, which is part of the point in this piece. Nice that it’s not demonizing this position but putting it in context.
  • Apple
    was the first type
    • One might argue that it was a hybrid case. Although, it does sound like the very beginnings of Apple weren’t about “thinking from afar.”
  • class of users other than you
    • Since developers are part of a very specific “class” of people, this isn’t insignificant a way to phrase this.
  • They still rely on this principle today, incidentally.
    The iPhone is the phone Steve Jobs wants.
    • Apple tends to be perceived in a different light. According to many people, it’s the “textbook example” of a company where decisions are made without concerns for what people need. “Steve Jobs uses a top-down approach,” “They don’t even use focus groups,” “They don’t let me use their tools the way I want to use them.” But we’re not talking about the same distinction between top-down and bottom-up. Though “organic ideas” seem to imply that it’s a grassroots/bottom-up phenomenon, the core distinction isn’t about the origin of the ideas (from the “top,” in both cases) but on the reasoning behind these ideas.
  • We didn’t need this software ourselves.
    • Sounds partly like a disclaimer but this approach is quite common and “there’s nothing wrong with it.”
  • comparatively old
    • Age and life experience make for an interesting angle. It’s not that this strategy needs people of a specific age to work. It’s that there’s a connection between one’s experience and the way things may pan out.
  • There is no sharp line between the two types of ideas,
    • Those in the “engineering worldview” might go nuts, at this point. I can hear the claims of “hand waving.” But we’re talking about something complex, here, not a merely complicated problem.
  • Apple type
    • One thing to note in the three examples here: they’re all made by pairs of guys. Jobs and Woz, Gates and Allen, Page and Brin. In many cases, the formula might be that one guy (or gal, one wishes) comes up with ideas knowing that the other can implement them. Again, it’s about getting somebody else to build it for you, not about scratching your own itch.
  • Bill Gates was writing something he would use
    • Again, Gates may not be the most obvious example, since he’s mostly known for another approach. It’s not inaccurate to say he was solving his own problem, at the time, but it may not be that convincing as an example.
  • Larry and Sergey when they wrote the first versions of Google.
    • Although, the inception of the original ideas was academic in context. They weren’t solving a search problem or thinking about monetization. They were discovering the power of CitationRank.
  • generally preferable
    • Nicely relativistic.
  • It takes experience
    to predict what other people will want.
    • And possibly a lot more. Interesting that he doesn’t mention empirical data.
  • young founders
    • They sound like a fascinating group to observe. They do wonders when they open up to others, but they seem to have a tendency to impose their worldviews.
  • I’d encourage you to focus initially on organic ideas
    • Now, this advice sounds more like the “scratch your own itch” advocation. But there’s a key difference in that it’s stated as part of a broader process. It’s more of a “walk before you run” or “do your homework” piece of advice, not a “you can’t come up with good ideas if you just think about how people will use your tool.”
  • missing or broken
    • It can cover a lot, but it’s couched in terms of the typical “problem-solving” approach at the centre of the engineering worldview. Since we’re talking about developing tools, it makes sense. But there could be a broader version, admitting for dreams, inspiration, aspiration. Not necessarily of the “what would make you happy?” kind, although there’s a lot to be said about happiness and imagination. You’re brainstorming, here.
  • immediate answers
    • Which might imply that there’s a second step. If you keep asking yourself the same question, you may be able to get a very large number of ideas. The second step could be to prioritize them but I prefer “outlining” as a process: you shuffle things together and you group some ideas to get one which covers several. What’s common between your need for a simpler way to code on the Altair and your values? Why do you care so much about algorithms instead of human encoding?
  • You may need to stand outside yourself a bit to see brokenness
    • Ah, yes! “Taking a step back,” “distancing yourself,” “seeing the forest for the trees”… A core dimension of the ethnographic approach and the need for a back-and-forth between “inside” and “outside.” There’s a reflexive component in this “being an outsider to yourself.” It’s not only psychological, it’s a way to get into the social, which can lead to broader success if it’s indeed not just about scratching your own itch.
  • get used to it and take it for granted
    • That’s enculturation, to you. When you do things a certain way simply because “we’ve always done them that way,” you may not create these organic ideas. But it’s a fine way to do your work. Asking yourself important questions about what’s wrong with your situation works well in terms of getting new ideas. But, sometimes, you need to get some work done.
  • a Facebook
    • Yet another recontextualized example. Zuckerberg wasn’t trying to solve that specific brokenness, as far as we know. But Facebook became part of what it is when Zuck began scratching that itch.
  • organic startup ideas usually don’t
    seem like startup ideas at first
    • Which gets us to the pivotal importance of working with others. Per this article, VCs and “angel investors,” probably. But, in the case of some of cases cited, those we tend to forget, like Paul Allen, Narendra, and the Winklevosses.
  • end up making
    something of value to a lot of people
    • Trial and error, it’s an iterative process. So you must recognize errors quickly and not invest too much effort in a specific brokenness. Part of this requires maturity.
  • something
    other people dismiss as a toy
    • The passage on which Gruber focused and an interesting tidbit. Not that central, come to think of it. But it’s important to note that people’s dismissive attitude may be misled, that “toys” may hide tools, that it’s probably a good idea not to take all feedback to heart…
  • At this point, when someone comes to us with
    something that users like but that we could envision forum trolls
    dismissing as a toy, it makes us especially likely to invest.
  • the best source of organic ones
    • Especially to investors. Potentially self-serving… in a useful way.
  • they’re at the forefront of technology
    • That part I would dispute, actually. Unless we talk about a specific subgroup of young founders and a specific set of tools. Young founders tend to be oblivious to a large field in technology, including social tools.
  • they’re in a position to discover
    valuable types of fixable brokenness first
    • The focus on fixable brokenness makes sense if we’re thinking exclusively through the engineering worldview, but it’s at the centre of some failures like the Google Buzz launch.
  • you still have to work hard
    • Of the “inspiration shouldn’t make use forget perspiration” kind. Makes for a more thoughtful approach than the frequent “all you need to do…” claims.
  • I’d encourage anyone
    starting a startup to become one of its users, however unnatural it
    seems.
    • Not merely an argument for dogfooding. It’s deeper than that. Googloids probably use Google tools but they didn’t actually become users. They’re beta testers with a strong background in troubleshooting. Not the best way to figure out what users really want or how the tool will ultimately fail.
  • It’s hard to compete directly with open source software
    • Open Source as competition isn’t new as a concept, but it takes time to seep in.
  • there has to be some part
    you can charge for
    • The breach through which old-school “business models” enter with little attention paid to everything else. To the extent that much of the whole piece might crumble from pressure built up by the “beancounter” worldview. Good thing he acknowledges it.

In Phase

Lissajous curve

Lissajous curve

Something which happens to me on a rather regular basis (and about which I blogged before) is that I’ll hear about something right after thinking about it. For instance, if I think about the fact that a given tool should exist, it may be announced right at that moment.

Hey, I was just thinking about this!

The effect is a bit strange but it’s quite easy to explain. It feels like a “premonition,” but it probably has more to do with “being in phase.” In some cases, it may also be that I heard about that something but hadn’t registered the information. I know it happens a lot and  it might not be too hard to trace back. But I prefer thinking about phase.

And, yes, I am thinking about phase difference in waves. Not in a very precise sense, but the image still works, for me. Especially with the Lissajous representation, as above.

See, I don’t particularly want to be “ahead of the curve” and I don’t particularly mind being “behind the curve.” But when I’m right “in the curve,” something interesting happens. I’m “in the now.”

I originally thought about being “in tune” and it could also be about “in sync” or even “matching impedances.” But I still like the waves analogy. Especially since, when two waves are in phase, they reinforce one another. As analogies go, it’s not only a beautiful one, but a powerful one. And, yes, I do think about my sweetheart.

One reason I like the concept of phase difference is that I think through sound. My first exposure to the concept comes from courses in musical acoustics, almost twenty years ago. It wasn’t the main thing I’d remember from the course and it’s not something I investigated at any point since. Like I keep telling students, some things hit you long after you’ve heard about it in a course. Lifelong learning and “landminds” are based on such elements, even tiny unimportant ones. Phase difference is one such thing.

And it’s no big deal, of course. It’s not like I spent days thinking about these concepts. But I’ve been feeling like writing, lately, and this is as good an opportunity as any.

The trigger for this particular thing is rather silly and is probably explained more accurately, come to think of it, by “unconsciously registering” something before consciously registering it.

Was having breakfast and started thinking about the importance of being environmentally responsible, the paradox of “consumption as freedom,” the consequences of some lifestyle choices including carfree living, etc. This stream of thought led me, not unexpectedly, to the perspectives on climate change, people’s perception of scientific evidence, and the so-called ClimateGate. I care a lot about critical thinking, regardless of whether or not I agree with a certain idea, so I think the email controversy shows the importance of transparency. So far, nothing unexpected. Within a couple of minutes, I had covered a few of the subjects du jour. And that’s what struck me, because right then, I (over)heard a radio host introduce a guest whose talk is titled:

What is the role of climate scientists in the climate change debate?

Obviously, Tremblay addressed ClimateGate quite directly. So my thoughts were “in phase” with Tremblay’s.

A few minutes prior to (over)hearing this introduction, I (over)heard a comment about topics of social conversations at different points in recent history. According to screenwriter Fabienne Larouche, issues covered in the first seasons of her “flagship” tv series are still at the forefront in Quebec society today, fourteen years later. So I was probably even more “in tune” with the notion of being “in phase.” Especially with my society.

I said “(over)heard” because I wasn’t really listening to that radio show. It was just playing in the background and I wasn’t paying much attention. I don’t tend to listen to live radio but I do listen to some radio recordings as podcasts. One reason I like doing so is that I can pay much closer attention to what I hear. Another is that I can listen to what I want when I feel like listen to it, which means that I can prepare myself for a heady topic or choose some tech-fluff to wind down after a course. There’s also the serendipity of listening to very disparate programmes in the same listening session, as if I were “turning the dial” after each show on a worldwide radio (I often switch between French and English and/or between European and North American sources). For a while now, I’ve been listening to podcasts at double-speed, which helps me focus on what’s most significant.

(In Jazz, we talk about “top notes,” meaning the ones which are more prominent. It’s easier to focus on them at double-speed than at normal speed so “double-times” have an interesting cognitive effect.)

So, I felt “in phase.” As mentioned, it probably has much more to do with having passively heard things without paying attention yet letting it “seep into my brain” to create connections between a few subjects which get me to the same point as what comes later. A large part of this is well-known in psychology, especially in terms of cognition. We start noticing things when they enter into a schema we have in our mind. These things we start noticing were there all along so the “discovery” is only in our mind (in the sense that it wouldn’t be a discovery for others). When we learn a new word, for instance, we start hearing it everywhere.

But there are also words which start being used by everyone because they have been diffused largely at a given point in time. An actual neologism can travel quickly and a word in our passive vocabulary can also come to prominence, especially in mainstream media. Clearly, this is an issue of interest to psychologists, folklorists, and media analysts alike. I’m enough of a folklorist and media observer to think about the social processes behind the diffusion of terms regardless of what psychologists think.

A few months back, I got the impression that the word “nimble” had suddenly increased in currency after it was used in a speech by the current PotUS. Since I’m a non-native speaker of English, I’m likely to be accused of noticing the word because it’s part my own passive vocabulary. I have examples in French, though some are with words which were new to me, at the time («peoplisation», «battante»…). I probably won’t be able to defend myself from those who say that it’s just a matter of my own exposure to those terms. Though there are ways to analyze the currency of a given term, I’m not sure I trust this type of analysis a lot more than my gut feeling, at least in terms of realtime trends.

Which makes me think of “memetics.” Not in the strict sense that Dawkins would like us to use. But in the way popular culture cares about the propagation of “units of thought.” I recently read a fascinating blogpost (in French) about  memetics from this perspective, playing Dawkins against himself. As coincidences keep happening (or, more accurately, as I’m accutely tuned to find coincidences everywhere), I’ve been having a discussion about Mahir‘s personal homepage (aka “I kiss you”), who became an “Internet celebrity” through this process which is now called memetic. The reason his page was noticed isn’t that it was so unique. But it had this je ne sais quoi which captured the imagination, at the time (the latter part of the “Dot-Com Bubble”). As some literary critics and many other humanists teach us, it’s not the item itself which counts, it’s how we receive it (yes, I tend to be on the “reception” and “eye of the beholder” side of things). Mahir was striking because he was, indeed, “out of phase” with the times.

As I think about phase, I keep hearing the other acoustic analogy: the tuning of sine waves. When a sine wave is very slightly “out of tune” with another, we hear a very slow oscillation (interference beats) until they produce resonance. There’s a direct relationship between beat tones and phase, but I think “in tune” and “in phase” remain separate analogies.

One reason I like to think about waves for these analogies is that I tend to perceive temporal change through these concepts. If we think of historical change through cycles, being “in phase” is a matter of matching two change processes until they’re aligned but the cycles may be in harmonic relationships. One can move twice as fast as society and still be “in phase” with it.

Sure, I’m overextending the analogies, and there’s something far-fetched about this. But that’s pretty much what I like about analogical thinking. As I’m under the weather, this kind of rambling is almost therapeutic.


Installing BuddyPress on a Webhost

[Jump here for more technical details.]

A few months ago, I installed BuddyPress on my Mac to try it out. It was a bit of an involved process, so I documented it:

WordPress MU, BuddyPress, and bbPress on Local Machine « Disparate.

More recently, I decided to get a webhost. Both to run some tests and, eventually, to build something useful. BuddyPress seems like a good way to go at it, especially since it’s improved a lot, in the past several months.

In fact, the installation process is much simpler, now, and I ran into some difficulties because I was following my own instructions (though adapting the process to my webhost). So a new blogpost may be in order. My previous one was very (possibly too) detailed. This one is much simpler, technically.

One thing to make clear is that BuddyPress is a set of plugins meant for WordPress µ (“WordPress MU,” “WPMU,” “WPµ”), the multi-user version of the WordPress blogging platform. BP is meant as a way to make WPµ more “social,” with such useful features as flexible profiles, user-to-user relationships, and forums (through bbPress, yet another one of those independent projects based on WordPress).

While BuddyPress depends on WPµ and does follow a blogging logic, I’m thinking about it as a social platform. Once I build it into something practical, I’ll probably use the blogging features but, in a way, it’s more of a tool to engage people in online social activities. BuddyPress probably doesn’t work as a way to “build a community” from scratch. But I think it can be quite useful as a way to engage members of an existing community, even if this engagement follows a blogger’s version of a Pareto distribution (which, hopefully, is dissociated from elitist principles).

But I digress, of course. This blogpost is more about the practical issue of adding a BuddyPress installation to a webhost.

Webhosts have come a long way, recently. Especially in terms of shared webhosting focused on LAMP (or PHP/MySQL, more specifically) for blogs and content-management. I don’t have any data on this, but it seems to me that a lot of people these days are relying on third-party webhosts instead of relying on their own servers when they want to build on their own blogging and content-management platforms. Of course, there’s a lot more people who prefer to use preexisting blog and content-management systems. For instance, it seems that there are more bloggers on WordPress.com than on other WordPress installations. And WP.com blogs probably represent a small number of people in comparison to the number of people who visit these blogs. So, in a way, those who run their own WordPress installations are a minority in the group of active WordPress bloggers which, itself, is a minority of blog visitors. Again, let’s hope this “power distribution” not a basis for elite theory!

Yes, another digression. I did tell you to skip, if you wanted the technical details!

I became part of the “self-hosted WordPress” community through a project on which I started work during the summer. It’s a website for an academic organization and I’m acting as the organization’s “Web Guru” (no, I didn’t choose the title). The site was already based on WordPress but I was rebuilding much of it in collaboration with the then-current “Digital Content Editor.” Through this project, I got to learn a lot about WordPress, themes, PHP, CSS, etc. And it was my first experience using a cPanel- (and Fantastico-)enabled webhost (BlueHost, at the time). It’s also how I decided to install WordPress on my local machine and did some amount of work from that machine.

But the local installation wasn’t an ideal solution for two reasons: a) I had to be in front of that local machine to work on this project; and b) it was much harder to show the results to the person with whom I was collaborating.

So, in the Fall, I decided to get my own staging server. After a few quick searches, I decided HostGator, partly because it was available on a monthly basis. Since this staging server was meant as a temporary solution, HG was close to ideal. It was easy to set up as a PayPal “subscription,” wasn’t that expensive (9$/month), had adequate support, and included everything that I needed at that point to install a current version of WordPress and play with theme files (after importing content from the original site). I’m really glad I made that decision because it made a number of things easier, including working from different computers, and sending links to get feedback.

While monthly HostGator fees were reasonable, it was still a more expensive proposition than what I had in mind for a longer-term solution. So, recently, a few weeks after releasing the new version of the organization’s website, I decided to cancel my HostGator subscription. A decision I made without any regret or bad feeling. HostGator was good to me. It’s just that I didn’t have any reason to keep that account or to do anything major with the domain name I was using on HG.

Though only a few weeks elapsed since I canceled that account, I didn’t immediately set out to transition to a new webhost. I didn’t go from HostGator to another webhost.

But having my own webhost still remained at the back of my mind as something which might be useful. For instance, while not really making a staging server necessary, a new phase in the academic website project brought up a sandboxing idea. Also, I went to a “WordPress Montreal” meeting and got to think about further WordPress development/deployment, including using BuddyPress for my own needs (both as my own project and as a way to build my own knowledge of the platform) instead of it being part of an organization’s project. I was also thinking about other interesting platforms which necessitate a webhost.

(More on these other platforms at a later point in time. Bottom line is, I’m happy with the prospects.)

So I wanted a new webhost. I set out to do some comparison shopping, as I’m wont to do. In my (allegedly limited) experience, finding the ideal webhost is particularly difficult. For one thing, search results are cluttered with a variety of “unuseful” things such as rants, advertising, and limited comparisons. And it’s actually not that easy to give a new webhost a try. For one thing, these hosting companies don’t necessarily have the most liberal refund policies you could imagine. And, switching a domain name between different hosts and registrars is a complicated process through which a name may remain “hostage.” Had I realized what was involved, I might have used a domain name to which I have no attachment or actually eschewed the whole domain transition and just try the webhost without a dedicated domain name.

Doh!
Live and learn. I sure do. Loving almost every minute of it.

At any rate, I had a relatively hard time finding my webhost.

I really didn’t need “bells and whistles.” For instance, all the AdSense, shopping cart, and other business-oriented features which seem to be publicized by most webhosting companies have no interest, to me.

I didn’t even care so much about absolute degree of reliability or speed. What I’m to do with this host is fairly basic stuff. The core idea is to use my own host to bypass some limitations. For instance, WordPress.com doesn’t allow for plugins yet most of the WordPress fun has to do with plugins.

I did want an “unlimited” host, as much as possible. Not because expect to have huge resource needs but I just didn’t want to have to monitor bandwidth.

I thought that my needs would be basic enough that any cPanel-enabled webhost would fit. As much as I could see, I needed FTP access to something which had PHP 5 and MySQL 5. I expected to install things myself, without use of the webhost’s scripts but I also thought the host would have some useful scripts. Although I had already registered the domain I wanted to use (through Name.com), I thought it might be useful to have a free domain in the webhosting package. Not that domain names are expensive, it’s more of a matter of convenience in terms of payment or setup.

I ended up with FatCow. But, honestly, I’d probably go with a different host if I were to start over (which I may do with another project).

I paid 88$ for two years of “unlimited” hosting, which is quite reasonable. And, on paper, FatCow has everything I need (and I bunch of things I don’t need). The missing parts aren’t anything major but have to do with minor annoyances. In other words, no real deal-breaker, here. But there’s a few things I wish I had realized before I committed on FatCow with a domain name I actually want to use.

Something which was almost a deal-breaker for me is the fact that FatCow requires payment for any additional subdomain. And these aren’t cheap: the minimum is 5$/month for five subdomains, up to 25$/month for unlimited subdomains! Even at a “regular” price of 88$/year for the basic webhosting plan, the “unlimited subdomains” feature (included in some webhosting plans elsewhere) is more than three times more expensive than the core plan.

As I don’t absolutely need extra subdomains, this is mostly a minor irritant. But it’s one reason I’ll probably be using another webhost for other projects.

Other issues with FatCow are probably not enough to motivate a switch.

For instance, the PHP version installed on FatCow (5.2.1) is a few minor releases behind the one needed by some interesting web applications. No biggie, especially if PHP is updated in a relatively reasonable timeframe. But still makes for a slight frustration.

The MySQL version seems recent enough, but it uses non-standard tools to manage it, which makes for some confusion. Attempting to create some MySQL databases with obvious names (say “wordpress”) fails because the database allegedly exists (even though it doesn’t show up in the MySQL administration). In the same vein, the URL of the MySQL is <username>.fatcowmysql.com instead of localhost as most installers seem to expect. Easy to handle once you realize it, but it makes for some confusion.

In terms of Fantastico-like simplified installation of webapps, FatCow uses InstallCentral, which looks like it might be its own Fantastico replacement. InstallCentral is decent enough as an installation tool and FatCow does provide for some of the most popular blog and CMS platforms. But, in some cases, the application version installed by FatCow is old enough (2005!)  that it requires multiple upgrades to get to a current version. Compared to other installation tools, FatCow’s InstallCentral doesn’t seem really efficient at keeping track of installed and released versions.

Something which is partly a neat feature and partly a potential issue is the way FatCow handles Apache-related security. This isn’t something which is so clear to me, so I might be wrong.

Accounts on both BlueHost and HostGator include a public_html directory where all sorts of things go, especially if they’re related to publicly-accessible content. This directory serves as the website’s root, so one expects content to be available there. The “index.html” or “index.php” file in this directory serves as the website’s frontpage. It’s fairly obvious, but it does require that one would understand a few things about webservers. FatCow doesn’t seem to create a public_html directory in a user’s server space. Or, more accurately, it seems that the root directory (aka ‘/’) is in fact public_html. In this sense, a user doesn’t have to think about which directory to use to share things on the Web. But it also means that some higher-level directories aren’t available. I’ve already run into some issues with this and I’ll probably be looking for a workaround. I’m assuming there’s one. But it’s sometimes easier to use generally-applicable advice than to find a custom solution.

Further, in terms of access control… It seems that webapps typically make use of diverse directories and .htaccess files to manage some forms of access controls. Unix-style file permissions are also involved but the kind of access needed for a web app is somewhat different from the “User/Group/All” of Unix filesystems. AFAICT, FatCow does support those .htaccess files. But it has its own tools for building them. That can be a neat feature, as it makes it easier, for instance, to password-protect some directories. But it could also be the source of some confusion.

There are other issues I have with FatCow, but it’s probably enough for now.

So… On to the installation process… 😉

It only takes a few minutes and is rather straightforward. This is the most verbose version of that process you could imagine…

Surprised? 😎

Disclaimer: I’m mostly documenting how I did it and there are some things about which I’m unclear. So it may not work for you. If it doesn’t, I may be able to help but I provide no guarantee that I will. I’m an anthropologist, not a Web development expert.

As always, YMMV.

A few instructions here are specific to FatCow, but the general process is probably valid on other hosts.

I’m presenting things in a sequence which should make sense. I used a slightly different order myself, but I think this one should still work. (If it doesn’t, drop me a comment!)

In these instructions, straight quotes (“”) are used to isolate elements from the rest of the text. They shouldn’t be typed or pasted.

I use “example.com” to refer to the domain on which the installation is done. In my case, it’s the domain name I transfered to FatCow from another registrar but it could probably be done without a dedicated domain (in which case it would be “<username>.fatcow.com” where “<username>” is your FatCow username).

I started with creating a MySQL database for WordPress MU. FatCow does have phpMyAdmin but the default tool in the cPanel is labeled “Manage MySQL.” It’s slightly easier to use for creating new databases than phpMyAdmin because it creates the database and initial user (with confirmed password) in a single, easy-to-understand dialog box.

So I created that new database, user, and password, noting down this information. Since that password appears in clear text at some point and can easily be changed through the same interface, I used one which was easy to remember but wasn’t one I use elsewhere.
Then, I dowloaded the following files to my local machine in order to upload them to my FatCow server space. The upload can be done through either FTP or FatCow’s FileManager. I tend to prefer FTP (via CyberDuck on the Mac or FileZilla on PC). But the FileManager does allow for easy uploads.
(Wish it could be more direct, using the HTTP links directly instead of downloading to upload. But I haven’t found a way to do it through either FTP or the FileManager.)
At any rate, here are the four files I transfered to my FatCow space, using .zip when there’s a choice (the .tar.gz “tarball” versions also work but require a couple of extra steps).
  1. WordPress MU (wordpress-mu-2.9.1.1.zip, in my case)
  2. Buddymatic (buddymatic.0.9.6.3.1.zip, in my case)
  3. EarlyMorning (only one version, it seems)
  4. EarlyMorning-BP (only one version, it seems)

Only the WordPress MU archive is needed to install BuddyPress. The last three files are needed for EarlyMorning, a BuddyPress theme that I found particularly neat. It’s perfectly possible to install BuddyPress without this specific theme. (Although, doing so, you need to install a BuddyPress-compatible theme, if only by moving some folders to make the default theme available, as I explained in point 15 in that previous tutorial.) Buddymatic itself is a theme framework which includes some child themes, so you don’t need to install EarlyMorning. But installing it is easy enough that I’m adding instructions related to that theme.

These files can be uploaded anywhere in my FatCow space. I uploaded them to a kind of test/upload directory, just to make it clear, for me.

A major FatCow idiosyncrasy is its FileManager (actually called “FileManager Beta” in the documentation but showing up as “FileManager” in the cPanel). From my experience with both BlueHost and HostGator (two well-known webhosting companies), I can say that FC’s FileManager is quite limited. One thing it doesn’t do is uncompress archives. So I have to resort to the “Archive Gateway,” which is surprisingly slow and cumbersome.

At any rate, I used that Archive Gateway to uncompress the four files. WordPress µ first (in the root directory or “/”), then both Buddymatic and EarlyMorning in “/wordpress-mu/wp-content/themes” (you can chose the output directory for zip and tar files), and finally EarlyMorning-BP (anywhere, individual files are moved later). To uncompress each file, select it in the dropdown menu (it can be located in any subdirectory, Archive Gateway looks everywhere), add the output directory in the appropriate field in the case of Buddymatic or EarlyMorning, and press “Extract/Uncompress”. Wait to see a message (in green) at the top of the window saying that the file has been uncompressed successfully.

Then, in the FileManager, the contents of the EarlyMorning-BP directory have to be moved to “/wordpress-mu/wp-content/themes/earlymorning”. (Thought they could be uncompressed there directly, but it created an extra folder.) To move those files in the FileManager, I browse to that earlymorning-bp directory, click on the checkbox to select all, click on the “Move” button (fourth from right, marked with a blue folder), and add the output path: /wordpress-mu/wp-content/themes/earlymorning

These files are tweaks to make the EarlyMorning theme work with BuddyPress.

Then, I had to change two files, through the FileManager (it could also be done with an FTP client).

One change is to EarlyMorning’s style.css:

/wordpress-mu/wp-content/themes/earlymorning/style.css

There, “Template: thematic” has to be changed to “Template: buddymatic” (so, “the” should be changed to “buddy”).

That change is needed because the EarlyMorning theme is a child theme of the “Thematic” WordPress parent theme. Buddymatic is a BuddyPress-savvy version of Thematic and this changes the child-parent relation from Thematic to Buddymatic.

The other change is in the Buddymatic “extensions”:

/wordpress-mu/wp-content/themes/buddymatic/library/extensions/buddypress_extensions.php

There, on line 39, “$bp->root_domain” should be changed to “bp_root_domain()”.

This change is needed because of something I’d consider a bug but that a commenter on another blog was kind enough to troubleshoot. Without this modification, the login button in BuddyPress wasn’t working because it was going to the website’s root (example.com/wp-login.php) instead of the WPµ installation (example.com/wordpress-mu/wp-login.php). I was quite happy to find this workaround but I’m not completely clear on the reason it works.

Then, something I did which might not be needed is to rename the “wordpress-mu” directory. Without that change, the BuddyPress installation would sit at “example.com/wordpress-mu,” which seems a bit cryptic for users. In my mind, “example.com/<name>,” where “<name>” is something meaningful like “social” or “community” works well enough for my needs. Because FatCow charges for subdomains, the “<name>.example.com” option would be costly.

(Of course, WPµ and BuddyPress could be installed in the site’s root and the frontpage for “example.com” could be the BuddyPress frontpage. But since I think of BuddyPress as an add-on to a more complete site, it seems better to have it as a level lower in the site’s hierarchy.)

With all of this done, the actual WPµ installation process can begin.

The first thing is to browse to that directory in which WPµ resides, either “example.com/wordpress-mu” or “example.com/<name>” with the “<name>” you chose. You’re then presented with the WordPress µ Installation screen.

Since FatCow charges for subdomains, it’s important to choose the following option: “Sub-directories (like example.com/blog1).” It’s actually by selecting the other option that I realized that FatCow restricted subdomains.

The Database Name, username and password are the ones you created initially with Manage MySQL. If you forgot that password, you can actually change it with that same tool.

An important FatCow-specific point, here, is that “Database Host” should be “<username>.fatcowmysql.com” (where “<username>” is your FatCow username). In my experience, other webhosts use “localhost” and WPµ defaults to that.

You’re asked to give a name to your blog. In a way, though, if you think of BuddyPress as more of a platform than a blogging system, that name should be rather general. As you’re installing “WordPress Multi-User,” you’ll be able to create many blogs with more specific names, if you want. But the name you’re entering here is for BuddyPress as a whole. As with <name> in “example.com/<name>” (instead of “example.com/wordpress-mu”), it’s a matter of personal opinion.

Something I noticed with the EarlyMorning theme is that it’s a good idea to keep the main blog’s name relatively short. I used thirteen characters and it seemed to fit quite well.

Once you’re done filling in this page, WPµ is installed in a flash. You’re then presented with some information about your installation. It’s probably a good idea to note down some of that information, including the full paths to your installation and the administrator’s password.

But the first thing you should do, as soon as you log in with “admin” as username and the password provided, is probably to the change that administrator password. (In fact, it seems that a frequent advice in the WordPress community is to create a new administrator user account, with a different username than “admin,” and delete the “admin” account. Given some security issues with WordPress in the past, it seems like a good piece of advice. But I won’t describe it here. I did do it in my installation and it’s quite easy to do in WPµ.

Then, you should probably enable plugins here:

example.com/<name>/wp-admin/wpmu-options.php#menu

(From what I understand, it might be possible to install BuddyPress without enabling plugins, since you’re logged in as the administrator, but it still makes sense to enable them and it happens to be what I did.)

You can also change a few other options, but these can be set at another point.

One option which is probably useful, is this one:

Allow new registrations Disabled
Enabled. Blogs and user accounts can be created.
Only user account can be created.

Obviously, it’s not necessary. But in the interest of opening up the BuddyPress to the wider world without worrying too much about a proliferation of blogs, it might make sense. You may end up with some fake user accounts, but that shouldn’t be a difficult problem to solve.

Now comes the installation of the BuddyPress plugin itself. You can do so by going here:

example.com/<name>/wp-admin/plugin-install.php

And do a search for “BuddyPress” as a term. The plugin you want was authored by “The BuddyPress Community.” (In my case, version 1.1.3.) Click the “Install” link to bring up the installation dialog, then click “Install Now” to actually install the plugin.

Once the install is done, click the “Activate” link to complete the basic BuddyPress installation.

You now have a working installation of BuddyPress but the BuddyPress-savvy EarlyMorning isn’t enabled. So you need to go to “example.com/<name>/wp-admin/wpmu-themes.php” to enable both Buddymatic and EarlyMorning. You should then go to “example.com/<name>/wp-admin/themes.php” to activate the EarlyMorning theme.

Something which tripped me up because it’s now much easier than before is that forums (provided through bbPress) are now, literally, a one-click install. If you go here:

example.com/<name>/wp-admin/admin.php?page=bb-forums-setup

You can set up a new bbPress install (“Set up a new bbPress installation”) and everything will work wonderfully in terms of having forums fully integrated in BuddyPress. It’s so seamless that I wasn’t completely sure it had worked.

Besides this, I’d advise that you set up a few widgets for the BuddyPress frontpage. You do so through an easy-to-use drag-and-drop interface here:

example.com/<name>/wp-admin/widgets.php

I especially advise you to add the Twitter RSS widget because it seems to me to fit right in. If I’m not mistaken, the EarlyMorning theme contains specific elements to make this widget look good.

After that, you can just have fun with your new BuddyPress installation. The first thing I did was to register a new user. To do so, I logged out of my admin account,  and clicked on the Sign Up button. Since I “allow new registrations,” it’s a very simple process. In fact, this is one place where I think that BuddyPress shines. Something I didn’t explain is that you can add a series of fields for that registration and the user profile which goes with it.

The whole process really shouldn’t take very long. In fact, the longest parts have probably to do with waiting for Archive Gateway.

The rest is “merely” to get people involved in your BuddyPress installation. It can happen relatively easily, if you already have a group of people trying to do things together online. But it can be much more complicated than any software installation process… 😉


Development and Quality: Reply to Agile Diary

Former WiZiQ product manager Vikrama Dhiman responded to one of my tweets with a full-blown blogpost, thereby giving support to Matt Mullenweg‘s point that microblogging goes hand-in-hand with “macroblogging.”

My tweet:

enjoys draft æsthetics yet wishes more developers would release stable products. / adopte certains produits trop rapidement.

Vikrama’s post:

Good Enough Software Does Not Mean Bad Software « Agile Diary, Agile Introduction, Agile Implementation.

My reply:

“To an engineer, good enough means perfect. With an artist, there’s no such thing as perfect.” (Alexander Calder)

Thanks a lot for your kind comments. I’m very happy that my tweet (and status update) triggered this.

A bit of context for my tweet (actually, a post from Ping.fm, meant as a status update, thereby giving support in favour of conscious duplication, «n’en déplaise aux partisans de l’action contre la duplication».)

I’ve been thinking about what I call the “draft æsthetics.” In fact, I did a podcast episode about it. My description of that episode was:

Sometimes, there is such a thing as “Good Enough.”

Though I didn’t emphasize the “sometimes” part in that podcast episode, it was an important part of what I wanted to say. In fact, my intention wasn’t to defend draft æsthetics but to note that there seems to be a tendency toward this æsthetic mode. I do situate myself within that mode in many things I do, but it really doesn’t mean that this mode should be the exclusive one used in any context.

That aforequoted tweet was thus a response to my podcast episode on draft æsthetics. “Yes, ‘good enough’ may work, sometimes. But it needs not be applied in all cases.”

As I often get into convoluted discussions with people who seem to think that I condone or defend a position because I take it for myself, the main thing I’d say there is that I’m not only a relativist but I cherish nuance. In other words, my tweet was a way to qualify the core statement I was talking about in my podcast episode (that “good enough” exists, at times). And that statement isn’t necessarily my own. I notice a pattern by which this statement seems to be held as accurate by people. I share that opinion, but it’s not a strongly held belief of mine.

Of course, I digress…

So, the tweet which motivated Vikrama had to do with my approach to “good enough.” In this case, I tend to think about writing but in view of Eric S. Raymond’s approach to “Release Early, Release Often” (RERO). So there is a connection to software development and geek culture. But I think of “good enough” in a broader sense.

Disclaimer: I am not a coder.

The Calder quote remained in my head, after it was mentioned by a colleague who had read it in a local newspaper. One reason it struck me is that I spend some time thinking about artists and engineers, especially in social terms. I spend some time hanging out with engineers but I tend to be more on the “artist” side of what I perceive to be an axis of attitudes found in some social contexts. I do get a fair deal of flack for some of my comments on this characterization and it should be clear that it isn’t meant to imply any evaluation of individuals. But, as a model, the artist and engineer distinction seems to work, for me. In a way, it seems more useful than the distinction between science and art.

An engineer friend with whom I discussed this kind of distinction was quick to point out that, to him, there’s no such thing as “good enough.” He was also quick to point out that engineers can be creative and so on. But the point isn’t to exclude engineers from artistic endeavours. It’s to describe differences in modes of thought, ways of knowing, approaches to reality. And the way these are perceived socially. We could do a simple exercise with terms like “troubleshooting” and “emotional” to be assigned to the two broad categories of “engineer” and “artist.” Chances are that clear patterns would emerge. Of course, many concepts are as important to both sides (“intelligence,” “innovation”…) and they may also be telling. But dichotomies have heuristic value.

Now, to go back to software development, the focus in Vikrama’s Agile Diary post…

What pushed me to post my status update and tweet is in fact related to software development. Contrary to what Vikrama presumes, it wasn’t about a Web application. And it wasn’t even about a single thing. But it did have to do with firmware development and with software documentation.

The first case is that of my Fonera 2.0n router. Bought it in early November and I wasn’t able to connect to its private signal using my iPod touch. I could connect to the router using the public signal, but that required frequent authentication, as annoying as with ISF. Since my iPod touch is my main WiFi device, this issue made my Fonera 2.0n experience rather frustrating.

Of course, I’ve been contacting Fon‘s tech support. As is often the case, that experience was itself quite frustrating. I was told to reset my touch’s network settings which forced me to reauthenticate my touch on a number of networks I access regularly and only solved the problem temporarily. The same tech support person (or, at least, somebody using the same name) had me repeat the same description several times in the same email message. Perhaps unsurprisingly, I was also told to use third-party software which had nothing to do with my issue. All in all, your typical tech support experience.

But my tweet wasn’t really about tech support. It was about the product. Thougb I find the overall concept behind the Fonera 2.0n router very interesting, its implementation seems to me to be lacking. In fact, it reminds me of several FLOSS development projects that I’ve been observing and, to an extent, benefitting from.

This is rapidly transforming into a rant I’ve had in my “to blog” list for a while about “thinking outside the geek box.” I’ll try to resist the temptation, for now. But I can mention a blog thread which has been on my mind, in terms of this issue.

Firefox 3 is Still a Memory Hog — The NeoSmart Files.

The blogpost refers to a situation in which, according to at least some users (including the blogpost’s author), Firefox uses up more memory than it should and becomes difficult to use. The thread has several comments providing support to statements about the relatively poor performance of Firefox on people’s systems, but it also has “contributions” from an obvious troll, who keeps assigning the problem on the users’ side.

The thing about this is that it’s representative of a tricky issue in the geek world, whereby developers and users are perceived as belonging to two sides of a type of “class struggle.” Within the geek niche, users are often dismissed as “lusers.” Tech support humour includes condescending jokes about “code 6”: “the problem is 6″ from the screen.” The aforementioned Eric S. Raymond wrote a rather popular guide to asking questions in geek circles which seems surprisingly unaware of social and cultural issues, especially from someone with an anthropological background. Following that guide, one should switch their mind to that of a very effective problem-solver (i.e., the engineer frame) to ask questions “the smart way.” Not only is the onus on users, but any failure to comply with these rules may be met with this air of intellectual superiority encoded in that guide. IOW, “Troubleshoot now, ask questions later.”

Of course, many users are “guilty” of all sorts of “crimes” having to do with not reading the documentation which comes with the product or with simply not thinking about the issue with sufficient depth before contacting tech support. And as the majority of the population is on the “user” side, the situation can be described as both a form of marginalization (geek culture comes from “nerd” labels) and a matter of elitism (geek culture as self-absorbed).

This does have something to do with my Fonera 2.0n. With it, I was caught in this dynamic whereby I had to switch to the “engineer frame” in order to solve my problem. I eventually did solve my Fonera authentication problem, using a workaround mentioned in a forum post about another issue (free registration required). Turns out, the “release candidate” version of my Fonera’s firmware does solve the issue. Of course, this new firmware may cause other forms of instability and installing it required a bit of digging. But it eventually worked.

The point is that, as released, the Fonera 2.0n router is a geek toy. It’s unpolished in many ways. It’s full of promise in terms of what it may make possible, but it failed to deliver in terms of what a router should do (route a signal). In this case, I don’t consider it to be a finished product. It’s not necessarily “unstable” in the strict sense that a software engineer might use the term. In fact, I hesitated between different terms to use instead of “stable,” in that tweet, and I’m not that happy with my final choice. The Fonera 2.0n isn’t unstable. But it’s akin to an alpha version released as a finished product. That’s something we see a lot of, these days.

The main other case which prompted me to send that tweet is “CivRev for iPhone,” a game that I’ve been playing on my iPod touch.

I’ve played with different games in the Civ franchise and I even used the FLOSS version on occasion. Not only is “Civilization” a geek classic, but it does connect with some anthropological issues (usually in a problematic view: Civ’s worldview lacks anthro’s insight). And it’s the kind of game that I can easily play while listening to podcasts (I subscribe to a number of th0se).

What’s wrong with that game? Actually, not much. I can’t even say that it’s unstable, unlike some other items in the App Store. But there’s a few things which aren’t optimal in terms of documentation. Not that it’s difficult to figure out how the game works. But the game is complex enough that some documentation is quite useful. Especially since it does change between one version of the game and another. Unfortunately, the online manual isn’t particularly helpful. Oh, sure, it probably contains all the information required. But it’s not available offline, isn’t optimized for the device it’s supposed to be used with, doesn’t contain proper links between sections, isn’t directly searchable, and isn’t particularly well-written. Not to mention that it seems to only be available in English even though the game itself is available in multiple languages (I play it in French).

Nothing tragic, of course. But coupled with my Fonera experience, it contributed to both a slight sense of frustration and this whole reflection about unfinished products.

Sure, it’s not much. But it’s “good enough” to get me started.


Happiness Anniversary

HappyTweet

A year ago today, I found out that I was, in fact, happy.

Continue reading


War of the Bugs: Playing with Life in the Brewery

Kept brewing and thinking about brewing, after that last post. Been meaning to discuss my approach to “brewing bugs”: the yeast and bacteria strains which are involved in some of my beers. So, it’s a kind of follow-up.

Perhaps more than a reason for me to brew, getting to have fun with these living organisms is something of an achievement. It took a while before it started paying off, but it now does.

Now, I’m no biochemist. In fact, I’m fairly far to “wet sciences” in general. What I do with these organisms is based on a very limited understanding of what goes on during fermentation. But as long as I’m having fun, that should be ok.

This blogpost is about yeast in brewing. My focus is on homebrewing but many things also apply to craft brewing or even to macrobreweries.

There’s supposed to be a saying that “brewers make wort, yeast makes beer.” Whether or not it’s an actual saying, it’s quite accurate.

“Wort” is unfermented beer. It’s a liquid containing fermentable sugars and all sorts of other compounds which will make their way into the final beer after the yeast has had its fun in it. It’s a sweet liquid which tastes pretty much like Malta (e.g. Vitamalt).

Yeast is a single-cell organism which can do a number of neat things including the fine act of converting simple sugars into alcohol and CO2. Yeast cells also do a number of other neat (and not so neat) things with the wort, including the creation of a large array of flavour compounds which can radically change the character of the beer. Among the four main ingredients in beer (water, grain, hops, and yeast), I’d say that yeast often makes the largest contribution to the finished beer’s flavour and aroma profile.

The importance of yeast in brewing has been acknowledged to different degrees in history. The well-known Reinheitsgebot “purity law” of 1516, which specifies permissible ingredients in beer, made no mention of yeast. As the story goes, it took Pasteur (and probably others) to discover the role of yeast in brewing. After this “discovery,” Pasteur and others have been active at isolating diverse yeast strains to be used in brewing. Before that time, it seems that yeast was just occurring naturally in the brewing process.

As may be apparent in my tone, I’m somewhat skeptical of the “discovery” narrative. Yeast may not have been understood very clearly before Pasteur came on the scene, but there’s some evidence showing that yeast’s contribution to brewing had been known in different places at previous points in history. It also seems likely that multiple people had the same basic insight as LP did but may not have had the evidence to support this insight. This narrative is part of the (home)brewing “shared knowledge.”

But I’m getting ahead of myself.

There’s a lot to be said about yeast biochemistry. In fact, the most casual of brewers who spends any significant amount of time with online brewing resources has some understanding, albeit fragmentary, of diverse dimensions of biochemistry through the action of yeast. But this blogpost isn’t about yeast biochemistry.

I’m no expert and biochemistry is a field for experts. What tends to interest me more than the hard science on yeast is the kind of “folk science” brewers create around yeast. Even the most scientific of brewers occasionally talks about yeast in a way which sounds more like folk beliefs than like hard science. In ethnographic disciplines, there’s a field of “ethnoscience” which deals with this kind of “folk knowledge.” My characterization of “folk yeast science” will probably sound overly simplistic and I’m not saying that it accurately represents a common approach to yeast among brewers. It’s more in line with the tone of Horace Miner’s classic text about the Nacirema than with anything else. A caricature, maybe, but one which can provide some insight.

In this case, because it’s a post on my personal blog, it probably provides more insight about yours truly than about anybody else. So be it.

I’m probably more naïve than most. Or, at least, I try to maintain a sense of wonder, as I play with yeast. I’ve done just enough reading about biochemistry to be dangerous. Again, “the brewery is an adult’s chemistry set.”

A broad distinction in the brewer’s approach to yeast is between “pure” and “wild” yeast. Pure yeast usually comes to the brewer from a manufacturer but it originated in a well-known brewery. Wild yeast comes from the environment and should be avoided at all costs. Wild yeast infects and spoils the wort. Pure yeast is a brewer’s best friend as it’s the one which transforms sweet wort into tasty, alcoholic beer. Brewers do everything to “keep the yeast happy.” Though yeast happiness sounds like exaggeration on my part, this kind of anthropomorphic concept is clearly visible in discussions among brewers. (Certainly, “yeast health” is a common concept. It’s not anthropomorphic by itself, but it takes part in the brewer’s approach to yeast as life.) Wild yeast is the reason brewers use sanitizing agents. Pure yeast is carefully handled, preserved, “cultured.” In this context, “wild yeast” is unwanted yeast. “Pure yeast” is the desirable portion of microflora.

It wouldn’t be too much of an exaggeration to say that many brewers are obsessed with the careful handling of pure yeast and the complete avoidance of wild yeast. The homebrewer’s motto, following Charlie Papazian, may be “Relax, Don’t Worry, Have a Homebrew,” when brewers do worry, they often worry about keeping their yeast as pure as possible or keeping their wort as devoid of wild yeast as possible.

In the context of brewers’ folk taxonomy, wild yeast is functionally a “pest,” its impact is largely seen as negative. Pure yeast is beneficial. Terms like “bugs” or “beasties” are applied to both but, with wild yeast, their connotations and associations are negative (“nasty bugs”) while the terms are applied to pure yeast in a more playful, almost endeared tone. “Yeasties” is almost a pet name for pure yeast.

I’ve mentioned “folk taxonomy.” Here, I’m mostly thinking about cognitive anthropology. Taxonomies have been the hallmark of cognitive anthropology, as they reveal a lot about the ways people conceive of diverse parts of reality and are relatively easy to study. Eliciting categories in a folk taxonomy is a relatively simple exercise which can even lead to other interesting things in terms of ethnographic research (including, for instance, establishing rapport with local experts or providing a useful basis to understanding subtleties in the local language). I use terms like “folk” and “local” in a rather vague way. The distinction is often with “Western” or even “scientific.” Given the fact that brewing in North America has some strong underpinnings in science, it’s quite fun to think about North American homebrewers through a model which involves an opposition to “Western/scientific.” Brewers, including a large proportion of homebrewers, tend to be almost stereotypically Western and to work through (and sometimes labour under) an almost-reductionist scientific mindframe. In other words, my talking about “folk taxonomy” is almost a way to tease brewers. But it also relates to my academic interest in cultural diversity, language, worldviews, and humanism.

“Folk taxonomies” can be somewhat fluid but the concept applies mostly to classification systems which are tree-like, with “branches” coming of broader categories. The term “folksonomy” has some currency, these days, to refer to a classification structure which has some relation to folk taxonomy but which doesn’t tend to work through a very clear arborescence. In many contexts, “folksonomy” simply means “tagging,” with the notion that it’s a free-form classification, not amenable to treatment in the usual “hierarchical database” format. Examples of folksonomies often have to do with the way people classify books or other sources of information. A folksonomy is then the opposite of the classification system used in libraries or in Web directories such as the original Yahoo! site. Tags assigned to this blogpost (“Tagged: Belgian artist…”) are part of my own folksonomy for blogposts. Categories on WordPress blogs such as this ones are supposed to create more of a (folk) taxonomy. For several reasons (including the fact that tags weren’t originally available to me for this blog), I tend to use categories as more of a folksonomy, but with a bit more structure. Categories are more stable than tags. For a while, now, I’ve refrained from adding new categories (to my already overly-long list). But I do add lots of new tags.

Anyhoo…

Going back to brewers’ folk taxonomy of yeast strains…

Technically, if I’m not mistaken, the term “pure” should probably refer to the yeast culture, not to the yeast itself. But the overall concept does seem to apply to types of yeast, even if other terms are used. The terms “wild” and “pure” aren’t inappropriate. “Wild” yeast is undomesticated. “Pure” yeast strains were those strains which were selected from wild yeast strains and were isolated in laboratories.

Typically, pure yeast strains come from one of two species of the genus Saccharomyces. One species includes the “top-fermenting” yeast strains used in ales while the other species includes the “bottom-fermenting” yeast strains used in lagers. The distinction between ale and lager is relatively recent, in terms of brewing history, but it’s one which is well-known among brewers. The “ale” species is called cerevisiae (with all sorts of common misspellings) and the “lager” species has been called different names through history, to the extent that the most appropriate name (pastorianus) seems to be the object of specialized, not of common knowledge.

“Wild yeast” can be any yeast strain. In fact, the two species of pure yeast used in brewing exist as wild yeast and brewers’ “folk classification” of microorganisms often lumps bacteria in the “wild yeast” category. The distinction between bacteria and yeast appears relatively unimportant in relation to brewing.

As can be expected from my emphasis on “typically,” above, not all pure yeast strains belong to the “ale” and “lager” species. And as is often the case in research, the exceptions are where things get interesting.

One category of yeast which is indeed pure but which doesn’t belong to one of the two species is wine yeast. While brewers do occasionally use strains of wild yeast when making other beverages besides beer, wine yeast strains mostly don’t appear on the beer brewer’s radar as being important or interesting. Unlike wild yeast, it shouldn’t be avoided at all costs. Unlike pure yeast, it shouldn’t be cherished. In this sense, it could almost serve as «degré zéro» or “null” in the brewer’s yeast taxonomy.

Then, there are yeast strains which are usually considered in a negative way but which are treated as pure strains. I’m mostly thinking about two of the main species in the Brettanomyces genus, commonly referred to as “Brett.” These are winemakers’ pests, especially in the case of oak aging. Oak casks are expensive and they can be ruined by Brett infections. In beer, while Brett strains are usually classified as wild yeast, some breweries have been using Brett in fermentation to effects which are considered by some people to be rather positive while others find these flavours and aromas quite displeasing. It’s part of the brewing discourse to use “barnyard” and “horse blanket” as descriptors for some of the aroma and flavour characteristics given by Brett.

Brewers who consciously involve Brett in the fermentation process are rather uncommon. There are a few breweries in Belgium which make use of Brett, mostly in lambic beers which are fermented “spontaneously” (without the use of controlled innoculation). And there’s a (slightly) growing trend among North American home- and craft brewers toward using Brett and other bugs in brewing.

Because of these North American brewers, Brett strains are now available commercially, as “pure” strains.

Which makes for something quite interesting. Brett is now part of the “pure yeast” category, at least for some brewers. They then use Brett as they would other pure strains, taking precautions to make sure it’s not contaminated. At the same time, Brett is often used in conjunction with other yeast strains and, contrary to the large majority of beer fermentation methods, what brewers use is a complex yeast culture which includes both Saccharomyces and Brett. It may not seem that significant but it brings fermentation out of the strict “mono-yeast” model. Talking about “miscegenation” in social terms would be abusive. But it’s interesting to notice which brewers use Brett in this way. In some sense, it’s an attitude which has dimensions from both the “Belgian Artist” and “German Engineer” poles in my brewing attitude continuum.

Other brewers use Brett in a more carefree way. Since Brett-brewing is based on a complex culture, one can go all the way and mix other bugs. Because Brett has been mostly associated with lambic brewing, since the onset of “pure yeast” brewing, the complex cultures used in lambic breweries serve as the main model. In those breweries, little control can be applied to the balance between yeast strains and the concept of “pure yeast” seems quite foreign. I’ve never visited a lambic brewery (worse yet, I’ve yet to set foot in Belgium), but I get to hear and read a lot about lambic brewing. My perception might be inaccurate, but it also reflects “common knowledge” among North American brewers.

As you might guess, by now, I take part in the trend to brew carefreely. Even carelessly. Which makes me more of a MadMan than the majority of brewers.

Among both winemakers and beer brewers, Brett has the reputation to be “resilient.” Once Brett takes hold of your winery or brewery, it’s hard to get rid of it. Common knowledge about Brett includes different things about its behaviour in the fermentation process (it eats some sugars that Saccharomyces doesn’t, it takes a while to do its work…). But Brett also has a kind of “character,” in an almost-psychological sense.

Which reminds me of a comment by a pro brewer about a well-known strain of lager yeast being “wimpy,” especially in comparison with some well-known British ale yeast strains such as Ringwood. To do their work properly, lager strains tend to require more care than ale strains, for several reasons. Ringwood and some other strains are fast fermenters and tend to “take over,” leaving little room for other bugs.

Come to think of it, I should try brewing with a blend of Ringwood and Brett. It’d be interesting to see “who wins.”

Which brings me to “war.”

Now, I’m as much of a pacifist as one can be. Not only do I not tend to be bellicose and do I cherish peace, I frequently try to avoid conflict and I even believe that there’s a peaceful resolution to most situations.

Yet, one thing I enjoy about brewing is to play with conflicting yeast strains. Pitting one strain against another is my way to “wage wars.” And it’s not very violent.

I also tend to enjoy some games which involve a bit of conflict, including Diplomacy and Civilization. But I tend to play these games as peacefully as possible. Even Spymaster, which rapidly became focused on aggressions, I’ve been playing as a peace-loving, happy-go-lucky character.

But, in the brewery, I kinda like the fact that yeast cells from different strains are “fighting” one another. I don’t picture yeast cells like warriors (with tiny helmets), but I do have fun imagining the “Battle of the Yeast.”

Of course, this has more to do with competition than with conflict. But both are related, in my mind. I’m also not that much into competition and I don’t like to pit people against one another, even in friendly competition. But this is darwinian competition. True “survival of the fittest,” with everything which is implied in terms of being contextually appropriate.

So I’m playing with life, in my brewery. I’m not acting as a Creator over the yeast population, but there’s something about letting yeast cells “having at it” while exercising some level of control that could be compared to some spiritual figures.

Thinking about this also makes me think about the Life game. There are some similarities between what goes on in my wort and what Conway’s game implies. But there are also several differences, including the type of control which can be applied in either case and the fact that the interaction between yeast cells is difficult to visualize. Not to mention that yeast cells are actual, living organisms while the cellular automaton is pure simulation.

The fun I have playing with yeast cells is part of the reason I like to use Brett in my beers. The main reason, though, is that I like the taste of Brett in beer. In fact, I even like it in wine, by transfer from my taste for Brett in beer.

And then, there’s carefree brewing.

As I described above, brewers are very careful to avoid wild yeast and other unwanted bugs in their beers. Sanitizing agents are an important part of the brewer’s arsenal. Which goes well with the “German engineer” dimension of brewing. There’s an extreme position in brewing, even in homebrewing. The “full-sanitization brewery.” Apart from pure yeast, nothing should live in the wort. Actually, nothing else should live in the brewery. If it weren’t for the need to use yeast in the fermentation process, brewing could be done in a completely sterile environment. The reference for this type of brewery is the “wet science” lab. As much as possible, wort shouldn’t come in contact with air (oxidization is another reason behind this; the obsession with bugs and the distaste for oxidization often go together). It’s all about control.

There’s an obvious reason behind this. Wort is exactly the kind of thing wild yeast and other bugs really like. Apparently, slants used to culture microorganisms in labs may contain a malt-based gelatin which is fairly similar to wort. I don’t think it contains hops, but hops are an agent of preservation and could have a positive effect in such a slant.

I keep talking about “wild yeast and other bugs” and I mentioned that, in the brewer’s folk taxonomy, bacteria are equivalent to wild yeast. The distinction between yeast and bacteria matters much less in the brewery than in relation to life sciences. In the conceptual system behind brewing, bacteria is functionally equivalent to wild yeast.

Fear of bacteria and microbes is widespread, in North America. Obviously, there are many excellent medical reasons to fear a number of microorganisms. Bacteria can in fact be deadly, in the right context. Not that the mere presence of bacteria is directly linked with human death. But there’s a clear association, in a number of North American minds, between bacteria and disease.

As a North American, despite my European background, I tended to perceive bacteria in a very negative way. Even today, I react “viscerally” at the mention of bacteria. Though I know that bacteria may in fact be beneficial to human health and that the human body contains a large number of bacterial cells, I have this kind of ingrained fear of bacteria. I love cheese and yogurt, including those which are made with very complex bacterial culture. But even the mere mention of bacteria in this context requires that I think about the distinction between beneficial and dangerous bacteria. In other words, I can admit that I have an irrational fear of bacteria. I can go beyond it, but my conception of microflora is skewed.

For two years in Indiana, I was living with a doctoral student in biochemistry. Though we haven’t spent that much time talking about microorganisms, I was probably influenced by his attitude toward sanitization. What’s funny, though, is that our house wasn’t among the cleanest in which I’ve lived. In terms of “sanitary conditions,” I’ve had much better and a bit worse. (I’ve lived in a house where we received an eviction notice from the county based on safety hazards in that place. Lots of problems with flooding, mould, etc.)

Like most other North American brewers, I used to obsess about sanitization, at every step in the process. I was doing an average job at sanitization and didn’t seem to get any obvious infection. I did get “gushers” (beers which gush out of the bottle when I open it) and a few “bottle bombs” (beer bottles which actually explode). But there were other explanations behind those occurrences than contamination.

The practise of sanitizing everything in the brewery had some significance in other parts of my life. For instance, I tend to think about dishes and dishwashing in a way which has more to do with caution over potential contamination than with dishes appearing clean and/or shiny. I also think about what should be put in the refrigerator and what can be left out, based on my limited understanding of biochemistry. And I think about food safety in a specific way.

In the brewery, however, I moved more and more toward another approach to microflora. Again, a more carefree approach to brewing. And I’m getting results that I enjoy while having a lot of fun. This approach is also based on my pseudo-biochemistry.

One thing is that, in brewing, we usually boil the wort for an hour or more before inoculation with pure yeast. As boiling kills most bugs, there’s something to be said about sanitization being mostly need for equipment which touches the wort after the boil. Part of the equipment is sanitized during the boiling process and what bugs other pieces of equipment may transfer to the wort before boiling are unlikely to have negative effects on the finished beer. With this idea in mind, I became increasingly careless with some pieces of my brewing equipment. Starting with the immersion chiller and kettle, going all the way to the mashtun.

Then, there’s the fact that I use wild yeast in some fermentations. In both brewing and baking, actually. Though my results with completely “wild” fermentations have been mixed to unsatisfactory, some of my results with “partially-wild” fermentations have been quite good.

Common knowledge among brewers is that “no known pathogen can survive in beer.” From a food safety standpoint, beer is “safe” for four main reasons: boiling, alcohol, low pH, and hops. At least, that’s what is shared among brewers, with narratives about diverse historical figures who saved whole populations through beer, making water sanitary. Depending on people’s attitudes toward alcohol, these stories about beer may have different connotations. But it does seem historically accurate to say that beer played an important part in making water drinkable.

So, even wild fermentation is considered safe. People may still get anxious but, apart from off-flavours, the notion is that contaminated beer can do no more harm than other beers.

The most harmful products of fermentation about which brewers may talk are fusel alcohols. These, brewers say, may cause headaches if you get too much of them. Fusels can cause some unwanted consequences, but they’re not living organisms and won’t spread as a disease. In brewer common knowledge, “fusels” mostly have to do with beers with high degrees of alcohol which have been fermented at a high temperature. My personal sense is that fusels aren’t more likely to occur in wild fermentation than with pure fermentation, especially given the fact that most wild fermentation happens with beer with a low degree of alcohol.

Most of the “risks” associated with wild fermentation have to do with flavours and aromas which may be displeasing. Many of these have to do with souring, as some bugs transform different compounds (alcohol especially, if I’m not mistaken) into different types of acids. While Brett and other strains of wild yeast can cause some souring, the acids in questions mostly have to do with bacteria. For instance, lactobacillus creates lactic acid, acetobacter creates acetic acid, etc.

Not only do I like that flavour and aroma characteristics associated with some wild yeast strains (Brett, especially), I also like sour beers. It may sound strange given the fact that I suffer from GERD. But I don’t overindulge in sour beers. I rarely drink large quantities of beer and sour beers would be the last thing I’d drink large quantities of. Besides, there’s a lot to be said about balance in pH. I may be off but I get the impression that there are times in which sour things are either beneficial to me or at least harmless. Part of brewer common knowledge in fact has a whole thing about alkalinity and pH. I’m not exactly clear on how it affects my body based on ingestion of diverse substances, but I’m probably affected by my background as a homebrewer.

Despite my taste for sour beers, I don’t necessarily have the same reaction to all souring agents. For instance, I have a fairly clear threshold in terms of acetic acid in beer. I enjoy it when a sour beer has some acetic character. But I prefer to limit the “aceticness” of my beers. Two batches I’ve fermented with wild bugs were way too acetic for me and I’m now concerned that other beers may develop the same character. In fact, if there’s a way to prevent acetobacter from getting in my wort while still getting the other bugs working, I could be even more carefree as a brewer than I currently am.

Which is a fair deal. These days, I really am brewing carefreely. Partly because of my “discovery” of lactobacillus.

As brewer common knowledge has it, lactobacillus is just about everywhere. It’s certainly found on grain and it’s present in human saliva. It’s involved in some dairy fermentation and it’s probably the main source of bacterial fear among dairy farmers.

Apart from lambic beers (which all come from a specific region in Belgium), the main sour beer that is part of brewer knowledge is Berliner Weisse. Though I have little data on how Berliner Weisse is fermented, I’ve known for a while that some people create a beer akin to Berliner Weisse through what brewers call a “sour mash” (and which may or may not be related to sour mash in American whiskey production). After thinking about it for years, I’ve done my first sour mash last year. I wasn’t very careful in doing it but I got satisfying results. One advantage of the sour mash is that it happens before boiling, which means that the production of acid can be controlled, to a certain degree. While I did boil my wort coming from sour mash, it’s clear that I still had some lactobacillus in my fermenters. It’s possible that my boil (which was much shorter than the usual) wasn’t enough to kill all the bugs. But, come to think of it, I may have been a bit careless with sanitization of some pieces of equipment which had touched the sour wort before boiling. Whatever the cause, I ended up with some souring bugs in my fermentation. And these worked really well for what I wanted. So much so that I’ve consciously reused that culture in some of my most recent brewing experiments.

So, in my case, lactobacillus is in the “desirable” category of yeast taxonomy. With Brett and diverse Saccharomyces strains, lactobacillus is part of my fermentation apparatus.

As a mad brewer, I can use what I want to use. I may not create life, but I create beer out of this increasingly complex microflora which has been taking over my brewery.

And I’m a happy brewer.