In Memoriam, Tim Tripcony

Friday, May 16. 5pm ET at Tuscany in Woodstock, GA.

We’re exploring options for virtual guests as well. Details will follow.

How to make a White Russian: Pour 2oz of vodka and 1oz of coffee liquor over ice. Add light cream or milk to taste. Your choice of vodka should reflect the person we’ll be honoring.

Posted in Uncategorized

My Friend, Tim Tripcony


The XMage and I first met in North Carolina at Lotusphere Comes to You in 2007. We had collaborated on some open source projects before, but had never been in the same room until that point. I was smitten. And I managed to convince my bosses at the time to make him an offer. He accepted and our worlds were forever changed.

Over the last 7 years, Tim and I shared a deep collaboration that, while it faced its share of struggles, stemmed from our enduring friendship. It saddens me that we’ll never get to finish each other’s code blocks or pick a blog fight or present a session together again. It makes my soul ache that I’ll never get to roll my eyes at one of his cheesy puns or pretend we can dance at a music festival or be his wingman and introduce him to a pretty girl ever again.

Much has been and will be said about Tim’s genius and generosity and every word of it will barely scratch the surface of the contributions he’s made. Having worked keyboard-to-keyboard with him for many years, I would add that he always used both sides of his brain in every line of code, applying musical creativity and linguistic flourishes right along with his anonymous callbacks and love of ternary notation.

Unlike most of my readers, I knew a Tim who would sit on the floor and play with my dogs for hours after Christmas dinner. I knew a Tim who snored like an elephant after too many white Russians at Kimono’s. I knew a Tim who fought through a haze of tears to share with me the loss of his marriage. I knew a Tim who nearly punched a Dolphin network tech in the face while we sat backstage at Lotusphere watching months of planning and effort blow up in our faces. I knew a Tim who fell asleep sitting upright in a hotel bed trying to get just one more bug fixed before our big demo. I knew a Tim who would would come over to my house on a Sunday to write some crazy piece of code together, because while making a computer do what you want is fun, doing it with your best friend on a self-imposed deadline just because you can is positively gut-busting.

I knew Tim; and I am a better coder, a better husband, a better father, a better man for it.

I wish I’d given him as much as he gave me.

EDIT: My friend Cheryl Spring shared this picture on Facebook and I thought it was too perfect to withhold.


Posted in Uncategorized

Meme time

Pro tip: Make sure you read the hover text

Posted in Uncategorized

A timely lesson on logic

One of the most indispensable resources on the entire internet is a simple web page that describes the generally accepted logical fallacies. When you encounter a debate that seems confusing or intuitively incorrect, it’s a great technique to look over the fallacies and see if the arguments in the debate rely on any of them. I’ve found that the most common are:


Personal Incredulity

False Cause

Slippery Slope


False Dichotomy



Appeal to Authority

Middle Ground

The Fallacy Fallacy

Watch out for these fallacies when you encounter debates online. Even people that you would expect to be experts at logic and argumentation are prone to committing them.

Posted in Uncategorized

Why I’m no longer a “consultant”

Does this meeting sound familiar to you?

Posted in Uncategorized

Hmm… upgrades!

Marky Roden has published an excellent post on the difference between what’s good for developers and what’s good for users over at his Xomino blog. I wanted to give my reply due consideration, and spent a bit of time thinking about why there’s this dichotomy of interests. And I ultimately realized that in order to do the topic justice, I would have to develop both solutions and compare. I set myself a simple task: have an XPage with two radio button groups, one that would show & hide a div using partial refresh, and another that would show & hide a div using client-only code.

The first part was easy enough and took about 5 minutes. It looks like this…

<xp:div id="partialTarget">
<xp:radioGroup id="radioGroup1" value="#{viewScope.partialRadio}" defaultValue="hide">
<xp:selectItem itemLabel="show" itemValue="show"/>
<xp:selectItem itemLabel="hide" itemValue="hide"/>
<xp:eventHandler event="onchange" submit="true" refreshMode="partial" refreshId="partialTarget" execMode="partial" execId="partialTarget"/>
<xp:this.rendered><![CDATA[#{javascript:return viewScope.partialRadio=="show";}]]></xp:this.rendered>
<xp:label value="Partial Refresh area now being shown!" id="label1"/>

But then a funny thing happened when I went to do the client-only version. I couldn’t. I thought it would be easy enough to add a client event handler to the radio button that toggled the visibility of the target div, but I discovered that I didn’t know how to get the value for the radio button. And a bit of Google-fu revealed that I wasn’t the only person to have this challenge. Because of the arcane way that radio button groups work, lots of people have struggled with this problem.

In the end, I had to turn to people who know client-side Javascript better than I, including the esteemed Dr. Roden himself, to come up with a solution. It looks like this…

<xp:radioGroup id="clientRadio" value="#{viewScope.clientRadio}" defaultValue="hide">
<xp:selectItem itemLabel="show" itemValue="show"/>
<xp:selectItem itemLabel="hide" itemValue="hide"/>
<xp:this.value><![CDATA[dojo.query("input[name=#{id:clientRadio}]").connect("onchange", function() { dojo.query("div[id=#{id:clientTarget}]")[0], "display", (this.value=="show" ? "" : "none") );
<xp:div id="clientTarget" style="display:none">
<xp:label value="Client refresh area now being shown!" id="label2"/>

Needless to say, this is quite a bit different. I hesitate to say it’s more complicated, because if you’re thoroughly familiar with Dojo, it’s not much code. But Designer didn’t offer me any help in solving the problem client-side. I might even say that it actively got in the way by misleading me with the onChange event in the IDE not being able to provide me with the selected value of the radio button.

But as I look at what code gets generated at the browser level, there’s no particular reason why the Designer components couldn’t do this. Indeed, if I’m willing to switch to a Dojo radio button set, I can do this with a client simple action. It looks like this…

<xe:djRadioButton label="show" id="djRadioButton1" value="#{viewScope.dojoRadio}" defaultValue="show" selectedValue="show" groupName="dojoRadio">
<xp:eventHandler event="onChange" submit="false">
<xe:this.script><xe:dojoFadeIn node="dojoTarget"/></xe:this.script>
<xe:djRadioButton label="hide" id="djRadioButton2"  value="#{viewScope.dojoRadio}" selectedValue="hide" groupName="dojoRadio">
<xp:eventHandler event="onChange" submit="false">
<xe:this.script><xe:dojoFadeOut node="dojoTarget"/></xe:this.script>
<xp:div id="dojoTarget">
<xp:label value="Dojo refresh area now being shown!" id="label3"/>

Definitely more complicated but perhaps worth it.

So how do we solve this conflict between developer productivity and user experience? Better tooling, of course. We need new components that are as simple to use and understand as the partial refresh example, while providing the user experience and efficiency of the client-side or Dojo examples. To me, the obvious place to do this is in the Bootstrap4XPages open source project.

Who’s in?

Posted in Uncategorized

Really IBM?

“Bluemix is for the quick creation of applications by line of business developers. The reason: we used to hear the line of business ask for applications, and we’d talk about development in months, then we’d talk about weeks, now we start to hear them request application development in days. And the traditional IT development cycle just can’t handle that. That’s where Bluemix comes in. It’s a place for these line of business developers to go, quickly create applications and they don’t need to deal with underlying infrastructure.”

Are you kidding me? Look, Bluemix might be totally awesome and the best thing since sliced bread (which, come to think of it, isn’t nearly as good as whole loaf bread.) but this isn’t an unsolved problem. The fact that line of business developers could quickly create applications in days without needing to deal with underlying infrastructure is why Notes is one of the most successful application platforms in history and even companies that have “gotten off Notes” still have version 6 and 7 clients installed as part of their standard desktop image.

I haven’t even gotten to the demo yet because I’m just so incredulous about this introduction. It’s been almost two decades since IBM acquired Notes and they STILL don’t understand what it does for customers.

Posted in Uncategorized