Category Archives: Computing

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

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

Things You Should Be Reading

Posted on August 12, 2011 by Jeff Mather

Hey, everybody. It’s that time again. The time to clean out a bunch of links that I’ve read and share them with you because I think you might find them interesting.

Posted in Computing, Cycling, Data-betes, Diabetes, Software Engineering, Worthy Feeds | 1 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

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

30 Days of Posts (and iPod/iPhone Apps, too!)

Posted on November 30, 2010 by Jeff Mather

I just wasn’t feeling “National” Blog Post Month (NaBloPoMo) this year. Last November I think everything came together: I had just started setting free my thoughts about diabetes, and I was just getting back into the swing of writing here. This year it just felt like a bit of a chore.

It wasn’t an awful experience. It did help keep me posting photographs and whatnot, but it doesn’t seem that I set aside enough time to write some of the longer articles that I hoped to create. In fact, I often found myself remembering right at the end of the day that I needed to write something. Now that the month is over, I’ll keep going with the occasional posting — with more substantial content, I hope.

See you back here real soon.

. . . I guess there’s no time like the present to write a bit more and say that I got an iPod Touch for an early Christmas present. (Thanks, Mom and Miles!) I like it very much as a media device — navigating playlists and moving around the interface is just much more awesome than my old 6th generation “classic” iPod — and I’m starting to look around at some of the apps for it.

Let’s see here, there’s Twitter and Facebook and the New York Times reader and Netflix and Skype and the ESPN app which I’m sure will be useful once baseball season starts again. (It has rugby, but no Australian scores. Go Rabbitohs!) And I’ve just started looking for things that could help me out with diabetes and exercise.

Here’s where I need your advice.

What are your favorite iPhone / iPod Touch apps? What do you use to help you manage your diabetes? What should I download just for fun or because no properly decked out Apple gizmo is complete without it?

Posted in Computing, Data-betes, Diabetes, MetaBlogging, NaBloPoMo, NaBloPoMo 2010 | 2 Comments

Performance Programming Links

Posted on October 22, 2010 by Jeff Mather

Faithful readers: This dispatch falls into the bucket of “stuff that’s about work and not diabetes.” (Not that diabetes isn’t its own kind of work.) This is what I do for my 9-5. It’s the stuff I do between thinking about diabetes, my next bike outing, where I want to travel someday, and all those other things. Don’t worry, we’ll get back to all that “good stuff” soon enough; but this post is for the lurking coworkers and people searching on the Google.

Here are a few performance-related articles and presentations that I stumbled upon recently:

Igor Ostrovsky at Microsoft wrote a very useful description of various processor cache effects. Here are the notes I took while reading it:

  • Array access is slower than math
  • Data alignment can determine how many cache lines are touched
  • Keep modifications/accesses within the same cache level
  • Be aware of instruction level dependencies and parallelism opportunities
  • Avoid touching too many memory locations from the same cache line, causes contention
  • There’s a trade-off between the size of what you’re putting in the cache and the number of elements you touch in it. — What does that mean, Jeff? Not exactly sure, but cache assoc. is usually not a huge deal compared to other issues.
  • Because cores have their own caches and because memory needs to remain consistent, avoid letting two threads modify data on the same cache line.
  • Even when you think you know what you’re doing, there’s other crazy stuff going on.

Isn’t that last one the sad truth about performance optimization?

Igor also has an excellent article about branch prediction. Basically, if you structure your code so that if branches are predictably true (or predictably false) the CPU can start walking down that code path until it’s proved wrong. But if it’s close to random, you’ll see performance hits.

Joe Duffy, also at Microsoft, debunks the “premature optimization is evil” myth. Joe summarizes the article himself quite well, so I’ll just quote him.

In this short article, we’ll look at some important principles that are counter to what many people erroneously believe this [“avoid premature optimization”] statement to be saying. To save you time and suspense, I will summarize the main conclusions: I do not advocate contorting oneself in order to achieve a perceived minor performance gain. Even the best performance architects, when following their intuition, are wrong 9 times out of 10 about what matters. (Or maybe 97 times out of 100, based on Knuth’s numbers.) What I do advocate is thoughtful and intentional performance tradeoffs being made as every line of code is written. Always understand the order of magnitude that matters, why it matters, and where it matters. And measure regularly! I am a big believer in statistics, so if a programmer sitting in his or her office writing code thinks just a little bit more about the performance implications of every line of code that is written, he or she will save an entire team that time and then some down the road. Given the choice between two ways of writing a line of code, both with similar readability, writability, and maintainability properties, and yet interestingly different performance profiles, don’t be a bozo: choose the performant approach. Eschew redundant work, and poorly written code. And lastly, avoid gratuitously abstract, generalized, and allocation-heavy code, when slimmer, more precise code will do the trick.

Follow these suggestions and your code will just about always win in both maintainability and performance.

If you do anything that falls under the labels of “multicore,” “multithreaded,” or “multi-processor,” then you should definitely add Multicore Info and Intel’s software blogs to your RSS feed aggregator.

One recent Intel offering is a recording of “Introducing Intel Parallel Building Blocks”. The Intel folks discusses Intel Cilk Plus, Threading Building Blocks (TBB), and Array Building Blocks. Here are some notes from the 45 minute presentation:

  • Intel Cilk Plus is a lower-level way to expose parallelism and the potential for vectorization to C++ code. It currently only works with the Intel compiler.
  • TBB is awesome. That’s me saying that. I use it to easily exploit data parallelism in our existing codebase. (Because I use it already, I didn’t take many notes on it. Sorry.)
  • Array Building Block (ArBB) provide the highest level of abstraction presenting the ability to specify array data containers (1-D to N-D, including nested containers and [soon] sparse data) and then do vector operations on the data in the containers. Sounds familiar.
  • Cilk Plus includes reducers to prevent data races, has #pragma simd to empower the compiler to make vector assumptions, and has a mechanism for specifying a range of vector data.
  • Parallel Inspector and Parallel Amplifier are alleged to help squeeze performance out of code that uses TBB.
  • ArBB uses a two-part compilation process, one of which is a runtime JIT.
  • There are collisions between the schedulers in Intel MKL and Cilk (and TBB, etc.). Beware.

And finally, there’s a recording of a webinar about Intel Parallel Advisor that may be of interest. It’s next in my queue of things to watch.

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

Reading a Freestyle Blood Glucose Meter with MATLAB

Posted on September 10, 2010 by Jeff Mather

Here’s some MATLAB code that will read data from a Freestyle blood glucose meter that is attached to your computer via serial cable. (Be sure to replace the “smart” quotes with appropriate single quotes. And the “…”, too. Sorry.)



% Jeff Mather - 3 October 2001
% Connect to meter.
s = serial('com1', 'baudrate', 19200, ...
           'FlowControl', 'Software');
fopen(s);

% Initiate communication.
fprintf(s, 'mem');
fprintf(s, 'log250');

% Read diagnostics.
fgetl(s);   % First line is empty.
meter_ID     = fgetl(s);
software_ver = fgetl(s);
current_time = fgetl(s);
num_readings = str2num(fgetl(s));

for p = 1:num_readings

    reading = fgetl(s);
    sprintf(reading)
    
    pause(0.25);
    
end

fclose(s);
Posted in Computing, Data-betes, Diabetes, Fodder for Techno-weenies, MATLAB | Leave a comment

The Ultimate Blood Glucose Meter

Posted on September 8, 2010 by Jeff Mather

Let’s talk gadgets.

Usually I can hold off getting things with buttons and displays. I’m a guy whose “smartphone” is an unlocked multi-band phone from the middle of the last decade that we took to India and that now mostly sits in my bag uncharged unused. It has a camera and Bluetooth, and I can play Monopoly on it (using a Java virtual machine) but that’s pretty much it. Fancy MacBook Pro laptop (from 2006)? Yes. 4th-gen iPod (ca. 2007)? Also yes. iPad/iPhone/Android/everything else? Not so much. After that decision to get an overpriced HP iPAQ hx4700 with a short shelf-life in early 2005, I’ve been reluctant to get many expensive, shiny things.

I’m definitely not opposed to gadgets, though. After thinking about the experience of recording my diabetes events at the end of last month, I’ve decided that I would like one shiny, new thing. Unfortunately, what I want — an awesome, new blood glucose meter — doesn’t exist yet. What would such a sugasheen have?

First off, it would be part of an integrated system. It would work with my pump, sending BG readings to it, similar to the way my OneTouch Ultra Link does with my Minimed Paradigm pump. It would also accept sensor data from a CGMS.

It would be easy to get data off of it. We’re talking as simple as docking an MP3 player, preferably using a standard USB connector. The data should be open and sharable. I hate that Medtronic’s software lets me download all of my pump’s events — including suspensions, temporary basals and bolus wizard suggestions — but then stores them in a password-protected Microsoft Access database that I can’t open because they won’t share the password or let me change it. And unlike the Freestyle connection cable, Medtronic won’t provide the API calls that I could use as an application developer to retrieve the data from my pump/meter. It’s my data. They don’t own it. It’s my life I’m trying to improve. Meter manufacturers should help me do that, right?

It would be open. There are lots of ways to slice and dice and visualize data if you have access to it. I should be able review my data, get averages, display events, and plot my activity in a billion different ways: time series, modal day, statistical box plots, histograms, even pie charts. Basically, if you can think of something to do with BG data, it should be possible to get the data and do it. That doesn’t have to happen on the meter itself, but it could. Wouldn’t that be sweet?

It would have lots of metadata. My Freestyle meter didn’t have any metadata at all. My OneTouch has two axes: before/after meals and a limited set of comments. But I find the events don’t often describe the reading I’ve just taken. “Not enough food” and “too much food” might describe the experience of people with type 2 or those unfortunate souls still on NPH, but I find myself wanting something like “miscalculated carbs” and “infusion set change.” I would love to be able to define my own events — especially a “WTF?!” comment — and be able to tag particular readings for follow-up with my endocrinologist or her nurse.

I would love to be able to type short, free-form notes to myself about my BG and bolus events: “Bolus wizard said 5.0 units, but I took 4.0 because of exercise” or “Had some ketones.” We’re talking Twitter-length here (140 characters) not Anna Karenina. Since a lot of diabetes is tweaking things, the perfect meter software would let me remember what I’ve tried and try it again or change it up next time.

As long as we’re talking about notes and readings and metadata, let’s talk sharing. I would love to be able to e-mail a portion or all of my log to my healthcare team for consultation. There’s no need to post my results to Twitter, but then again, why not?

Switching to the nuts-and-bolts, getting-the-BG-reading level, let’s try to think beyond blood and consumables: The ultimate BG meter would take blood and test strips out of the picture. Strips are expensive and have to be disposed. Pricking fingers isn’t exactly painful for me (I know it is for some people) but it is a bit 20th century. How about something that uses subcutaneous light scattering or UV “tattoos” that change depending on BG levels? However it might work, we’re talking about something noninvasive that doesn’t require another trip to the pharmacy every month in order to buy something I’m going to bleed on and (responsibly) throw away.

And, of course, it would be very accurate. None of this ±10% nonsense. We’re occasionally making life-or-death decisions with those BG readings, especially when deciding how to treat a high BG. The values should be precise and accurate enough that we can’t overcorrect because we’re in the margin of error.

It would also be possible to use this meter at night. LEDs are cheap. Use them. Put one in the front so that I can see my finger and another behind the display so that I can read the results w/o blinding myself at 4:00AM.

And for the love of g-d, if you’re going to require batteries, use normal ones that you find at a gas station on the NJ Turnpike or at the Eiffel Tower gift shop. AAAs would be nice.

Since blood glucose self-monitoring is the first step in a decision-making process, the ideal BG meter would help me with the rest of the process. Get a BG reading, add in the name and amount of the thing I’m going to eat, and voilà the carbs show up for the bolus wizard. I should be able enter in foods that I frequently eat as well as downloading nutritional information for those place we won’t tell our nutritionist about. If I’m going for a bicycle ride, the decision-support part of the system could remind me what works and suggest some snacks or insulin pre-gaming that I need to do based on my own history. It could even point my attention to the fact that I’ve been going high around 4:00 most afternoons for the last month and suggest that I bring it up with my healthcare team.

Finally, it would be at least as small as my current meter. If it has to be a separate device, it should fit into a stylish case that won’t get nasty after a year of constant use. But . . .

Look at this:

iPod Touch

Look closer!

iPod Touch

The data ports on the iPod and iPhone are perfect for attaching something small that can communicate with the software on the device. The ultimate BG meter would just attach to an iPhone or iPod Touch (or Android device), adding the BG reading capability to a platform that is perfect for everything else. Basically, I want a smartphone with “an app for that,” where “that” is diabetes.*

BG database with flexible journaling? There’s an app for that.

BG results analysis? There’s an app for that, too.

Bolus wizard support using a food database? E-mailing results? Decision support? Apps for them, of course.

These devices already have a backlight for those late-night readings and wireless connectivity to integrate CGMs and insulin pumps.

And we already carry them around. Or at least I would go buy one now if this were available. I’d probably buy two.


* — Look at what Apple has already done with the point-of-sale (POS) system in their own stores. “Running an Apple supply chain? There’s an app for that.”

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

New Video File Formats

Posted on August 26, 2010 by Jeff Mather

File formats come, and file formats go. Strike that last part. File formats never really go away. People just stop storing data in them, and vendors stop supporting the formats in their products. Eventually the data is just a bunch of bits that nobody really cares about. (At least that’s how I feel about most of the papers that I wrote in college.)

While formats never really retire*, there’s a steady stream of rookies. Sometimes a format totally destroys the competition: PDF, JPEG, GIF, etc. (Being first helps, as does being in the right place at the right time.) Other times a new file format results from an actual deficiency for one community in an existing family of widely-used formats. Those formats — such as DNG, JPEG 2000, etc. — have rather more difficulty overcoming the inertia of the majority of data users’ workflows despite their superior qualities.

For example, DNG never really took off the way I had hoped. My Nikon D300′s RAW file is still NEF. As are all Nikon RAW files. And I’m not convinced that there are enough applications that support DNG in my workflow (beyond the obvious Adobe applications) for me to consider converting my .nef files to DNG on import. It’s a funny chicken and egg problem.

Add to this menagerie two new video file formats.

I don’t have a lot of video experience. Still photography was always more accessible and interesting to me, though I have to confess that I’ve been greatly enjoying editing the video from our trip to Australia. iMovie is surprisingly good at what it does, and the video coming out of my point-and-shoot camera is acceptable for reminiscing. I still like the story that a still photograph can tell, but video fits that niche that I always used to fill with babbling during my slide shows.

Anyway, I digress.

I don’t have a lot of video file format experience. Undoubtedly it’s more complicated than I know, but the sense I got was that there are a few widely used file formats — AVI, MPEG, Quicktime — with a variety of audio and video compression codecs, chroma subsampling settings, and bit depths thrown in to complicate what would otherwise be a very simple landscape.

Enter the consumer HD video revolution — partly thanks to a new generation of dSLR cameras — and it seems like we’re on the cusp of another explosion of proprietary file formats. Add in the demands of professional workflows, and you get two new file formats.

Just as it did with DNG for still cameras, Adobe is proposing CinemaDNG as an open file format for storing RAW files from digital video cameras.

Storing, retrieving, and manipulating the RAW pixels in a video frame only goes so far. Eventually those frames are edited, cut and combined with audio tracks. Those frames and audio are mixed with other assets, such as subtitles, alternate audio tracks, time codes, and other metadata. Finally all of these assets are combined with a desired output intent to create a digital or film copy for cinema projection, a television broadcast, a DVD, streaming video, etc.

The Entertainment Technology Center at the University of Southern California (ETC) has worked with industry players to develop an interoperable master format (IMF) that encapsulates audio, video, and effects assets together with metadata and output profiles into a package. Basically IMF is the file-level portion of a digital asset management (DAM) solution.

The details of this encapsulating master format are quite numerous, but the following might be of interest to people who need to contemplate support for reading and writing the imagery portions of IMF. The format is evolving, but as of version 0.82a these were true.

  • IMF is pretty permissive with respect to image dimensions, audio sampling frequencies, bit depths, and so on. There are a lot of “shoulds” in the spec.
  • “Essence files” contain the video and audio assets.
  • Essence files must use ISO or SMPTE standard formats. That’s good news. I hate the reinvention of the wheel.
  • Frame rates must be constant.
  • There are some required standard and nonstandard resolutions and frame rates.
  • Non-1:1 pixel aspect ratios are OK.
  • 8- and 10-bit samples must be supported, and I/O drivers should support 12- and 16-bit imagery, too.
  • 4:4:4 and 4:2:2 chroma sampling is allowed.
  • RGB-709, YCbCr-709, YCbCr-601, and CIE XYZ are supported color spaces.
  • 3-D/stereoscopic imagery must be supported.
  • Compression is recommended, especially visually/perceptually lossless methods (but not necessarily mathematically reversible).
  • Compression must be industry standard and open. In fact, it probably should look a lot like JPEG-2000.
  • Uncompressed data will look a lot like DPX or SMPTE 384M.

Once again this is just the tip of the iceberg of the details are in the draft document. If you like these or don’t agree with them or if you have other suggestions — such as specifying a particular set of options and metadata settings as a “baseline” — do download the spec yourself and comment.


* — For an example of a moribund format, consider PICT from Apple.

Posted in Computing, File Formats, Fodder for Techno-weenies, Photography, Video | Leave a comment

Ten Things I Love about Adobe Photoshop CS5

Posted on August 2, 2010 by Jeff Mather

I just recently upgraded from Adobe Photoshop CS to Photoshop CS5. As you might imagine, a lot has changed in four major releases over the last seven years. I know I should have upgraded sooner . . . blah blah blah.

After installing CS5 over the weekend, I gave it a quick go and was immediately pleased. Tonight I used it a bit more, and now I’m even happier. Who knows how many of these are new to CS5? Not me. Anyway, here are ten things I really like:

Screenshot #1 of Adobe Photoshop CS5
Click for larger.

Screenshot #2 of Adobe Photoshop CS5
Click for larger.

  1. The “Adjustments” panel — I can work on multiple layers without being locked into editing one layer at a time. This makes me sooooo happy.
  2. Photo filters — Yeah, so they’re not real photo filters, since they don’t work on color spectra. But who cares? It’s 2010, not 2020. At least now I can easily make a warming filter.
  3. Adjustment presets — A lot of the curve shapes and levels adjustments are now precooked. Just select the right one from the drop-down list.
  4. Nicer panels — The way to move around and resize panels/palettes is just like I’d expect.
  5. More adjustments shiz — Okay, I guess I really like the adjustment layer improvements, because I honestly can’t remember what I was going to say here. I think it might have had something to do with being able to browse the precooked adjustments. Maybe? I don’t know.
  6. New adjustment layers — Easy to get to, right there next to the adjustments I want to make.
  7. Tabs — Tabs for files . . . Up there on the top, right where they belong.
  8. Action menus — The context menus appear on each panel, and the Photoshop engineers have located most of the common actions in the action menus, making them easier to find.
  9. Workspace browser — I like very much that Adobe is customizing the Photoshop experience for various communities via workspace. Click a button and you’ve changed your Photoshop experience. The panels move around, and (perhaps controversially) the menus change. I’ve saved my panel configuration as my own workspace.
  10. Mini Bridge — Do I like this or don’t I? I’ve never used Bridge effectively before. I used the Mini Bridge tonight to find and load a file; it seemed alright.

And of course there’s stuff you can’t see here, stuff buried in the menus. Some of them are brand new features to CS5, and some — like many of the items listed above — are only new to me.

I can’t wait to see what else is new and how it will continue to improve my retouching and editing workflow.


* — A couple years ago I was part of the Photoshop CS4 beta. As part of that, I used the Photomerge feature to create some panoramas from multiple photographs. I loved it then, and I’m excited to try it out with some photos from Australia. Stay tuned.

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