It’s a cop-out, I realize, but I’ve been terribly busy lately. This previous week was my fiance’s last in town before heading back to Macomb (home of Western Illinois University, a three-hour drive, and a soul-sucking morass of small-town irrelevance); in addition, I’ve been in the throes of house-hunting, in an effort to capitalize on the currently-depressed real estate market. Sadly, it seems, my buying a house will not come to pass until late summer, when my lease expires: my landlord, despite having no such verbiage in the lease I signed, decided that early termination of a lease would run me $2,500.

On the educational front, I’ve started two more grad school classes; both need books this time. I’ve managed to cut the cost of one of them from $200 to $100 by buying an electronic format. The other, I’m not sure about yet. The classes are a heaping of additional deadlines among the many I already deal with. Not that I’m complaining; two online classes is hardly a strenuous life, but I currently like the capacity for very much patience.

My immediate boss at work (not just manager, but technical expert, as well), recently became a father, and has been out for a week and a half. It’s amazing how many support issues trickle down when he’s not there to catch them: mostly it’s simple user mistakes, but sometimes its seriously issues with recent upgrades that require more time than I’d like. In my spare(!) time, I’ve been alternating between managing our new hire (who, in turn, is managing the new student worker), and doing some initial codebase cleanup for a new SVN branch I’m going to make which will eventually become our new redesigned and unified portal.

jQuery, the javascript library on which we’ve standardized, released v1.3 last week. I hadn’t intended upon switching so early (to avoid any bugs), but the new release of jQuery UI 1.6, which requires jQuery 1.3, may force that issue. Then, too, I’ve noticed a lot of performance issues and IE6 bugs with the release candidates of 1.6, and so we may not do much with them after all.

Some of the work I’ve been doing is trying to find a decent modal window solution for our portal. We use them in several places; generally, it’s pseudo-replacements for confirm() and alert(), but sometimes they serve as genuine subpages for additional data input. Our currently codebase, which has been developing since June 2007, contains a mix of jqModal and BlockUI. I looked into the new jQuery UI Dialog component, but it was too bulky, buggy, and didn’t quite have the robust API I was looking for. Perhaps in a version or two…

jqModal is quick (performance-wise), but its implementation bothers me. The plugin I’ve come to enjoy as of late is boxy, which apes the look and feel of Facebox (which in turn apes the look and feel of Facebook’s modal script), but which comes with a much better API, I think. It’s got built-in methods for alert() and confirm(), as well as a few others, and is relatively fast. My only worry is that the API still isn’t stable (current git branches break existing invocations) and that it has no good way to set position or dimensions.

My goal, however, is to do some cleanup on the existing codebase, abstracting wherever possible, while designing the logic for the application redesign. I would prefer not to do a general redesign and then have to spend weeks upon weeks fixing cruft and broken hacks wherever they exist in our codebase (which, as of mid-January, stands at about 110,449 LOC).

This is all a long and circumlocutory way of saying that I hope posting will pick up soon and I can gain some ground not only on my book meme, but on posting in general.

After the initial learning curve, this has all been going swimmingly. I merged my first development branch into the trunk yesterday, and this branch just so happens to dovetail nicely into the whole point of this post, which is the YUI compressor, an open-source javascript and CSS minification tool developed by Yahoo’s YUI team.

The Problem

To understand quickly why one should minify production client-side code, consider only that with the upward trend of size in javascript libraries (and the necessary files for such libraries), it’s possibly to be downloading a lot of client-side code in a typical web application, especially as its scope grows.

For a long time, I was using Dean Edward’s Packer, as was everyone, because its Base62 encoding produced the very lowest file size. However, what should have been obvious to everyone is that eval(bunch_of_stuff_goes_here) is making the browser do a lot more work, and this is a problem on dinosaurs like IE6.

To make matters worse, the nature of such encoding also meant that for servers which tried to compress outgoing content like javascript (either with zlib or gzip), the compression ratio suffered. Just look at this table that Julien Lecomte posted last August.

I said to myself, “Hey, we use a lot of this stuff, and we still support a lot of users with slow computers and slow browsers.” So, I moved our project from a Packer-based compression to a YUI-based compression, and turned on server-side GZIP compression for javascript files. The only problem was that I was storing the javascript files already minified, and simply pasted them into a large a couple of large global .js files. I had to keep a separate source directory, along with any customizations.

This got to be a pain in the ass, as you might well expect, and so when it occurred to me that I might be able to use the YUI library at build-time in our Netbeans project, I immediately sprung into action.

This was around April, and one night while attending Sungard Summit in Anaheim. I did the initial work to get our Netbeans project into a state that could use the YUI compressor at build-time, creating separate source file directories and breaking our massive javascript file into modules; I did the same with our CSS, splitting it up based on what it decorated.

There are a few tutorials about using the YUI library. Some of them involve adding the YUI library to Ant’s classpath (didn’t want to go down this route); a lot of them involve invoking the library as an external executable during the build process, which is messy.

The solution I finally settled on was yui-compressor-ant-task, a small library that allows Ant to use YUI as a build task. By adding this library and the YUI compressor library to our common libraries folder, and enabling them at build only (and not for deploying in the web archive), it makes using the compressor pretty easy.

Here’s part of our build.xml:

<!--
   * minify will concatenate all of our non-TinyMCE javascripts and stylesheets
   * then use the YUI compressor library to compress them
   -->
   <target name="minify">
       <!--${libs} is path to the downloaded jars -->
       <property
           name="yui-compressor.jar"
           location="${file.reference.yuicompressor.jar}" />
       <property
           name="yui-compressor-ant-task.jar"
           location="${file.reference.yui-compressor-ant-task.jar}" />
 
       <path id="task.classpath">
           <pathelement location="${yui-compressor.jar}" />
           <pathelement location="${yui-compressor-ant-task.jar}" />
       </path>
 
       <!-- yui-compressor task definition -->
       <taskdef
           name="yui-compressor"
           classname="net.noha.tools.ant.yuicompressor.tasks.YuiCompressorTask">
 
           <classpath refid="task.classpath" />
       </taskdef>
 
       <!-- concatenation of javascript -->
       <echo message="Building global javascript" />
       <concat destfile="${build.dir}/web/common/js/global.js" force="no">
           <!-- explicitly order js concat because ordering matters here -->
           <fileset dir="${build.dir}" includes="web/common/js/jquery.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.bgiframe.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.hoverIntent.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.core.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.autocomplete.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.datepicker.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.tabs.js" />
           <fileset dir="${build.dir}" includes="web/common/js/tablesort.js" />
           <fileset dir="${build.dir}" includes="web/common/js/customsort.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.blockUI.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.form.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.ifixpng.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.superfish.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.cluetip.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.scrollTo.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.jqModal.js" />
           <fileset dir="${build.dir}" includes="web/common/js/validation.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.timeentry.js" />
       </concat>
 
       <!-- concatenation of cascading stylesheets -->
       <echo message="Building global cascading stylesheets" />
       <concat destfile="${build.dir}/web/common/css/global.css" force="no">
           <fileset dir="${build.dir}" includes="web/common/css/base.css" />
           <fileset dir="${build.dir}" includes="web/common/css/superfish.css" />
           <fileset dir="${build.dir}" includes="web/common/css/announcements.css" />
           <fileset dir="${build.dir}" includes="web/common/css/myvt.css" />
           <fileset dir="${build.dir}" includes="web/common/css/forms.css" />
           <fileset dir="${build.dir}" includes="web/common/css/cluetip.css" />   
           <fileset dir="${build.dir}" includes="web/common/css/tables.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.tabs.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.datepicker.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.autocomplete.css" />
           <fileset dir="${build.dir}" includes="web/common/css/linkspan.css" />
           <fileset dir="${build.dir}" includes="web/common/css/stepMenu.css" />
           <fileset dir="${build.dir}" includes="web/common/css/print.css" />
           <fileset dir="${build.dir}" includes="web/common/css/youHaveMessages.css" />
       </concat>
 
       <!-- invoke compressor -->
       <yui-compressor warn="false" charset="UTF-8" fromdir="${build.dir}" todir="${build.dir}">
           <include name="web/common/js/global.js" />
           <include name="web/common/css/global.css" />
       </yui-compressor>
 
   </target>
 
   <!--
   * purge-src takes our compressed files, moves them to the base /common dir
   * and deletes the source js and css dirs from the build dir
   -->
   <target name="purge-src" depends="minify">
       <echo message="Purging javascript and stylesheet sources" />
 
       <move file="${build.dir}/web/common/js/global-min.js" tofile="${build.dir}/web/common/global.js"/>
       <move file="${build.dir}/web/common/css/global-min.css" tofile="${build.dir}/web/common/global.css"/>
 
       <delete dir="${build.dir}/web/common/js" />
       <delete dir="${build.dir}/web/common/css" />
 
   </target>

What you see there is essentially four steps.

1. Concatenate all the constituent source files into a global.js and a global.css
2. Compress both of these files, which creates global-min.js and global-min.css (default behavior)
3. Move these files out of the source directories and into the root of the common web directory as global.js and global.css
4. Delete the source directories in our build folder so they don’t get deployed with the web archive

Because certain browsers (IE) break without explicit ordering, we unfortunately can’t just use “*.js” and “*.css” in our concatenation step, but having to explicitly list our components in the build file certainly isn’t the end of the world. The nice thing is that the Ant task will even print out handy statistics on just how much you’ve been able to compress the files down. In our case, we have about 441.8KB of common Javascript and CSS in our source code that, by the time it gets sent to the user, has been minified and/or gzipped to about 89KB.

The Problem

Admissions needed help. They had been moved from their former product, Exeter, to Banner’s native admissions module. But Banner’s interface stinks, and there was no decent way for counselors to do, well, anything. They relied on daily reports run out of an Excel pivot table by the executive directory of admissions, and therefore they lived on paper. The counselors needed a better way to get their work done and stay on top (figuratively speaking) of their recruits.

Enter my department. It fell to us, after some discussion, to build a tool that would be initial for undergraduate counselors, to let them slice and dice their data as needed. After a pilot run, it will gradually be expanded to include graduate and transfer admissions, as well as reporting tools for directors and and other muckity-mucks.

The current iteration is 4808 lines of code, for both the views and the comment submissions servlet. Most of it was written by me, though some was reused code, and the initial servlet skeleton was written by my boss.

Setting Parameters

The first thing an admissions counselor sees is a parameter page. There are a number of options to choose from:

• Term (can be multiple)
• Population selection (e.g. active applicants, active but non-applied recruits, enrolled applicants, etc)
• Student level (can be multiple)
• Recruiter (signed-in counselors will be auto-selected (can be multiple)
• High School (can be multiple)

Selecting from term or student level repopulates the possible recruiter list with only applicable options. Selecting “Undergraduate” applicants will necessarily filter out (or should filter out) graduate admissions counselors so they’re no longer an option.

Perhaps the toughest engineering challenge here was high schools. We currently have ≈10’000 high schools in our database, and will likely have a lot more soon. Loading all those into a multiple select box would make the page huge, and likely overload some underpowered browsers. My solution? Autocomplete. Using a simple JSP fragment and the Autocomplete plugin for jQuery, I was able to make a simple autosearch/complete behavior; selecting an item drops it into a list below the input box.

The odd thing about the plugin was that it didn’t end up being very flexible about the format of returned data. I had figured it would ask you to specify a data type and do your own parsing. It seems, though, that it only wanted one format: pipe-delimited data, with newlines between records. After wrestling with it for a while, I finally got it to work, but I really would have rather just returned XML and done some simple parsing.

The Table View

Once the parameters are chosen, the user gets a very complex table (the specifications were given to us by the Admissions department).

• Name
• Term (if >1 chosen)
• High School (if >1 chosen or none specified)
• Intended major (code display; full description on hover)
• Application decision (e.g. accepted, denied, etc) (code display; full description on hover)
• Student type (e.g. new freshman, transfer, etc)
• Athlete indicator
• Registered indicator
• Application status
  • Green: complete, no pending items
  • Yellow: complete, but pending items which don’t affect admission
  • Red: incomplete: pending items affect admission
  • None (has no application; is only a recruit)
• Financial Aid
  • Green: all items complete, and aid is packaged
  • Yellow: all items complete, but aid is not yet packaged
  • Red: outstanding items; aid cannot be packaged
  • None (has no financial aid)
• Date of application
• Composite admissions score
• Date of last comment (usually a contact with applicant)
• Visited campus indicator (is not currently used)

The recruiter can export this table as an Excel document for easy printing and carrying; otherwise, clicking on a recruit/applicant’s name will bring up a detail screen, which is divided into several sections.

The Detail View

Basic

I call it basic, but this is really the most detailed tab of this entire view.

• Application-related Items
  • Entry Term
  • Source
  • Major
  • Admissions Counselor
  • Application Status
• Biographical Items
  • Banner ID
  • PIN (for helping with portal access)
  • Last Portal login
  • Student Type
  • Advisor (email link)
  • Residence (dorm icon for on-campus, car icon for commuter)
  • College (Education, Arts & Science, etc)
  • Date of Birth
  • Phone Number(s) (shows primary; expands to show others)
  • Email Address(es) (shows primary; expands to show others)
  • Address
• Holds (is only shown when there are holds on the student’s account)
  • Hold Type
  • List of items which this hold prevents
• Education
  • High School (for undergrad and transfer)
    • Name of high school
    • Graduation Date
    • GPA
    • Class rank
    • ACT composite score
  • College (for graduate and transfer)
    • Name of college
    • Dates of attendance
    • GPA transferred
• Athletics (list of sports/activities)

Checklist

The checklist is a simple table displaying pending and completed items necessary for admission. The applicant sees the exact same table when they sign into the portal, so now the counselor can see what the applicant sees.

Mailings/Contacts/Comment

This is a tripartite screen. The first and most important section is “Comments,” which is a sort of chronicle of counselors contacts with the applicant or the applicant’s parents. This screen is especially nasty using the native Banner interface, and so the object was not only to make the viewing nice, but also allow for the deletion, editing, and creation of comments.

Contacts and mailings are merely for records of correspondence the applicant or recruit has received, aggregated from several places.

Financial Aid

This screen gives detail of all awarded financial aid, as well as both completed and outstanding documents. This, too, is almost exactly what the applicant will see when signed into his or her portal.

Bill

This screen, which details charges and payments for the student, is once again a replica of screens available to the applicant when logged in. These screens are mostly to provide parity for support with applicants who have questions about financial aid, bills, or schedules.

Schedule

Once an applicant is accepted, and registers for class, this schedule tab will be filled out. It is a slight modification of the student’s schedule, which is displayed to them upon portal sign-in. Advisor see a similar view, since this is a module we reuse in several different portions of the web app.

The Big Finish

There are always bugs. I realize, just before going live, that the abbr tag that I used so heavily in the tabular view isn’t natively supported by Internet Explorer 6.

Luckily, good old Dean Edwards notes that for some reason, prefixing the namespace to the <abbr> tag makes the damn thing suddenly work, and it’s still valid XHTML! Crisis averted.

As with most of our web application, we make heavy use of jQuery. Specifically for this application, we make use of the UI Tabs plugin, the UI Autocomplete plugin, and jQuery’s native AJAX functionality. We also use the Unobtrusive Tablesort Script from Frequency Decoder, which has much better performance than jQuery equivalents.

As I said, this is only a first try at a first stage, but we’re pretty happy with the progress, and the admissions folks seem to be as well, so we’re doing something right.

It’s not a particularly disastrous bug or anything, but I’ve altered the code to check string lengths instead of looking checking for null.

Get it here.

A (possibly boring) section about institutional technology

As an application developer, I’m generally interested in building frontends to things; by contrast, a lot of sessions at Summit consisted of processes and user-focused talks. I stayed mostly inside the “Technical” track, which did include some cool things. Bridgewater College had done some alterations to make secondary PINs (used for student self-registration) transparent to students; faculty could turn such self-registration on or off with a single click in a web panel. Also, the presenter had an absolutely wonderful Boston accent, pronouncing “vanilla” as “vaniller,” which thrilled me to no end.

As an institution that has built a lot of custom web applications outside the purview of Banner’s web engine (Self Service / WebTailor), we’re always looking for good ideas from other institutions that have done the same. Unfortunately, those institutions are few and far between. I did go to one session about forecasting class demand in which the school had built a reporting system in PHP, and they used jQuery. I’m always surprised there’s so little custom application writing; it’s not as though using the WebTailor piece to make Self Serve screens is particular nice or elegant. I find it much easier, once you have a simple data access framework, to do it yourself. That’s why my university’s been able to get so many reports, services, and other screens into our portal.

Peripheral anecdotes not having to do with technology per se

Victuals

But the conference only lasted from 8-5 every day, leaving the surplus time free to cavort with my colleagues around Anaheim. I say “cavort,” but what I really mean it “walk slowly, and stop often for cocktails.” I’ve said before that the immediate surrounding area was almost nothing but hotels and Disneyland, meaning that just about everything in Anaheim, including restaurants, was out of our range. There were a few restaurants in the vicinity, however. On Saturday, we ate at the Overland Stage, a somewhat pretentious place whose subtitle included “BBQ Company.” Our waitress was hesitant to bring us additional chips and salsa when asked, claiming that it would ruin our dinner; as it happens, she forgot to put my order in anyway, which was probably for the best, since when it finally did come, it had as much flavor as chewing on a sock.

On Sunday, we ate at the Cheesecake Factory (our attempt to dine somewhere local was aborted when it was discovered that the real distance was much farther than the map indicated), which was a veritable comedy of errors. When our promised patio table, at “15 to 30 minutes” took about 45, apparently because they forgot about us, we should have known it was a harbinger of things to come. To date, we don’t really know what caused it all, but our drinks took about 30 minutes, apparently because they were made and set off to the side and promptly ignored (they were eventually comped). Our food came in fits and starts, with a turkey club sandwich never coming at all. Our waitress, who, it must said, was very nice, kept apologizing and saying that this sort of thing never happened at the Cheesecake Factory, though it’s been my experience that any location besides the rather ugly one in downtown Chicago tends to be subpar.

On Monday, the company hosting the conference sponsored a trip to Knott’s Berry Farm, which interests me about as much as colorectal surgery; I gave my ticket to someone from my group who didn’t have one, and stayed in my hotel room, savoring a bit of isolation and the chance to do some work on my laptop and read my book. I’m told I missed a good time, but mostly people just looked exhausted and sore the next day from the g-force and copious amounts of beer. I have no regrets.

Tuesday night, a subset of my group walked the half-mile or so to Buca de Beppo’s, one of a chain of family-style Italian restaurants, and stuffed ourselves to the gills with pasta, waddling back to the hotel surprisingly early. We stopped at the lobby bar of the Sheraton and had cocktails—I thoroughly enjoyed my Manhattan—while everyone sank into the lounge chairs and imagined, wearily, that they could magically be home again, or at least in bed. Personally, I was doing OK, having relaxed considerably more the previous night, but the bourbon and cream sherry accelerated me to sleep.

Motivation

Summits always have at least two big speakers bookending the conference. This year, the opening address was given by Erik Weihenmayer, a blind man who has achieved the summit of the highest peak on each of the seven continents. Yes, that’s as delightfully absurd as it sounds. I’m also happy to report that he was actually a very good speaker as well, with a dry, self-deprecating kind of wit. The man’s very presence is humbling, since he more or less automatically puts all of your achievements to shame.

The second speaker, more lightly attended since it was 8:00am on the last day of the conference, was Carl Hammerschlag. I was less impressed with him, since, although he made very valid points, tended dangerously close to hokey in his “Mind Body Spirit” mantra, which he tries to validate immediately by telling the story of an Indian medicine man he once treated. Sorry, but I just don’t feel all warm and fuzzy at such Chicken Soup for the Soul kind of pabulum.

But that is neither here nor there.

Introspection

Melancholy fills my head with short stories. On a plane, deep in my own thoughts, I watch the clouds grow a deep red below, and finally thin out to reveal the expansive grid of Chicago lit beneath us, a bustling Lite Brite, pulsing with late traffic. To me, there’s nothing quite like staring out the window of a plane at the land below; nothing so utterly ravishes one’s sense of proportion as realizing one green speck is a baseballs stadium; a hairsbreadth of grey is some major highway crossing the California desert; that the endless expanse of Pacific blue is some small fraction of a whole. At 31’000 feet, there’s a persistent grey strip, seemingly thin as a pencil, that separates the sky’s blue from the seedy grey-white of the clouds below.

I watched an invisible sun slowly cede, blurring the boundaries of the horizon, as I thought about my travels; my desire for home, for sleep, for better coffee. Eventually all the distinctions I draw, however carefully, are smeared and vanished in low light. In the seemingly interminable distance between genesis and exodus, radix and terminus, participant and celebrant, attendee and refugee, I belong to neither part of either world, carrying my own time and space with me. These things ask such capacity of me, an accidental tourist, that I groan to accommodate, and yet the transition happens unbidden, somehow, quietly in a wedge of rarefied time like alarm clocks and takeoffs and the enormous, strange silence of a dark hotel room; in a pocket of space at an equally interminable distance between my hands and my heart.

The world of Javascript is an interesting one right now; it seems like most major browsers are on the eve of a major new release, many with new (& improved JS engines). With WebKit’s porting to Windows in Safari (and eventually Konqueror, I imagine), yet another player has thrown his hat into the arena. Javascript is, as Jeff rightly says, the lingua franca of the web: everything is javascript-[based|dependent] today, and rich interfaces are now the norm, rather than a pleasant surprise.

As a web applications developer, I’ve banged by head against javascript and various and sundry browser implementations at work, and worried about performances, both now and in the future. Standardizing on a common library (cf. jQuery) helps, although the performance or functionality of jQuery plugins don’t always match those of home-grown counterparts. For instance, Brian McAllister’s Unobtrusive Table Sort Script far outpaces the popular TableSorter script for jQuery. I ended up implementing the latter at work, simply because of the sheer size of tables we render, and the relative slow speed of many of ours users’ browsers.

Due to time constraints, I hadn’t gotten around to performing my own benchmark until today. I don’t have any fancy (or controversial) graphs like Jeff, but here’s the data anyway, followed by the raw result text. The first table is high-level summaries listing only the sum times for groups of test. The second table lists all the tests.

Somewhat to my surprise, the much-touted improvements to Firefox 3′s javascript engine weren’t consistent across the board. In some cases, it performed worse than 2.0.0.11. The clear winner was Opera’s upcoming 9.5 release (codenamed ‘Kestrel’), followed closely by Apple’s port of the WebKit engine. With respect to the latter, it’s clear that the WebKit/KHTML engine is a good one, though I look forward to an inevitable Konqueror port, since Safari on Windows is just about the ugliest interface I’ve ever seen.

The Results

SunSpider 0.9 Benchmarks
Performed on 15 January 2007
Ben Gunnink | http://heliologue.com/

- Intel Q6600 Quad-Core
- Windows XP SP2 32-bit
- 4GB RAM

All browsers were tested with extensions and plugins disabled.

Firefox 2.0.0.11

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 14032.0ms +/- 2.4%
--------------------------------------------

  3d:                   1909.0ms +/- 4.1%
    cube:                531.4ms +/- 7.6%
    morph:              1078.0ms +/- 3.6%
    raytrace:            299.6ms +/- 10.8%

  access:               1275.0ms +/- 2.3%
    binary-trees:        140.6ms +/- 9.7%
    fannkuch:            422.0ms +/- 0.0%
    nbody:               484.6ms +/- 2.8%
    nsieve:              227.8ms +/- 4.6%

  bitops:               3340.6ms +/- 0.9%
    3bit-bits-in-byte:   253.2ms +/- 3.5%
    bits-in-byte:        256.4ms +/- 4.2%
    bitwise-and:        2459.4ms +/- 0.7%
    nsieve-bits:         371.6ms +/- 4.4%

  controlflow:            94.0ms +/- 0.0%
    recursive:            94.0ms +/- 0.0%

  crypto:                694.4ms +/- 5.2%
    aes:                 215.6ms +/- 7.7%
    md5:                 244.2ms +/- 7.0%
    sha1:                234.6ms +/- 6.0%

  date:                 2049.8ms +/- 0.4%
    format-tofte:        693.8ms +/- 3.1%
    format-xparb:       1356.0ms +/- 1.2%

  math:                 1281.8ms +/- 10.7%
    cordic:              665.8ms +/- 17.3%
    partial-sums:        375.2ms +/- 3.6%
    spectral-norm:       240.8ms +/- 9.2%

  regexp:                784.2ms +/- 5.4%
    dna:                 784.2ms +/- 5.4%

  string:               2603.2ms +/- 7.1%
    base64:              565.8ms +/- 3.8%
    fasta:               415.6ms +/- 4.3%
    tagcloud:            512.4ms +/- 34.7%
    unpack-code:         718.8ms +/- 7.9%
    validate-input:      390.6ms +/- 8.7%

Firefox 3.0.0 beta 2

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 11195.2ms +/- 5.9%
--------------------------------------------

  3d:                   1821.2ms +/- 5.4%
    cube:                543.6ms +/- 12.5%
    morph:               921.8ms +/- 2.2%
    raytrace:            355.8ms +/- 11.9%

  access:               1632.4ms +/- 8.6%
    binary-trees:        160.6ms +/- 34.5%
    fannkuch:            629.2ms +/- 8.5%
    nbody:               568.4ms +/- 6.2%
    nsieve:              274.2ms +/- 13.1%

  bitops:               1759.0ms +/- 6.6%
    3bit-bits-in-byte:   280.8ms +/- 12.8%
    bits-in-byte:        286.0ms +/- 8.8%
    bitwise-and:         808.0ms +/- 5.1%
    nsieve-bits:         384.2ms +/- 9.8%

  controlflow:            93.4ms +/- 27.3%
    recursive:            93.4ms +/- 27.3%

  crypto:                615.6ms +/- 3.2%
    aes:                 276.0ms +/- 6.3%
    md5:                 166.6ms +/- 6.2%
    sha1:                173.0ms +/- 5.5%

  date:                  628.2ms +/- 4.4%
    format-tofte:        409.4ms +/- 3.7%
    format-xparb:        218.8ms +/- 8.1%

  math:                 1121.8ms +/- 3.8%
    cordic:              527.6ms +/- 3.8%
    partial-sums:        383.8ms +/- 4.0%
    spectral-norm:       210.4ms +/- 6.4%

  regexp:                947.0ms +/- 57.3%
    dna:                 947.0ms +/- 57.3%

  string:               2576.6ms +/- 14.3%
    base64:              466.4ms +/- 5.7%
    fasta:               443.2ms +/- 10.0%
    tagcloud:            396.8ms +/- 10.0%
    unpack-code:         942.0ms +/- 35.9%
    validate-input:      328.2ms +/- 8.9%

Internet Explorer 7.0.5730.13

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  26676.8ms +/- 0.8%
--------------------------------------------

  3d:                    1212.8ms +/- 2.4%
    cube:                 334.6ms +/- 5.3%
    morph:                412.4ms +/- 2.6%
    raytrace:             465.8ms +/- 1.8%

  access:                1731.6ms +/- 1.0%
    binary-trees:         409.4ms +/- 2.1%
    fannkuch:             687.6ms +/- 0.1%
    nbody:                343.8ms +/- 0.2%
    nsieve:               290.8ms +/- 3.6%

  bitops:                1552.8ms +/- 1.7%
    3bit-bits-in-byte:    368.8ms +/- 2.9%
    bits-in-byte:         387.2ms +/- 2.2%
    bitwise-and:          450.2ms +/- 1.9%
    nsieve-bits:          346.6ms +/- 2.7%

  controlflow:            447.0ms +/- 2.4%
    recursive:            447.0ms +/- 2.4%

  crypto:                 934.4ms +/- 0.9%
    aes:                  343.6ms +/- 0.2%
    md5:                  297.0ms +/- 0.0%
    sha1:                 293.8ms +/- 3.0%

  date:                   796.6ms +/- 2.9%
    format-tofte:         390.4ms +/- 3.5%
    format-xparb:         406.2ms +/- 3.4%

  math:                  1075.6ms +/- 0.9%
    cordic:               453.6ms +/- 0.2%
    partial-sums:         281.2ms +/- 0.2%
    spectral-norm:        340.8ms +/- 2.6%

  regexp:                 350.0ms +/- 5.0%
    dna:                  350.0ms +/- 5.0%

  string:               18576.0ms +/- 0.9%
    base64:              9212.6ms +/- 0.4%
    fasta:                438.0ms +/- 0.0%
    tagcloud:            1740.6ms +/- 5.7%
    unpack-code:          453.2ms +/- 0.1%
    validate-input:      6731.6ms +/- 1.2%

Safari 3.04 beta

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  8583.4ms +/- 1.7%
--------------------------------------------

  3d:                   1184.4ms +/- 4.6%
    cube:                353.0ms +/- 3.1%
    morph:               490.6ms +/- 5.2%
    raytrace:            340.8ms +/- 6.4%

  access:               1668.2ms +/- 2.5%
    binary-trees:        143.4ms +/- 6.1%
    fannkuch:            703.2ms +/- 0.1%
    nbody:               331.2ms +/- 2.5%
    nsieve:              490.4ms +/- 7.7%

  bitops:               1465.0ms +/- 2.0%
    3bit-bits-in-byte:   302.8ms +/- 5.8%
    bits-in-byte:        387.2ms +/- 2.2%
    bitwise-and:         303.0ms +/- 3.6%
    nsieve-bits:         472.0ms +/- 1.9%

  controlflow:           212.4ms +/- 5.0%
    recursive:           212.4ms +/- 5.0%

  crypto:                815.8ms +/- 3.1%
    aes:                 218.6ms +/- 10.9%
    md5:                 297.0ms +/- 0.0%
    sha1:                300.2ms +/- 3.0%

  date:                  621.8ms +/- 3.5%
    format-tofte:        259.4ms +/- 4.1%
    format-xparb:        362.4ms +/- 4.6%

  math:                 1012.4ms +/- 1.6%
    cordic:              559.4ms +/- 1.5%
    partial-sums:        228.0ms +/- 5.0%
    spectral-norm:       225.0ms +/- 5.0%

  regexp:                337.6ms +/- 3.2%
    dna:                 337.6ms +/- 3.2%

  string:               1265.8ms +/- 2.2%
    base64:              300.0ms +/- 2.8%
    fasta:               297.0ms +/- 4.7%
    tagcloud:            237.6ms +/- 6.8%
    unpack-code:         193.8ms +/- 5.4%
    validate-input:      237.4ms +/- 3.7%

Opera 9.5 beta 1 (build 9613)

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  6501.0ms +/- 1.2%
--------------------------------------------

  3d:                    572.0ms +/- 2.9%
    cube:                162.8ms +/- 6.4%
    morph:               231.2ms +/- 3.7%
    raytrace:            178.0ms +/- 5.7%

  access:                775.4ms +/- 2.8%
    binary-trees:         50.0ms +/- 16.7%
    fannkuch:            365.8ms +/- 2.9%
    nbody:               197.0ms +/- 5.5%
    nsieve:              162.6ms +/- 6.6%

  bitops:                803.2ms +/- 5.6%
    3bit-bits-in-byte:    65.6ms +/- 13.2%
    bits-in-byte:         97.0ms +/- 8.6%
    bitwise-and:         425.0ms +/- 6.0%
    nsieve-bits:         215.6ms +/- 4.1%

  controlflow:            65.6ms +/- 14.2%
    recursive:            65.6ms +/- 14.2%

  crypto:                319.0ms +/- 7.0%
    aes:                 153.0ms +/- 5.9%
    md5:                  81.4ms +/- 10.8%
    sha1:                 84.6ms +/- 12.6%

  date:                  734.2ms +/- 1.9%
    format-tofte:        272.0ms +/- 4.0%
    format-xparb:        462.2ms +/- 3.7%

  math:                  456.0ms +/- 3.4%
    cordic:              197.0ms +/- 5.5%
    partial-sums:        171.8ms +/- 0.3%
    spectral-norm:        87.2ms +/- 12.0%

  regexp:                747.0ms +/- 2.2%
    dna:                 747.0ms +/- 2.2%

  string:               2028.6ms +/- 2.9%
    base64:              140.8ms +/- 10.0%
    fasta:               390.6ms +/- 6.1%
    tagcloud:            365.8ms +/- 8.0%
    unpack-code:         965.6ms +/- 1.7%
    validate-input:      165.8ms +/- 6.4%

Yet, I find myself at home, with a White Russian and the urge to opine.

The Background

In the summer of 2006, my workplace (The University of St. Francis, my alma mater) went live with a portal. For the previous year and half, when I was a student worker, we’d been working desperately to implement Oracle Portal. At a conference that summer, my boss, Tim, heard about uPortal, an open-source J2EE portal. On the ride back from Ohio, we more or less decided to try it on a lark. It’s basic ease of setup let us switch to uPortal and go live in 6 weeks. That’s right, a production-ready portal in 6 weeks.

Much of the work in that time was tying CAS into our LDAP implementation (Novell’s eDirectory), customizing the view (props to Virginia Tech for their excellent Tab-Column customization), and writing some basic portlets to allow quick views into student data: schedule, personal info, billing, &c. We’re a Banner school, so we could basically just reach into our Oracle database and pull the data we needed.

The Cool Bits

Since that time, we’ve poured a tremendous amount of energy into the portal, as it’s become our go-to spot for finding information and getting things done. Actually, we’ve spent very little time on uPortal at all, as it already contains much of the quick-view functionality we want. Much of what we do is a custom extension to the portal that transparently shares session data via CAS.

We have completed our portal rollout using uPortal (running on apache/tomcat), and are integrated with Sungard Banner 7.x for much of the information we pull and display, and we are using Novell E-Directory for our directory.

We used uPortal which proved to be a much more promising and easier to use platform than Oracle portal. Within 6 weeks we had our first production portal deployment. Over the last year we have built and put the following into production:

• Student Schedule and Grades Display (pulled realtime from Banner)
• WebCT Integration/SSO
• Announcements (Targeted coming by end of summer ’07)
• SSO to Novell WebMail, Netstorage, and Banner Self Serve
• Bookstore Integration with Barnes and Noble (Shopping cart of books)
• Financial Aid Portlet/Accept Loans – Display and update banner data
• Tuition Bill Portlet – Pulled in realtime from Banner AR
• Payment of Tuition Bill/Post Directly to Banner AR
• My Profile Portlet (information pulled realtime from Banner)
• GPA/Credit Hours Portlet (Pulled realtime from banner)
• Banner Security Question/Reset Password Functionality
• Expired Password Functionality
• Faculty Schedule/Class Rosters/Email Class, Export to Excel
• Banner Survey Integration
• HR Leave Balances
• Budget Reporting/Financial Activity/View Documents, checks cut, etc
• Banner Requisition Approval
• Web Based University Income/P&L Statement
• Banner Finance Journal Voucher Upload
• PIDM Usage Utility to help identify and resolve duplicate pidms
• EZProxy/Library Databases Integration
• Advancement Constituent Profiles
• Advancement Fundraising Activity Reports
• Advancement Constituent Contacts Data Entry/Reminders
• Financial Aid targeted messages
• GUAMESG
• Residence Life View your Room/Roomates
• Bulletin Boards (phpBB)
• VT Calendar
• Various Web based Reports
• E-Directory Integration/Account Creation
• Early alert and midterm warning submission, that allows the student, advisor, registrar, athletic coaches, and other support staff know when a student is having academic difficulties.
• An online advising center. Advisors can now see all of their advisees, look at who’s registered, view issues with the students account such as registration or medical holds, etc. The goal is so that advisors can also help the students get their issues resolved.
• Our initial stab at targeted announcements is done. We can now target based on the student type, level, or college as currently stored in the Banner ERP, as well as target to only employees or faculty members. The framework is in place to target off of any data element stored in Banner. Now we just need to expand our GUI allowing users to target messages.
• Accounts Receivable Reporting Suite – Our finance office now uses the portal to do various AR reporting tasks, drilling into student details, etc.
• Enrollment/Registration Status Reports – Various members of the university can now easily look at the overall student registration status through the portal.
• A faculty attendance tracking module for faculty to electronically submit the attendance of students in their classes at the beginning of term and at the mid-term point. This helps the registrar and financial aid determine who is actually attending, and replaces an old paper based process.
• On online Student Check-In procedure. Students can now confirm their class schedules, financial aid, and pay their bill through an easy to use “wizard” interface. The system will notify when they need to perform the electronic check in process before the start of the term, and then walks them through the process. This helps to collect payments sooner and determine which students are actually going to show up to class on day 1.
• Our portal now has a targeted messaging facility which looks at business rules and notifies the students of issues or action items related to their student records. For example, if a student has holds on their account the system will tell them, show them the hold, tell them what it prevents them from doing, and who to contact to resolve the hold. For students with incomplete medical records they are notified, and shown which parts of their medical records are incomplete (and for our nursing program, which shots, etc they need to have on file to be able to attend clinicals).
• A co-curricular transcript which pulls from Banner all the clubs, organizations, and sports a student has been a member of during their time at the university, and shows them in a nicely formatted page that they can print.
• A real-time registration status dashboard for administrators, deans, and faculty members. This dashboard now shows the head counts, course registration counts, credit hours, and billing hours generated for registered students, and the number of potential students who are left to register. It breaks the summary counts down in several ways: by college, major, advisor, or level (graduate, undergrad, etc). The users can drill into this report and extract lists of students who still need to get registered, whom to call to see if they need advising help or assistance registering, etc.

As the UI architect for the portal extension, I decided this past summer to standardise on jQuery, and certainly haven’t regretted it. The only bad thing about javascript is that it becomes easy to rely on it for things which should really be controlled server-side. Important validation checks, for instance. Since our ERP system has certain business logic which it enforces on the database level, we usually do two checks for important data: one (javascript) for the user’s sake, and one (servlet) for ours.

It got to the point where we were loading 10 different jQuery javascripts and 2 stylesheets in our header. Most of the javascripts were either packed or uncompressed (if packing broke them), and totaled about 200Kb. Not only was this too much, but the eval() caused a delay for each script. Recently, after one of our rollouts to production, when I got more leeway to play, I completely upgraded our script layout. I’m not going to provide an apples-to-apples comparison table here, since the prior configuration was a hodgepodge, but after minifying and turning on server-side compression for javascripts and stylesheets, I managed to reduce the load from 200Kb in 12 requests to about 50Kb in 5 requests. According to Julien Lecomte, running mod_deflate on a minified (but no obfuscated) javascript yields the lowest file size; regardless of how often that’s true, I like the idea of avoid latency from the eval(). A lot of our users are still on IE6, and they take some pretty big performance hits.

Goodness knows there’s more I could do, but given the nature of our portal (single-image CSS layouts, anyone?), it wouldn’t be a productive use of our time); I have enough crap to do with counting pixels.

jQuery rocks my socks

I might take a moment here to say just how much I love jQuery. For those of you who don’t know, jQuery is a javascript framework which abstracts a lot of functions into a much more easily-written manner. In the past, I’ve sort of been a Copy & Paste javascript programmer, since it’s been easier to use some free script than to write one’s own code. jQuery and it’s vast array (har!) of plugins makes it easy to implement or write new code. For instance, if we want to implement a support for CSS hover effects in IE, all we do is this:

$("input:text,input:password,textarea").focus(function() {
     $(this).addClass("focused");
});
 
$("input:text,input:password,textarea").blur(function() {
     $(this).removeClass("focused");
});

Easy as pie.

Granted, there are a lot of frameworks to choose from. Originally, there was only Prototype; now there’s also jQuery, Dojo, YUI, Mootools, Rico, and any one of a number of others.

The one I wanted to talk about in this post in particular is ExtJS, which was originally an extension of the YUI framework, but which eventually split off into its own project. It recently went 2.0, and boasts some rather impressive demos. I marvel at the Vista-like UI, which, admittedly, is very slick.

But the more I look at ExtJS, and half-heartedly consider its possible deployment within our portal, the less enthused I become. ExtJS’s grid, for instance, doesn’t even function on existing HTML table markup: you mass it an array of data as a javascript variable, and it creates markup on the fly… a lot of markup, in order to create it’s slick Office 2007 interface. While this is good insofar as it manages to completely abstract data from presentation, I’m not sure how much I like the idea, since it (1) relegates users to the script default without heavy customization, and (2) doesn’t allow for any kind of fallback mechanism if the javascript should fail or the user has it disabled. Our table-sorting function, in a case like that, doesn’t at all prevent the table markup and data itself from being rendered.

Work can be fun sometimes.

As I said in a previous comment, the problem with having content about a new theme is that it won’t be relevant when the theme goes away or changes. So this post is to both exhibit and archive this theme so that there is some record of it.

Hooloovoo

toggle thumbnails

It’s a different creature than I’m used to—I’ve never not had a sidebar, but I decided that perhaps a sidebar wasn’t the best way to do things. I moved that sort of ancillary data to the top, but I used a pull-down menu á la Foliage mod. Since sidebar data tends to not be particularly important to the content anyway, it doesn’t need to take up real estate.

Metadata, while displayed more or less inline on the index page, is moved down into a content footer on the individual post pages. This kind of graphical metaphor is actually very common now, but I’ve wanted to do it ever since I saw it in Hemingway about a year and a half ago. Like the upper menu, I’m dividing into thirds, and iterating with lists.

In general, I’ve tried to round off a lot of corners. This involves more images than I’d normally like, but I’ve tried to take shortcuts wherever possible, combining multiple images and simply changing their positioning: I managed to reduce the number of server requests significantly from the early phases of the design, but I still have some more to go.

Which brings me to another thing: I’ve used some 24-bit PNGs, not only as icons but as background images as well. I made a half-hearted attempt to use ifixpng to resolve display issues for IE6, but when it didn’t work satisfactorily, I decided that I spend enough timer catering to IE6 users and work, and I’ll be damned if I’m going to expend any extra effort on my hobby site. So let me make myself clear:

Attention IE6 users: there is no good excuse to be using IE6. Either upgrade or use a different browser. Firefox is good, as is Opera. Or go away.

On with the tour: I’ve heavily incorporated the jQuery javascript library into my redesign, and attempted to make it as performance-tuned as possible by including the extra plugins in a common file, and gzipping everything on the fly.

Beyond that, the theme is pretty unremarkable, really, but (I hope) aesthetically-pleasing and useful. I’ve completely removed categories from the template, since I think that tags have much more utility.

Comments? Questions? Suggestions? Venom?

Just for grins, I’ve worked that snippet of code up into a genuine jQuery plugin. Go ahead and visit the page for more information. Or, download it directly.

MIT license.

Blockquotes, by definition, can and should in most cases have a title attribute and, if possible, a cite attribute. The former is the actually name of the quote’s source. The latter is the URI to the quotes location, if it was retrieved online.

For instance:

<blockquote cite="http://heliologue.com" title="A Modest Construct">
 
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.
 
</blockquote>

This is all well and good for search engines, but it doesn’t do much for human readers (who are arguably more important, though it depends on who you ask). A human might want to see something like this:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.

A Modest Construct

Which I achieved by appending

<cite class="source">
     <a href="http://heliologue.com" title="A Modest Construct">A Modest Construct</a>
</cite>

to the blockquote.

But nobody wants to hard-code a citation into every blockquote, especially when it’s technically correct to attach the information to the semantic element in question (the blockquote, for those of you not following along). So, how to be structurally correct when using blockquotes, while still allowing human readers the benefit of such data?

Well, there are a number of methods. If you’re using a CMS or any kind of dynamically-generated page, you can use the system itself to parse blockquotes for their attributes and reuse that information.

The Old Way

A somewhat simpler and more flexible solution would be Javascript, which isn’t foolproof, but should be good enough for most people. Previously, I used Dunstan’s Blockquotes, which was an excellent solution for a long time.

function extractBlockquoteInfo()
        {
        quotes = document.getElementsByTagName('blockquote');
	for (i = 0; i < quotes.length; i++)
		{
		cite = quotes[i].getAttribute('cite');
		title = quotes[i].getAttribute('title');
		if ((cite) && (cite != ''))
			{
			if ( (cite.match('http://', 'i')) || (cite.match('ftp://', 'i')) || (cite.match('person://', 'i')) )
				{
				newlink = document.createElement('a');
				newlink.setAttribute('href', cite);
				newlink.setAttribute('title', ('Go to ' + cite));
				title = quotes[i].getAttribute('title');
				if ((title) && (title != ''))
					{
					newlink.appendChild(document.createTextNode(title));
					}
				else
					{
					newlink.appendChild(document.createTextNode('Quote source'));
					}
				newdiv = document.createElement('div');
				newdiv.className = 'source';
				newdiv.appendChild(document.createTextNode('\u2014 '));
				newdiv.appendChild(newlink);
				quotes[i].appendChild(newdiv);
				}
			else
				{
				newdiv = document.createElement('div');
				newdiv.className = 'source';
				newdiv.appendChild(document.createTextNode('\u2014 ' + cite));
				quotes[i].appendChild(newdiv);
				}
			}
 
		else if ((title) && (title != ''))
			{
			newdiv = document.createElement('div');
			newdiv.className = 'source';
			newdiv.appendChild(document.createTextNode('\u2014 ' + title));
			quotes[i].appendChild(newdiv);
			}
		}
	}
 
window.onload = function(e) {
extractBlockquoteInfo();
}

The New Way

I ran into conflict issues, however. Also, the script seems overly complicated for what it’s doing. I long ago chose my spot in the jQuery camp, and am currently using it on this blog for Thickbox and a few other miscellaneous things. So I thought: why not get blockquote data using jQuery? Here’s my resulting code (which I’m sure is flawed and crufty, but I put it together in about five minutes; suggestions are welcome).

$(document).ready(function(){
     $("blockquote").each(function(){
          var title = $(this).attr("title");
          var cite = $(this).attr("cite");
 
          if (cite == null && title != null) {
              $(this).append("<cite class='source'>"+title+"</cite>");
          }
 
          else if (cite != null && title == null) {
               $(this).append("<cite class='source'><a href='"+cite+"' title='"+cite+"'>"+cite+"</a></cite>");
          }
 
          else if (cite != null && title != null) {
               $(this).append("<cite class='source'><a href='"+cite+"' title='"+title+"'>"+title+"</a></cite>");
          }
 
          else {
          }
     });
});

Essentially, I’m looking for blockquotes that contains at least one of our particular attributes, and then parsing them for title and cite values. There are four possible outcomes:

1. title but no cite:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.

2. cite but no title:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.

3. cite and title:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.

4. no cite and no title:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.

I think that the <cite> element is the most semantically correct, but of course you’ll have to change that to fit your needs. I style it like this:

blockquote cite.source {
     text-align: right;
     border-top: 1px dashed #aaa;
     font-size: 0.95em;
     display: block;
     }

And there you go. An excellent Javascript library, a few lines of code (more than necessary even, as I wanted to cover all the possible cases), and you’ve got a flexible solution to blockquote citations.