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.

Wednesday, August 06, 2014

A Workflow Wish List

In my day job, I evaluate content management systems (enterprise-grade systems, not light-duty blogware), and I get to see and touch a lot of so-called workflow systems. This is the part of the system that (for example) routes documents to people who can approve them (or not) before they're pushed out to a web site.

What I find is that almost all enterprise-grade content management systems have a workflow subsystem of some kind, but it's typically not well implemented. I understand the reason for this. Workflow, like so many things in life, is easy to do, hard to do well. It's hard to make a good workflow system. That's the bottom line.

Still, there are certain things I like to see. (If you're in the market for an enterprise-grade CMS, here's your checklist.)

1. A good visual designer. I like to be able to plop new activities down on a canvas, in arbitrary locations (and give them arbitrary names), and move them around, then draw links between them.

2. There should be a small number of easy-to-understand activity types.

3. I should be able to see what the input and output documents (including flow metadata) are for any given activity in the flow. Ideally, every activity should be capable of taking one or more XML documents in and spitting one or more XML documents out.

4. I should be able to draw arrows backwards from any activity to an upstream activity. In other words, the system shouldn't just support acyclic graphs.

5. Each activity should support the notion of a timeout value.

6. Each activity should support the notion of a retry count.

7. Each activity should support the notion of a retry interval.

8. The visual designer should let me (through some kind of easy gesture, whether a mouse click, doubleclick, right-click, etc.) expose an editable property sheet for the activity, where I can inspect and set values like timeout and retry interval.

9. I should be able to specify a logging activity at each step of the flow. The more configurable the logging activity, the better.

10. I should be able to specify a fault handler for any given activity. Including a default fault handler.

11. There should be an easy facility in the GUI for attaching JavaScript logic to any step. (And please don't invent a new scripting language. Use something standard. That means JavaScript.) Ideally, each step in the flow will have event handlers to which I can attach my own scripts. Scripts should have access to any XML that travels with the flow.

12. Ideally (and I know this is a lot to ask), the design-time tool will have an animation capability (for testing workflows) so that I can do certain kinds of QA testing right in the design environment.

The real point of Item 12 is that it should be easy to test a workflow and debug it. Very seldom is this actually the case, even in systems costing $50,000.

In addition to the 12 items above, a system that really "goes the distance" will also have some way to delegate approval tasks.

If all workflow systems supported these features, my job would be easier, and (needless to say) so would the jobs of the people who buy and use these systems. And that's the real point.