Monday, September 01, 2014

Are You Up to Speed on Microdata?

Today's post is reblogged (with permission) from

Do you have a web site? Do you care about Google search ranking? Do you tag blog posts with keywords? Practice safe SEO?

Well, everything you know is about to change. But first a bit of backstory. Not long ago, Google announced the official end of its Authorship markup program. best known as the scheme that allowed people to appear with their G+ picture off to the left in a highly structured "rich snippet" search-result. Google talked about the death of the program here.

The even bigger news, though (already well known to hard-core SEO geeks but still making its way out to the hinterlands), is that Google will increasingly rely on semantic hints in HTML markup (hints that you need to be sure are there) when indexing web pages. The hints can be RDFa, or microformat-based, or microdata-based (using the schema). The latter is "recommended."

According to Google, failure to use any of these hinting schemes will not adversely affect page rank, nor will using them affect rank. But let's be honest here. It's pretty clear that your pages are unlikely as hell to show up in cosmetically pleasing rich-snippet format, on any Google page, if you've neglected to use microdata in your markup. It doesn't take a rocket surgeon to understand that eventually, if your site isn't using microdata (and everyone else's is), you're going to be at a disadvantage in certain situations. Extrapolate that however you wish.

What do you have to do to get microdata into your content? Basically stand on your goddam head and count backward to infinity. No rich text HTML editor I know of has built-in support for microdata (and yet, this support is clearly needed in all rich text editors, going forward). Who'll get there first? I have no idea. It's wide open. I expect the tooling situation will change, quickly. But in the meantime, you have only a couple of options for making your site's pages microdata-savvy (read: super-Google/Bing-friendly).

The first option is really a workaround, not a solution; and that's to head over to Google Webmaster Tools, where you can manually train Google to know where the key itemtypes and itemprops are (or should be) located on your site's pages. Once you've registered your site with GWT, flip open the Search Appearance item in the command tree on the left edge of the page, then start clicking around.

That's good enough as a right-this-minute workaround, but it obviously doesn't leave your site with different markup than it had before. And that's where Option No. 2 (the stand-on-your-head option) comes into play: Insert microdata yourself. By hand.

Mind you, this is not something a human being should have to do without proper tooling, and frankly, until tooling arrives I think you'd be crazy to invest a lot of time in marking up your stuff by hand. But to give you a quick visual idea of what kind of markup I'm talking about, here's what needs to happen to, say, a blog post. First, the entire post needs to be wrapped in an article tag with microdata inside it, like so:
<article itemscope itemtype="" id="post-410" class="post-410 post type-post status-publish format-standard hentry category-uncategorized tag-font tag-legibility tag-readability tag-reading-comprehension tag-serif tag-typeface"> <!-- CONTENT GOES HERE --> </article>
I've highlighted microdata in peach so you can get a taste of the deliciousness. (Blech!) The headline for your peach piece needs to be wrapped something like this:
<h2 class="entry-title"> <a href="" title="Permalink to The Serif Readability Myth" rel="bookmark"> <span itemprop="name">The Serif Readability Myth</span></a> </h2>
If you've got a byline, it needs to look something like:
<span class="date-time"><a href="" title="1:15 am" rel="bookmark"><time itemprop="datePublished" content="2014-08-29" class="entry-date" datetime="2014-08-29T01:15:55+00:00">August 29, 2014</time></a></span> / <span class="author vcard"><a class="url fn n" href="" title="View all posts by Kas Thomas" rel="author"> <span itemprop="author" itemscope itemtype=""> <span itemprop="name">Kas Thomas</span></span>
And the content itself should begin with:
<span itemprop="articleBody"><p>I’ve been involved in publishing all my life, and like many others I’ve always accepted as axiomatic the notion that typefaces with serifs (such as Times-Roman) are, in general, are more readable than [ . . . ]
Don't use curly-quotes; those are a WordPress artifact. So as you can see, this stuff is butt-fugly, not at all intuitive (unless you're a taxonomy geek), and clearly not something an unaided human being should be doing by hand. It's a situation that very obviously calls for better tools, and right now we have [crickets chirping].

WordPress developers? HTML rich-text tooling geeks? Open source community? Content management vendors? We need your help. This situation calls for immediate action. Lots of people could use lots of great tools. Please help us out. I can't stand on my head and count backward much longer.    

Want great tips, news, and resource links in your inbox? Sign up for the Author-Zone Newsletter!

Saturday, August 30, 2014

How to Get JavaScript to Work in a WordPress Page

Why does it so often happen that the things you thought were going to be easy turn out to be hard, and the things you knew were going to be hard turn out to be easy?

Case in point: I wanted to get a bunch of RSS feeds onto a news page at, and did. (See my previous post about the great free HungryFEED plugin for WordPress.) But the various feed items were not in date-sorted order, because the individual feeds were added in no particular order (and who knows which feed will update at which time anyway?).

What to do. What to do . . .

I thought it would be doable (but hard) to parse out the dates from the 70+ items manually (with JavaScript), then sort the items, and redisplay them. "Redisplay them" means first you remove all the DOM elements in question, then add them back to the page in sorted order. Fortunately, that turns out to be easy. You can call remove() on a node to vanish it from the page. But if you capture a reference to the node before doing that, the node will still exist in memory after it's been removed from the DOM. So you can then just add it back in to the page using appendChild() on a given target node. No problem.

The greater problem turned out to be how to get WordPress to accept JavaScript inside a page or a post. Turns out the rich text editor will stomp on embedded scripts pretty badly. This is a known sore point for WordPress users. And as with so many content management system problems (involving dynamic page assembly), it turns out there's a workaround, but it's the kind of thing that's not at all obvious and could drive you crazy for a solid day if you're not working with a partner who already has hit such snags and found the cure.

The magic workaround is to, first, put your script in a file and place it somewhere on the site on a public URL. Then reference that file from a script tag, and make your call to the file's main method inside a commented-out section of page (so the rich text editor ignores it) with CDATA wrappering (so the browser doesn't parse it either), with appropriate JS comments (double-slash) so the JS parser doesn't get confused by the CDATA directives. Like so:

<script>// <![CDATA[
//--> ]]></script>

I know, it seems weird as hell that the JS parser doesn't choke on the <!-- line. Apparently it treats it as an undefined quantity, but since you're not using that undefined "thing" for anything it doesn't trigger an exception. But guess what? It works! That's the main thing. The garblesnarble works. And (perhaps because I pasted the above lines AFTER the shortcodes in my WordPress content page, not in the <head> section of the page) the call to reorderItems() occurs after the DOM is safely loaded, hence there's no timing issue of woops! I can't mess with the DOM until after onload-time.

With this magic incantation in place, my script finally worked and the RSS feeds get date-sorted in real time no matter which feed updates first. I set HungryFEED's cache timeout to 3600 seconds, so the feeds are pulled once an hour. Unfortunately, it means that once an hour some unlucky soul gets to be the first person to request a fresh version of the page with all-updated RSS feeds (and there are 70+ feeds, so it's a lot of feed-slurping); wait-time up to 90 seconds. (Ugh!) It all happens on the server, though, with no AJAX. Once the feeds update, the content is static for the next hour, and during that time, the Author-Zone News Page loads in about four seconds, which is tolerable.

If you're a code geek and you want to see my code for date-ordering a bunch of feeds, the 40 lines of code are shown below. The first function is admittedly fugly. It hard-parses a bit of feed text to get the date string on the end, which will be something like "August 30, 2014, 3:23 pm". Fortunately, JavaScript is such an ace language that you can hand such a string to the Date() constructor and you'll get a real Date object back! Once you have that object, you can (again in genius JS fashion) multiply it by one to convert it to milliseconds-since-the-dawn-of-time. A number! Perfect for sorting!

The rest of the code is not terribly interesting. I loop over the nodes of interest and collect them into an array along with date-as-number. Then I sort using a custom comparator function (an inner method). Then I have to loop over the nodes-of-interest and remove them from the DOM. Then I have to loop again to add them back to the DOM in sorted order, and voila! Sorted RSS feeds.

function getDateFromItem(item) {
    var d = 
    return 1 * new Date(d);
function reorderItems() {
    var rootClassName = "entry-header";
    var rootNode = 
    var cl = 
    var r = []; // scratch array to hold nodes, dates
    // loop over nodes of interest
    // & push them into r[] as [node,date]
    for (var i = 0; i < cl.length; i++) {
        var item = cl[i];
        var d = getDateFromItem(item);
        r.push([item, d]);

    // we need this comparator function to 
    // sort the array on Date 
    function comp(a, b) {
        var aa = a[1];
        var bb = b[1];
        return bb - aa;
    r = r.sort(comp);  // sort on date using comparator 
    // remove all news feed items!
    // they're shown in random order!
    for (var i = 0; i < r.length; i++)
    // add them back, in date order
    for (var i = 0; i < r.length; i++)
reorderItems();  // do it

Thursday, August 28, 2014

Putting a News Stream into a WordPress Site

Over at, I managed to put together a News page in record time using the WordPress plugin HungryFEED. The (free) plugin was worth its weight in gold. And validates (in my mind) the superiority of the WordPress platform as a blogging platform.

Most plugins are easy to install or uninstall on WordPress and can be figured out quickly. HungryFEED was and is way better than most, though. It pulls RSS feeds from any source (you drop a shortcode into a page to render the feed or feeds you want to use) and lets you apply custom CSS and/or custom JavaScript to your streams very easily. It has easy ways to strip out img tags or table tags or other tags you might not want to render from the RSS sources. I was able to override any and all features easily using a few lines of custom JavaScript or CSS.

Way to go, HungryFEED! Way to go WordPress.

A ways to go, Blogger.

Tuesday, August 26, 2014

Last Responsible Moment

A military officer who was about to retire once reportedly said: "The most important thing I did in my career was to teach young leaders that whenever they saw a threat, their first job was to determine the timebox for their response. Their second job was to hold off making a decision until the end of the timebox, so that they could make it based on the best possible data."

This is an illustration of a principle that I think is (sadly) underutilized not only in R&D circles but in project planning generally, namely the principle of delaying decisions until the "last responsible moment" (championed by the Poppendiecks and others). The key intuition is that crucial decisions are best made when as much information as possible has been taken into account.

This is a good tactic when the following criteria are met:

1. Not all requirements for success are known in advance
2. The decision has huge downstream consequences
3. The decision is essentially irreversible

If one or more of the conditions is not met, the tactic of deferring commitment might not gain you anything (and could actually be costly, if it holds up development).

Conventional project planning, as practiced in enterpise today, tends to overemphasize (to an often ridiculous degree) the need for completeness in requirements-gathering. The completeness fetish leads to the Big Huge Requirements Document (or Big Huge RFP) Syndrome and nearly always introduces unnecessary dependencies and brittleness into implementations.

There's a certain hubris associated with the notion that you can have a complete specification for something. You almost certainly can't. You almost certainly don't know your true needs ahead of rollout. True, some decisions have to be made in the absence of complete data (you don't always have the luxury of waiting for all the information to arrive), and there's the fact that you need to start somewhere even if you know that you "don't know what you're doing" yet. But that's not my real point. My real point is that too often we make decisions ahead of time (that we didn't really have to make, and later realize we shouldn't have made) based on the usually-false assumption that it's possible to know all requirements in advance.

What I'm suggesting, then, is that you reconsider whether it's always a good idea to strive for a complete specification before starting work on something. Accept the fact that you can't know everything in advance. Allow for "emergentcy." (Good decisions are often "emergent" in nature.) Reject the arrogant notion that with proper advance planning, you'll have a project that goes smoothly and results in a usable solution. Most of the time, from what I've seen, it doesn't work out that way. Not at all.

Thursday, August 21, 2014

Amazon and Acquia

A fascinating news tidbit surfaced a few days ago at CMS Wire. It seems Amazon has invested in Acquia (the company that provides commercial support for Drupal, the popular open-source content management system), at a time when Acquia didn't exactly need any more cash.

According to CMS Watch's Virginia Backaitis:
Though neither company is disclosing the size of the investment, it certainly makes their relationship more symbiotic than it already was. Consider that Acquia runs on more than 8,000 AWS instances and serves more than 27 billion hits a month (333 TB of bandwidth a month).
The Amazon cash infusion comes only 90 days after a $50 million non-Amazon investment round for Acquia. In other words, they didn't need any more money. But Amazon insisted.

Make of it what you will; it's hard not to get the impression that Amazon will soon want to give other content-management options a run for the money, perhaps unveiling a WordPress-like solution for book bloggers, or wooing content creators away from Google's Blogger platform, or some such. Obviously they have some kind of content play in mind. But what?

Complexity Begets Charm

Giamatti and Church in Sideways.
Giamatti and Curch in Sideways.
Today's post is reblogged (with permission) from

It took me ten years to finally get around to watching the quirky 2004 bromance Sideways, starring Paul Giamatti, Thomas Hayden Church, Virginia Madsen, and the ever-piquant Sandra Oh. While the film does many things well and is, on the whole, watchable, it's also the kind of highly forgettable flick that will spawn no sitcoms, inspire no remakes, prompt no sequels, but in all likelihood simply linger in cable purgatory for untold aeons, to perplex future millions.

One of the film's main characters is not a person but a thing: wine. (Stop. There's Lesson No. 1. Are you making at least one thing into a character?) Two buddies go on a road trip (and try to get laid) before one of them has to appear at his wedding; that's the logline. (Already forgettable, right?) But the road trip involves winery-hopping, and we get to watch and listen as characters constantly fuss over wines, swirling them, sipping them, describing their "sturdiness" or their spicy oakiness, or their past-their-peakness, etc., to the point where you want to reach for a paper bag and puke up something well past its primeness.

One of the failings of the movie, IMHO, is that for all the wine talk, it failed to draw parallels between characteristics of wine and themes of the story. The opportunities for synergistic symbolisms was (dare I say) ripe. They mostly went (dare I say) wasted.

But the script (by Alexander Payne and Jim Taylor) did do a lot of things right, and I suspect Rex Pickett, in writing the novel on which the film is based, did even more of those things right. I'm talking mostly about character development. The characters could easily have been cardboard cutouts, stereotypical bachelor-buddies, and in some ways they were, of course; but below the surface-level depictions lurked dark, thwarted dreams, conflicting desires, countervailing motivations, self-doubts, under-realized virtues, and unexpected flaws as well as unexpected behaviors. All of these sorts of things make the characters more believable (if not always more sympathetic), and that's what a reader or a viewer wants: real people with real faults, conflicting desires, complex agendas, the capacity for change (maybe only in some ways, not in all ways); and a capacity for optimism, despite an overlay of gloom. (In Sideways, the Giamatti character is a depressed school teacher whose novels keep getting rejected.)

A character with no faults is a caricature. No real human being is all good or all bad. Hitler had a dog, for crying out loud. (Of course, he famously euthanized it in the end.)

Just as a wine can have many small flaws and still exude charm, so can (and should) the characters in your story. Give all your characters real flaws, along with inner turmoil. Be sure your villain is not one-hundred-and-ten-percent villainous; give him or her some endearing qualities, and show him to have inner doubts as well.

And by the end of the story, force the characters to confront some demons. Force them to change, or at least consider what they lost by not changing.

People are complex, in the real world. Make it so in your story-world.

Get free tips in your inbox: sign up for the Author-Zone Newsletter.

Monday, August 18, 2014

When Is It Really Necessary to Hold a Meeting?

Jason Fried explains very nicely, in a 15-minute TED talk (watch it here), why the modern office is a singularly poor place in which to get work done. Bottom line: The modern office is specifically designed to facilitate interruptions. It's what one might call a high-interruptivity environment (by intent; by design).

For much the same reason that eight one-hour naps interspersed with short periods of wakefulness do not add up to a full night's sleep, a succession of 15- and 20-minute periods of work (in an office environment where you're interrupted by texts, phone calls, e-mails, IM, meetings, coworkers coming in to see you, bosses checking on you, trips to the coffee machine, and so forth) seldom adds up to a day's work. To get serious work done requires long periods of uninterrupted private time. This is why so many people say that their favorite place to get serious work done is the back porch, the basement, the attic, the shower, the library, the park, Starbucks, etc., or (if it's indeed the office) the office after everyone leaves to go home, or before everyone arrives in the morning. No one counts as their most productive environment the office during normal working hours.

Through technologies like Webex and Go-to-Meeting, we're now able to introduce productivity losses even to people working from home.

Toward the end of his TED talk, Jason Fried suggests, as an exercise (not as a policy), that any manager who has a meeting planned for Monday simply cancel (and not reschedule) the meeting and see what happens. Does the world come to an end? Do sales drop? Do people stop getting work done? Or, to the contrary, does the cancellation of a one-hour meeting involving ten people result in ten additional person-hours of productivity, reclaimed for free?

I wish Fried would have taken his own logic to the ultimate conclusion, which is that meetings (particularly regularly scheduled staff meetings) should simply be abolished, outlawed.

Over the years, I've worked for small, medium, and large companies, mostly in software development, both as an individual contributor and as a manager. As a manager at Novell, I attended an average of three meetings a week, or about 1000 meetings total. At Adobe, I attended a weekly status meeting (which was often cancelled, to no ill effect whatever) plus one or two division-level all-hands meetings per quarter, and one to two company-level all-hands meetings per quarter. I can say without reservation that all meetings I ever attended at Novell and Adobe, except for some one-on-one and impromptu 3- or 4-person meetings, were utterly without effect, aside from the undeniable effect of resetting everyone's productivity to zero at the time of the meeting.

You might ask yourself, if you're involved in setting up meetings, what it says about the fragility of your company or the ineffectuality of your organization (or your management style) if the success of the enterprise is somehow compromised by not holding that weekly status meeting, or that monthly planning meeting, or that quarterly all-hands meeting that you (vainly, stupidly) imagine is so necessary to inspiring team spirit and getting everyone "on the same page." In all my time at big companies (and smaller ones too) I can't remember a single meeting being indispensible (except, as I say, for a few one-on-one or two-on-one events). The meetings invariably distracted me from getting real work done. The bigger the meeting, the worse the productivity loss.

Whenever I missed a meeting, I found out later that I either missed nothing substantive whatsoever, or I could easily (and in a few minutes' time) catch up on whatever I'd missed simply by reading a transcript, a key memo, or someone's "takeaways" summary.

Meetings are a classic example of a central-command push technology that should be replaced by an opt-in/pull technology. Quarterly all-hands meetings, in particular, are surreal in the way they evoke 1980s business culture. Can we get beyond the 1980s? Just post what I need to know somewhere. Drop me a memo. I'll look at it when it's time for me to look at it. When I can spare some time to be nonproductive.

Saturday, August 09, 2014

Hachette vs. Amazon: A Trader's Perspective

Hachette and Amazon are locked in a pricing dispute that's gone on for some time now. It may eventually be resolved, although frankly, it could well go unresolved, too; Hachette doesn't have to cave in to Amazon's demands. Hachette may well hold its hard-line position forever (and suffer the consequences in terms of poor placecment on Amazon's sites, shipping delays by Amazon on Hachette books, and so forth) . But many people believe the dispute will eventually be resolved. Is there a way for investors to come out ahead?

Bear in mind, none of what follows constitutes investing advice. I mention it as a hypothetical scenario.

Here's how some investors would play this situation. We know that if the dispute is suddenly resolved, there's a good chance Amazon shares will go up in value. But there's also a chance Hachette will pull the plug on Amazon and announce a deal with another (r)etailer, in which case Amazon shares would likely plummet. A resolution to the dispute could send AMZN shares sharply higher, or sharply lower.

This is a classic example of a situation in which an options trader would hope to make money on a straddle. A straddle is where you buy a call option and a put option (one is a bullish bet; the other a bearish bet), simultaneously, at the same strike price.

Let's say you think the dispute will be resolved in the next 30 days. You might decide to buy an October AMZN call option for $16.05 (full contract price: $1605, 100 shares), at the $315 strike. An October 2014 put is $13.95. Total cost: $3000. (These prices are based on the 8 Aug 2014 closing prices.)

If the Hachette dispute is resolved and the dispute resolution moves AMZN share price by $30 (which is not unreasonable; it's less than 10% of Amazon's current share price), one option will move into the money and the other will move out of the money. Currently, a $30 into-the-money move on the call makes it worth $37.30 while a $30 out move makes its worth $5.25. On the put, a $30 move makes it worth either $33.20 (if the stock goes down $30) or $4.55 (if the stock moves up). In one case you end up with a total of $4185 and in the other case you end up with $3845. Your initial investment was $3000.

If you think the dispute won't resolve in September (and there's certainly no indication that it will), you could choose to buy January options. The prices of the options will be higher but the straddle would still work, in theory. The problem with all options contracts, though, is that they suffer substantial price decay over time (for January contracts, figure roughly ten to twelve cents a share per day, per option). Bottom line, 40 days' worth of waiting could cost you $800+ in decay (on one call and one put). So there's a substantial penalty for having to wait. And it looks like this dispute could go on for some time. In fact, it could go on forever, since the parties are not obligated to reach an agreement.

Also, bear in mind there's no guarantee AMZN stock price will move $30/share when the Hachette dispute is resolved (if indeed it ever is resolved). It could move a lot less, or not at all.

So use caution. This is far from a risk-free strategy.

Disclaimer: Consult your investment advisor (I am not one) before doing any trades.