Eddie Welker.com

I love reading programming books, especially to learn a new programming language.  Learning XSLT, I read a large number of books, as there are quite a few available.  The quality of the XSLT books struck me as particularly all over the place, some were quite good while others weren’t even worth the time to skim.  So I’m throwing together a simple list of my current collection of XSLT references, which happened to be my favorites of the bunch.   These books are all geared towards specific audiences… beginners, advanced, etc, so I included their audiences.

• XSLT – Mastering XML Transformations, Doug Tidwell
  This is my favorite XSLT book.  Mr. Tidwell did a great job of combining an introduction to the language, a tutorial on how to write XSLTs, and a reference all into one book.  On top of that, I found it to be written in the clearest, most conversational style I’ve found in many a programming book.  I find this book covers 90% of my day-to-day needs, and when I forget how something works, this book usually answers my questions.  (Plus, hey, you can get the 1.0 version for about $3 used.)
• XSLT: Programmer’s Reference, Michael Kay
  If Mr. Tidwell’s book covers 90%, this book covers all 100%, and then some.  Mr. Kay (who wrote the Saxon processor, if you weren’t aware) presents what amounts to an annotated specification in book form.  One of my co-workers calls this book the XSLT dictionary, and I can’t argue with that.  This book is probably best for advanced programmers.
• XSLT and XPATH on the Edge, Jeni Tennison
  Once you’ve got the basics of the language down, you’ve got to use it to write real-world code.  I found this book helps to smooth down the rough edges of working with the language.  This book requires a mid-level familiarity with the language.
• XSLT Cookbook, Second Edition, Salvatore Mangano
  I reach for this book whenever I’ve got to do something weird.  I use it to find the solution to some odd edge case, or for my “can I do this with XSLT” questions.  The book covers everything from faking regular expressions, to set operations on different node-sets, to functional programming with XSLT.  I don’t use it often, but it’s like gold when I do.  This book is mostly for advanced users.
• XPath and XPointer, John E. Simpson
  The content in this book is totally covered in each of the other books, and it isn’t really XSLT, because it only covers XPath.  But this book is my simple reference to 90% of the XPath questions I have.  It is a nice little book that I could live without, but it certainly makes my life easier having it around.  I think new users will likely get the most out of this book. (Another book that can be had for about $3 used.)

(For disclosure, I did make the links amazon referrals. I feel kinda weird, but figured why not. I don’t expect any results, but if I got some, it’d go straight to buying a new book.)

Recursion is one of the core concepts in programming. It’s valuable not only as a technique for writing programs, but as a general concept for solving problems. XSLT provides many useful elements such as for-each (and apply-templates), but occasionally you will run into a problem which must be solved with recursion. Let’s take a look at a real-world (no Fibonacci!!) example, where we have to operate on a simple string of numbers separated by commas. We’ll take a step-by-step approach to writing a recursive template.

Let’s say we have the following source document, short and sweet. We want to take each number, and wrap it with an element.

<?xml version="1.0" encoding="UTF-8"?>
<comma>1,2,3,4,5,6,7,88,99,100</comma>

The easy way to do this is to use the EXSLT str:tokenize function, which takes a string and some delimiters and splits the string based on those delimiters. All we do is add the xmlns:str and extension-element-prefixes attributes to our xsl:stylesheet declaration, and then call the str:tokenize function.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
version="1.0" xmlns:str="http://exslt.org/strings" 
extension-element-prefixes="str">
 
    <xsl:template match="/>
        <xsl:for-each select="str:tokenize( comma, ',')">
            <xsl:copy-of select="."/>
        </xsl:for-each>
    </xsl:template>
 
</xsl:stylesheet>

The result is, (new-lines added for readability):

<?xml version="1.0"?>
<token>1</token>
<token>2</token>
<token>3</token>
<token>4</token>
<token>5</token>
<token>6</token>
<token>7</token>
<token>88</token>
<token>99</token>
<token>100</token>

Excellent. But let’s say that we don’t have access to the EXSLT functions, and we have to write a template to perform the same thing.

So now we think up a recursive algorithm. Let’s look at a simplified list with three numbers, such as “1,2,3”. First, we print the “1”, the value before the first comma, and then we discard the first comma. At that point, our list will be “2,3” and we repeat, printing the new first value, and discarding the new first comma. Finally, the list becomes only “3”. There is no comma, so we simply print out the rest of the list, “3”. So we will be recursing over the string printing the first number, and then popping off the first number and first comma. This technique will work with a three number list, or a million-number list (though your processor will probably run out of memory before that).

XPath’s “substring-before”, “substring-after”, and “contains” functions are all of the tools that we’ll need to implement our algorithm. “substring-before” lets us obtain the number before the first comma. “substring-after” lets us discard the first number and first comma, and “contains” allows us figure out the last, comma-less case.

Our function starts in the same manner as all recursive functions, dealing with the last case, and then all of the cases before it. The last case will be the comma-less case from our algorithm. So here’s our template skeleton.

    <xsl:template name="splitcommas">
        <xsl:choose>
            <xsl:when test=" not(contains($comma, ','))">
                <!-- do something -->
            </xsl:when>
            <xsl:otherwise>
                <!-- do something -->
            </xsl:otherwise>
        </xsl:choose>
    </xsl:template>

We use the XPath “not(contains($comma, ‘,’))” to, obviously, test whether our list contains a comma. As you probably noticed, we don’t actually have a $comma variable defined, so we’ll add our xsl:param to the template.

    <xsl:template name="splitcommas">
        <xsl:param name="comma"/>
        <xsl:choose>
            <xsl:when test=" not(contains($comma, ','))">
                <!-- do something -->
            </xsl:when>
            <xsl:otherwise>
                <!-- do something -->
            </xsl:otherwise>
        </xsl:choose>
    </xsl:template>

Now we fill in the holes in the template’s framework. First, we’ll handle the comma-less case, simply outputting the value wrapped in a “value” element.

<value><xsl:value-of select="$comma"/></value>

Then we will deal with the otherwise case. We’ll first print out the number before the first comma in the same manner that we printed the comma-less case.

<value><xsl:value-of select="substring-before($comma, ',')"/></value>

Then we’ll perform the same operation on the list after discarding the first number and first comma. We’ll call the template again, passing everything after the first comma (thus excluding both the first number and the first comma).

<xsl:call-template name="splitcommas">
    <xsl:with-param name="comma" select="substring-after($comma, ',')"/>
</xsl:call-template>

Finally, we’ll put all of these parts together, as well as adding a root template that will call our “splitcommas” template.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 
    <xsl:template match="/">
        <xsl:call-template name="splitcommas">
            <xsl:with-param name="comma" select="comma"/>
        </xsl:call-template>
    </xsl:template>
 
    <xsl:template name="splitcommas">
        <xsl:param name="comma"/>
        <xsl:choose>
            <xsl:when test=" not(contains($comma, ','))">
                <value><xsl:value-of select="$comma"/></value>
            </xsl:when>
            <xsl:otherwise>
                <value><xsl:value-of select="substring-before($comma, ',')"/></value>
                <xsl:call-template name="splitcommas">
                    <xsl:with-param name="comma" select="substring-after($comma, ',')"/>
                </xsl:call-template>
            </xsl:otherwise>
        </xsl:choose>
    </xsl:template>
 
</xsl:stylesheet>

When applied to our source document, we get exactly what we wanted, each number of the string, enclosed in a element (I added new-lines for readability).

<?xml version="1.0"?>
<value>1</value>
<value>2</value>
<value>3</value>
<value>4</value>
<value>5</value>
<value>6</value>
<value>7</value>
<value>88</value>
<value>99</value>
<value>100</value>

So we accomplished what we were looking to accomplish by writing a recursive template, however our template only deals with commas. What if our list was separated by spaces instead of commas? We’d have to either write a new template that deals with spaces, or, better yet, modify our template to be more generic and handle many cases. I invite you to take a look at the actual implementation of the str:tokenize function. It isn’t that much more complicated, but does contain a few interesting wrinkles.

If you’re interested in the basics of recursion in general, I highly recommend The Little Schemer which is the most outstanding book I’ve read on the subject.

Using XSLT to copy elements is extremely common when you’re transforming a source document of a certain type (XML, HTML, etc.) to the same type. Often, you need an exact copy of an element verbatim, but other times you need to selectively choose certain elements to copy and others to discard. XSLT makes this process quite elegant using it’s xsl:copy-of and xsl:copy elements. The following is a setp-by-step tutorial on how these elements are used.

When you need an exact copy of an element and it’s children, you use the xsl:copy-of element, which makes an exact copy of the selected element and it’s children. Given the following XML data, which represents a (trivial) inventory of a store, let’s say you want an exact copy of any items with the name “XSLT”.

<?xml version="1.0" encoding="UTF-8"?>
<inventory>
    <item id="1">
        <name>The Little Schemer</name>
        <type>book</type>
        <author>Friedman</author>
        <author>Felleisen</author>
        <list-price>29.95</list-price>
        <sell-price>26.99</sell-price>
        <cost>17.92</cost>
    </item>
    <item id="2">
        <name>XSLT</name>
        <type>book</type>
        <author>Tidwell</author>
        <list-price>49.95</list-price>
        <sell-price>34.99</sell-price>
        <cost>22.92</cost>
    </item>
    <item id="3">
        <name>Romeo and Juliet</name>
        <type>compact disc</type>
        <conductor>Rostropovich</conductor>
        <list-price>18.98</list-price>
        <sell-price>13.99</sell-price>
        <cost>9.92</cost>
    </item>
</inventory>

You simply apply the following XSLT stylesheet to your source document:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 
    <xsl:template match="/">
        <xsl:copy-of select="inventory/item[name = 'XSLT']"/>
    </xsl:template>
 
</xsl:stylesheet>

Which gives you exactly what you were looking for, the “item” with the name “XSLT”.

<?xml version="1.0" encoding="utf-8"?>
<item id="2">
    <name>XSLT</name>
    <type>book</type>
    <author>Tidwell</author>
    <list-price>49.95</list-price>
    <sell-price>34.99</sell-price>
    <cost>22.92</cost>
</item>

That was easy, so now let’s say you want to do a little more with your inventory document. Your boss wants a copy of it to look at the numbers and do some accounting. She doesn’t care about the authors or conductors, so she’d like that information left out. Also, she would like an additional piece of information for each item, the amount of profit off each item sold, the difference between the sell-price and the cost.

Because we are adding a piece of information and getting rid of elements that don’t affect the accounting, we can’t use a xsl:copy-of, because that would output an exact copy of the item element, it’s attribute nodes, and it’s child nodes. This exact copy is called a deep copy, because it not only copies the element, but all of it’s children as well. The solution is to use xsl:copy which performs a shallow copy, which means it only copies the current node, and ignores all children or attribute nodes.

Since xsl:copy only copies one element at a time, you need to explicitly specify that you want to continue copying attribute nodes and child nodes. xsl:apply-templates gives us the leverage to write a template that accomplishes that. The following template starts by matching attribute and children nodes, then copies the node, and recursively applies itself to any attribute or child nodes found in the source tree.

<!-- @* matches any attribute node on the current element,
       node() matches any child nodes of the current element -->
<xsl:template match="@*|node()">
    <!-- shallow copy... 
          only copy the node you're on (be that attribute or child node) -->
    <xsl:copy>
        <!-- apply this template to any other attribute or child nodes found -->
        <xsl:apply-templates select="@*|node()"/>  
    </xsl:copy>
</xsl:template>

Using this template, I can write a XSLT stylesheet that will copy the entire source document without any changes. This isn’t quite what we were looking for, because we wanted to add and remove child elements of item, but this is the first step.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 
    <xsl:template match="/">
        <xsl:apply-templates/>
    </xsl:template>
 
 
    <!-- copy all attribute or child nodes in place -->
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>  
        </xsl:copy>
    </xsl:template>
 
 
</xsl:stylesheet>

So how do we add the profit made from each item and remove the unnecessary information? We use the fact that our xsl:match=”@*|node()” template has a very low priority. Determination of default XSLT priorities are an advanced topic I won’t go into right now, but feel free to explore the topic if you are interested. Our template is essentially given a priority of -.5. Templates such as xsl:template match=”foo”, however, are given a default priority of 0. Because templates matching element names are higher priority, we can easily figure out how to remove the “author” and “conductor” elements, just declare templates without outputs!

<xsl:template match="author"/>
<xsl:template match="conductor"/>

We use the same technique to add an element to our “item” elements. First we use xsl:copy to copy the item node itself. Then we apply-templates to any attribute or children nodes found. When an author or conductor element is found, it will match our explicit rules and produce no output, therefore they will not be copied into our result. Finally, we create a new element named “profit” which will contain the difference between the sell-price and the cost.

<xsl:template match="item">
    <xsl:copy>
        <xsl:apply-templates select="@*|node()"/>
        <profit><xsl:value-of select="(sell-price - cost)"/></profit>
    </xsl:copy>
</xsl:template>

So we arrive at our final XSLT stylesheet, which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 
    <xsl:template match="/">
        <xsl:apply-templates/>
    </xsl:template>
 
    <!-- for each item, copy the <item> element, and apply-templates
         to it's attributes and children. Finally, create a <profit> 
         element, the difference between the sell-price and the cost.  -->
    <xsl:template match="item">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
            <profit><xsl:value-of select="(sell-price - cost)"/></profit>
        </xsl:copy>
    </xsl:template>
 
    <!-- don't copy these, when they're found, there is no output -->
    <xsl:template match="author"/>
    <xsl:template match="conductor"/>
 
    <!-- copy all attribute or child nodes in place -->
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>  
        </xsl:copy>
    </xsl:template>
 
 
</xsl:stylesheet>

When applied to our source document, we get the result our boss wanted, it excludes any “author” or “composer” elements, and includes a “profit” element.

<?xml version="1.0" encoding="utf-8"?>
<inventory>
    <item id="1">
        <name>The Little Schemer</name>
        <type>book</type>
        <list-price>29.95</list-price>
        <sell-price>26.99</sell-price>
        <cost>17.92</cost>
        <profit>9.07</profit>
    </item>
    <item id="2">
        <name>XSLT</name>
        <type>book</type>
        <list-price>49.95</list-price>
        <sell-price>34.99</sell-price>
        <cost>22.92</cost>
        <profit>12.07</profit>
    </item>
    <item id="3">
        <name>Romeo and Juliet</name>
        <type>compact disc</type>
        <list-price>18.98</list-price>
        <sell-price>13.99</sell-price>
        <cost>9.92</cost>
        <profit>4.07</profit>
    </item>
</inventory>

Using this technique, we can then easily prepare another XSLT stylesheet to generate an inventory list for the customer, which will exclude the “cost” element, since we don’t want them knowing it! All we need is to match all attribute and children nodes and copy them as normal, while providing no output when the XSLT processor encounters a “cost” element.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 
    <xsl:template match="/">
        <xsl:apply-templates/>
    </xsl:template>
 
 
    <!-- don't copy the cost, the customer doesn't need to know! -->
    <xsl:template match="cost"/>
 
 
    <!-- copy all attribute or child nodes in place -->
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>  
        </xsl:copy>
    </xsl:template>
 
</xsl:stylesheet>

Personally, because I end up transforming XML sources to XML output, I end up using xsl:copy-of and xsl:template match=”@*|node()” all the time. In fact, xsl:template match=”@*|node()” just happens to be the first piece of code in my XSLT toolbox.

I don’t typically link to other blogs/articles, nor do I mention classical music particularly often, but I found this article and blog entry so interesting and thought-provoking that they deserve a re-post.

First, a moving blog entry from David Finlayson, trombonist in the New York Philharmonic, and second, the New York Times article describing the background, as well as referencing the blog post.

While I’ve never had a specifically parallel experience, I can relate to the concepts of “fakes” in a particular industry.  I find Mr. Finlayson’s reaction (that all musicians must take responsibility and blame for the situation) to be both bold, yet… well, correct.  It takes a strong person to identify a stormy situation clearly and react in an appropriate fashion.  I only hope that I would react the same way given the circumstanses.

Working with more than a few new-hires over the last few weeks, I’ve noticed that new XSLT developers often write pull-style XSLTs by default. However, this tends to defy XSLT’s functional heritage, and is not as useful as the opposite form, push-style XSLTs.

Pull-style XSLTs reach into the source document and pull out the data they need to transform. The pull-style is similar to template systems like those found in Rails or Django, or inserting PHP commands between HTML elements. For example, given the trivial input:

<?xml version="1.0" encoding="UTF-8"?>
<books>
    <book>
        <title>The Scheme Programming Language</title>
        <author>R. Kent Dybvig</author>
    </book>
    <book>
        <title>Essentials of Programming Languages</title>
        <author>Daniel P. Friedman</author>
    </book>
    <book>
        <title>An Introduction to Information Theory</title>
        <author>John R. Pierce</author>
    </book>
</books>

an XSLT novice will produce a stylesheet like the following (note lines 11 and 12 which reach into the source and grab the data):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
    <xsl:template match="/">
        <html>
            <head>
                <title>books</title>
            </head>
            <body>
                <dl>
                    <xsl:for-each select="books/book">
                        <dt><xsl:value-of select="title"/></dt>
                        <dd><xsl:value-of select="author"/></dd>
                    </xsl:for-each>
                </dl>
            </body>
        </html>
    </xsl:template>
</xsl:stylesheet>

which transforms into:

<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <title>books</title>
   </head>
   <body>
      <dl>
         <dt>The Scheme Programming Language</dt>
         <dd>R. Kent Dybvig</dd>
         <dt>Essentials of Programming Languages</dt>
         <dd>Daniel P. Friedman</dd>
         <dt>An Introduction to Information Theory</dt>
         <dd>John R. Pierce</dd>
      </dl>
   </body>
</html>

The real power of XSLT, however, is defining templates for the elements found within the source document. These are push-style XSLTs. They have two main advantages. First, push-style gracefully handles complex source structures, including recursively nested elements. It would be near impossible to handle the following source document using pull-style,

<div><div><div>a</div></div></div>

if you didn’t know how deep the recursive divs would go. A push-style solution, though, is incredibly simple.

<xsl:template match="div">
     * <xsl:apply-templates/> *
</xsl:template>

Will transform the previous source into the following.

* * * a * * *

In addition to handling complex source structures, push-style allows code reuse. This is of course an ideal of any programming language. Push-style XSLTs have a greater ability to be reused, because the individual templates can be reused. When you only have one template, it is quite difficult to make it general without resorting to numerous choose-when statements. Here is an example of code reuse, where we extend a previously written template with the xsl:apply-imports rule.

Given the input,

<images>
    <image>
        <url>http://www.filmjunkie.com/drinks/blixa/blixa.jpg</url>
        <alt>Blixa!</alt>
    </image>
</images>

and the XSLTs,

    <xsl:import href="imageformat.xsl"/>
 
    <xsl:template match="image">
        <div class="wrapper">
            <xsl:apply-imports/>
        </div>
    </xsl:template>

and the rule in “imageformat.xsl” (the template being extended in this case),

    <xsl:template match="image">
        <img src="{url}" alt="{alt_text}"/>
    </xsl:template>

the processor will apply the higher-precedence template first, and then apply the imported (and lower-precedence) template to yield the following output.

<div class="wrapper">
    <img src="http://www.filmjunkie.com/drinks/blixa/blixa.jpg" alt="Blixa!"/>
<div>

Push-style XSLTs are not the most obvious thing to pick up unless you’ve been exposed to a functional programming language like Lisp or Scheme. However, considering their great value, they should be among the first disciplines studied when learning XSLT.

The final installment… a little late.

• Amityville Horror – (The OLD one, not the new one.)  I’d watched this before, but it was so much better than I remember it.  In fact, I felt it was the scariest movie that I ended up watching.  The scene at the beginning where the priest goes into the house was totally blood chilling.
• House of 1000 Corpses – I waited for years to see this movie, only to end up kinda disappointed.  I figured Rob Zombie had to know what he was doing with a horror movie, but the plot was so off-the-wall that I couldn’t believe anything, resulting in my rather ambivalent feeling towards it.  Too many characters killing too many other characters.  The creepy clown was the only interesting/memorable character.
• The Devil’s Rejects – I also waited a number of years to see this movie, but was prevented under the reasoning that I had to see House of 1000 Corpses first.  With that finally out of the way, I was now allowed, but I was wary… especially after the last film.  For the Devil’s Rejects, Rob Zombie took the large number of characters and un-realistic plot from the first movie, and turned it on it’s head… keeping the cast numbers low and keeping the entire movie realistic.  Zombie made the 3 bad guys out to be quasi-good guys, and the cop into a revenge obsessed bad guy.  The result was a really good character study of some truly bizarre people.  This movie wasn’t particularly scary, but it was quite good.
• Carrie – One of the best scary movies ever… my favorite part is at the end where Carrie’s hand… well, you know.
• The Exorcist – I LOVE this movie. I saved this pick until Halloween night. I love Max von Sydow, the early scenes in the desert, Father Damien, the fact that the movie is based on something that happened in a part of Maryland I frequent, that the movie’s steps are right down the street from where I used to work in Georgetown.  My favorite.

Latest installment…

• The Blob – Pure 60’s cheese (well, technically 1958, but close enough). Not scary, more silly than anything else. I was amazed that at one point, there was 24 minutes of no blobbing. Instead, we were shown a nearly 30 year old McQueen pretending to be a high schooler.  At least I can say I’ve seen it once.
• Hellbound: Hellraiser II – I had heard (multiple times) that this lived up to, if not surpassed, the original.  I didn’t quite think that was true.  [spoiler] I didn’t like Pinhead reverting to a human and dying.  A hero has an air of invincibility, and a super-villain (from hell no less) should be the same.  The plot set him up against the true villain of this movie, and Pinhead lost.  What a shame.  That said, it was immensely psychological, and quite a captivating movie (we were all watching with baited breath throughout). I thought it was terrific, just not as good as the first.
• Dead Alive – What can you say about a movie like that? Tons of gore and grossness, with only a hint of a plot. It is indeed a “classic.” Did I like it?  Ehh, it was ok… but I can appreciate it, especially viewed through the eyes of others.

Continuing the reviews of my house’s October horror movie film-fest:

• 28 Days Later – Rick told me that this was among the most realistic zombie movies ever made.  While it had a realistic look and feel, I had a problem with the unrealistic (and porous) plot line.  Of the 4 or so main characters, the supporting father and daughter roles were sympathetic, but I cared nothing for the main male and female leads.  That would be fine, if I didn’t also have to care about the weak plot (and yes, I know we’re talking about a zombie movie, but still!).  I didn’t dislike the movie, but it wasn’t my favorite.
• Hellraiser – I’ve been excited about watching this ever since I first heard the (rejected) soundtrack by Coil.  It was well worth it.  The movie’s imagery was pure 80’s (a compliment) and quite realistic, compared to the only-special-effects imagery I’m used to after watching modern movies. I won’t soon forget the rats nailed to the walls.  Hoping I can sneak Hellraiser II in before Halloween.
• The Shining – I’m sure I don’t need to mention how this movie helps to define the horror genre.  It’s spooky, creepy, and maintains the feeling that things are about to descend into total chaos for so long that you’re exhausted by the end.  My only problem is that the Simpson’s parody is so good that’s all I could think of at times.  Teriffic movie.
• Feast – Ok, I didn’t get all the way through this last night, but I’ve seen it (a few times) before.  It doesn’t take itself too seriously, and is a quintessential example of a trashy, gorey, funny horror movie.  You’d think the end woud be a let-down after how front-heavy the action is, but you’d be wrong.

I recently read Object-Oriented JavaScript, by Stoyan Stefanov. In reviewing it, I found it was one of the most interesting books I’ve read in a while, for some good reasons and a few more curious reasons.

Object-Oriented JavaScript was authored by Mr. Stefanov, who is a developer at Yahoo. It features an impressive number of reviewers (twelve), among them Douglas Crockford, the author of JavaScript: The Good Parts, and Ross Harmes, author of JavaScript Design Patterns, both of whom are Stefanov’s Yahoo co-workers. In a reasonable 330 pages, it features eight chapters on JavaScript’s History, Basic Syntax/Features, Functions, Objects, Prototypes, Inheritance, the DOM, and Patterns/Best Practices.

Readers with little to no JavaScript knowledge will be able to read this book, but I’m uncertain how much they’ll be able to glean from the meaty inner chapters (functions, objects, prototypes, and inheritance). Readers with moderate JavaScript understanding should be able to learn a great deal from this book. At the very least, advanced readers should be reminded of some of the language’s quirkier parts, as well as benefiting from an organized chapter on inheritance techniques.

It is tricky placing Object-Oriented JavaScript in context of the corpus of JavaScript literature. This book includes more than a little introductory material (chapters 1-2), while the core chapters (3-6) are way beyond an introduction. Only after those chapters (which I will discuss in a second) is the reader introduced briefly to the DOM and XHR before a chapter on design patterns and best practices. At a minimum, every chapter is useful and full of hints that are difficult to grep from run-of-the-mill JavaScript books. The book steers clear of the murky world of browser differences unless they’re pertinent to the topic of Object-Oriented JavaScript, which seems perfectly acceptable.

Back to those middle chapters, they are sheer gold. I am going force myself to make time to re-read this book, if not those chapters alone. They present, in a clear and organized fashion, many difficult aspects of the language, including closures, prototype, and 12 different methods for inheritance. In comparison, I believe Harmes’ book isn’t as well organized, and Crockford’s book isn’t as clear. Stefanov doesn’t break much new ground here, but the clarity describing these techniques is quite valuable regardless.

Object-Oriented JavaScript appears occasionally try to be something to everyone. This is kind of disappointing, since I would have loved to have seen any additional discussion or insight the author could have offered in the core chapters. There are tons of introductory JavaScript books, so I don’t know what a book titled Object-Oriented JavaScript gains by including more introduction. This shouldn’t detract from the book’s overall value. All of the chapters are well written and useful. However as a reader gains a better understanding of JavaScript, the introductory chapters will become far less useful, while the other chapters will remain an excellent reference.

In my mind, the three best JavaScript books are Flanagan’s JavaScript The Definitive Guide, Crockford’s JavaScript: The Good Parts, and Harmes’ and [Dustin] Diaz’s Pro JavaScript Design Patterns. Object-Oriented JavaScript doesn’t belong in that company for the reasons mentioned above. However, I would easily give it fourth place, and recommend it as a clear description of JavaScript’s harder parts.

My roommates and I have decided to try to watch a horror/thriller every night of October.  Unfortunately, the Red Sox and a few other distractions have prevented watching one every night, but here’s what we’ve got so far:

• Nightwatch – Not a fan of this movie.  I thought that the scary parts were kinda cheap, and that the plot of the movie was gross (really gross) for the sake of being gross.  That gets under my skin faster than just about anything.  Plus, what’s the point of a movie where the number of possible suspects is 2? As Rick points out, one of the biggest hit/miss parts of Scream was that there were 15 possible suspects. That’s much more interesting.  This was Alissa’s pick.
• Sisters – A psychological horror movie about two Siamese twins that were separated after a number of years and the emotional result of that operation. Very spooky, in a thought-required way.  This movie was my pick.
• Dressed to Kill – Continuing on the Brian De Palma theme… I’m a sucker for Michael Caine.  So I really enjoyed his performance.  The rest of the movie had a really constant quality to it that wasn’t quite eerie, but was close.  Unfortunately, I fell asleep during part of the film (not long…) but I liked it anyway.  This was Rick’s choice.

And upon consultation with them (I had to ask just to be certain) that was it.  They watched Cape Fear without me (I’ve seen it before), but even still… 4 movies in 16 days isn’t good enough.

Other movies that I remember are on our combined list:

• Alien
• The Shining
• Feast*
• Carrie*
• Hellraiser I & II
• Repulsion* (one of the scariest I’ve ever seen, and one of my favs)

* I’ve seen (and loved)

Oct. 8, 2009 – 12:32am

Right now I’m…

Sitting on my bed reading the Fannie Farmer Cookbook (my favorite) on how to bake a 9.25lb ham.  Page 201. Remembering how I tell everyone they can’t take it into the kitchen, because I don’t want it getting dirty.

Thinking about how I need a roasting pan, which I should have grabbed when I was in Laurel, picking up my new camera lens from UPS. Thinking about how I waited 45 minutes for it, when I probably should have had it re-delivered.  Also thinking that the roasting pan may be too large for my oven here.

Listening to George Crumb’s Ancient Voices of Children.  Wishing it drowned out more of “The Shield,” the program my roommates are watching/listening to.  Thinking how much I like Ancient Voices of Children, despite how weird some of the sounds are.

Finished taking a few play photos with the new lens. Posted them to flickr.  Wondering if every good lens makes it this easy, which should I purchase next?  Thinking I made a good choice to start.

Wondering if I will have any clean sock pairs left for me to wear to work tomorrow.

Resisting falling asleep, so I can formally get ready for sleep instead.

They just keep popping up.

I just scrolled down my own blog, and saw a post titled “Down to three bugs.”  Funny enough, three months later, we’re still trying to push the website out. (Wow, those were some really big bugs!!!  Haha, jk…)  In fact, I’ve been pressing for the last 2 days, trying to expedite a few last-minute bugs so that QA testing could begin (for about the 18th time, now in snapshot 21).  Kinda odd, when QA finds bugs in round 20 that they didn’t find in round 10… despite no code changes in the meantime…

But I’m not going to complain.  Programming is still a lot of fun when you’re actually doing it.  It ends up being almost therapeutic when you’ve got other stuff going on that you’re trying to ignore.  Not only that, but there’s always room to improve.  A co-worker came to my desk yesterday and schooled me on how to write code.  When you’re young, you’re stupid.  He had lots of experience, and was… well, right… most of the time.  I was boxed into a corner at some points, but also made a few bad decisions.  The good thing is that I always learn from my mistakes, and next time will be much better.

I remember writing 3.5 websites before I really got common code working the way I wanted.  It was similar to the way I learned how to write CSS.  Excerpting common code so that I would only edit once, vs. editing 6 files just to make one update.  It was easy when I was using CSS, SSI’s, or PHP includes to simply import exactly what I needed, but I find it is far more difficult when using XSLT’s.  Why?  Because in XSLT you need to know not only the structure, but the context.  That’s what makes it difficult… writing context dependent generic code is difficult.

[Of course, dirty secret (I know you’re skimming at this point, not really reading) is that I’m almost on only my 2 year anniversary (Sept. 20) of doing programming/development work.  So my progress is still quite good.]

Alright, I admit that this post was far more stream-of-conciousness than actual post, but it was good for me.  It wasn’t intended to be a “I haven’t written in a month, here’s what I’ve been doing” post, but more a “I’m busy, I’ll be back soon, but I don’t know when” type post.  So on that note…

[I think it’s Siouxsie that’s making me intentionally ambiguous. ]

Ta ta!

-e

[this post is like an email I never wrote to anyone…]

Sweet, Django 1.0 has been released.

“Forms suck.  If you don’t believe me, try to find people who like filling them in.”

Are you kidding, I paid for a book that begins like that?  My first reaction was that I could have written that!  Well I didn’t write it, and I also feel that I got my money’s worth out of Web Form Design, Filling in the Blanks, by Luke Wroblewski.

Forms are hard.  I don’t think I need to mention how hard they can be for users… nor do I need to mention what’s at stake if a user finds your form too difficult.  Every web developer who doesn’t have his/her head in the clouds should know that.  Forms, however, are also very difficult to create… correctly!  A well designed form requires a lot of careful, detailed thought.  You have so much to consider… usability issues, accessibility issues, and you usually don’t have anything to go on except for your personal experience.  This book will help you methodically approach form design, and give you the experience of an expert to guide your decisions.

Web Form Design is useful, because Mr. Wroblewski takes a very detailed approach to each aspect of form design.  Within each chapter, he thoroughly analyzes the major elements to consider when designing a form.   For example, the chapter on “Actions” is devoted to action items such as submit and cancel buttons.  One of the sub-sections discusses where to place these items on the page.  The author first presents the reader with the following image demonstrating all of the reasonable placements for the submit and cancel actions.

Using eye-tracking and usability data, he then discusses the pros and cons of each arrangement, without ever deciding one is better then all others.  This is key because it lets the reader, knowledge in hand, decide his/her own course of action.

The book is especially valuable because of the user data, eye-tracking data, and case studies presented within. Mr. Wroblewski’s backs his reasoning with either a summary of these tests or with an example culled from his experiences.  He reinforces his points with a number of demonstration images, all available from the book’s flickr page.  Then he includes a short “best practices” section to close each chapter, outlining what was discussed.  These can be used almost as checklists.  Interspersed in the text are sidebars which present real-life examples and perspectives from numerous field authorities.

Web Form Design is written well enough so that it can be easily read within a few hours.  However, it’s real place is beside you the next time that you have to design or write a form, so that you will be able to make intelligent design decisions, rather than just best guesses.

Last weekend, I FINALLY had a chance to clean my room, and I’m pleased with the results.  Really, though, this post is just an excuse to do one of those “this is my desk, this is my bookshelf” posts that everyone seems to do.  🙂

My favorite books are mostly at the top (actually, there’s no rhyme or reason to any of it).  Just looking, I realize that there are a bunch of Ruby books that I almost never look at. The orange book behind the wire on the top shelf is a really good Dover book on Graph Theory.

My monitor setup.  I’ve got 3 computers, the laptop, my ‘frankenmac’ desktop, and a pc.  The frankenmac is dying, so I am probably going to have to shift things around.  I don’t have a plan for which computer will go with which monitor, but the desk is now set, and won’t change.  I’ve got my new Griffin Elevator sitting there.  I’m happy with it, keeps the bottom of the laptop really cool.

Anyway, it’s been a week… let’s see how clean I can keep it.