Category Archives: Fodder for Techno-weenies

An Experiment with SSE

Posted on February 4, 2012 by Jeff Mather

Updated: 6 February 2012.

Techie people, the good stuff—code, results, more info—is below the fold.


Friends, I’ve been in my head a bit recently. That’s not necessarily bad—it’s a nice neighborhood, really—but one of the dark alleys I’ve had to walk past a lot lately involves way too many imposter-type feelings. As I previously mentioned, we’re hiring, and we’re looking for someone to do many of the same job tasks that I do. Being mostly self-taught at software engineering and computer science, I have to remind myself that I have more than a dozen years of experience; whereas, for most of the people whose résumés cross my desk, they do not.

It’s sometimes hard to silence those voices that say “everyone else is more accomplished than you.” Even though it’s not true, I’ve been meaning to pick up some more skills so that I can (a) try to feel like less of an imposter and (b) write more awesome code to make our product more awesome and help us fend off our competitors and make more loot.

So yesterday afternoon, rather than coming up with (yet another) daunting list of all of the places where I feel like I should learn more, I just picked one that I already knew about: Streaming SIMD Extensions, a.k.a. SSE. For me, the best way to learn is to write a program that does something (theoretically) useful, run into real-life obstacles, and workaround the pitfalls I encountered. Practice, practice, practice.


My dear readers who don’t program, you can now safely navigate away for another day without guilt. The rest of the post is rather technical and describes how I took an example I found online, made it work with gcc, and got a 4x speedup by using SSE. A speedup and happier outlook. Not bad for a few hours on a Saturday!

Continue reading →

Posted in Computing, Fodder for Techno-weenies, General | Leave a comment

Welcome to Herb Sutter’s Jungle

Posted on January 30, 2012 by Jeff Mather

In an effort to keep posting something here until I’m in the right place mentally to write about things that probably interest you, my dear friends, family, and online diabetes peeps, here’s another computing performance excerpt and link. (Working on this stuff is the 9-5 part of your favorite international playboy’s life.)


A half-decade after Herb Sutter wrote that the “free lunch” of Moore’s Law is over, he’s back with his prophet’s wisdom about where we’re going in his January Dr. Dobbs article, “Welcome to the Jungle”. I’ll give you a moment to decide whether to get the Guns N’ Roses song out of your head or use it as a backdrop for this juicy quotation:

If hardware designers merely use Moore’s Law to deliver more big fat cores, on-device hardware parallelism will stay in double digits for the next decade, which is very roughly when Moore’s Law is due to sputter, give or take about a half decade. If hardware follows Niagara’s and MIC’s lead to go back to simpler cores, we’ll see a one-time jump and then stay in triple digits. If we all learn to leverage GPUs, we already have 1,500-way parallelism in modern graphics cards (I’ll say “cores” for convenience, though that word means something a little different on GPUs) and likely reach five digits in the decade timeframe.

But all of that is eclipsed by the scalability of the cloud, whose growth line is already steeper than Moore’s Law because we’re better at quickly deploying and using cost-effective networked machines than we’ve been at quickly jam-packing and harnessing cost-effective transistors. It’s hard to get data on the current largest cloud deployments because many projects are private, but the largest documented public cloud apps (which don’t use GPUs) are already harnessing over 30,000 cores for a single computation. I wouldn’t be surprised if some projects are exceeding 100,000 cores today. And that’s general-purpose cores; if you add GPU-capable nodes to the mix, add two more zeroes.

The big takeaway for software engineers like me is that we’d best be learning how to develop solutions using the emerging APIs so that we can harness all of those extra orders of magnitude of scalability. That involves figuring out how to . . .

  • Deal with the processor axis’ lower section [of Sutter's chart] by supporting compute cores with different performance (big/fast, slow/small).
  • Deal with the processor axis’ upper section by supporting language subsets, to allow for cores with different capabilities including that not all fully support mainstream language features.
  • Deal with the memory axis for computation, by providing distributed algorithms that can scale not just locally but also across a compute cloud.
  • Deal with the memory axis for data, by providing distributed data containers, which can be spread across many nodes.
  • Enable a unified programming model that can handle the entire [memory/locality/processor] chart with the same source code.

Perhaps our most difficult mental adjustment, however, will be to learn to think of the cloud as part of the mainstream machine — to view all these local and non-local cores as being equally part of the target machine that executes our application, where the network is just another bus that connects us to more cores. That is, in a few years we will write code for mainstream machines assuming that they have million-way parallelism, of which only thousand-way parallelism is guaranteed to always be available (when out of WiFi range). . . .

If you haven’t done so already, now is the time to take a hard look at the design of your applications, determine what existing features — or better still, what potential and currently unimaginable demanding new features — are CPU-sensitive now or are likely to become so soon, and identify how those places could benefit from local and distributed parallelism. Now is also the time for you and your team to grok the requirements, pitfalls, styles, and idioms of hetero-parallel (e.g., GPGPU) and cloud programming (e.g., Amazon Web Services, Microsoft Azure, Google App Engine).


p.s. — I can’t believe that it’s been almost four years since I took a course with Herb out in Washington. That was some hard-core learnin’.

Posted in Computing, Fodder for Techno-weenies, Software Engineering | Leave a comment

We Need a New Mindset

Posted on January 27, 2012 by Jeff Mather

Guy Steele drops a truth bomb.

(From How to Think about Parallel Programming: Not!)

Posted in Computing, Fodder for Techno-weenies, Software Engineering | Leave a comment

Thinking Differently about Software Optimization

Posted on January 26, 2012 by Jeff Mather

Yesterday morning while eating my “Free Wednesday Breakfast” chocolate croissant and fresh fruit with yoghurt, I watched an interview with John Nolan entitled “The State of Hardware Acceleration with GPUs/FPGAs, Parallel Algorithm Design.” In the spirit of giving back, I’m posting a few notes.

  • When optimizing code for GPU, FPGA, or CPU, definitely focus on pipelining and overall throughput, not just local optimizations.
  • There’s a trade-off between “faster” and “sooner.” It’s not always worth saving a few seconds (or even a few minutes) if the kernels take hours or days to compile. (Then again, sometimes it is.)
  • Try to reduce dependence on the language/compiler “stack” that removes inefficiencies. The optimizer does good work, but you can do things to help it. Think about the hardware or architecture format. It’s not a sin to reduce the amount of abstraction in the service of performance. Pay attention to things that affect processor pipelining and cache movement.
  • BTW, some languages and technologies exist to provide higher level programming that’s close to the hardware, but they’re proprietary, secret, or still in R&D.
  • Use algorithmic optimization techniques. Step back and find the shortest-time computation.
  • Avoid using if statements. The goto construct is considered harmful, but if is basically the same thing. Instead think about state machines and polymorphism. There’s no branch-prediction penalty to pay, since the system “just is” in the state it’s supposed to be in. The logic is clearer, because there are no switches, making it easier to test, too.
  • Don’t always assume that floating-point values are necessary. Integers can often be creatively used and are far faster for math than double-precision numbers.
  • Of course, there’s a compromise between speedy/efficient and readable/maintainable.
  • Aim to structure programs as “symbolic intent.” Mathematical descriptions are bad ways of expressing programs. Think about functional programming models instead of procedural.

If you want to know more, you should definitely watch the half-hour interview. And if your reaction was more along the lines of “Yes, yes; that’s all true, and it’s how I design my image processing code,” then I definitely hope you’ll consider applying for the GPU/multicore engineering position we have open.

Posted in Computing, Fodder for Techno-weenies, From the Yellow Notepad, Software Engineering | Leave a comment

QCon SF 2011 Software Engineering Conference Notes

Posted on December 29, 2011 by Jeff Mather

It’s sometimes possible to forget when reading all of the posts here about travel, diabetes, triathlon, and photography that they’re just a small part of my life. I have a job to which I devote a whole lot more time. I don’t talk about it much because (a) discussing what I’m working on putting into the Image Processing Toolbox isn’t appropriate or allowed, and even if it were (b) talking shop probably isn’t that interesting to most of the people here. But—believe it or not—the majority of traffic to my site lands on the pages that are technical, so I don’t feel so bad about posting the random “fodder for techno-weenies” post. (It’s a term of endearment, I promise! :^)

This is another one of those posts. Every year between Christmas and New Years Day, I try to use the quiet week to get stuff done and tie up loose ends. Last year, I cleared out a bunch of notes. This year, I’m looking at presentations and slides from the QCon SF 2011 conference (wrap-up). Its focus on software architecture and project management is about 75% of my job, so many of the presentations seemed tailor-made for me. Here’s some of what I learned.


Erik Doernenburg. “Software Quality: You Know It When You See It” has a really good slide deck that got me thinking about some projects I might want to set up. It’s full of practical, usable suggestions:

  • View the code at the 1,000 view, rather than ground-level or 30,000 feet.
  • Look at the test-to-code ratio, not just code coverage.
  • Graph the change of metrics between versions and revisions, compare across different parts of the code, and look at them relative to industry standards.
  • Measure the “toxicity” of code by rolling up various quality metrics about a bunch of modules into stacked bar charts.

We should pose these questions during design and code reviews:

  • Is the software/change of value to its users?
  • How appropriate is the design?
  • How easy is the code/design to understand and extend?
  • How maintainable is the software?

It was full of some really great links to things like Metrics tree maps (a.k.a., pretty heatmaps for source code) as well as a few tools: SourceMonitor, iPlasma, and using Moose to visualize quality.


Joshua Kerievsky. “Refactoring to Patterns” — some notes:

  • Refactoring is like algebra’s equivalence-preserving manipulations. “Design patterns are the word problems of the programming world; refactoring is its algebra.”
  • Understanding the refactoring thought process is more important than remembering individual techniques or tool support.
  • Code smells have multiple refactoring options and often benefit from composite refactorings.
  • Look for automatable refactorings first. Consider changing the client of smelly code before the smelly code itself.


Guilherme Silveira. “How To Stop Writing Next Year’s Unsustainable Piece Of Code” was pithy and thought-provoking.

  • There is no value for architecture or design without implementation. That’s just interpretation of the software.
  • “New language. New mindset. new idiomatic usage. Same mistakes.”
  • Complexity and composition are natural and good, but if they’re invisible, they’re evil.
  • Start with a mess and refactor right away. Starting “right” is hard (and misguided thinking). Refactor for better, not just prettier.
  • Make complexity easier to understand and see.
  • Hiding complexity in concision hurts testability, since no one knows the complexity is there. Furthermore, if it’s hard to test, it’s also hard to use correctly.
  • “Model rules. Do not model models.”


Michael Feathers. “Software Naturalism: Embracing The Real Behind The Ideal” is a presentation that I would like to see/hear, since the slides seemed full of information but weren’t self-explanatory. Here are two things I could glean: 80% of software defects in large projects were in 20% of the files. In general, the more churn in a file, the more complex it tends to be.


Panel: “Objects on Trial” was perhaps the most unusual presentation, since it was a mock-trial. I use objects all the time . . . some of them are good . . . some demonstrably so. Even so, I never latched onto the idea of object-oriented (OO) design versus objects as types. The four panelists, in one way or another, basically said, “That’s the problem.”

One of the panelists drew an extended analogy between the space program and OO. The space shuttle (which we all love) was fixated on reuse but basically was a waste of heavy lifting; people don’t reuse the right stuff. In software, object reuse is largely accomplished by cut-and-paste copying of boilerplate code that does close to what you want. Of course, the panelist acknowledged that we do reuse the ideas in OO via design patterns, and no one seems to have much of a problem with that. Ironically, having a rich pattern language means that software engineers are in a better place than ever before to use objects correctly.

A key problem with our approach to objects is that we’ve failed (generally in software engineering) to handle complexity well, which was supposed to be the point of OO design. A conflation of beauty and OO design makes things worse. Internally, software is ugly, and beauty shouldn’t be a goal. Making a fetish of beauty makes code inflexible because people don’t want to extend the beautiful thing that works.

For other panelists, objects weren’t the problem at all. For them it’s static typing in “OO languages,” such as C++, Java, and C#. We’re at a place now where all of the good things about OO have been lost in an attempt to make OO languages as fast as C. This runs counter to the goal of having “ordinary,” understandable code. Generic programming using strongly typed (possibly template heavy) languages just makes everything complicated.

For me, it’s moot. C++ is what I use, and I don’t have a large proprietary object system that I can tap into for reuse. I’m in the camp that uses C++ objects to generate new types for data hiding and aggregation, as well as (to a lesser extent) reuse. But some of these types are generic, template classes that are hard to understand. I plead “no contest.”

Posted in Computing, Fodder for Techno-weenies, From the Yellow Notepad, Software Engineering | Leave a comment

Heart Rate Training?

Posted on November 29, 2011 by Jeff Mather

How do you get faster at any endurance activity? Ironically, you get faster by doing it faster than usual. If you run every run at one pace or do every ride at the same tempo, then you’ll never progress. You can only build up so much aerobic capacity, since you can only move so much blood and oxygen around. What you need to do is to work harder so that the muscles themselves are stronger and capable of giving more.

My running plan includes plenty of tempo running and interval sessions. And I’ve finally gotten to the point where there’s “normal swimming” and “harder swimming.” But how do I know how hard to work when cycling?

I think the answer is heart rate training, which is new to me. Have any of you had success doing this?

I’ve figured out several of the basic calculations based on my computed maximum heart rate (183 bpm) and resting heart rate (52 bpm). According to an online calculator, these are my target heart rate zones:

Zone 1: 118-131
Zone 2: 131-144
Zone 3: 144-157 (Aerobic)
Zone 4: 157-170 (Anaerobic)
Zone 5: 170-183 (Maximal)

Now, where do I go from here?

Posted in Cycling, Data-betes, Fodder for Techno-weenies, NaBloPoMo, NaBloPoMo 2011 | Leave a comment

Just Give Me the Dorky Helmet and I Will Be “That Guy”

Posted on November 22, 2011 by Jeff Mather

In order not to bury the lede, I’m going to start with the big news: I put down a deposit on a new bike today, which I will pick up (hopefully) on Monday after a final fitting session. Here it is:


You should know a few things about my decision to get this bike:

  1. I have been saving money to buy a new bike at some point in the future ever since I bought my last bike in 2009.
  2. I hadn’t expected to buy a tri-bike after just one season.
  3. Lisa suggested, out of the blue, that I should get one. Merry Christmas from my sweetie (and my slush fund)!
  4. I’m deeply, deeply ambivalent about this bike for so many reasons.

A couple of my coworkers and I joke that “triathlon is a rich white person’s sport.” And while I’ve seen people riding all sorts of bikes and wearing all manner of kit during various triathlons, the joke is uncomfortably close to the truth. Even though swimmers can wear just about anything (although a wetsuit will give you some advantage) and running is running is running regardless of your income level, anything involving a bike—including triathlon—is going to start to seem like thoroughbred horse racing. Cycling is where all of the money is spent, often for diminishing returns

“$2,000 for an aero wheelset to save a couple of minutes over 112 miles? $500 to save 30 grams by switching pedals? Yes, those are just what I need to get me to Kona.” Um, right. It would be like most of us thinking we can buy our way to a Boston Qualifying time by getting better shoes. I’m not saying the advantages aren’t real or that people shouldn’t be able to spend their money in whatever race-legal way they want. It just seems that common sense goes out the window whenever our reptilian brains see anything associated with two wheels.

So how did I end up standing around in my bike shorts and jersey this afternoon at Landry’s bike store waiting to get fit for a super-aero time trial/triathlon bike? Believe me, I’ve been asking myself that question and second-guessing myself and looking deep inside my athlete’s soul for the answer.


I guess it’s the simple fact that tri-bikes are faster than the bike I have now. Not just a little bit faster. No. A lot faster. A couple years ago I was just a guy with diabetes on a bike, but after this past year I consider myself an athlete. I feel I can be competitive in several of the races on next year’s docket, and I’d like to see how far I can go by giving my potential just a bit of help. [1]

This is the big, up-front investment. While it’s true that you never really “just buy a bike,” I don’t plan on putting much additional loot into this one right away. I hope I’m more down-to-earth than that. After all, it’s “not about the bike.” There’s a whole lot of hard work for me to do to feel like I’m living up to the potential of this bike, and that’s a big motivator.


Of course, maybe I’m just making a big deal out of nothing at all. Why don’t I just get on with telling you about the bike fit process.

When I bought my road bike (at a different store) the fitting was really simple: “Sit on the bike on a trainer while I get out my calipers and protractor and we will adjust the saddle.”

Today was nothing like that. Over the better part of an hour I was videotaped riding a highly reconfigurable “bike.” A specially trained bike shop guy reviewed the video frame by frame, measuring various angles, reconfiguring, retaping, remeasuring, repeating, . . . He used a laser level to aid in making extremely accurate measurements throughout the process.


Having recorded myself swimming, it was interesting to have this applied to another event. (Now I just need someone to film me running and to analyze my stride, in order to complete my mini-series triathlon.) Turns out I have very long arms and legs and a rather short torso—which I already knew, since most of my clothes must be tailored in order to fit right. I also have very flexible hip, knee and lower back joints, so I can get into a pretty aggressive aero position. That was unexpected.

Forty-five minutes after stripping down to my bike clothes (which I was wearing under my regular clothes [2]) I was ready to get bike recommendations. Or rather one recommendation. “Can we at least pretend like I comparison shopped?” I asked; so we played that charade quite convincingly. If I got that less expensive bike I would need to spend more money in accessories to get the same fit as the “right” bike. Or I could spend twice as much for the same fit with better components (like aero-er wheels and lighter pedals and shit like that.)

And then, the soft sell: “Do you want to take it for a ride?” Without a helmet? “We can lend you a helmet.” Outdoors in the cold? “Do you want a jacket or something? [Seriously, man, HTFU.]” I can manage without one for a few minutes.

It wasn’t the same pure joy that I had when I first pedaled my road bike. That feeling of effortlessness and the fluidity was replaced by wobbliness as I got used to the equivalent of driving a Porsche with a go-kart’s steering wheel. Because I was in a residential neighborhood, I didn’t really get the chance to open it up; nevertheless I could feel the responsiveness of this almost weightless bike.

I can hardly wait to give it a try.


1 — 2011 really was the year when I became an athlete. I competed in nine different races, and I used a couple of training plans to prepare for them. I was actually a bit haphazard in the events I chose, and I’m trying to be a little more focused next year. Of course, I’m also trying to keep a lot of the spontaneity and love for what I’m doing, which is precisely why I rebel against most triathlon training programs. “Life is choices.” [Back . . ]

2 —  I put my new office gym membership to use for the first time today over lunch so that I could change clothes. OMG, those were some chatty guys in the locker-room with me. I thought we were genetically programmed to become mute and blind in the presence of other naked men. (It’s a mutation on the Y chromosome. That’s a fact. Look it up.) This is going to take some getting used to. [Back . . ]

Posted in Cycling, Fodder for Techno-weenies, General, NaBloPoMo, NaBloPoMo 2011, Reluctant Triathlete | 3 Comments

What I Do

Posted on August 19, 2011 by Jeff Mather

If you’ve ever wondered what I do for my 9-5, it’s figure out stuff like this and this.

Posted in Computing, Fodder for Techno-weenies | Leave a comment

My Insulin Pump Hacker Name is “Glux0se”

Posted on August 10, 2011 by Jeff Mather

Victoria wrote an excellent piece on her site about what’s become known as “pumphackingate.” In it, she gives a brief recap of the facts and some of the reactions that have appeared on other blogs. Here’s an even briefer recap, in case you don’t know anything about it: Some hacker/builder dude created a device that can control some insulin pumps remotely along with gathering data from them. Based on a comment I left over on Victoria’s site, here’s my take on the issue.

First off, I’m not surprised. Like any device that transmits and receives wirelessly, the signals from pumps and CGMs are interceptable. Furthermore, like any other device that communicates with limited access control—you just need to know (or sniff out or be able to guess) the six or seven digit code that’s used to connect with another device—they’re essentially open. From there it’s all just figuring out the protocols and the format of the data as it’s passed around. As someone who spent about ten years working with and occasionally reverse-engineering formats, I can tell you, it’s all just a matter of trial and error and careful observation. (If I were a hacker, my handle would be “gluX0se.”)

So, in a world where relatively few people have these medical devices—unlike, say, mobile phones or bluetooth devices—the device manufacturers essentially did the easy thing, which was to assume we use our medical devices in a trustable world where people don’t mess with medical devices. (BTW, who knew there was a free Vulnerability Management for Dummies e-book?)

There’s been a lot of unease in the community about the way that the information was presented to the press and the way that some outlets sensationalized it (e.g., “Black Hat: Lethal Hack and wireless attack on insulin pumps to kill people”). It’s hard not to agree with a lot of the criticism there. But I can’t criticize looking for security holes in medical devices. Nor can I fault the impulse to hack into own’s own medical device—even one that keeps people alive—or to help other people hack their devices. Not all hacking is scary villainy, but this incident certainly exposes some problems.

Using the AP to share this information leaves a bad taste in my mouth, but presenting the findings at the Black Hat Conference seems like the most appropriate way to publicly disclose this research. (And it is, in my mind, legitimate personal security research that should be shared openly.) I would have preferred that Radcliffe work more closely with the device manufacturers leading up to the announcement. (I’m assuming that he did not.)

On the other hand, just presenting the findings to the device manufacturers—as some would have liked—violates the hacker ethos, both the black hat and white hat versions. Part of hacking—the part that I can get down with—is when motivated hobbyists exploit technology to solve a problem (real or imagined). I have thought many times how great it would be to sniff the unprotected data that’s transmitted by my pump/CGM and skip the middleman of uploading data to a web site. I’ve even gone so far as to seek out the information that Radcliffe presented, but it wasn’t available at the time.

Device manufacturers limit our access to our own medical data and tightly control the way that we can interact with our devices. It’s understandable given the limitations put on them by the FDA, their own desire to help (not harm) customers/patients, and their lawyers’ desire to limit risk exposure. It does mean, though, that the enormous potential for third-party, patient-focused tools goes untapped. Those tools could benefit so much from being able to present data the way that their users want to see them: A dashboard light in a car, a desktop computer widget that display CGM values, a mobile app that records all of the data for later use, a device that calls parents of children with diabetes when something happens, an awesome mood ring displaying BG, etc.

I suspect (and once again I’m assuming here) that Radcliffe was intrigued by the rather obvious possibilities of unprotected communication, and that’s getting lost in the whole “malicious people ruining diabetics’ lives” reporting. I fear the notoriety this incident is garnering is going to scare manufacturers into closing exploitable security holes without providing a secure, replacement method for getting at all of that data. And that’s a shame.

Posted in Computing, Data-betes, Diabetes, File Formats, Fodder for Techno-weenies | Leave a comment

App Update

Posted on April 1, 2011 by Jeff Mather

Today a bunch of my online peeps were in California visiting Medtronic. I wish I’d been invited to go to, but that was not the case. Had I been there, I would have squealed like a little schoolgirl at the pre-announcement that they’re rolling out support for uploading and using CareLink on a Mac next week.

Not only is that great for me when working with my own data, it will make developing my app easier. People may still need to take the extra step of downloading a CSV file containing their data, but at least they’ll be able to do it on their platform. Not perfect, but better.

In an ideal world — the one that I would have advocated for at pump/CGM HQ — third-party app developers (like me) would be able to ask the online CareLink database for a person’s diabetes data via an application programming interface (API). Mobile app developers could then hold on to that data for offline or mobile use without ever needing to talk directly to the medical devices themselves. Frankly, writing code to connect directly to a life-preserving medical device is quite risky and something I would like to avoid; it’s also the kind of thing that requires rigorous, time-consuming, expensive FDA approval. Not very appealing when all I want to be is a data consumer.

I’m hoping that Medtronic provides a mechanism to open up this data soon, because I’m getting close to being able to benefit from it. And when I say “this data,” I mean “our data” because it really is ours. We’re the ones who generated the data through our self-managment decisions, and we’re the ones who will benefit the most from using that data to make decisions. All I’m really asking for is a way to log in to CareLink without using a web browser and to retrieve data securely.

I’ve been working on my pump+CGM data visualizer a lot recently — most evenings in fact. On my Mac, I can extract events from a comma-separated value (CSV) file generated on the CareLink website, and I can pick out “interesting” events that are relevant for self-management. Now I’m working on being able to store those interesting events in a form that I can send to my iPod. (Then there are the tasks related to visualizing the data, but I’m starting small.)

It’s taking me longer than I expected to build this application. Objective-C isn’t hard, but learning the ins and outs of any new framework library is always a bit involved. (Turns out I’ve been using a lot more C++ than I had expected . . . not that there’s anything wrong with that.) And I realized that I actually need to build two applications: one part that sits on a “traditional computer” that can talk to CareLink and the other that visualizes the data on an iPhone, iPod, iPad.

Here’s a little example of the raw data that I will eventually use to generate graphs and an annotatable logbook:

3/30/11|16:20:00|GlucoseSensorData|AMOUNT=106, ISIG=10.2
3/30/11|16:25:00|GlucoseSensorData|AMOUNT=98, ISIG=9.71
3/30/11|16:30:00|GlucoseSensorData|AMOUNT=98, ISIG=10.59
3/30/11|16:35:00|GlucoseSensorData|AMOUNT=100, ISIG=10.66
3/30/11|16:40:00|GlucoseSensorData|AMOUNT=102, ISIG=10.94
3/30/11|16:45:00|GlucoseSensorData|AMOUNT=102, ISIG=10.6
3/30/11|16:50:00|GlucoseSensorData|AMOUNT=102, ISIG=10.56
. . .
3/30/11|18:14:01|BolusWizardBolusEstimate|BG_INPUT=195, BG_UNITS=mg dl,
  CARB_INPUT=0, CARB_UNITS=grams, CARB_RATIO=8, INSULIN_SENSITIVITY=50,
  BG_TARGET_LOW=110, BG_TARGET_HIGH=110, BOLUS_ESTIMATE=1.7,
  CORRECTION_ESTIMATE=1.7, FOOD_ESTIMATE=0, UNABSORBED_INSULIN_TOTAL=0,
  UNABSORBED_INSULIN_COUNT=2, ACTION_REQUESTOR=pump
3/30/11|18:14:01|BolusNormal|AMOUNT=1.7, CONCENTRATION=null,
  PROGRAMMED_AMOUNT=1.7
Posted in CGM, Data-betes, Diabetes, Fodder for Techno-weenies, Software Engineering | Leave a comment

Ready to Start Coding

Posted on February 26, 2011 by Jeff Mather

It’s been a week since I announced that I was going to write an iPhone app. I’m still excited about it, even though someone told me that Medtronic is working on their own version of the same thing I proposed — a working prototype, she said. Well, I for one am glad that they seem some value in having a mobile app, but I plan to keep working on mine. Competition is good. We’ll see who can get their app out there first: the newbie picking up iPhone development skills or the large medical company who is going through FDA approval.

Since last Saturday I’ve learned a lot. I’ve picked up the syntax of Objective-C, which is causing this C++ programmer to “think differently.” I like what I’ve seen from it so far, but we’ll see what I think after building something real. I’ve made a couple “Hello, World!” applications, just enough to get a few basic skills using Xcode and Interface Builder.

Now the hard work begins.

I’ve made a list of requirements for the first couple of (internal) versions of the app; so I know what needs I plan to satisfy. I’ve picked an external library to plot the CGM data. And I’ve started working on the functional design, sketching a few different views that people will use to interact with their data. (I usually hate graphical user interface design, but something about the UIKit components seem to be amplifying my scanty abilities with interaction design.) I still have to figure out the data model — that is to say, the architecture — but I think that should follow from the views I create, which of course is supposed to visualize items in the pump/CGM data model.

Tomorrow I’ll try to put a few components together. Stay tuned!

Posted in CGM, Computing, Data-betes, Diabetes, Fodder for Techno-weenies, Software Engineering | 1 Comment

Helpful iOS Apps for Diabetes

Posted on February 23, 2011 by Jeff Mather

I’ve been thinking about iPod/iPhone/iPad apps for good reason lately. My research into how to write such an app of my own continues apace, and I’ve contemplating exactly what I can make it do.

I’ve also been thinking thinking about the apps I have now that I find useful for diabetes. To be perfectly honest, none of them are the typical journaling apps. I downloaded a few, used a couple, but stuck with none. Journaling just takes too much time and/or sustained attention. You either stick with it and get a lot of use out of it, or you have a life. I’m trying not to make that same mistake with my own app. Let the machines collect the data, I say. We’ll use our brains to make decisions based on their hard work. Thinking, that’s our proper role.

Anyway, what apps do I have on my iPod Touch (a.k.a., cheapo iPhone) that help me with my diabetes?

  • Tap & Track: Calorie Tracker ($3.99) — It has a ridiculous amount of foods in its onboard database, including loads of restaurants and name-brand packaged foods. No network connection required. Easily access things you eat regularly. Get details about your own recipes. A bargain at twice the price.
  • Twitter (Free) — Gotta keep in touch with my diabetes online community.
  • Things ($9.99) — This GTD app is a bit pricey, but it’s the best I’ve found. Among other things, I use it to keep track of my diabetes and health-related projects and tasks. I can set it to remind me to get my A1c drawn months in the future, when it’s actually relevant. It reminded me to “write that weblog entry about iPod apps” before DSMA. Oh, and since I made a recurring task to take my vitamins, I’ve gotten much better at doing that. I like checking things off a To-Do list. :^)
  • Due ($2.99) — I try to bolus for breakie 15 minutes before I eat. This little reminder app has reminded me more than once that it’s finally time to stop working and go eat that cereal.
  • Reeder ($2.99) — This RSS aggregator hooks up to Google Reader and helps me keep up to date with all y’all’s weblogs. (Thanks to Pearlsa for recommending this.)
  • iBooks (Free) — I keep my running plan that I built on a running web site in a PDF here, along with a few exercisey things that I scanned from magazines. (What I really want is a tear-sheet app, but until then . . .)

So what am I missing? What do you use? Please leave a comment!

Posted in Computing, Data-betes, Diabetes, Fodder for Techno-weenies, Health Care | 6 Comments

JPEGmini v. The Man

Posted on January 23, 2011 by Jeff Mather

UPDATE: Be sure to read the comments. There’s no new file format.

Real low on the world’s priority list is a patent-pending image compression algorithm and format that attempts to replace JPEG. (I’ve written why before, more than once.) But just in case I’m wrong — after all, JPEG-XR hasn’t really taken off like I thought it would three years ago — here’s a link to JPEGmini.

The makers say via Twitter that they’ll be at the same conference that I’m at right now. I will report more when I have details. (I sure hope these aren’t the same folks that I tried to talk out of adding a new JPEG format some years ago. Gosh, that would be awkward.)

Posted in File Formats, Fodder for Techno-weenies | 3 Comments

Artificial Pancreas Workshop slides

Posted on November 11, 2010 by Jeff Mather

Here are some slides from yesterday’s NIH/FDA Artificial Pancreas Workshop. Click any image for a larger version.


Public Workshop on Artificial Pancreas (AP)

Slides from John Mastrototaro, Ph.D., VP Global R&D Medtronic Diabetes


Product opportunities to integrate toward AP


Predictive low-glucose suspend and resume


FDA questions for AP vendors


Percentage of glucose values in target range using AP

Slides from Henry Anhalt, DO, Medical Director Artificial Pancreas, Animas Corp.


AP development roadmap


Closed-loop (AP) versus open-loop (traditional) blood glucose


Model predictive control


Possible methods for improving pharmacokinetics/pharmacodynamics


What’s involved in moving the AP forward

Posted in Diabetes, Fodder for Techno-weenies, NaBloPoMo, NaBloPoMo 2010 | Leave a comment

Artificial Pancreas Workshop

Posted on November 10, 2010 by Jeff Mather

Man, I wish there were times that I didn’t have to work. Don’t get me wrong; I love my job and get a lot of satisfaction from the work that I do and from being with my coworkers. The MathWorks is a great company, and I wouldn’t want to work anywhere else. But sometimes it would be nice if I could just take the day off to attend or follow one of the diabetes events that people discuss on Twitter as it happens: EASD, FDA meetings, Epatcon, ADA scientific sessions, and so on.

Today it was the FDA and NIH’s public workshop on the artificial pancreas project (APP). From the little bits of the live webcast that I heard during lunch, the project is engaged in numerous clinical trials at several locations using multiple different technologies. It would seem that there’s also a lot of room for debate between the doctors, researchers, and FDA regulators about how to interpret the results of the trials and what the standards for safety and efficacy really are.

So many things seem so promising. Some pumps can predict low blood glucose and then suspend background insulin delivery, preventing hypoglycemia from occurring. Other solutions involve a “closed loop” between the insulin pump and the continuous glucose monitor (CGM), constantly adjusting the amount of insulin delivery in response to changing levels of blood sugar. Stopping lows is one thing; preventing highs seems much more difficult.

Everybody said the right things: a solution should prevent lows, minimize the intensity and duration of post-meal blood glucose spikes, be easy to use by people with diabetes, and make our lives better. Of course, for the doctors and regulators, making our lives better means reducing the number of complications and the risk of death from hypoglycemia. Those are important, but I think that most of us with diabetes think that “making our lives better” involves feeling like we have a greater degree of influence over our blood glucose, making our daily choices and actions easier.

But I was surprised by how much disagreement there was between the doctors on the research and regulatory sides. How many hours of in-clinic trials do you need to do before you can start out-patient trials? How much can your rely on software and hardware simulation (“in silica” v. “in vivo”)? If CGMs are reliable enough to use in the project, why aren’t they reliable enough to gather the data needed to validate the research findings? What level of higher blood glucose is acceptable if a pump prevents 90+% of all lows? Can you look at outcomes instead of just A1c numbers?

Those are all great questions, but answering them to the FDA’s satisfaction is going to take a lot of time. It’s good that the FDA purports to take an impartial look at the technology, free from conflicts of interest. But in my mind, they seem like they’re really dragging their feet when it comes to patient-operated technology. It’s hard for me to see so many promising technologies and wonder how long we’re going to have to wait before the products are available on the market. Patricia Beaston, one of the regulators, was very skeptical of integrating medical devices with mobile devices. (It’s enough to make someone like me say things like, “We don’t need your stinking FDA approval.”)

The variability — one might say “inaccuracy” — of CGM sensors and blood glucose meters seems to be the limiting factor in the current technology. The algorithms appear fairly robust, but the data they receive is frequently suspect. As one of the speakers said, the CGM sensors are quite accurate near the calibration points, but not so much as you get farther away. (Those less accurate zones seem likely to be the ones where critical decisions about insulin delivery need to happen.) I wish the FDA would apply the same amount of scrutiny and rigor to existing sensors and monitors that they’re applying to the rest of the artificial pancreas project.

Expect to see some more thoughts on the APP here in the coming days.

Posted in Diabetes, Fodder for Techno-weenies, Health Care, NaBloPoMo, NaBloPoMo 2010 | Leave a comment