Hacking at 0300

Now that sendkeys is fixed to work with contenteditable and I've analyzed Lebedev's VirtualKeyboard to allow typing on the physical keyboard, updating the hebrewKeyboard plugin was straightforward. I had to learn a fair amount about the difference between keyup, keydown, and keypress events, but I think everything works. Check it out!

Update: I no longer (2012-08-05) use Chili, I've switched to Prism.

I wanted to try different syntax highlighters so I wrote a little WordPress plugin that let me switch between different highlighters (email me if you would like that code). I wanted syntax highlighters that were javascript-based (ruling out GeSHi), and that allowed me to highlight inline code elements as well as code elements within block-level pre elements, using the HTML5 <code class="language-whatever"> notation for determining language. I also wanted something that didn't do any fancy javascript or Flash for selection and copying, and either supported Lisp and Basic or was easy enough to extend.

Everyone seems to use Alex Gorbatchev's syntaxhighlighter but it uses nonstandard name attributes and only works on pre and textarea elements, so I haven't tried that. I tried Benjamin Lupton's jQuery syntaxhighlighter based on Google's prettify. It insisted on making all elements display: block but a little CSS manipulation fixed that.

Then I tried snippet, which only works on pre elements but was easily modifiable to get around that, then also needed some stylesheet changes to keep the results from being display: block. Adding new languages however looks far too complicated; it uses shjs which uses language definitions from GNU Source-highlight, which is a whole different language.

jush does things right (working on code elements and not forcing them to be block) but it's hardwired for a limited number of languages and the CSS is pretty ugly. That could be fixed, though, and it does a cool trick of turning keywords into links to the documentation. Too limited a language selection, though, but it would be a nice base for working on.

In the end, I'm going to stick with chili. It's simple enough for me to modify to suit my needs, it's easy to add new languages and it works. Creating new "themes" is impossible; the styles are hard-coded into the javascript files, but I can live with that. I may sometime write my own highlighter, but for now, I'll stick with what works.

The $.fn.sendkeys Plugin

This is now obsolete. sendkeys is at version 4, and is documented at "Rethinking $.fn.sendkeys".

I wanted to make a general-purpose onscreen keypad, and wasted a huge amount of time trying to find a way to simulate a keypress. $(element).trigger("keypress",...) won't work. Neither will keyup or keydown. For security reasons, I guess, you can't tell an element to pretend a key was pressed. The browser is too worried that you will access menus or something.

So I wrote my own plugin and named it after Microsoft's sendkeys which does similar things. For any editable element elem, $(elem).sendkeys(string) inserts string at the insertion point or selection. It's the insertion point sensitivity that makes it more sophisticated than elem.value += string.

It depends on my bililiteRange routines to manage the selections in a cross-browser way.

Downloads

See $.fn.sendkeys on github.

See bililiteRange on github.

See the demo.

Continue reading ‘Improved sendkeys’ »

Updated to version 2.3 on 2014-02-26 for data routines.

I was trying to update my sendkeys plugin to use contentEditable, and realized that it was getting harder and harder to do without some selection/text replacement library. Each browser is different and even different elements are treated differently. There are a few libraries out there, but none handled both input and textarea elements and regular elements, and would constrain the selections to a given element (critical if I want to edit only part of a document) and none made it easy to simulate arrow keys, moving the selection left or right. So I figured I would make my own.

See the code on Github.

See the demo (try it in different browsers!).

Continue reading ‘Cross-Browser Text Ranges and Selections’ »

I like Andrea Ercolino's chili syntax highlighter. I like it because it works well with jQuery, it allows me to use the HTML5 <code class="language-whatever"> notation for determining language, and I can highlight inline elements, not just pre elements. And Andrea has been very responsive to my questions.

But it has an annoying habit of being too clever about cutting and pasting: selecting text in marked-up pre elements evidently used to cause problems in Firefox, so chili detects the mousedown when you try to select and creates a pop-up box with plain text instead. Unfortunately, it just gets in the way and the text is no longer formatted correctly. And the problem only exists for code with line numbers, which I never use.

So I modified the code in file jquery.chili.js: I turned the function fixTextSelection (line 1097 in my copy) into a no-op by adding a return; at the beginning. Now select and copy/paste work correctly in Firefox. It may be broken in Internet Explorer, but that doesn't bother me: my whole blog theme breaks in Internet Explorer. That's a feature, not a bug :) .

There still are some problems; it loads styles and scripts dynamically and if there's a lot happening on a page the syntax highlighter tends to lose race conditions and nothing happens. I may look at Benjamin Lupton's jQuery syntaxhighlighter or JUSH or make my own (in my copious free time).

A depressing but absolutely correct editorial from Dimitri Christakis of the University of Washington in this month's Archives of Pediatrics and Adolescent Medicine (behind a pay wall, unfortunately, but the full reference is there).

[H]undreds of decision tools in a variety of forms—guidelines, practice parameters, prediction rules—have been generated. Some have been good, some bad; some have been validated, others not. But what they all have in common is that their overall use remains poor at best. In the meantime, those of us in academia continue to create them and those of us on editorial boards continue to vet them for methodological rigor. The cottage industry of decision tools has at least the appearance of an academic jobs program since, to clinicians in the real world, their utilities remain largely unproven [emphasis added]. For example, there are no fewer than 10 clinical prediction rules for something as common as streptococcal pharyngitis, and I would be surprised if most clinicians even use one.

The big problem is the difference between significance and importance. Significance in statistical jargon is an estimate of how likely the results are to be true (see David Sackett's article on randomized controlled trials) but it says nothing about whether the results mean anything to me in real life. A test that tells me a patient has a 50% chance of having strep throat, when before I would have guessed at 20%, may have a p = 0.0001 (the test is consistently better than chance!). But who cares? For actual clinical practice, things that affect my decision-making need to be orders of magnitude apart, not a few percent. Similarly, a new fever-reducing medicine may have reduced the temperature by 0.1 degree with a really high ?², but isn't going to make me prescribe it.

But real life is rarely so cooperative as to give you high odds ratios, so guidelines based on actual data tend to be less than useful, and guidelines with advice that can actually be implemented tend to be based on "expert opinion," which is a polite way of saying "faith." ("Experience is the ability to make the same mistakes with greater and greater confidence").

So what do we do? The academics would have us analyze every article ever published and determine our own statistics, but that's impossible. All we can do is read the reviews and guidelines and make sure we know which conclusions are solid, and treat them with respect, and which are strongly-held opinions by experts in the field, and listen politely and decide if we think we know enough to overrule them. If the guideline won't tell you the difference, throw it out.

There's still some room out there for the art of medicine.

Update: A perfect example in this month's Pediatrics (Taisan and Copp (2011) Pediatrics 127:119-128). A review of ultrasound to look for undescended testes showed that it would change the probability of an intra-abdominal testis (requiring surgery) from 49% to 64%. It doesn't matter how significant that difference is, it isn't clinically important and therefore the ultrasound is not indicated.

As Douglas Crockford has said, javascript is Lisp is C's clothing. That is part of what make javascript fun to program, but I never realized how literally true that statement is until I found this fascinating article by Thomas Lord about GNU and Scheme, that claims:

I've read, since then, that up to around that point Brendan Eich had been working on a Scheme-based extension language for Netscape Navigator. Such was the power of the hegemony of the high level folks at Sun that the word came down on Mr. Eich: "Get it done. And make it look like Java." Staying true to his sense of Self, he quickly knocked out the first implementation of Mocha, later renamed Javascript.

Explains a lot. And shows what an under-appreciated genius Brendan Eich is.

I have no idea when I would ever want to use these, but they are very cool.

<h4>Click Me</h4>
<div id="texteffect" style="width: 200px;height: 200px; border: 1px solid purple; background: #abcdef; cursor: pointer; padding: 2px; overflow: hidden">
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur libero sem, fringilla in posuere a, cursus nec felis. Integer eu mi in tortor malesuada pretium vel sed augue. Donec eget convallis tellus. Aenean vehicula nisl ac justo facilisis et bibendum mauris aliquam. Fusce quis dolor sapien, et lacinia lorem.
</div>

var text = '';
$('#texteffect').click(function(){
  if (text){
    $(this).effect('type', {text: text, word: true}, 2500);
    text = '';
  }else{
    text = $(this).text();
    $(this).effect('backspace', {text: '', word: true},  2500);
  }
});

One downside of the virtual keyboard is that it takes over the physical keyboard, so that typing is in the language of the virtual keyboard. This is often an advantage, but I usually want to mix Hebrew and English text. So I modified the program to track the Caps Lock key: if the caps lock key is depressed, then the physical keyboard types in the virtual language; if not (the usual state) the physical keyboard remains at its default. I'm using the new code in the Young Israel Hebrew Keyboard (now renamed the Bililite Hebrew Keyboard).

Continue reading ‘New Hebrew Keyboard’ »

Part of the drudgery of medicine is all the certification and paperwork, and the petty bureaucrats who need to constantly justify their existence by creating new rules. All the rules are well-intentioned, but taken together pave the road to hell—keeping us away from our patients and actually helping people. One such well-paved path is the American Board of Pediatrics which, over the past 20 years, turned board certification from "Take a test" to "Take a test at home every 7 years" to "Take a closed-book test in a secure environment because we can't trust you, every 7 years" to "Take a secured test every 7 years, keep your medical license (even losing it for not paying taxes means you lose your certification), do Board-approved CME, get patient-satisfaction surveys, and do Board-approved quality improvement projects, every 5 years." There's no reason to believe any of this makes me a better doctor but without it, what's the Board for? But enough griping, I may write about this more later.

One of the first things I tried to do when I started at the St. Lukes Pediatric Care Center this fall was improve our asthma management and follow up, so my Quality Improvement project will be the Board's Asthma Practice Improvement Module. It's no different from what I'm doing anyway, with the added fun of filling out data forms online for the Board to adjudicate.

Asthma Management

Asthma is a growing problem in the US, and the NIH has produced a huge (4 MB) report on managing it, with lots of its own jargon. Basically it's a chronic disease that comes in attacks, which can either be in control—only occasional symptoms—or not in control—frequent symptoms. Either way, attacks are treated with rescue medicines, usually an inhaler that relaxes the muscles in the lungs. If your asthma is in control without any other medicines, then you have intermittent asthma. If not, you have persistent asthma and need control medicines to take every day to prevent attacks. The report further divides persistent asthma into grades of severity, but judging severity is inconsistent and largely irrelevant: if your control medicines keep you in control, good; if not, do something more.

Continue reading ‘Better Asthma Care through Technology’ »