Tuesday, July 14, 2015

How to donate used bikes (and why that may beat selling them)

In the Twin Cities we have a number of places that accept bike donations, fix them up, and sell them. They use the money to fund community activities and provide selected donations.

if you’re fortunate enough to be in a high tax bracket, the deduction may be competitive with what you’d get selling the 2nd hand bike to a local shop. You’d get more if you could find a direct buyer, but that’s work. Second hand bike shops don’t offer much for a used bike, though they sell them for more than I’d expect.

If you do donate you need to know the $250 (single transaction) and $500 (yearly total rules). If you are over $250 you need a record of the donation; the shop provides that, along with proof of tax status - so that’s no problem. (No point in trying to split donations.) If you are over $500 for the year (easy to do) you need to complete Form 8283 so you’ll need records for EACH donated item of:

  1. Donee organization
  2. Property description
  3. Date contribution
  4. Date acquisition and how it was acquired (getting harder!)
  5. Cost at time of acquisition
  6. Fair Market value at time of donation  and method used to determine (recipient can’t help, I compared items to price of similar items on sale and used that value).

Yes, bit of a pain if you don’t know ahead of time. I use a Google Sheet to enter data, print it out, stick receipt on it, then toss it in the box.

Sunday, July 12, 2015

Tools: emulating (Rally) Agile work using Appigo ToDo.app and ToDo Cloud

My circumstances have changed. I may have more to say on that later; even in the sort term it is probably a change for the better. But of course life must be lived forward and understood backwards and all that.

One of the benefits of my new position is an opportunity to revisit my Tools. At one time (less so now) I’d read that tools didn’t matter, it was all about … something. Process maybe, or magic. This was sometimes used to justify a lack of investment in tools to support getting work done. I won’t bother refuting this idea, it’s self-evidently wrong.

Tool choices shape everything. I like Tools that last years to decades; switching costs are often high [10]. In practice, since modern software has very short lifespans, this means choosing adaptable tools and, when data lifespan is longer than tool life expectancy, portable data. For a serious Tool complexity and learning curve don’t bother me, but complexity shortens already too short software lifespans and and usually binds a Tool to a single platform (web typically). So I reluctantly favor simplicity - just enough functionality to do what I need. (I despise the current fashion for early delivery of barely working products, but that’s another story.)

These past few days I’ve been choosing my go-forward task and project management tool. Over the past few years I’ve used a mixture of Google/Outlook Calendars (don't underestimate the power of the Calendar), Appigo ToDo.app for iOS with sync to Toodledo for web access and data freedom, and RallyDev’s “Rally” Agile project/task management software.

I could write a book on the RallyAgile (which is Agile shaped by Rally) and the twisted evolution of that tortured product. It is hard to watch software adolescence — the drinking, the reckless driving, the law breakin … then, if one is lucky, the emergence of a somewhat broken product that may do some good in the world.

Suffice to say there are things I liked about the way I adapted RallyAgile, such as Features that are completed in 3-10 weeks of work, Feature-Stories that map to 1-10 days of work, and Feature-Story-Tasks that map to 1-6 hours of work. I sized “Stories” [1] by “Points” where a “Point” is 5 hours of work [2], and where a Story could be any one of 1, 3, 5, 8, 13, 20 Points [3]. I liked two week iterations [4] as a practical planning unit - a period where each task was (tentatively) assigned Calendar blocks and where one could focus on getting Stories complete rather than constantly replanning. I liked having protected time for planning a “Release” (set of Features basically) and for planning an “Iteration” (2-3 week collection of Stories), time to review and improve process, and time to look ahead and reassess “Features” and “Release”.

Today I’ve made my first pass at a set of Tools (and, yes, practices) that will give me the functionality I want within the constraints [5] of time, budget, familiarity, platform (Mac/web) and the requirements of longevity. In bullet form, here’s my list:

  • Google Calendar: Well, I’m certainly not going to use anything Apple owns [6], and Outlook is owned by ZombieSoft. So pretty much narrows that down.
  • Appigo ToDo and ToDo Cloud: I never seriously considered Rally. Omni products are too platform specific and I fear lifespan. My use of Toodledo was a path-dependency accident of history, and now that Appigo has fixed task-creation-by-email I can switch fully. Primary downside is data lock [7]. My next option would have been Trello, but there’s no native Mac client, I don’t need distributed team support, it’s complex, the nomenclature is odd, etc. [8]
Here’s how I map “Agile” style of “getting things done” [9] to Appigo ToDo
  • Tasks -> Tasks. (Tasks are are tied to projects may get Stars, not sure if I need to do that)
  • Stories -> Projects
  • Features -> List Name (Contexts and Tags will take on some of the things I use List Names for).
I think I’ll put “hours” and “points” into the Titles of Tasks and Stories.
 
The relation of “Features” to bigger Goals/Initiatives/etc I plan to map out in MindNode.app, but that’s another post.

Tasks associated with “Stories” get slots on the Calendar. I will still use Appigo ToDo for tasks unrelated to “Features”/“Projects”, those have the usual ABC priority (simplified from old Franklin/GTD priorities) which work like this:

  • A/High: Get Due Date and time on calendar
  • B/Medium: May get a due date, may have calendar time
  • C/Low: No due date, no calendar
I’ll update this post in future as I fill in the rough spots.

- fn -

[1] Without going into details on my own twisted adaptation of Agile, I dislike the word “Story” and all of it’s subject-action baggage. I use “Story” to mean a testable unit of work that is composed of tasks, is measured in “points” where a “point” is 5 hours of real work, and may be part of a “Feature” (which is, etc).

[2] Ok, one more detail. The mysticism about the meaning of a “Story” "Point” also annoys.

[3] Fibonacci more or less, where as Points go up so does uncertainty. I was the best Estimator I know of — I’d do my initial Story estimates, decompose to Tasks and assign hours to tasks, sum the hours and divide by 5, then round up to next Fibonacci number (so 11 hours is 3 points). When I did Task estimates I assumed an average rather than ideal path, and adjusted for dependencies — esp. on unreliable corporate infrastructure.

[4] In practice this was too much planning overhead with distributed teams; 3 weeks is better in that case. I like 2 weeks for local teams. I could write another book on doing corporate software development with distributed teams.

[5] Ahh, Constraints. So important to choice, thus project planning. Could write a book about those too :-). Constraints are my friend, a relative of Requirements I suppose.

[6] Has any company ever killed more data, data formats, products and platforms? Apple is a charming TV sociopath serial-killer of a company.

[7] App.net.@clarkgoble tells me there’s a SQLite database and Todo Cloud data is CalDAV and theoretically extractable, though I suspect much would be lost. There’s also the back door of switching back to Toodledo and their export features, but that’s a cheat. I wish Toodledo had implemented full-text search, but I understand my task volume and complexity is not their market.

[8] I’m keeping on eye on Trello. Familiarity and time were constraints too.

[9] Yeah, GTD and all kinds of old Franklin stuff on goals, etc all fit in here, but that’s yet another book.

[10] In writing this post I reviewed past blog posts. It wasn’t too hard to switch from Franklin Planner paper to the PalmOS in the 90s, but the 00s switch from PalmOS productivity Tools to early iOS was brutal. Awful. Horrible. MobileMe… argggggghhh. It went on for years, no thanks to Apple [6] but sincere thanks to pre-Evil Google. The pain of that switch is one reason I’m reluctant to commit to anything novel - like Trello.

See also

Sunday, July 05, 2015

Why don't we have better medical textbook descriptions of disease?

I have a problem with the way medicine describes diseases. It’s not a new problem - it’s bugged me since about my third year of medical school - 1985 that is. I don’t think things have changed much.

To describe my problem, I’ll invent a disease “Y”.  Y has 3 findings - flat feet, pimples, and bad breath. Each occurs in 1/3 of the people suffering from Y.

What’s the probability that someone has flat feet and pimples given that they have Y?

No, it’s not 1/9.

I never said these were independent findings, and I never said they persist. Y starts with flat feet, then is asymptomatic, then patients develop bad breath and pimples. Yvians never have both flat feet and pimples at the same time. The old multiplication rule only works for independent events.

Ok, so you saw this one coming. Obvious, isn’t it? Well, yes, but most textbooks describe diseases as though they were collections of independent events without correlation or sequence or evolution or treatment effects. They provide long lists of symptoms, some of which rarely or ever coexist, followed by lists of findings, tests and so on. They very rarely, almost never, describe the long term sequelae of common acute conditions. (Often that’s because nobody has researched the “natural history” of the disorder. So the section would have to read “we have no idea” most of the time. That would be a start though.)

At the end of reading a classic textbook disease description you might be able to pass your Board exam, but you really have very little idea what the disease looks like, much less how it’s experienced by the patient. Sure, you learn that stuff after 5-10 years of patient care — but, really, that’s nuts.

Another way to learn this is to experience disease first hand - especially if you’re a 50+ physician. My own (one time) 1-2 day episode of vertigo didn’t match the textbook description of acute labyrinthitis or benign positional vertigo — it had features of both. It also left me with a subtle and persistent degradation of my balance - that doesn’t show up in textbooks either. Every 50+ physician can probably tell a similar story - our textbook descriptions of disease are misleading, incomplete, and frustrating.

I don’t think it was always this way. I have a 1930 edition of William Osler’s ‘The Principles and Practice of Medicine’ on my desk, what that book called “symptoms” was more the course of a disease. I wonder if the 19th century editions were even more case based.

We could fix this, but I never see anyone talking about it. We’d have to first admit we had a problem.

The American Heart Associations "911" heart attack campaign is not evidence based

My friend Jim Levin died a couple of years ago; he had an MI running for a plane. Shortly after his death I visited the American Hearth Association's warning signs of a “heart attack”. I wasn’t impressed. What active 55yo doesn’t have chest discomfort 20 minutes into a killer CrossFit workout? Short of breath? Yeah, a bit.

So I made my own list, based on nothing but my native ignorance ...

  • If these things occur together it's more likely to be heart disease. So shortness of breath AND "cold sweat" [2] AND jaw discomfort all together means more than one of them by itself.
  • It's one thing to feel short of breath when you're a healthy person running a 5 mile race, another if you are short of breath doing stuff that is normally easy (like watching TV).
  • If symptoms like "arm discomfort" and " nausea" come on with exercise and get better with rest -- that's ominous. (Exercise means the heart needs more oxygen, so it can expose an underlying problem.)
  • If your parents died of heart disease in their 40s and your LDL cholesterol is 250 and you smoke and you're male ... Ok. You get the point. Most of us have some heart disease by age 50, but some people have a lot. Weird pains at rest may not mean too much in a low risk 30 yo woman but in a "high risk" person they might be bad news.

Today I again thought of the AHA’s non-specific warning sign list. I thought maybe things had improved, so I went looking for a publication that describes the predictive value, or even sensitivity and specificity, of the AHA’s heart attack classification criteria. After all, we communicate the AHA list to hundreds of millions of people. There’s gotta be some science behind it … right ...

I found two interesting references, one predating my 2013 blog post

The 2014 study was limited to patients who were actually in the ED. The 2008 study was broader and concluded: "there were almost no included studies that investigated the diagnostic accuracy of combinations of signs and symptoms …it was not possible to define an important role for signs and symptoms in the diagnosis of acute myocardial infarction or acute coronary syndrome”.

Dear AHA — this is ridiculous. I suspect if everyone took your 911 signs seriously ERs would be overwhelmed with “rule out MI”. You need to come up with an evidence-based symptom list.

Friday, July 03, 2015

Perspective - 20 year family reunion probabilities

For at least two good reasons I’ve been doing a bit of planning. More on those reasons later, but first a digression to answer a relevant question.

What is the probability that, estrangement aside, our nuclear family will be able to do a reunion in 20 years? Let’s assume for simplicity’s sake, no major disruption of civilization and no major changes in US mortality rates by age. I’ll also exclude Kateva, who is healthy at age 10 but unlikely to break canine longevity records.

It’s not hard to do the rough calculations, unadjusted for gender, wealth, education or health, using a basic Life table. I'm looking for 

tPx: probability someone aged x will survive for t more years.

and the formula based on a Life Table is:

Lx+t/Lx where Lx is the number surviving to age x

Lx can be found in the US 2010 Life Table. (Excel version can be downloaded from: ftp://ftp.cdc.gov/pub/Health_Statistics/NCHS/Publications/NVSR/63_07/Table01.xlsx)

For my family the relevant values are:

Living

Which gives survival probabilities for 20 years beyond current age as:

Screen Shot 2015 07 03 at 2 05 26 PM

Where Product All is the product of each more-or-less independent probability. That is only about 50%, which is not so great. On the other hand, in the event of the cosmic calamity of my demise, I won't have much skin in the game. So the interesting number is the probability that Emily and kids make it assuming I do, which is Product “Impt” (important). That’s 71%.

Which is a useful number for my planning purposes and that future post I promised.

PS. I can remember when 20 years felt like a long time. It’s not.

Thursday, July 02, 2015

Apple TV's PBS station has great shows, but an awful user experience

Anthro prof John Hawks, one of my favorite bloggers, is hosting a sure-to-be-good PBS series called First Peoples. You can stream the (ugh) Flash (ugh) version … too bad it’s not on Apple TV….

Except … it is. It’s just bloody hard to find. The PBS Channel Search menu searches only “Videos”, not “Shows”. To find Shows you have to scroll around … and around … and around… the “Shows” screen. Good luck with that. Once you find a show you can add it to Favorites.

I don’t know if this is something PBS can fix or if it’s some sort of Apple malfunction, but … wow … needs a fix. At the least Search needs to include Shows.

Automating medical error: misadventures in medication reconciliation

I recently enjoyed a nasal surgery procedure. More on that in a later post, this one is about a medical error that followed the surgery. It’s a kind of error that fits my professional work in clinical computing (“medical informatics”).

The error, actually multiple errors, showed up in a part of my computer generated post-operative discharge summary labeled “CONTINUE taking these medications”. In the clinical computing industry this is the “medication reconciliation” or “medrec” section…

AHRQ Patient Safety Network - Medication Reconciliation

Patients often receive new medications or have changes made to their existing medications at times of transitions in care—upon hospital admission, transfer from one unit to another during hospitalization, or discharge from the hospital to home or another facility. Although most of these changes are intentional, unintended changes occur frequently for a variety of reasons. For example, hospital-based clinicians might not be able to easily access patients' complete pre-admission medication lists, or may be unaware of recent medication changes. As a result, the new medication regimen prescribed at the time of discharge may inadvertently omit needed medications, unnecessarily duplicate existing therapies, or contain incorrect dosages. These discrepancies place patients at risk for adverse drug events (ADEs), which have been shown to be one of the most common types of adverse events after hospital discharge. Medication reconciliation refers to the process of avoiding such inadvertent inconsistencies across transitions in care by reviewing the patient's complete medication regimen at the time of admission, transfer, and discharge and comparing it with the regimen being considered for the new setting of care.

Most of the electronic health record (EHR) industry more-or-less automated medrec in the 00s. Typically a physician (usually this is a physician task) reviews a list of “existing” (tricky term!) medications as well as “new” meds and, in theory, produces a reconciled list that  fits the patient’s current sate.

That’s the theory; in practice the “existing” medication list is often incorrect.  Additionally, it’s usually quite easy to, with a click or two, replicate the “existing” medication list without the tedious work of actually reviewing it.

Both errors, and more, showed up in the “continue” list I was given for:

  • Afrin 2 sprays 2 times a day
  • Flonase 50 mcg/actuation
  • fluticasone 50mcg 1 spray into each nostril daily
  • azelastine 137 mcg 2 sprays into each nostril two times a day.
Let’s count the errors:
  • None of these meds are appropriate for my post-op fully obstructed nose. The Afrin and steroid sprays are theoretically harmful, but in practice none of them would go anywhere anyway. So that’s 3-4 errors depending on how one treats Flonase/fluticasone. These is most likely either physician inattention or a process error.
  • Flonase and fluticasone are Brand and Unbranded names for the same medication. This is a software error or a data entry/design error (accepting free text meds rather than “coded" meds).
  • The Afrin dose and frequency is incorrect, it would be dangerous to use it so often. This is likely a physician error. (I actually corrected this during an office visit, but my correction was evidently ignored.)
  • The list omits QNasl. This almost certainly an error in compiling the “existing medication” list, but like all the others it shouldn’t have been on the list post-of. I’ll count this as an error anyway.
So in one medication reconciliation process we have 7 errors, 1 which is probably software (Flonase/fluticasone resolution) and 6 which are physician/process errors likely facilitated by poor software design.

In this case no harm was done. My wife and I are both physicians; we knew to ignore the errors. There might have been a small potential for harm with a non-expert patient, but in practice the nasal meds aren’t going to get far in a post-op obstructed nose. Obviously there’s potential for harm in different cases, which is why “medrec” has been a patient safety goal for the past … well … 25 years or so.

This isn’t a new problem — Emily and I both remember common medication reconciliation errors in the pen and paper era. I suspect, however, that quick-click list merges may make it faster and easier to make the same old mistakes.

It would be nice to think about what we could do differently…

Saturday, May 23, 2015

Story of our times - What happened to screen door latches?

This is the only screen door latch design sold in our local hardware stores:

 

The t-shaped metal bar in the center has two prongs that join the indoor mechanism. One first mounts the outdoor handle mechanism, then joins the bar to the indoor mechanism  and attaches it to the door. The bar slides into the outdoor mechanism collar. There’s no stop or spring in the outdoor mechanism, the bar can easily slide in and out. Only the two metal prongs at the tip hold it to the indoor mechanism.

After about 6-8 weeks of use at our home those prongs come loose, the bar slides deeper into the outdoor handle, and it is no longer possible to open the door. 

It’s a bad design. There should be a better way to attach the bar to the indoor mechanism, or there should be a spring in the outside handle.

This is different from the quality issues that afflicted toasters in 2006; the mechanisms are well made. It’s just that they’re well made to a hopelessly bad design.

I wonder if, years ago, a Chinese manufacturer incorrectly copied an older design. But why did it become universal?

I’m half-heartedly looking for a different design, but the market is probably telling us that nobody has a wooden screen door in 2015. We need to replace the door with something that will lose less heat in the winter.

Weird, and somehow characteristic of our times.

Crime and the enterprise

What do Seagrams, YouTube, Uber, Elon Musk’s PayPal, 1930’s McKesson, Jobs Rip. Mix. Burn, and Las Vegas have in common?

Many very successful enterprises have a history of unethical or criminal behavior. Sometimes there are convictions, sometimes not. The history is usually buried, sometimes it’s romanticized. Occasionally, as with Enron, the crime ends the enterprise.

I think if one wrapped the average CEO with Wonder Woman’s Lasso of Truth they’d confess to lesser versions of the kinds of sins that put Bernard Madoff in jail.

We don’t pay enough attention to this.

Fixing the iPad: Family share and iBooks

It’s a geek consensus - the iPad is on its last legs. Mostly this is because it’s nuts to have both a single-user iPhone 6 and a single-user iPad. You gotta be both top 2% for assets and have time to burn. Everyone else will do with either an iPhone 6 or 6+ (or Android equivalents).

There are obvious future fixes. One is for Apple to sell an iPhoneMini, based on tech developed for the failing aWatch [1], and a complementary iPad. That complementary iPad would work standalone, but it would also seamlessly switch between iCloud/iPhone user profiles — so a family of four iPhones might start with one iPad but move up to three (see also). [2]

There’s something else that’s gotten lost though — and I want to call this out. eBook adoption has stalled. That includes eTexbook adoption — my daughter’s school backpack is still 25 lbs. The iPad has dramatically failed to delivery on reading device expectations.

That’s big — because reading is what the iPad does best. Chromebooks have clobbered iPads in the classroom because, without the reading advantage, Chromebooks win on cost, durability, ease of management, lack of theft appeal, and suitability to traditional educational models. Video? Easier to watch up close on a lighter phablet, or rest your arms and use an AppleTV.

So it’s not enough to fix the iPad’s standalone single-user device model. Apple has to make the iPad a first class reading device. Google owns the K12 market now, but there’s still an opening in the post-secondary textbook market. More importantly, there’s the global market for books and magazines.

For that market, Apple needs to rethink its DRM approach. Sure, keep FairPlay proprietary for video — but use something else for books. Something that’s owned by an independent standards body and licenses for free along with a cross-platform authoring tool. Or, more radically, start paying authors up front for non-exclusive book distribution and then publish without DRM.

Be creative Apple. The iPad is too good an idea to die quietly.

[1] There’s an emerging consensus that aWatch 1.0 has failed. I expected it to fail in the US, but we need to see what happens in China. There’s a lot of room for improvement beyond 1.0 though: "A waterproof $150 iOS 8 Nano-clip replacement in Sept 2015 will be interesting. Splitting the cellular phone into multiple components, for which iPad and Apple Watch are interaction elements will be interesting. Standalone Apple Watch 4 running on next-generation LTE will be interesting.”

[2] Apple’s FairPlay Family Sharing, iCloud enhancements, and iOS 8 handoff do point in this direction.

Reorganizations - did Petronius Arbiter really say that in AD 27? No.

John Halamka is unhappy with the direction of federal health computing initiatives. He’s not alone, just about everyone outside of Madison Wisconsin is unhappy. My prescription would differ from John’s, and maybe I’ll write about that one day, but that’s not what this post is about.

This post is about a quote he references:

As Petronius Arbiter said in 27 A.D., we have to avoid change purely for the sake of change as this creates frustration

“We trained hard—but it seemed that every time we were beginning to form up into teams we were reorganized. I was to learn later in life that we tend to meet any new situation by reorganizing, and what a wonderful method it can be for creating the illusion of progress while actually producing confusion, inefficiency, and demoralization.”

On the one hand, this is perfect. I speak, of course, from experience. I’ve lived through reorg death spirals — when the reorg interval falls below 12 months the end is quite near.

On the other hand, it’s too perfect. It turns out we know very little about Gaius Petronius Arbiter except that he hung out with Nero. Even allowing for the slanderous and largely fictional descriptions of the Roman emperors, he was probably no pillar of virtue. This doesn’t really feel like something a Nero flunky would say.

Turns out, it’s a misattribution. The original was by Charlton Ogburn (1911–1998) in “Merrill’s Marauders: The truth about an incredible adventure” in the January 1957 issue of Harper’s Magazine …

We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganized. Presumably the plans for our employment were being changed. I was to learn later in life that, perhaps because we are so good at organizing, we tend as a nation to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency and demoralization."

Ogburn’s article isn’t freely available, but you can read about Merrill’s Marauders: "a United States Army long range penetration special operations jungle warfare unit, which fought in the South-East Asian theatre of World War II, or China-Burma-India Theater (CBI). The unit became famous for its deep-penetration missions behind Japanese lines, often engaging Japanese forces superior in number.” They had a blood and brutal story. I have no idea how that connects to Ogburn’s observation on reorgs. Anyone know?

Wednesday, May 20, 2015

Medical research is hard - two NYT articles on Losartan for Marfan syndrome.

In 2013 the NYT’s Gina Kolata was optimistic about using Losartan, an angiotensin II receptor blocker (ARB), to treat Marfan’s syndrome …

… He sought a way to block the function of T.G.F.-beta and found a widely used blood pressure drug, losartan, that did just that.

In the mice, the drug prevented features of the syndrome, including ballooning of the aorta. Instead of dying of aortic aneurysms by three months of age, the mice lived a normal life span of two years…

… The Specks enrolled Daniel, and suspect he got losartan. His mother said the family saw “wonderful changes — everything started to stabilize.” Daniel’s aorta had been “growing astronomically,” she said, and that growth slowed so much that he would not qualify if he tried to enter the trial today. He also developed better muscle tone and more body fat.

When his time in the trial ended, the Specks were told Daniel could take losartan or the older drug, whichever they preferred. Ms. Speck did not want to take any chances. They chose both…

The human trial wasn’t finished at the time of publication but everyone was optimistic.

A year later Ms. Kolata wrote a followup article…

Heart Drug, Losartan, Falls Short of Promise in a Study - NYTimes.com

The idea seemed compelling: A blood pressure drug was found to block the effects of a gene mutation that causes Marfan syndrome, a condition that leads to terrible heart problems. The drug worked in mice with a gene that causes Marfan, doing just what everyone hoped it would do. A pilot study with 17 children showed the drug seemed to work in them, too, although there was no group that, for comparison, did not get the drug.

Now the more objective human evidence is in — results from a large clinical trial testing the experimental drug against the standard treatment. There was no difference in outcomes

The standard treatment is a beta blocker - atenolol. It’s thought both drugs work better than placebo, so losartan isn’t necessarily ineffective, it just doesn’t seem to work as well in humans as it does in genetically modified mice.

Medical research is hard.

PS. I found the 2013 Losartan ref in my Pinboard share stream, specifically, in an accidentally untagged portion the stream I was reviewing. Seeing it I wondered if there was a followup article….

 

Wednesday, May 13, 2015

Paul Theroux's 1976 visit to Santa Ana, El Salvador - repeat on 2015 Google Street View

Paul Theroux’s The Old Patagonian Express was published in 1979. Today it’s as much historical document as travel guide. Part of that history is experiencing the semi-conscious neocolonial attitudes of 1970s Theroux, though that’s probably his personality as much as the times.

There’s a lot he disdains, but he liked Santa Ana El Salvador. At one point he claims it wasn’t on his map; for him it was a pleasant surprise.

Today you can retrace his journey with very limited version of Google Street View. You can’t navigate in the usual Street View way, but you can visit the primary plaza and you can browse user contributed images.

I wonder how long it will be for Santa Ana to go full Street View. On the one hand it’s amazing what’s there now, but it’s noteworthy that Santa Ana is still a bit mysterious.

How to (properly) use a nasal spray

It’s spring in Minnesota, so a new allergy season. Many of us are restarting our nasal sprays - often Flonase, which just went ‘over-the-counter’. Many of us are also doing it wrong.

I know I have, and I know most physicians don’t describe proper use. Mostly because most physicians don’t know there’s a right and wrong way. I recently interrogated an allergist (they do know this stuff) and here’s what I learned:

  • Don’t snort it. Breathe normally or don’t breath.
  • Don’t jam the nozzle up the schnozzle (sorry). Just a few mm in.
  • Aim away from the septum — there’s nothing there to spray, it runs out, and it can hurt the thin mucosa there. Aim towards eye on same side of nostril.
  • If you cross-over, use right hand to spray left side and vice-versa, you get right position.
  • Don’t mix sprays or mix with nasal irrigation. Volume effect — one spray solution washes out another. Recommendation is to space 1 hour apart. (Which is a pain. I wonder how real this is, but that’s the party line.)

Now you know. Go forth and sin no more.

Monday, May 11, 2015

A data lock free local file format for a concept map or mind map application

It occurred to me, probably not for the first time, that there’s a natural local file store data lock free ‘file format’ for a concept map or mind map application.

Treat each node as a file system directory (folder) and make the node name the name of the folder. Treat hierarchical relationships between nodes as container relationships in the file system. Represent other arcs as hard links (unix) or soft links/shortcuts/alias contained with a folder. (Would be good to be able to distinguish Aliases that represent relationships between nodes from Aliases to system files that are properties of the node, such as an nvAlt/Simplenote text file.)

Treat other contents of a folder as properties of the node, such as notes (plain text, RTF, etc). 

And so on.

That’s the file “format”, the UI can be any variant of current Mindmap/concept map. User interactions turn into file system calls.

I’m sure someone has done this somewhere. Anyone know of a reference?