We are a brand new startup, working to build our MVP. We currently have 2 of our desired 3 “Dream Team”. We have our Hustler (business/marketing) and our Hacker (coding/sys-admin), we just need our Hipster (UI/UX) co-founder to help make our dream a reality.

We are Australian and Canadian and the company is based in Delaware, USA, but we are living and working in Buenos Aires, where we plan to build out the initial product and work on doing market testing and gaining traction. If everything goes well, we plan to move to San Francisco (Silicon Valley) to scale out the business.

The Role

You will be part of a 3 man team, working to build a highly needed, super useful product that helps businesses make more money. Easy sell.

Because you are coming in at the ground level, you will be entitled to founders equity – which we all know is going to be worth BILLION$ in just a few short months

Responsibilities

• User EXPERIENCE. Yes, that’s experience, not design, or interface, or graphics, or logos… EXPERIENCE.
  We are building a B2B product, and our first and foremost focus is to make sure our product is and simple, quick and painless to use. Because time is money for businesses, and unless we can make our product as easy to use as possible, we will fail.
• User Interface.
  Yes, you will still be doing design work and will be responsible for the look and feel of all of the areas of the startup. This includes product interface design, marketing site design, logos, color schemes etc… BUT WAIT. If you are a kick ass user experience person who hates thinking about colors, we still want to talk to you
• Front End HTML/CSS. Putting your UI/UX designs into action. You know the deal.
• Countless other startup hats including content, customer support, testing, marketing, etc.

Requirements

• UX Freak.
  We are looking for someone who lives and breathes UX. UX is your shit, you know what I mean. Websites, web apps, mobile, TV, you are interested in all interfaces. You are on a mission to optimize design and streamline the way humans interact with technology. You have a focus on functionality, simplicity, customer conversion and retention as your key experience design principals. Not pretty colors (not that we don’t like pretty colors).
• Outstanding Overall Communicator (English).
  You gotsa know how to read, write, talk, yell, sing, shout, etc.
• A flexible life situation.
• An understanding of how startups operate (understanding this job description is a good start).
• A burning desire to do something BIG.

Contact vinay@vskill.com.

In this article I will give a quick overview of the pros and cons of these validation techniques, as well as introduce my solution to the problem: Pajama.

Client-side Validation

Performing validation on the client has the advantage of being responsive to the user, as the data can be validated without communicating with the server.

On the other hand, client-side validation has the enormous disadvantage in that it cannot be trusted by the server. The client is in total control of what is being sent, meaning there is no way for a developer to guarantee that the browser is sending valid data. As a result, client-side validation must be combined with some sort of server-side validation in order to ensure the client isn’t tampering with the data.

Server-side Validation

With that in mind, server-side validation seems like a much better solution. Since there are no trust issues with server-side validation, a developer has the option of foregoing client-side validation altogether.

Unfortunately, server-side validation has the downside that every time the client attempts validation, the entire form must be sent to the server. Worse yet, with some server-side validation schemes, all that data must then be sent back to the client and re-rendered if validation fails. This can happen several times for a single form leading to a significant amount of wasted bandwidth, especially for high-traffic sites.

Hybrid Validation

This brings us to hybrid validation. Under this validation scheme, data is first validated by the client. Once the client is satisfied the data is valid, it is then sent to the server and re-validated. This allows a form to have the responsiveness and efficiency of client-side validation with the trust of server-side validation. If a client tampers with the data before it is sent, the server-side validation will catch it.

Hybrid validation isn’t without it’s own drawbacks, however. Unlike client- or server-side validation, hybrid validation takes place in two different spots: the browser and the server. This adds to the implementation complexity. Complicating matters further, the client and server typically do not use the same programming language. This leads to a lot of questions: How do we validate the same way on client and server? Do we need to define our rules twice, once in JavaScript and once in the other language? What happens if the rules need to change? Do we have to remember to update the rules in both languages each time? What if each language has a different validation engine? Do I need to learn both?

This is where Pajama comes in.

Pajama

Pajama is a model validator written in PHP. It uses the same rule system as the popular jQuery Validation plugin and has a similar API. For example, here is how a validator is setup with the jQuery Validation plugin:

$("form").validate({
    rules: {
        first_name: "required",
        last_name: "required"
    },
    submitHandler: function() {
        $.post(...);
    }
});

…and here’s how it’s setup in Pajama:

\Pajama\Validator::validate(array(
     'model' => $_POST,
     'rules' => array(
          'first_name' => 'required',
          'last_name' => 'required',
     ),
     'validHandler' => function() {
          // Store in database.
     },    
));

Notice the similarities in the API. If someone knows how to use the jQuery Validation plugin, they’ll have a good idea of how to use Pajama.

Also notice how the rules are defined. Except for the differences in language syntax (i.e. { foo: "bar" } versus array('foo' => 'bar')), they’re identical. This is where the power of Pajama lies. Pajama implements all the standard jQuery Validation methods. As a result, most rulesets used by the jQuery Validation plugin can also be used with Pajama with minimal modification to account for syntax. But wouldn’t it be nice if we didn’t have to do any modifications?

JSON To The Rescue

One of the biggest issues with hybrid validation is figuring out a way to share the rules between two different programming languages. Pajama solves this issue by using a common JSON rules file. Why does Pajama use a JSON rules file? Well, first off, the jQuery Validation plugin already defines its rules as JavaScript literals, so converting them to JSON is a cinche. Better yet, PHP can easily convert to and from JSON using the json_encode and json_decode functions. Thus, since both JavaScript and PHP can speak JSON, sharing rules between the languages in that format is straightforward and convenient.

To see how simple it is, here’s how the rules from the above example would look as a standalone JSON file:

{
    "first_name":"required",
    "last_name":"required"    
}

Next, to use them with client-side JavaScript, we’d modify the previous example to:

var form = $("form").on("submit", function() { 
    // Disable submit while loading rules.
    return false; 
});
 
$.getJSON("rules.json", function(rules) {
    // Enable submit now that rules are loaded.
    form.off("submit");
    form.validate({
        rules: rules,
        submitHandler: function() {
            $.post(...);
        }
    });
});

…and modify the PHP slightly to:

\Pajama\Validator::validate(array(
     'model' => $_POST,
     'rules' => json_decode('rules.json', true),
     'validHandler' => function() {
          // Store in database.
     },    
));

Presto! We now have a single rules file being used by both the client and the server to validate. If any of the rules need to change, we just need to edit that single file.

And That’s Not All

In addition to the basic functionality outlined in this post, Pajama also supports custom validation methods and a small subset of CSS selectors that can be used for conditional rules. For more information on these subjects, refer to the GitHub page.

“If you want to prove you’re really paying attention, include a verse of ottava rima and a link to your GitHub profile with your application and you’re guaranteed to have your application reviewed by our Software Development Manager.”

I’d never heard of the ottava rima rhyming stanza form before, but a quick trip to Wikipedia remedied that. Essentially, an ottava rima stanza must satisfy three rules:

1. Each stanza must have 8 lines,
2. The lines must be iambic pentameter,
3. The stanza must have the rhyming format a-b-a-b-a-b-c-c.

Here is an example of an ottava rima stanza by Frere (as given in the Wikipedia article):

But chiefly, when the shadowy moon had shed
O’er woods and waters her mysterious hue,
Their passive hearts and vacant fancies fed
With thoughts and aspirations strange and new,
Till their brute souls with inward working bred
Dark hints that in the depths of instinct grew
Subjection not from Locke’s associations,
Nor David Hartley’s doctrine of vibrations.

The simplicity of the rules got me thinking: how hard would it be to write a program to check if a poem stanza is ottava rima?

In this article, we will write a simple ottava rima detector in PHP.

(If you’re not interested in the details, you can skip to the code at GitHub.)

The Detector Function

In our PHP program, the ottava rima detector will be a function named is_ottava_rima that will return true or false depending on whether the stanza string passed to it satisfies the 3 ottava rima rules. The general structure looks something like this:

function is_ottava_rima(
    $stanza, 
    $delimiter = "\n", 
    $syllable_tolerance = 2
) {
    $lines = extract_lines_from($stanza, $delimiter);
 
    // Rule 1.
    if (count($lines) !== 8) {
        return false;
    }
 
    // Rule 2.
    foreach ($lines as $line) {
        if (!is_iambic_pentameter($line, $syllable_tolerance)) {
            return false;
        }
    }
 
    // Rule 3.
    if (!is_abababcc_rhyme($lines)) {
        return false;
    }
 
    return true;
}

For the remainder of this article, we will explore how to implement each of the is_ottava_rima sub-functions in detail.

Extracting Lines

The second rule of our ottava rima detector states:

1. Each stanza must have 8 lines.

This is the most straightforward part of the detector. The extract_lines_from function separates the stanza into lines which are then counted. Here’s what the code looks like:

function is_ottava_rima(
    $stanza, 
    $delimiter = "\n", 
    $syllable_tolerance = 2
) {
    $lines = extract_lines_from($stanza, $delimiter);
 
    // Rule 1.
    if (count($lines) !== 8) {
        return false;
    }
 
    ...
}
 
function extract_lines_from($stanza, $delimiter = "\n") {    
    // Separate the stanza into lines.
    return explode($delimiter, trim($stanza));
}

Phonetic Transcription

Before we move on to the metre and rhyme rules, we need to briefly discuss the concept phonetic transcription.

In order for a program to be able to accurately count how many syllables a word has, or compare two words for rhyme, it needs to first transform the words into a phonetic transcription. This transform is necessary because, in English, the written form of a word, the orthography, can differ from the pronunciation of it. For example, the words “bough” and “trough” do not rhyme in English, even though their spellings might suggest they do.

Our detector will use a combination of two phonetic transcriptions: Arpabet and Metaphone code, although Metaphone code will only be used as a last resort in rhyme detection.

Arpabet, developed by Advanced Research Projects Agency (ARPA), represents each phoneme of General American English with a distinct sequence of ASCII characters. Here is an example of some of the phonemes:

Unfortunately, there is no algorithm for taking an English word and converting it to an Arpabet representation. There is, however, a dictionary called the CMU Pronouncing Dictionary (CMUDict), that allows a program to convert ~120,000 English words to their Arpabet equivalents.

Metaphone is a phonetic algorithm that can transcribe any English word into Metaphone code. Unfortunately, the resulting transcriptions are not as accurate Arpabet. There are 3 versions of Metaphone (Metaphone, Double Metaphone and Metaphone 3). In our detector, we will be using the original Metaphone algorithm that is included in PHP.

Detecting Iambic Pentameter

The second rule of our ottava rima detector states:

2. The lines must be iambic pentameter.

What does it mean for something to be iambic? In English, it refers to a metrical foot comprising of an unstressed syllable followed by a stressed syllable (i.e. “da-DUM”). Thus, in the case of iambic pentameter, there are 5 iambs: “da-DUM da-DUM da-DUM da-DUM da-DUM”.

To simplify our detector, we will be looking for a weaker version of iambic pentameter: we won’t be worrying about the stresses (“da-DUM”) and instead just be looking for 2 syllables per iamb (“da-da”) for a total of 10 syllables per line. With this in mind, we can sketch out some code for an is_iambic_pentameter function:

function is_iambic_pentameter($line, $syllable_tolerance) {
    $syllables = 0;
    $words = explode(' ', $line);
    foreach ($words as $word) {
        $syllables += estimate_syllables($word);
    }
    return $syllables === 10;
}

Which brings us to the next question: how do we count the number of syllables in a word? Well, in order to answer that question, we need ask a more elemental question: what is a syllable?

A syllable consists of two parts: a syllable nucleus (most often a vowel) with optional initial and final margins (typically, consonants). So, we can think of a syllable as a vowel with some optional consonant garnishes. That means that we can roughly estimate the number of syllables in an English word by counting the number of vowels in it. Let’s try that:

function estimate_syllables($word) {
    return count_english_vowels($word);
}
 
function count_english_vowels($word) {
    static $english_vowels = array('A', 'E', 'I', 'O', 'U');
    $vowel_count = 0;
    $letters = str_split(strtoupper($word));
    foreach ($letters as $letter) {
        if (in_array($letter, $english_vowels)) {
            $vowel_count++;
        }
    }
    return $vowel_count;
}

This heuristic works, but there are cases where it can give incorrect results due to the peculiarities of the orthography. For example: “here” would yield 2 syllables instead of 1 and “my” would yield 0 syllables instead of 1. How can we improve on that?

The answer lies in using the Arpabet phonetic transcription. Since a phonetic transcription provides a one-to-one mapping between symbols and sound, we can avoid the over- and under-counting we get with words like “here” and “my”. To demonstrate, here are the Arpabet transcriptions of “here” and “my” (with the vowels bolded):

In this case, both words are correctly shown as having a single Arpabet vowel each and therefore a single syllable. From this somewhat contrived example, we can see that Arpabet more accurately reflect vowel sounds as compared to English orthography. However, using Arpabet is not without its pitfalls. First off, it requires more time and memory, as the CMUDict database needs to be loaded into memory. Second, there are only ~120,000 words in the CMUDict, whereas the English language has ~600,000 words. That means there are a lot of words that CMUDict cannot transcribe to Arpabet.

Thus, in order to be able to handle any English word, we need to take a hybrid approach: If the word is in the CMUDict, we use the Arpabet transcription to get an accurate syllable count. If it’s not, we use the English vowel counting heuristic. Here’s what the code looks like:

function estimate_syllables($word, $syllable_tolerance) {
    $syllable_count = count_arpabet_vowels($word);
    if ($syllable_count === null) {
        $syllable_count = count_english_vowels($word);
    }
    return $syllable_count;
}
 
function count_arpabet_vowels($word) {
    static $arpabet_vowels = array(
        'AO', 'AA', 'IY', 'UW', 'EH', // Monophthongs
        'IH', 'UH', 'AH', 'AX', 'AE',
        'EY', 'AY', 'OW', 'AW', 'OY', // Diphthongs
        'ER' // R-colored vowels
    );
    $cmu_dict = CMUDict::get();
    $phonemes = $cmu_dict->getPhonemes($word);
    if ($phonemes !== null) {
        $vowel_count = 0;
        foreach ($phonemes as $phoneme) {
            if (in_array($phoneme, $arpabet_vowels)) {
                $vowel_count++;
            }
        }
        return $vowel_count;
    } else {
        return null;
    }
}
 
function count_english_vowels($word) {
    static $english_vowels = array('A', 'E', 'I', 'O', 'U');
    $vowel_count = 0;
    $letters = str_split(strtoupper($word));
    foreach ($letters as $letter) {
        if (in_array($letter, $english_vowels)) {
            $vowel_count++;
        }
    }
    return $vowel_count;
}

As you might have noticed, there’s a $syllable_tolerance argument for the is_iambic_pentameter function. This is to compensate for two facts:

• the English vowel counting heuristic can under- or over-estimate the number of syllables,
• some poems don’t match iambic pentameter perfectly.

Thus, to give the detector a bit of flexibility in detecting ottava rima, there is a $syllable_tolerance variable. A value of 2 means that the detector will accept lines that have between 8 and 12 syllables. Here’s the final code for is_iambic_pentameter:

function is_iambic_pentameter($line, $syllable_tolerance) {
    $syllable_count = 0;
    $words = get_words_from($line);
    foreach ($words as $word) {
        $syllable_count += estimate_syllables($word);
    }
    $min_syllable_count = 10 - $syllable_tolerance;
    $max_syllable_count = 10 + $syllable_tolerance;
    return $syllable_count >= $min_syllable_count && 
           $syllable_count <= $max_syllable_count;
}
 
function get_words_from($line) {
    $cleaned_line = trim(preg_replace("/[^A-Za-z' ]/", ' ', $line));
    return preg_split('/\s+/', $cleaned_line);
}

You might have noticed the get_words_from function. This function removes all superfluous punctuation that many poets are so fond of, and then separates the line string into an array of word strings. The reason this logic has been given its own function is because it is used again when detecting rhyme.

Detecting Rhyme

The third rule of our ottava rima detector states:

3. The stanza must have the rhyming format a-b-a-b-a-b-c-c.

Rhyme, according to Wikipedia, is:

“a repetition of similar sounds in two or more words and is most often used in poetry and songs.”

There are several different types of rhymes, including perfect rhymes, general rhymes, and mirror rhymes, each with their own subcategories. In the case of ottava rima, we will be specifically looking for a type of general rhyme called syllabic rhyme, where the last syllable of the words sounds the same.

What this means from a programming perspective is that we need only look at the last syllable of the last word of every line. Since we already have the get_words_from function for breaking lines into an array of words, all we need to do is grab the last word of that array, like so:

function does_rhyme($line1, $line2) {
    $words1 = get_words_from($line1);
    $last_word1 = $words1[count($words1) - 1];
    $words2 = get_words_from($line2);
    $last_word2 = $words2[count($words2) - 1];
 
    ...
}

Next, we need to check if the words are in the CMUDict and, if they are, we retrieve their corresponding Arpabet phonemes.

function does_rhyme($line1, $line2) {
    ...
 
    $words_found = true;
    $cmu_dict = CMUDict::get();
    $phonemes1 = $cmu_dict->getPhonemes($last_word1);
    if ($phonemes1 === null) {
        $words_found = false;
    }
    $phonemes2 = $cmu_dict->getPhonemes($last_word2);
    if ($phonemes2 === null) {
        $words_found = false;
    }
 
    ...
}

Once we know whether or not the CMUDict contains the words, we can check whether or not they rhyme by comparing the last syllable of each word. If the CMUDict did not contain either of the words then we instead compare the last Metaphone code symbol of each word.

function does_rhyme($line1, $line2) {
    ...
 
    if ($words_found) {
        $last_syllable1 = get_last_syllable_of($phonemes1);
        $last_syllable2 = get_last_syllable_of($phonemes2);
        $rhymes = $last_syllable1 === $last_syllable2;
    } else {
        $metaphone1 = metaphone($last_word1);
        $metaphone2 = metaphone($last_word2);
        $rhymes = substr($metaphone1, -1) === substr($metaphone2, -1);
    }
 
    if (!$rhymes) {
        error_log("$last_word1 and $last_word2 don't rhyme.");
    }
 
    return $rhymes;
}

How do we get the last syllable of an Arpabet transcribed word? Well, as we know from earlier, the vowel is the nucleus of a syllable. So, if we scan an Arpabet transcription backwards for the last vowel then chop off everything before it, we can approximately get the last syllable.

function get_last_syllable_of($phonemes) {
    static $arpabet_vowels = array(
        'AO', 'AA', 'IY', 'UW', 'EH', // Monophthongs
        'IH', 'UH', 'AH', 'AX', 'AE',
        'EY', 'AY', 'OW', 'AW', 'OY', // Diphthongs
        'ER' // R-colored vowels
    );
 
    $reversed_syllable_phonemes = array();
    foreach (array_reverse($phonemes) as $phoneme) {
        $reversed_syllable_phonemes[] = $phoneme;
        if (in_array($phoneme, $arpabet_vowels)) {
            break;
        }
    }
    return implode('', array_reverse($reversed_syllable_phonemes));
}

That completes the does_rhyme function for determining if two lines rhyme. Now, in order to determine if an array of lines has the a-b-a-b-a-b-c-c rhyming scheme, we simply need to apply that function to the appropriate lines:

function is_abababcc_rhyme($lines) {
    list($a1, $b1, $a2, $b2, $a3, $b3, $c1, $c2) = $lines;
    $a_rhyme = does_rhyme($a1, $a2) && 
               does_rhyme($a2, $a3) && 
               does_rhyme($a1, $a3);
    $b_rhyme = does_rhyme($b1, $b2) && 
               does_rhyme($b2, $b3) && 
               does_rhyme($b1, $b3);
    $c_rhyme = does_rhyme($c1, $c2);
    return $a_rhyme && $b_rhyme && $c_rhyme;
}

Bringing It All Together

That completes the simplified ottava rima detector. Here is what the final code looks like:

<?php
require_once __DIR__ . '/classes/CMUDict.class.php';
 
function is_ottava_rima(
    $stanza,
    $delimiter = "\n",
    $syllable_tolerance = 2
) {
    $lines = extract_lines_from($stanza, $delimiter);
 
    // Rule 1.
    if (count($lines) !== 8) {
        return false;
    }
 
    // Rule 2.
    foreach ($lines as $line) {
        if (!is_iambic_pentameter($line, $syllable_tolerance)) {
            return false;
        }
    }
 
    // Rule 3.
    if (!is_abababcc_rhyme($lines)) {
        return false;
    }
 
    return true;
}
 
function extract_lines_from($stanza, $delimiter = "\n") {
    // Separate the stanza into lines.
    return explode($delimiter, trim($stanza));
}
 
function is_iambic_pentameter($line, $syllable_tolerance) {
    $syllable_count = 0;
    $words = get_words_from($line);
    foreach ($words as $word) {
        $syllable_count += estimate_syllables($word);
    }
    $min_syllable_count = 10 - $syllable_tolerance;
    $max_syllable_count = 10 + $syllable_tolerance;
    return $syllable_count >= $min_syllable_count && 
           $syllable_count <= $max_syllable_count;
}
 
function get_words_from($line) {
    $cleaned_line = trim(preg_replace("/[^A-Za-z' ]/", ' ', $line));
    return preg_split('/\s+/', $cleaned_line);
}
 
function estimate_syllables($word) {
    $syllable_count = count_arpabet_vowels($word);
    if ($syllable_count === null) {
        $syllable_count = count_english_vowels($word);
    }
    return $syllable_count;
}
 
function count_arpabet_vowels($word) {
    static $arpabet_vowels = array(
        'AO', 'AA', 'IY', 'UW', 'EH', // Monophthongs
        'IH', 'UH', 'AH', 'AX', 'AE',
        'EY', 'AY', 'OW', 'AW', 'OY', // Diphthongs
        'ER' // R-colored vowels
    );
    $cmu_dict = CMUDict::get();
    $phonemes = $cmu_dict->getPhonemes($word);
    if ($phonemes !== null) {
        $vowel_count = 0;
        foreach ($phonemes as $phoneme) {
            if (in_array($phoneme, $arpabet_vowels)) {
                $vowel_count++;
            }
        }
        return $vowel_count;
    } else {
        return null;
    }
}
 
function count_english_vowels($word) {
    static $english_vowels = array('A', 'E', 'I', 'O', 'U');
    $vowel_count = 0;
    $letters = str_split(strtoupper($word));
    foreach ($letters as $letter) {
        if (in_array($letter, $english_vowels)) {
            $vowel_count++;
        }
    }
    return $vowel_count;
}
 
function is_abababcc_rhyme($lines) {
    list($a1, $b1, $a2, $b2, $a3, $b3, $c1, $c2) = $lines;
    $a_rhymes = does_rhyme($a1, $a2) &&
                does_rhyme($a2, $a3) &&
                does_rhyme($a1, $a3);
    $b_rhymes = does_rhyme($b1, $b2) &&
                does_rhyme($b2, $b3) &&
                does_rhyme($b1, $b3);
    $c_rhymes = does_rhyme($c1, $c2);
    return $a_rhymes && $b_rhymes && $c_rhymes;
}
 
function does_rhyme($line1, $line2) {
    $words1 = get_words_from($line1);
    $last_word1 = $words1[count($words1) - 1];
    $words2 = get_words_from($line2);
    $last_word2 = $words2[count($words2) - 1];
 
    $words_found = true;
    $cmu_dict = CMUDict::get();
    $phonemes1 = $cmu_dict->getPhonemes($last_word1);
    if ($phonemes1 === null) {
        $words_found = false;
    }
    $phonemes2 = $cmu_dict->getPhonemes($last_word2);
    if ($phonemes2 === null) {
        $words_found = false;
    }
 
    if ($words_found) {
        $last_syllable1 = get_last_syllable_of($phonemes1);
        $last_syllable2 = get_last_syllable_of($phonemes2);
        $rhymes = $last_syllable1 === $last_syllable2;
    } else {
        $metaphone1 = metaphone($last_word1);
        $metaphone2 = metaphone($last_word2);
        $rhymes = substr($metaphone1, -1) === 
                  substr($metaphone2, -1);
    }
 
    if (!$rhymes) {
        error_log("$last_word1 and $last_word2 don't rhyme.");
    }
 
    return $rhymes;
}
 
function get_last_syllable_of($phonemes) {
    static $arpabet_vowels = array(
        'AO', 'AA', 'IY', 'UW', 'EH', // Monophthongs
        'IH', 'UH', 'AH', 'AX', 'AE',
        'EY', 'AY', 'OW', 'AW', 'OY', // Diphthongs
        'ER' // R-colored vowels
    );
 
    $reversed_syllable_phonemes = array();
    foreach (array_reverse($phonemes) as $phoneme) {
        $reversed_syllable_phonemes[] = $phoneme;
        if (in_array($phoneme, $arpabet_vowels)) {
            break;
        }
    }
    return implode('', array_reverse($reversed_syllable_phonemes));
}

Does It Work?

Of course, there’s no point in writing all this code unless we test it. To that end, a test program was written that analyzed a smattering of ottava rima poems found on the University of Toronto Representative Poetry Online site. The test program analyzed ottava rima stanzas (for false negatives) and non ottava rima stanzas (for false positives). These were the results:

From this rather limited testing, we can can conclude that the detector has a 47.83% chance of false negatives and 0% chance of false positives.

So the detector works, but there is clearly room for improvement.

Conclusion

In this article we implemented a simple ottava rima detector in PHP. This was done by analyzing a string of text representing a poem stanza for the three characteristic properties of an ottava rima poem. The resulting program detected ottava rima stanzas correctly 52% of the time and never detected an non-ottava rima stanzas as ottava rima.

The final code, including the test program and test poetry, is available for download at GitHub.

Serialization

The .NET HttpCookie class stores multiple values in a single cookie by serializing them into a single string. For example, this code:

HttpCookie cookie = new HttpCookie("Cookie1");
cookie.Values["Val1"] = "1";
cookie.Values["Val2"] = "2";
cookie.Values["Val3"] = "3";
Response.Cookies.Add(cookie);

…will result in a cookie that looks like this:

Cookie1=Val1=1&Val2=2&Val3=3

Thus, we can see the HttpCookie serializes the Values property in a similar way to how parameters are encoded in query strings.

The JavaScript (for MS .NET and Mono)

Based on the example output Cookie1=Val1=1&Val2=2&Val3=3, we can work out some JavaScript code to generate it:

// Works with Microsoft .NET and Mono runtimes, with reservations.
var setMultiValuedCookie = function(name, values) {
    var valuePairs = [];
    for (var n in values) {
        valuePairs.push(n + "=" + values[n]);
    }
    var cookieValue = valuePairs.join("&");
    document.cookie = name + "=" + cookieValue;
};

This is more or less how the Microsoft .NET implementation of HttpCookie works. It also happens to be compatible with the Mono implementation (more on that below). The problem with this code is that it does not take into account edge cases, such as when a name or value contain the “=” or “&” characters. In those cases, things can get weird. For example, consider this code:

HttpCookie cookie = new HttpCookie("Cookie1");
cookie.Values["Val1"] = "1&Val2=2";
cookie.Values["Val3"] = "3";
Response.Cookies.Add(cookie);

Notice how only two values are set. Yet, when encoded by Microsoft’s HttpCookie class the resulting output is Cookie1=Val1=1&Val2=2&Val3=3, the exact same output that results the previous three value example in article. However, the cookie, when parsed by HttpCookie, will always be interpreted as having 3 values. This means that Microsoft’s .NET HttpCookie serialization scheme is ambiguous and care must be taken when using it with non-alphanumeric characters.

The JavaScript (just for Mono)

The Mono Project‘s HttpCookie class fares a lot better than its Microsoft counterpart. In the HttpCookie source, there is a nested CookieNVC class (NVC stands for NameValueCollection) with the serialization code in the overridden ToString method:

public override string ToString() {
    StringBuilder builder = new StringBuilder("");
    bool first_key = true;
    foreach (string key in Keys) {
        if (!first_key) { 
            builder.Append("&");
        }
        string[] vals = GetValues(key);        
        if (vals == null) {
           vals = new string[1] {String.Empty};
        }
        bool first_val = true;
        foreach (string v in vals) {
            if (!first_val) {
               builder.Append ("&");
            }
            if (key != null && key.Length > 0) {
                builder.Append (HttpUtility.UrlEncode(key));
                builder.Append ("=");
            }
            if (v != null && v.Length > 0) {
                builder.Append (HttpUtility.UrlEncode(v));
            }    
            first_val = false;
        }        
        first_key = false;
    }
    return builder.ToString();
}

Notice that in the Mono HttpCookie, the names and values are URL encoded in order to escape the “=” and “&” characters. This means that we can use “=” and “&” characters in the name and value of the Values property and they will be serialized unambiguously. To make our JavaScript work with the Mono HttpCookie class improvements, the name and value strings must be URL encoded using encodeURIComponent:

// Warning: Does not work well with the Microsoft .NET runtime.
var setMonoMultiValuedCookie = function(name, values) {
    var valuePairs = [];
    for (var n in values) {
        valuePairs.push(encodeURIComponent(n) + "=" + encodeURIComponent(values[n]));
    }
    var cookieValue = valuePairs.join("&");
    document.cookie = name + "=" + cookieValue;
};

And presto, we have a Mono-compatible verison of setMultiValuedCookie.

Conclusion

In this article we examined how the Microsoft and Mono versions HttpCookie class serialize multiple values into a single cookie. By looking at a sample cookies encoded by HttpCookie, as well as perusing the Mono HttpCookie source code, two JavaScript functions were written: setMultiValuedCookie, a function that serializes multi-valued cookies in manner compatible with both Microsoft and Mono .NET runtimes and setMonoMultiValuedCookie, a function that more robustly serializes multi-valued cookies but is only compatible with the Mono .NET runtime.

CoffeeDOM is intended as a natural evolution for JDOM developers. As such, there have been minimal changes to the API. CoffeeDOM adds support for Java 5 features like generics, enums, and covariant method return types, and reduces the amount of boilerplate required by making previously checked exceptions (like JDOMException) unchecked. In this article, I will briefly go over these changes.

(If you don’t want to bother with the article, you can skip right to the Google Code page or browse the Javadoc API documentation.)

Generic collections

JDOM makes heavy use of the Java Collections Framework, principally Lists and Iterators. Thus, in JDOM, to get a list of all child elements of an element, we do the following:

Element element = ...;
List<?> children = element.getChildren();
for (Object childObject : children) {
    // Cast :(
    Element child = (Element) childObject;
 
    // ...
}

See that pesky cast? How inconvenient. Another approach is to cast the List:

Element element = ...;
// Cast :(
List<Element> children = (List<Element>) element.getChildren();
for (Element child : children) {
    // ...
}

… but then we would need to either ignore a warning (not recommended) or add a @SuppressWarnings("unchecked") annotation. Neither is a desirable solution.

Fortuantely, CoffeeDOM comes to the rescue. In CoffeeDOM, all JCF classes like List, Collection, Iterable, etc. have appropriate generic parameters:

Element element = ...;
List<Element> children = element.getChildren();
for (Element child : children) {
    // ...
}

Enjoy the comfort of compile time type-checking.

Covariant method return types

In JDOM, in order to copy nodes, the built-in Object#clone() method is used:

Element element = ...;
Element clonedElement = (Element) element.clone();

Oh look, another silly cast. Fortunately, thanks to covariant method return types, CoffeeDOM eliminates this unneeded cast:

Element element = ...;
Element clonedElement = element.clone();

CoffeeDOM also removes the need for casting when using detach, setParent and getParent (in most cases).

Enums instead of int constants

This one is pretty straightforward. In JDOM, when we make a new Attribute, we can set the attribute type using an int constant like Attribute.CDATA_TYPE, Attribute.ENTITIES_TYPE, etc. Here’s a (contrived) example:

Element element = ...;
Attribute attribute = new Attribute("name", "value", 
        Attribute.UNDECLARED);
element.setAttribute(attribute);
// ...or just element.setAttribute("name", "value")

Unfortunately, modern IDEs have issues with int constants (they can’t tell which ones go with a particular method). Moreover, operations like iterating through the enum or converting from a string to a constant, are more difficult and messy.

CoffeeDOM remedies this by using Java 5′s enum structure. The above code turns into something rather similar:

Element element = ...;
Attribute attribute = new Attribute("name", "value", 
        Attribute.Type.UNDECLARED);
element.setAttribute(attribute);

…but with the added plus that we can do things like:

// Cycle through the constants.
for (Attribute.Type type : Attribute.Type.values()) {
    ...
}
 
// Get a constant from a string.
Attribute.Type type = Attribute.Type.valueOf("UNDECLARED");

Improved for-each compatibility

In Java 5, Sun juiced up the for loop by enabling it to cycle through Iterable instances. Unfortunately, since JDOM predated this enhancement, some methods return for loop unfriendly Iterator instances. This results in a lot of unneeded boilerplate:

Element element = ...;
Iterator<?> it = element.getDescendants();
while (it.hasNext()) {
    Content descendant = (Content) it.next();
    // ...
}

CoffeeDOM corrects this by making getDescendants return an Iterable instance instead, allowing it to be used with the for loop:

Element element = ...;
for (Content descendant : element.getDescendants()) {
    // ...
}

This change only affects classes implementing the JDOM Parent interface.

Unchecked exceptions

Constantly having to write exception checking code in Java can obfuscate code, especially if you’re just only re-throwing or logging checked exceptions to make the compiler happy. Consider this example in JDOM:

try {
    SAXBuilder builder = new SAXBuilder();
    Document document = builder.build("path/to/file.xml");
    XMLOutputter outputter = new XMLOutputter();
    outputter.output(doc, System.out);
} catch (IOException e) {
    e.printStackTrace();
} catch (JDOMException e) {
    e.printStackTrace();
}

To address this issue, CoffeeDOM changes CoffeeDOMException (the CoffeeDOM equivalent to JDOMException) to an unchecked exception. This reduces some of the exception noise:

// Ahhh... fewer checked exceptions.
try {
    SAXBuilder builder = new SAXBuilder();
    Document document = builder.build("path/to/file.xml");
    XMLOutputter outputter = new XMLOutputter();
    outputter.output(doc, System.out);
}  catch (IOException e) {
    e.printStackTrace();
}

Now with less noise

CoffeeDOM was designed to be an evolutionary step forward for JDOM. The main design goal of CoffeeDOM was to build on the excellent JDOM API by using modern Java features like generics, enums and covariance method return types. The result is better compile-time checking, fewer casts and less annoying exception handling.

Where do I get it? When can I use it?

CoffeeDOM is available now via Google Code as a downloadable JAR file or a Mercurial repository. It is also available from Maven Central using the following dependency markup:

<dependency>
  <groupId>org.cdmckay.coffeedom</groupId>
  <artifactId>coffeedom</artifactId>
  <version>1.0.0</version>
</dependency>

Learn more

As CoffeeDOM is brand new, there isn’t a whole lot of documentation available beyond the Javadoc reference and this article. However, since CoffeeDOM shares a similar API to JDOM, any JDOM tutorial can make a good starting point. See the JDOM documentation page for links to several tutorials that can get you started.

If code samples are your thing, the CoffeeDOM Mercurial repository has a CoffeeDOM-samples project that contains all the JDOM sample projects updated for CoffeeDOM.

As fate would have it, I have had the good fortune to have extensive experience with both C# and Java. While many articles will list things a programmer misses from C# while coding in Java (properties, LINQ, reified generics, type inference, named and optional parameters, closures, continuations), this post intends to look at things a Java programmer might miss while coding in C#.

1. Method return type covariance

Covariant method return types are one of the lesser known Java features (see Section 8.4.5 in the JLS). Basically, Java allows you to narrow the return type of a method when overriding it in a sub-class. For example:

public class Foo {
}
 
public class SubFoo extends Foo {
}
 
public class Bar {
    final Foo foo = new Foo();
    public Foo getFoo() {
        return foo;
    }
}
 
public class SubBar extends Bar {
    final SubFoo subFoo = new SubFoo();
 
    @Override
    public SubFoo getFoo() {
        return subFoo;
    }
}

Although situations where this is needed are seldom, it is a nice feature to have when you need it. An good example of its usage is in the Apache Wicket framework. All pages in Wicket typically derive from the WebPage class. Thus, when you want to access information from a custom Wicket session you need to do something like this:

public class UserInfoPage extends WebPage {
    public UserInfoPage() {
        FooSession session = (FooSession) getSession();
        String userName = session.getUserName();
        ...
    }
}

However, if you add a class above UserInfoPage called FooPage, you can use a covariant return type to eliminate the unsightly cast:

public class FooPage extends WebPage {
    @Override
    public FooSession getSession() {
        return (FooSession) super.getSession();
    }
}
 
public class UserInfoPage extends FooPage {
    public UserInfoPage() {
        FooSession session = getSession();
        String userName = session.getUserName();
        ...
    }
}

To me this is preferable to adding another method called getFooSession(). Having two methods can be confusing to a future maintainer (do I want getFooSession() or getSession()? What’s the difference?) and needlessly clutters your IDE’s code completion.

There is no equivalent in C#, short of adding a method. Will C# ever support such a feature? It’s hard to say, but probably not anytime soon. There has been a request for covariant method return types since 2004. Microsoft response then was:

We hear this request a lot. We’ll consider it for the next release.

After seven years and three major C# releases, it looks like they’re still considering it.

2. Class-like enums

This one is not a big surprise, as it is typically mentioned as one of the few things that Java has done better that C#. In C#, enums are basically glorified integral types. As such, they can’t contain any extra data without using attributes. While attributes are nice, accessing them requires quite a bit of boilerplate.

public enum MotionType {
    Stationary,
    Walking,
    Running,
    [Description("Time Travelling")],
    TimeTravelling
}
 
...
 
MotionType type = MotionType.TimeTravelling;
var description = type
    .GetType()
    .GetField(type.ToString())
    .GetCustomAttributes(typeof(DescriptionAttribute), false)
    .Cast<DescriptionAttribute>()
    .First()
    .Description;
Console.WriteLine(description);

A further restriction of C# enums if that they can’t be used as a generic constraint. For example, the following code would not compile:

public class Monster<TMotionType> where TMotionType : enum {
}

According to C# MVP Jon Skeet, this is not a restriction of the CLR, but is actually a restriction of the Microsoft C# compiler. The best you can do to work around this is to use the broader constraint where : struct, or the Unconstrained Melody library.

Java enums, on the other hand, are specialized classes. Like C# enums, Java enums can be used with switch statements and be converted to integral types. However, Java enums go far beyond these simple uses. Java enums can have instance fields, instance methods and even per-constant methods. Java generics can also be constrained to take only enums.

Here’s how the MotionType enum could be written in Java (notice how easy it is to get the description in this case):

public enum MotionType {
    STATIONARY("Stationary"),
    WALKING("Walking"),
    RUNNING("Running"),
    TIME_TRAVELLING("Time Travelling");
 
    public final String description;
    MotionType(String description) {
        this.description = description;
    }
}
 
...
 
MotionType type = MotionType.TIME_TRAVELLING;
System.out.println(type.description);

This is just scratching the surface of Java enum capabilities. I highly recommend reading Chapter 6 of Effective Java or the Oracle enum documentation.

3. Anonymous inner classes

This is another it’s-useful-when-you-need-it feature of Java that C# mostly addresses with events and delegates. The most common situation for anonymous inner classes in Java is for listeners:

Widget widget = new Widget() {
    public void onInteraction(WidgetState state) {
        ...
    }
};

In C#, this is handled using events and delegates:

Widget widget = new Widget();
widget.Interaction += state => {
    ...
};

The C# approach is superior in most cases. There’s far less clutter and it’s a lot easier to add listener support to a class in C#. Furthermore, since it’s a language feature, you can count on it being more or less the same everywhere. However, it’s not without drawbacks. You’ll notice in the previous Java example, we can guarantee that there is only one listener. Furthermore, if we declare onInteraction as abstract, we can also ensure that all concrete implementations of Widget have an onInteraction handler. The event/delegate approach as written cannot make the same guarantees.

Since C# does not support anonymous inner classes, the best we can do to emulate them is something like this:

Widget widget = new Widget(state => {
    ...
});

…or, if we wanted to make it a little more clear, we could use named parameters:

Widget widget = new Widget(onInteraction: state => {
    ...
});

Locally scoped final/readonly variables

In the book Code Complete 2, Steve McConnell recommends that you use final keyword whenever possible. The justification for this being that less mutable code is easier to keep track of mentally and less likely to be accidentally modified. Although the practice of making everything final can be weird at first, you eventually become so used to using final that you start to feel a little bit exposed whenever a variable isn’t marked final.

C# has a nearly equivalent keyword to final: readonly. However, for some reason, readonly is only usable on the field level. In the local scope, there is no direct equivalent to final in C#. The best you can do is use const, but this only works with compile-time constants, so

const string foo = Foo.getString();

…won’t work.

Conclusion

In this article we looked at four features of Java that lack direct C# equivalents: covariant method return types, class-like enums, anonymous inner classes and locally-scoped final/readonly keywords. C# is often thought of as a “better Java”. However, as this article has shown, this is not true. Java may not have as many bells and whistles as its newer cousin, but it still offers some compelling features that may never find their way into C#.

In this article we will look at how to implement non-short-circuited or “eager” versions of the JavaScript boolean operators && and ||.

As mentioned earlier, most programming languages have short-circuited boolean operators. Short-circuited operators are possible due to certain properties of conjunctions and disjunctions in Boolean logic. In Boolean logic, for a conjunction x1 && x2, if the first argument evaluates to false, the whole expression will be false, regardless of what the other argument evaluates to. Similarly, for a disjunction x1 || x2, if the first argument evaluates to true, the whole expression will be true, regardless of what the other argument evaluates to.

For a more concrete example, consider this snippet of JavaScript:

var str = null;
if (str !== null && str.length > 0) {
    alert("String is not null or empty");
} else {
    alert("String is null or empty");
}

If executed by a browser, this snippet will alert String is null or empty. It does not throw a TypeError when it hits str.length because str.length is never evaluated. The JavaScript interpreter skips it once it sees str !== null evaluates to false. This is an advantage of short-circuiting.

What if we don’t want to short the circuit?

Although short-circuiting is almost always what we want, there are rare instances where we may want to have non-short-circuited or eager evaluation. Consider this example using jQuery:

var validate = function(element) {
    if (element.val() === "") {
        element.addClass("invalid");
        return false;
    } else {
        element.removeClass("highlight");
        return true;
    }
};
 
var form = $("#comments-form");
var name = form.find("#name");
var email = form.find("#email");
var comments = form.find("#comments");
 
form.submit(function() {
    return validate(name) && validate(email) && validate(comments);
});

In this example, we are validating a comments form for a website. In order to do that, we use a validate function to verify that an HTML input is not empty. If it is empty, then we add a CSS class to highlight it and then return false to indicate validation failed. Conversely, if it’s not empty, we remove the highlight CSS class and then return true to indicate validation succeeded.

Unfortunately, this code will only highlight the first field that fails validation. Why? Because the && short-circuits the first time it evaluates an argument to false and thus the rest of the validations will not be executed.

So how do we force them run? Well, if we were using a language like Java or C#, we would simply use the & and | operators, which are eager versions of the short-circuited && and || operators. Unfortunately, although JavaScript does provide the & and | operators, they return numeric (0 or 1) instead of boolean (true or false) results.

Eager boolean operators in JavaScript

(Aside: In the following section I use the arithmetic operators * and + to emulate eager boolean operators. You can just as easily use the bitwise operators & and | in their place. The only reason I used the arithmetic operators was because I thought they would make for a more interesting article).

So we’ve established that JavaScript has no eager boolean operators. JavaScript does, however, offer us two arithmetic operators that can almost accomplish our goal: * and +. These operators, in conjunction with JavaScript’s type coercion semantics, produce the following truth tables when fed all combinations of true and false (&& and || are shown for comparison):

In the table you’ll notice that * and + operators yield almost identical truth tables to the && and || operators, with the exception being that the short-circuited operators produce boolean values (true and false) while the arithmetic operators produce integer values (0, 1 or 2). Moreover, unlike the boolean operators, the arithmetic operators are eager.

That means that, in order to use the arithmetic operators to implement eager boolean operators that produce the exact same results as the built-in boolean operators, we need to map 0 to false and map any non-0 values to true. Fortunately, this is exactly what JavaScript’s type coercion does when forced to coerce a number into a boolean, which can be accomplished by prefixing the number with two ! operators.

And there we have it. We’ve implemented eager boolean operators using JavaScript’s type coercion, the arithmetic operators * and + and the logical not operator !.

Conclusion

Boolean operators in most programming languages are short-circuited: they evaluate their terms left to right and stop (i.e. short-circuit) once they can definitively determine the truth value of expression. This behaviour is usually what we want. However, in some rare cases, we want to evaluate all terms in a boolean expression. Such an operator is called an eager boolean operator.

Although JavaScript does not provide eager boolean operators, they can be emulated by using a combination of JavaScript’s type coercion semantics and arithmetic and logical operators.

This article assumes you have read the first part of this series.

Before we start, we should take a step back and consider what we’re about to do. Our Searcher app has three parts:

• the client-side jQTouch UI,
• the client-side jQuery AJAX calls,
• the server-side PHP script (that could easily be backed by a database)

At this point we have finished the jQTouch UI. However, instead of immediately moving on to writing the jQuery AJAX calls, let’s start with the PHP script instead. This will help us understand our AJAX calls when it comes time to write them.

The PHP Script

Since our PHP script will be performing a search, let’s create a file called search.php and add a single line of boilerplate:

<?php

There’s no need for an end tag. In fact, in files containing only PHP, it is recommended that you do not include an end tag:

For files that contain only PHP code, the closing tag (“?>”) is never permitted. It is not required by PHP, and omitting it prevents the accidental injection of trailing white space into the response.

Our Searcher app needs to search for something, so let’s pretend it’s an interface for a music player and we’re searching for songs. In order to express that idea into PHP code, we need the following elements:

• a Song class to hold the artist name and the title,
• an array holding a bunch of Song objects,
• a function for searching the Song array,
• a way to get a search value from the AJAX request,
• a way to set the MIME type to JSON,
• a way to encode our Song array as JSON

First, we’ll need a class to hold the songs (place this starting at line 3 in search.php):

3
4
5
6
7
8
9
10
11

class Song {
    public $artist;
    public $title;
 
    public function __construct($artist, $title) {
        $this->artist = $artist;
        $this->title = $title;
    }
}

Let’s break it down for those not familiar with PHP classes:

• at line 3, we declare the class name
• at lines 4-5, we declare two public fields to represent the artist’s name and the title of the song,
• at lines 7-10, we declare the class constructor that we use to initialize the two fields of a Song object

Now that we have a way to model songs in our PHP script, we need to make an array of some dummy songs that we can query using AJAX:

13
14
15
16
17
18
19

$songs = array(
    new Song("Weezer", "Say It Ain't So"),
    new Song("Weezer", "Undone"),
    new Song("Cake", "Meanwhile, Rick James..."),
    new Song("The Stars", "Ageless Beauty"),
    new Song("Roy Orbison", "In Dreams")
);

Now we have something of a faux database setup. How will we search it? Why, with a search function, of course! Let’s write that now:

21
22
23
24
25
26
27
28
29
30
31
32
33
34

function search($songs, $value) {
    if (empty($value))
        return $songs;
 
    $matches = array();
    foreach ($songs as $s)
    {
        $matchArtist = stripos($s->artist, $value) !== false;
        $matchTitle = stripos($s->title, $value) !== false;
        if ($matchArtist || $matchTitle)
            $matches[] = $s;
    }
    return $matches;
}

So what does this function do? Let’s take a look line-by-line:

• at lines 22-23, we check to see if the search value is empty (i.e. an empty string or null). If that’s the case, then we just return all the songs
• at line 25, we declare the $matches array. This will contain all the songs that match the search value $value
• at line 26, we use a foreach loop to iterate through all the Song objects in the $songs array
• at lines 28-29, we check to see if the artist name or song title contain the search value $value
• at line 30-31, we add the Song object to the $matches array if it matches the artist name or song title
• at line 33, we return whatever matches (if any) we have found

Ok, so now we have a Song class, an array of Song objects, and a function that searches that array. What’s left in our PHP script? Well, as it stands, we have no way to interface with it. What we need to do now is have some sort of way to respond to the AJAX GET request that our Searcher app will send. To do that, we harness the awesome power of the $_GET superglobal:

36
37

$value = $_GET['value'];
$matches = search($songs, $value);

On the first line, we extract “value” parameter from the $_GET superglobal and assign it to the $value variable. The second line runs our search function on the $songs database and searches for songs that have an artist or title that contains the $value string.

We’re almost there! At this point we’ve managed to get an array of Song objects that match the passed search value. All we need to do now is return that PHP array of objects as a JSON-encoded array of objects. Let’s do that now:

39
40

header('Content-Type: application/json');
echo json_encode($matches);

The first line sets the the MIME type of an HTTP response. MIME types are a sort of meta data that is used to describe what sort of content is being returned. In this case, we are telling jQuery (or whatever client that issued the request) that we are returning content that is JSON formatted. The second line is a built-in PHP function that converts PHP types into a string containing their JSON counterparts. Basically, it allows us to encode our PHP objects into JavaScript and allow us to access them in a nearly identical way:

// PHP
array(
    new Song("Artist 1", "Title 1"),
    new Song("Artist 2", "Title 2")
);
 
// Becomes... (after json_encode)
// JavaScript
[
    { artist: "Artist 1", title: "Title 1" },
    { artist: "Artist 2", title: "Title 2" }
];

And we’re done the PHP script! If we want to test it, we can load execute the PHP file on our server and try different search values. For example, entering this URL should return a JSON array with two Song objects:

// URL
http://example.com/jQTouch-ajax-search/search.php?value=Weezer
 
// Response
[{"artist":"Weezer","title":"Say It Ain't So"},{"artist":"Weezer","title":"Undone"}]

The jQuery AJAX calls

The finish line is now in sight. We’ve successfully written our jQTouch UI and our PHP script. The last thing we need to do is write some jQuery AJAX calls to execute our search and load the results into our UI. In order to do that, we need to do the following:

• listen for the submission of the search form in the jQTouch UI
• when the submission happens, get the search value from the form and set it as a parameter in an AJAX call to search.php
• register a callback that will populate the jQTouch search results when the AJAX call completes

Let’s start with listening for the submit event on the search form. First, we’ll need to create a new JavaScript source file search.js and fill it with the following boilerplate:

(function($){
 
    // Put code here.    
 
})(jQuery);

What this boilerplate does is give our JavaScript script its own context so that can minimize leaking variables into the global JavaScript namespace. It also gives us access to the jQuery object in the convenient $ form, regardless of whether or not “no conflict” mode is enabled.

Recall in part 1 we defined an HTML search form that looked like this:

1
2
3
4
5
6
7
8
9
10
11
12

<form id="search" action="">
    <div class="toolbar">
        <h1>Search</h1>
        <a href="#" class="back">Back</a>
    </div>
    <ul class="rounded">
        <li><input type="text" name="search-text" placeholder="Search" id="search-text" /></li>
    </ul>
    <ul class="edgetoedge" id="search-results">
        <li class="sep">Results</li>                
    </ul>
</form>

Note that on line 1 we defined the id of the form as search. We’ll use that to find the form and register a handler for its submit event so that we can take action when someone tries to perform a search using the jQTouch UI.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

(function($){
 
$(function(){
 
    $("#search").submit(function(event, info) {
        var text = $("input[id=search-text]", this);
        text.blur();
 
        var results = $("#search-results", this).empty();
        results.append($("<li>", {
            "class": "sep",
            text: 'Results for "' + text.val() + '"'
        }));
 
        $.get("search.php",
            { value: text.val() },
            function(data) {
                $.each(data, function(i, song) {
                    var str = song.artist 
                        + " - "
                        + song.title;
                    $("<li>")
                        .text(str)
                        .appendTo(results);
                });
            }
        );
 
        return false;       
    });
 
});
 
})(jQuery);

There’s a lot there, so let’s break it down line-by-line:

• starting at line 3 and ending at line 32 we have the jQuery ready handler which is run once the DOM has finished loading
• starting at line 5 and ending at line 30 we bind a submit event handler to the submit event for the #search form
• at lines 6-7, we retrieve the search-text element, assign it to a variable (for later use on line 16), and then blur (i.e. deselect) the element so that the iPhone keyboard will go away
• at lines 9-13, we clear any previous items in the list that may be hanging around from a previous search and then load in a new separator (“sep”) that contains the search value
• at line 15-27, we perform our AJAX GET request to search.php with the value of the search text field as our value parameter (line 16) and a callback that adds the results to the list (lines 17-26)
• finally, at line 29, we return false to prevent the default form behaviour (i.e. submitting the form) from being carried out

And we’re done. All we need to do now and include search.php in the header of index.html so that it’ll be run:

12

<script src="search.js" type="application/x-javascript" charset="utf-8"></script>

Conclusion

In this, the final installment of How to do an AJAX search with jQTouch, we finished off the example application we started in the first part of this series.

In part 1, we covered building a UI using jQTouch. In part 2, we helped visualize our problem by pretending that we were writing a front-end UI to a server-side music player. To do that, we jumped into server side programming with PHP to write a script to serve us JSON-encoded Song objects. Once we had that setup, we moved back into JavaScript. In order to make use of the PHP script, we wrote a jQuery handler to respond to a jQTouch form submission. The handler, once triggered, issued an AJAX call to the PHP script to pull down the appropriate Song objects for display in our UI.

What Now?

With respect to the goals of this tutorial, nothing. However, if you want to pimp up the application a bit more, some things you could do are:

• Add genres and albums to the PHP Song object and then make the jQTouch UI menu have two additional options: Genres and Albums
• Try to make a Now Playing sub-menu that is activated when a Song is picked from the Search screen

Source

The source code I have written in this article is public domain, and you are free to do what you will with it. Here is a zip of the source, along with the required jQTouch source. It should work pretty much right out of the box.

In this article, we will look at how jQuery animation queues work, how to create and manipulate them, and how to use them in a meaningful way.

Queue fundamentals

Each element has its own set of queues. For example, if we execute this code:

$("#foo").fadeOut();
$("#bar").fadeOut();

The elements #foo and #bar will fade out more or less simultaneously. This is because they have their own fx queues. However, if we execute the code:

$("#foo").fadeOut();
$("#foo").fadeIn();

The element #foo will fade out and then fade in, instead of getting stuck in some sort of tug of war for opacity. This is because they are both using the fx queue of #foo, and thus run one after another.

Creating and manipulating queues

jQuery provides 5 commands for interacting with queues, which are summarized in the table below.

So how do we create a queue? We simply use a queue command that takes a queueName argument. For example, we can use the queue command and add a function to queue. Let’s try it first with the regular fx queue.

$("#foo").queue(function(next) {
    alert("I was queued!");
    next();
});

When this code is run on a page with a #foo element, it immediately emits an alert saying “I was queued!”. This is because the fx queue will dequeue elements right after they’re added. We can verify that the fx queue is being used by queuing an animation before our alert.

$("#foo").fadeOut().queue(function(next) {
    alert("I was queued!");
    next();
});

When this code is run the #foo element fades out and then an alert is shown. Now let’s try it with a custom queue.

$("#foo").queue("custom", function(next) {
    alert("I was queued!");
    next();
});

Nothing happens. Why? Because unlike the default fx queue, custom queues are not dequeued immediately. They require an explicit dequeue call to get them started.

$("#foo").queue("custom", function(next) {
    alert("I was queued!");
    next();
})
.dequeue("custom");

What’s the point?

At this point you may be wondering, what’s the point? Why would I ever need to use queues? The answer is: to implement animation time-lines. Imagine you’re making a game and you want to have an object float up wards for 2000 milliseconds. Furthermore, you would like said object to stay completely opaque for 1000 milliseconds before slowly becoming completely transparent over the remaining 1000 milliseconds. This time-line is shown below in tabular form (assuming that the object starts at top: 100px).

At first glance, it appears that the animate command could take care of this:

$("#object").animate({opacity: 0, top: "-=40"}, {duration: 2000});

Unfortunately, this code will fade the object out over 2000 ms, instead of waiting 1000 ms then fading out over the remaining 1000 ms. delay can’t help either, because it would delay the upward floating as well. At this point we can either fiddle with timeouts or, you guessed it, use queues.

1
2
3
4
5
6
7
8
9

$("#object")
.delay(1000, "fader")
.queue("fader", function(next) {
    $(this).animate({opacity: 0}, 
        {duration: 1000, queue: false});
    next();
})
.dequeue("fader")
.animate({top: "-=40"}, {duration: 2000})

In this example, we have two queues: the fx queue and the fader queue. First off, we setup the fader queue. Since we want to wait 1000 ms before fading, we use the delay command with 1000 ms (line 2). Next, we queue up an animation that fades the object out over 1000 ms (line 3-7). Pay close attention to the queue: false option (line 5) we set in the animate command. This is critical, as it ensures that the animate doesn’t use the fx queue. Finally, we unleash the queue using dequeue and immediately follow it with a regular fx-using animate call to move the top of the object up 40 pixels (line 9).

Conclusion

jQuery makes use of implicit animation queues behind the scenes whenever you run an animation. By taking advantage of jQuery queue commands, custom animation queues can be constructed that enable certain complex animation stuctures, like time-lines, that would be otherwise impossible without using intervals or timeouts.

Recently, in an effort to better understand how the Biomorph program worked, I decided to implement it myself in JavaScript using the HTML5 canvas element. The result of this endeavour can be found here. Read more to learn how to use the Biomorph program.

How do I work it?

The user interface contains 9 biomorphs arranged in a 3×3 grid. This is a biomorph generation. The centre the grid (with the blue border) contains the parent biomorph. The parent is the biomorph that the remaining 8 children biomorphs are based on. The children biomorphs are created by slightly mutating each of the eight genes in a biomorph.

In order to evolve a biomorph towards a certain goal, look at the 8 child biomorphs and select the one that is closest to looking like the biomorph you are aiming for. For example, if you’re trying to make a bat biomorph, pick the biomorph that looks most like a bat. Once you have a chosen a biomorph, click it to generate a new generation of biomorphs based on it.

If you choose the parent biomorph, you will simple be regenerating the child generation. However, since each gene can move in two directions, you have 16 possible children for each parent. Thus, if you are unhappy with your choice of children, you can try clicking the parent biomorph again to get one of the 8 other child biomorphs you haven’t seen.