disobey.com

Friend and well-known cryptozoologist Loren Coleman writes that his International Cryptozoology Museum is in dire need of financial support, else it might be closed down due to an IRS audit:

"The [IRS's] audit has gone to five or more levels of meetings and appeals, as I have attempted to explain what being a “cryptozoologist” is all about, that I do make my living this way, and that the museum is an essential part of the overall plan ... To the IRS, the museum verges on being a hobby ... and it needs more income (even if donations) to support itself ... The museum has to make money, or it ceases to exist ... I need to get donations to pay the mortgage for the house-museum where it is now, to keep it from foreclosure, and to pay for the other bills associated with the museum."

I've known about the museum for years and, altruistically, supported it in any way I can. Unbeknownst to me, I was one of the first two to contribute long ago on May 14th, 2005. Back then, Loren had some books donated that reeked of cigarette smoke and, due to allergies, needed to find them a better home. I offered to take them off his hands but, more importantly, to give him some cash to hunt up replacement copies for the museum.

This weekend, I offered my continued support:

"In the last 24 hours, the first “Museum Principal Donor / Life Member” contributed $1050.00. This individual “Morbus” challenges others to join him in donating at the $1000 level to [meet] the goal of keeping this institution open."

Please, do what you can to help the museum. The alternative is that this publicly available resource, in a field already entrenched with a lack of answers, will disappear. Even those who aren't involved or interested in cryptozoology should appreciate the need to keep this information easily available and approachable.

Friend Mark Bernstein promotes "software as craft" with the phrase NeoVictorian Computing. Jeremy recalls that "Part of his argument is that software creators have something to learn from the ideals of the arts and crafts movement: the software world is full of soulless bits and bytes, and maybe we would all be a little happier if we embraced handcraft ... During the talk, I remember Bernstein proposed that software creators should sign their work as a painter signs a painting, which is a lovely visual metaphor that I hope to keep around." And Greg Wilson has a book called Beautiful Code.

Happily, I already agree - they're all echoes of my own belief in "code shui", be it XML (a Morbus Rant from 2002 on "why beauty is important in computer file formats") or in code from 2004 ("His style is quite unique. [Morbus' AmphetaDesk] source reads almost like a paper, instead of terse code. He documents his code well and I've thus far found nothing that was very hard to understand. Best of all, its so un-Perl. He doesn't seem to use really clever tricks to do simple things, so the code has been very easy to understand").

In the Drupal content management system, a "node teaser" is small bit of content used to encourage you to "read more" of the post. Drupal can set the teaser to the entire length of the post (typically used for blogs where you don't need extra click-through), or can automatically generate the teaser to a specific character length. In the past, you could also manually generate teasers by including <--break--> in the node's body. In Drupal 6, manual teaser definition has been improved with JavaScript wizardry, along with a new checkbox: "Show summary in full view".

But there's a small problem with the use of the word "summary". Generally, when a Drupal teaser is included in the node's full view, it's because it's the introduction of the node itself, not necessarily a teaser or summary of the entire body. Over at gamegrene.com, a node's teaser is, in fact, a summary of the node, and is also displayed on the full view itself. It's not the first paragraph of the article but, rather, is styled differently to provide an overview of what you'll be reading. IBM uses the same model at their developerWorks.

If you placed a "summary" at the beginning of the node's body, unstyled, readability would tend to suffer - you'd have the summary (node teaser), and then, theoretically, the introduction (node body), with no clear indication that two different types of content, with two different purposes, are being served.

As I've been working on moving Gamegrene to Drupal 6 (in time for Dungeon and Dragons 4th Edition, coming June 7th), I had to solve the problem of: how do I theme the teaser differently than the body inside node.tpl.php? By the time the template gets the node data, only $body and $content exist; $content only contains the teaser (for list views) or body (for full views). The teaser never exists in a node's full view as its own variable.

To solve this and get the same view as seen on IBM's developerWorks, I used themename_preprocess_node() to detect if a teaser has been manually set and that the "Show summary in full view" checkbox has NOT been enabled. When that checkbox is checked, Drupal automatically adds the teaser to the node's $body (or $content) - it treats the teaser as the introduction to the post, not an actual summary of what you're reading:

function phptemplate_preprocess_node(&$variables) {
  // we like to display teasers on the node view pages in a different style,
  // but only if they were NOT set to "show summary on full view" (which seems
  // backward, but the implication with that checkbox is that the teaser is
  // PART of the node's body, instead of an actual summary of the entire
  // node's body). if a node's unbuilt body starts with <!--break-->, then
  // a teaser has been manually set, and "show summary" is not checked.
  if ($variables['page'] == TRUE) { // only do this on full page views.
    $node = node_load($variables['nid']); // we reload the node because
    // by the time it gets here <!--break--> has already been filtered out.
    // this if logic stolen from node.module's node_teaser_include_verify().
    if (strpos($node->body, '<!--break-->') === 0) {
      $variables['style_teaser_differently'] = TRUE;
      $variables['teaser'] = check_markup($node->teaser, $node->format, FALSE);
    }
  }
}

Note that the extra node_load() is nothing to worry about - since the node has already been loaded earlier in this execution, node_load() will happily return a cached version, saving us any performance concerns.

Now, it's just a matter of displaying it in node.tpl.php:

  <div class="node-summary"></div>

Comments and concerns? Note that, for my particular needs, I wanted this entirely in a theme - I'm not changing data or its structure, merely its display, so doing this sort of stuff in hook_nodeapi() with a module's overhead would be a little much.

You're right: this didn't come any sooner than any of the others.

• A Comprehensive ARG Report from the PMs: "However despite the great critical success of MeiGeist the producers [of the ARG] have been left without anything to show financially for what was in effect a twelve-month project with global impact. Having said that, there is a postscript - the increased reputation gained from the game’s success has drawn in valuable commercial work for the producers."
• 10 Books That Began Your Journey Down the Rabbit-hole: "Maybe they were the books that sparked your search for the truth about JFK or some other world event, about yourself or about that whole elusive thing called Reality. Perhaps these are the ten books that got you questioning all the received truths fed to you in school, by the media and by the well-meaning and equally deluded folks around you. Or maybe these are the ten books that brought you to that jaw-drop moment." Some of these now reside on my reading list.
• The 8 Most Needlessly Detailed Wikipedia Entries: "Unlike the wordy, full-of-itself recap of 7th Heaven, this series manages to sum itself up in a mere 6,787 words, and, it should be noted, seven of those words are "ass," and three of them are "hooker." Can you guess how many times 7th Heaven mentions ass? Not nearly as many times as it does "church," we can tell you that." This, and the other entries, are pretty hilarious.
• Adventures in participatory, interactive, rock'n'roll storytelling.: Great writeup. "Let's talk about this sort of meta-, user-generated-content for a second. In a very real sense, it is a significant and valuable part of the experience. If you joined the Perplex City experience a year in, the only way to conveniently catch up was to consult the player-created resources. Baudrillard once said "the territory no longer precedes the map." Well, in this case, it's more accurate to say "that the map is a big part of the territory itself." If you can encourage your readers to make this sort of content, they aren't just doing something "about" the fiction, they're adding to the experience of the fiction - whether you like it or not."
• Who Owns Hues?: "Until recently, the importance of color as a brand identity wasn’t a big legal issue and the courts were lenient. It was an open question whether trademark law protected distinctive colors that had become strongly associated with a particular product or manufacturer. Today a color war is exploding and the use of color is generating unprecedented lawsuits ... Here are four examples of true "color" trademark infringement lawsuits."

My second daughter, Scarlett Emily, was born April 16th, 2008.

Julia meets her new sister.

Scarlett, wide awake and physical, is suspicious of the butterfly.

All in all, the response to Drupal Tough Love, the new code reviewing blog from chx and I, has been quite favorable, and we've already got a queue of at least a dozen submitted modules to look over. I had a grande chuckle at Amy Stephen's post on it over at OpenSourceCommunity.org:

I lift this service up because it's a perfect example of a functioning community ... What I am trying to say to those of you who are considering this service, but are not quite in touch with the inner geek inside, is this --> don't ask these guys if they think you are fat if you have your box of big clothes out and your skinny clothes are pushed in the back of the closet. It would be just like asking Simon Cowell if you can sing ... Károly and Morbus are not only acknowledged for who they are, and they are not only accepted for who they are, but who they are is celebrated. So, rock on, Drupal community!

We all make mistakes; that's how we learn. Sometimes, though, we need someone to point out our mistakes, to sift through the chaos that is Drupal's contributions repository. Inspired by jpoesen's comment on my code quality entry, chx and I have taken up the task of giving some tough love to Drupal's greatest strength: the army of developers using its APIs. Want your own code publicly reviewed at DrupalToughLove.com? Let us know!

I'm pretty critical about code quality, be it for my own projects or those of others, and have become known as giving harsh code reviews for the Drupal community. Hearing "ask Morbus, but be prepared to cry" pleases me, and I have little impetus to stop doing things I enjoy, regardless of what people think. Recently, someone suggested the reason my reviews seem "assholish" is because I state "you" a lot. I agree with this, I think, and have made an attempt to lessen my usage, though not my anality.

I define code quality via a number of different hard-to-describe metrics. In the case of Drupal, following the code style guidelines is certainly key, but also following Drupal core patterns as well - doing things "like core" is pretty high up there. This could be as simple as using the same documentation string for Drupal hooks, using the same pattern for the null option of a select box, et cetera. Using coder.module (a Drupal lint) to correct 90% of your mistakes should be required and, sometime in the future, tests from something like SimpleTest should be too.

I also think that, if you're going to "take over" a module, or otherwise release one, it should make an attempt at meeting the highest level of code quality. One could argue that "release early, release often" dissuades us from this, but I disagree: there's a difference between "doing it right" and "continuing to suck". I have no problem with weekly releases if you make an attempt to maintain or improve code quality. Hearing "A lot of strings have been lingering in incorrect forms ... as I try to prevent translations from breaking" isn't a legitimate excuse: Drupal core doesn't care about backwards compatibility, and it highlights your own inability to spell-, grammar-, or read-aloud check your strings (while also calling into question the quality of translators who have converted your broken documentation without complaint). I didn't release "my" version of Case Tracker until I considered it of high quality, and I made sure to provide explanation for what I was doing.

Since I've stopped working on Case Tracker, the CHANGELOG.txt hasn't been updated but, more importantly, it hasn't been removed either. This is just the first of a dozen "heading back to crap" problems that Case Tracker is suffering under, as I watch the new maintainer commit style error after style error. I don't give two shits if you're a certain type of programmer, or if you've coded this way "for years": if you're committing a Drupal contribution, you should follow the goals and styles of the parent project. Anything else is utter failure. If you don't want to, get the hell out of contrib, because it's already a sodding mess and you'll only make it worse. Requiring developers to read even the most basic of code practice books should be a guideline for access into any repository. "What is the name of the checklist on page 579 of Code Complete First Edition?", and other "you must have the book" tests, would be awesome.

This lack of quality control is the same reason Steven Wittens (UnConeD) left. He and I have gotten into a number of arguments, certainly, and he coined "The Morbus Effect" but, ideally, we're after the same thing: the best the code can offer, and an attention to research, detail, and testing that is, at times, incredibly boring.

Which all leads us into the blanket response to any criticism of code: "Where's the patch?". The overuse of the "code is golden, talk is not" ideology is as frustrating as anything else. I have no problem with contributing patches to Drupal modules which have made an attempt at code quality. There's a difference in "your code is good, but this needs fixing" vs. "holy crap, everything about this module is wrong". If you make an attempt to write good code, I'll put forth the effort to make it even better. If you don't, then I'm not going to waste my time improving your code: it just needs to start over. Make a new file and port things carefully, rewriting and organizing them properly. Or, do it in the same file and separate the good stuff from the bad by gigantic swathes of whitespace. Until you make the effort to show you care about your code and the parent project it belongs to, I'm not going to either.

Quality is one of the prime reasons I wrote an (unreleased) Achievements module as opposed to installing User Points. Ignoring the different approaches of "achievements" vs. "accumulate[d] points" (which I'll probably touch on in a later post), the 2.0 version of User Points failed at nearly everything. Besides showing, to me, a lack of quality, it actually didn't work properly, further exasperated because it shipped with a number of modules that were never maintained. I sent an email or two stating my dislike, and marveled privately about how so much crap could make it into a "2.0" release, especially one that was proudly presented and ballyhooed at various Drupal conventions. This is why I don't mind complaining about it publicly - it positions itself as something great, but I've yet to see any indication of that. I don't think I'd be as aggressive if it were a new module or developer innocently asking for help - there's no marketing, ego, or pride to provoke my ire.

Inevitably, I got into a chat about it on IRC, and that ever-nefarious "patch?" lament appeared. To me, User Points 2.0 was an example of wrong from the ground up, with duplicate data in the database, a UI that didn't work (functionally or architecturally), shipped modules that no developer cared about anymore, and crazy code patterns that drove me up a wall. The same conversation promised a new developer had taken up the reins of 3.0 with lots of rewrites, and I should check it out. Hating duplicate functionality and the whole "Not Invented Here" problem that often plagues plugin-driven development, I told myself that I would.

I'm embarking on such a journey now, as I find a need for my Achievements module once again. And, still, as I look at the very first lines of User Points 3.0, I find myself clucking disapprovingly. I don't see much improvement but, certainly, it requires more effort to truly make the decision (to their credit, they did remove all the unmaintained contributed modules). For what it's worth, my first 15 minutes of discontent equate to:

• Abuse of constants: User Points defines its permissions and other strings inside constants. This isn't only wrong (Drupal core doesn't do such a thing) but serves no discernible purpose besides being an additional layer of abstraction - perhaps the developer's IDE supports constant completion? If you're not manually and anally testing every line of code (which would root out misspellings or typos, one of a few rationales for code completion in an IDE), then your module isn't up to par. Gladly, SimpleTest integration in the future will indicate more obvious dedication to testing and non-laziness but, of course, that presumes properly written and maintained tests, which is probably too much to ask and could lull one into a false sense of complacency.
• String retardation: Administration permissions in Drupal core are always in the form of "administer something", but User Points happily uses "admin userpoints". It also doesn't know what the hell it's called: the module's page has "User Points", but usage within the code indicate it could be "Userpoints" or "userpoints" and that it could integrate with "e-commerce" or "ecommerce". These are all things I consider easy and obvious indications of quality control - most module interaction is only ever to an end-user, and if you can't perfect the most visible output of your effort, then the actual code isn't getting any love either.

At a 15 minute glance, if someone yelled out "patch?", I'd decline. This is a module that is showing the same problems I lamented privately about for 2.0, and just needs to spend an entire release cycle worrying about quality not functionality. With that said, note that this is, literally, 15 minutes of glancing at the source. I've yet to actually install the new 3.0 and there's still a good chance I'll find it usable enough to merge with my achievements code. "Not Invented Here" syndrome is a sign of laziness too but, as jsled remarked after reading an early draft of this entry, "at some point, learning how to use a tool is more costly than just writing a special-purpose tool".

One suggestion for improving module visibility in Drupal is to offer module ratings. I wouldn't support this idea unless there were two distinct metrics: the end-user metric (does this module do what I want it to do?) and the developer metric (does this module's code live up to the code we ship in Drupal core?). To me, a module's quality equates to a combination of both, and any rating system that attempts to merge the two, or leaves one out, isn't adequately asserting overall health.

Oh, it has been so long since I've spewed some dumpages.

• Five Prescriptions for Viral Games: "Virality ... must be incorporated into a game while the rules are being designed and the technical architecture is being established. It is about making games that players feel invested in, that they want to share with friends--games they’ll go out of their way to show to others. When designing a game, developers should begin asking themselves not only "how will this make the game more fun?" but also "how will this encourage players to share the game with others?"
• The Forgotten Delicious: "The essence of the criticism boils down to two main issues: First, some (including myself) believe that these applications are not only pretty for the sake of pretty, but they also sacrifice functionality in the pursuit of form. Second, and an issue that has become more evident in recent months, the developers of many of these Delicious apps seem to follow a fairly consistent pattern of huge amounts of pre-release hype, 1.0 release with lots of fanfare (and sales), followed by not a whole lot else."
• Banner Blindness: Old and New Findings: "Users rarely look at display advertisements on websites. Of the four design elements that do attract a few ad fixations, one is unethical and reduces the value of advertising networks." Of particular note because it came out in August 2007; I'm 9 months behind!
• The Elements of Typographic Style Applied to the Web: "In order to allay some of the myths surrounding typography on the web, I have structured this website to step through Bringhurst's working principles [from The Elements of Typographic Style], explaining how to accomplish each using techniques available in HTML and CSS. The future is considered with coverage of CSS3, and practicality is ever present with workarounds, alternatives and compromises for less able browsers."
• ARG Stats: "The following list provides information about the uptake, impact and awards garnered from ‘alternate reality games’ (ARGs). I have gathered this information from published sources, preferencing of course information provided by the producers of the projects. Rather than list ‘top ARGs’, I’ve included whatever ARG I was able to find data on. I list them alphabetically because any grading of ARGs will be according to a set of criteria that is highly subjective. It is not a definitive list, but hopes to provoke one."

This has been sitting on my desktop for a while. Just posting it for searchability.

• Use MacTheRipper to rip the DVD to your hard drive. This not only removes encryption that prevents you from using your purchased media as you'd like, but also allows faster encoding times since you're not reading from a slow(er) disc drive.
• Launch ffmpegX and "Open" the VIDEO_TS directory MacTheRipper created.
• Choose an ffmpegX "Quick Preset". I like "XviD mencoder".
• Under the Video tab, first choose the "Title" and "Chapter" of the DVD content to encode. The default is usually enough for the main feature (i.e., the entire movie), but you can choose bonus material by opening the DVD in Apple's DVD Player, showing the Window > Navigation toolbar, and then browsing to the material you'd like. The proper Title and Chapter will be displayed and you'd enter those values into ffmpegX.
• Next, play around with the "Video parameters". Common ratios are 2.35:1 for a feature movie, 16:9 for widescreen video and 4:3 for standard, though you may have to do some test encodes with "5 sec test clip" under ffmpegX's Options tab to make sure you get it right.
• We're going to temporarily skip over the "Bitrate calculator" and head to the Audio tab. I tend to use 80 kbit/s and VBR but, in some cases, this depends on your output - if your output is a 700 MB CD, you may want to give more space to the video encode by setting the audio bitrate to 64 kbit/s. Depending on the source or length, you could use AC3 as opposed to MP3 for a higher quality audio - like for a 60 minute video or a LORD OF THE RINGS.
• Under the Filters tab is a handy "Autocrop"er which can shave off the black borders around your video. Simply click the "Autocrop" button and a preview window will appear with ffmpegX's suggestion. If it works, move on to Options, otherwise, tweak the four boxes (top, bottom, left, right). Unfortunately, if you do need to tweak the cropping, you'll have to do some test encodes to ensure accuracy.
• For a higher quality encode, there are a few things you'll want to turn on under the Options tab. "High Quality", "Use B-frames", "Two-pass encoding", "Trellis quantization" and "Scaling method" "bilinear" are all recommended. You'll also see the "5 sec test clip" option here if you'd like to experiment with your settings before queuing up a few hours of processing time.
• Back to the "Bitrate calculator" under Video. If you're looking for the best bitrate regardless of file size and based on your video size and framerate, click the "Best" button. Alternatively, you can define the number of minutes in your movie and the source destination (such as a CD or DVD) and click "Auto" to calculate the best value. For small clips, like movie trailers, I've decided on "5 MB for every 30 seconds" - a 1 minute 17 second clip would be entered into ffmpegX as "1.50 min" kept in "15 MB" of space. After clicking "Auto", the "Video Bitrate" is set and the "Video Size" ratio is recalculated to match my file size restrictions. Note that if you change any other setting under any tab, always come back here and click "Auto" again - you may be able to get a better bitrate and size.