Hacking at 0300

The bane of modern medicine is the paperwork, especially for a practice like mine that is largely Medicaid. If there's anything the government loves, it's paperwork. Fortunately, most of it is available electronically. Unfortunately, most of that is in PDF form, uneditable and closed. Sometimes the bureaucrats have thought to make it a fill-in form, but usually it needs to be printed and filled by hand. With my handwriting, that's a recipe for illegible disaster.

Comes a new website to save the day: PDFescape. It's free (Google ad-supported), all javascript-based (no Flash!), and lets you upload a PDF locally or from the web, then add text or form controls wherever you want, then save it locally. Poof, instant fill-in form! It's smooth, easy-to-use and does exactly what it claims to do. All programs/webservices should work that well.

Since AVH Amazon plugin no longer works, as Amazon in its infinite wisdom removed the ListLookup API call, I had to create my own. Without an API, I resorted to a hacker's best friend: screen scraping. The wishlist page has a simple structure, and all links to Amazon products have as part of the URL "dp/{ASIN}", where {ASIN} is the Amazon ID number. If you view a wishlist in compact form, then the only links are to wishlist items and all the items (as far as I can tell) will be on a single page. Other advertisements for Amazon products that you see on the page are added with Javascript, so they won't show up when we grab the page with PHP.

So it's easy to get a list of ASIN's of the products on my wishlist:

function wishlist($listname){
	$url = "http://www.amazon.com/registry/wishlist/$listname?layout=compact";
	$contents = file_get_contents($url);
	preg_match_all ('|/dp/(\w+)/|', $contents, $ASINs, PREG_PATTERN_ORDER);
	return $ASINs[1]; // just get the numbers
}

This returns an array of ASIN's, that you can now pass the the Amazon ItemLookup API, which still works fine (Ulrich Mierendorff's AWS Signed Query makes that easy).

If your web hosting service disables file_get_contents, as mine does, you can use cURL instead.

As you can see from my sidebar, it seems to work well. Obviously, Amazon can change the layout and content of their pages without notice, but as we have seen, they can change the API as well.

The Centers for Disease Control and the American Academy of Pediatrics just recommended that pediatricians stop using the old growth charts, based on 40 years of NHANES data, and switch to new charts from the World Health Organization, for children less than 2. The NHANES study is a survey of child health from the United States, and the original charts based on that data was descriptive: the charts showed what the distribution of heights and weights was for American children. That was used by pediatricians to define "normal," to say whether you were overweight or underweight. With the 2000 charts, they decided that kids were too heavy and that we couldn't call that "normal" anymore. So they effectively threw out all the recent weight data, and made the charts based on the 1970 distribution of weight (see page 16 of the original paper) and made the charts partly prescriptive (telling us what they thought the distribution of weight should be) and partly descriptive.

Now they've gone all the way: the WHO explicitly followed an international group of babies who were "were raised in environments that promote healthy growth", including exclusively breastfeeding to 4 months and continuing breastfeeding to 12 months, no smoking, and rich enough to be able to eat well.

I updated the bililite webservices charts to reflect the new charts, but I'm of two minds about the change. As a pediatrician following a kid's weight, I really do want to compare it to "healthy" rather than "common," so the change is for the better. On the other hand, it enshrines assumptions about what "healthy" means without good evidence that children who fall in the prescribed ranges actually live longer, healthier lives. We will get more recommendations for further restricting our children's lives in order to force them onto these graphs.

As these charts get more use, look for more press about increasing obesity, as we redefine the percentile lines downward, pushing more kids over the "overweight" 85^th percentile. It's like the AMT of biostatistics!

I've been using Peter van der Does's AVH Amazon plugin to display my Amazon wish list (more as an "about my interests" than a "buy things and make me money") and it's worked well, allowing a random selection of books I would like to be shown in the sidebar. Now it's dead, killed by Amazon's deprecating the API to get the wish list items. It seems short sighted, especially since Amazon's wish list widget is so limited and poorly formatted (it's on the sidebar now). I may look into creating my own, if I ever have free time again.

Been a long time since I last posted; real life has a way of getting in the way. The past few months read like the back cover of A Series of Unfortunate Events: if you don't want to hear about a thwarted move, a house fire, 2 graduations, negotiations for a new job and a carrot salad with lots of garlic, then you should put this down and live someone else's life.

But I'm not complaining; everything looks like it's working out well.

Going back to Scheme, the next Project Euler problem is:

The prime factors of 13195 are 5, 7, 13 and 29. What is the largest prime factor of the number 600851475143 ?

And straightforwardly:

(define gpf ; greatest prime factor
  (lambda (n try) ; n is the number to find the factor of; try is the lowest number to try
    (cond
      ((> try (sqrt n)) n) ; no need to try a factor higher than the square root; if we get here, n is prime
      ((divides try n) (gpf (/ n try) try)) ; divide out the current trial factor and try again
      (else (gpf n (+ try 1))))))
(define euler3
  (lambda (n) (gpf n 2)))

(euler3 600851475143) gives us the answer 6857 pretty quickly.

But this is getting boring; I'm not using the interesting parts of Scheme. This sort of problem cries out for a prime number generator, and that cries out for call-with-current-continuation, and that cries out for some more playing and learning. I'll see what I can do.

Well, they released jQuery UI 1.8 two days ago, and now everything is broken. I understand why the changes were made, but it sure is inconvenient. Plugins and posts updated so far:

• timepickr
• widget tutorial
• extending widgets
• flexcal
• googlesearch and ajaxpopup
• textpopup and hebrewkeyboard

And on top of that, chili stopped working with jQuery 1.4 and I haven't fixed it yet. Andrea Ercolino was nice enough to send me an updated version, but I haven't gotten around to installing it yet.

Update: got chili to work!

So much for using my spare time to learn Scheme!

I usually don't blog about medical stuff here, but Allie Brosh's comments about the Wong-Baker pain scale are perfectly on-target. The Joint Commission accredits health care organizations and comes up with intrusive, well-intended but largely pointless standards that the rest of us have to uphold. A sort of "unfounded mandate." One of these is the requirement that we document pain levels in every patient on a scale of one to ten. For pediatric patients, we have this "FACES" scale that starts from a big smile and doesn't even get to a frown until number six. I like Allie's much better.

And her comment about not eating red food when you're sick is absolutely right. Never give your kid red popsicles when they've got a stomach bug; you'll just rush into the ER worried that they're throwing up blood.

The second project Euler problem is:

Each new term in the Fibonacci sequence is generated by adding the previous two terms. By starting with 1 and 2, the first 10 terms will be: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ... Find the sum of all the even-valued terms in the sequence which do not exceed four million.

OK, so my new mini project is to learn Scheme. It can't be too hard, right? I mean Javascript is just Lisp in C's clothing, and I'm good at Javascript. I've installed PLT-Scheme and I figure the best way to learn it is solving Project Euler problems until I get bored.

I've been using Quicken for years, since Quicken 97 on Window then Quicken 5 on the Mac and then Quicken 2001 when I got my iMac. The problems is that Intuit doesn't upgrade Quicken, it replaces it each year with a version that has more frilly bells and whistles and less real utility (especially on the Mac; just look at the "Using a prior version of Quicken Mac?"). And the datafile is often different from the old file, so stuff gets lost with each "upgrade".

So I've kept my current Mac (a blue & white G3, the "Mickey Mouse" one) just to be able to run Quicken 2001 under Classic. I can't upgrade to an Intel Mac, since Classic won't work. And I want to balance my checkbook while talking to my wife, not only downstairs in my basement office. So I wanted something I could run on my dual-boot (XP and Ubuntu) laptop.

I've been looking at alternatives to Quicken for 5+ years, but with 20 years of data I was too scared. Until now. I've been using gnuCash for just a week now, but it seems to everything I need it to, including importing all my data, even from multiple investment accounts, from Quicken's exported QIF file. I haven't done any complicated investment things, so I don't know how well that side of it works.

Strong points

• It Just Works. Does what I expect it to do, in the way I expect it to. Of course, I'm a geek who understands double-entry bookkeeping, so that may not be surprising.
• I can control-S and save the file; I always felt out of control with Quicken since you couldn't force it to save.
• Open source. I will probably never have the time to tinker, but it's nice knowing that I could

Weak points

• Keyboard shortcuts. I miss being able to assign my own keystrokes; I hate going back to the trackpad to do anything. But see Open Source above; I can probably fix that.
• I'm going to have to learn Scheme to create custom reports. Not sure if that's a bug or a feature.

The biggest advantage is the feeling of freedom of not being tied to Intuit anymore. I'll see how it works out, but I'm not going back.