Sunday, March 27, 2016 without the bitter aftertaste looks pretty nice, but one thing I find irritating to the point of abandoning it is the way they botch the transaction descriptions read in from my credit union's records.

Consider some typical transaction descriptions from my statement, the way they are listed by Mint:

FEB 29   L Time Date   $43.41
FEB 29   L Time Date   $17.83
FEB 29   L Time Date   $6.43
FEB 29   L Time Date   $11.38
The "L Time Date" just happens to be the same on most of the transactions, and comes from a parse of strings that look like the following:
Statement Name: Point of Sale Debit L118 TIME 03:35 PM DATE 02-16 WM SUPERC WAL-MARRALEIGH NC
It isn't too difficult to see how the uselessly ambiguous description is derived, at least, functionally. The actual implementation steps may be different, but the net effect is that the first couple of phrases are excluded, and the next 30 characters or so are chopped and then stripped of non-alphabetic characters. I won't call that simplistic, because for all I know they've got some pretty signification inference algorithms going on back in the weeds somewhere. But when no one size fits all, there needs to be a method of tweaking the methods used.

The pain point here? Intuit has had years to address the issue, but still does not provide one alternative to manually editing a meaningful transaction description.

One might conjecture that Intuit has decided that nobody with technical skills is going to spend time on that particular issue. That would be be rather stupid, if it were true. Judging from the Mint Community comments, they've been ignoring the obvious and painful flaw for years - and grabbing this information is a killer benefit at which Mint is supposed to excel.

The problem cannot be that hard to address, with just a smidgen of imagination. In fact I did a proof of concept that solves the problem just fine for my purposes. If you are a Mint user, or a disgruntled Intuit developer who thinks the people making decisions are idiots, take a look:

jQuery('#txnEdit-merchant_input').on('click', function(e) {
  var truncateAfter = 66; // grab text after this many characters
  this.value = jQuery('table').first().attr('title').substr(truncateAfter);

This Javascript fragment was typed into the developer console in Chrome, while viewing the problem transactions page on  A click on a description highlights it, and configures the merchant input for editing - as Mint normally works. This handler catches any subsequent click on the input, and stuffs the rightmost part of the corresponding statement description into the input. A little tweaking and a little greasemonkey is all it would take to make this a full blown solution, sans Intuit's helpless support.

Now, I have no idea how long this little snot of a handler will continue to work, but it took me just a few minutes to put it together after poking around on the page to see what worked and what didn't. It is a trivial adaptation to use a regexp based match, or provide any other parsing and automation for editing the string for that matter. The information is all there present in the HTML page.

Sunday, January 24, 2016

Killing yourself with "good" supplements and protein sources

None of this is medical advice. It is simply a series of notes I took while reading on the subject of supplements, including choline and l-carnitine. I learned about Trimethylamine N-oxide (TMAO) as a primary causative factor implicated in several metabolic syndrome related consequences - atherosclerosis, fatty liver, heart disease - the effects are broad and pervasive.  

One study suggests that choline feeds bacteria in meat (red, white, fish, eggs, but not dairy) eaters, that produce TMAO that damages liver and promotes atherosclerosis; but this is mitigated in vegetarians who consume little L-carnitine and choline in their diet.

Eating foods rich in these nutrients (including supplements) would seem to have some serious known negative effects along with the postulated positive effects. Continuous dosing may lead to continuous high TMAO levels, and with it the stereotypical cascade of "Western" metabolic disorders. 

In one study I read that Anaerococcus hydrogenalis, Clostridium asparagiforme, Clostridium hathewayi, Clostridium sporogenes, Escherichia fergusonii, Proteus penneri, Providencia rettgeri, Edwardsiella tarda were implicated in TMA production from choline.   These germs can be pathological on their own.

  • A. Hydrogenalis eats meat
  • E. Fergusonii eats glucose and produces flatulance and eats other L-sugars as well and has been detected in clinical settings in human blood and spinal fluid
  • Clostridium species seem to eat meat and the lab medium is usually cooked meat
  • P. Penneri eats meat and sugar and prefers an alkaline environment in contaminated meat products, is implicated in kidney stone formation, and doesn't metabolize citric acid; E tarda is a meat eater and infects fish
  • P. rettgeri eats glucose and other sugars and sugar alcohols and has been found on meat products

Probiotics such as inulin (artichokes, garlic, leeks, chicory, asparagus) may supress these organisms by promoting other strains of microorganisms. Maintaining an acidic gut via acid-producing beneficial microorganisms, keeping to a more consistently vegetative diet, and/or shifting protein to vegetative sources and dairy consumption may shift the balance away from the pathogenic TMA producing strains and toward more beneficials. 

Sorry not to cite all my sources in the text, but as I said these are just my notes. I did jot down a few of the papers, but any search engine can show you more, particularly if you search PubMed for papers.

Tuesday, January 5, 2016

Is naming everything in programs an evolutionary dead end?

We program largely by using systems whose discrete components are bound by naming conventions.

Living systems don't use names much, at the scale of cellular biology anyway. Names are an affect of emergent brain behavior - the assignment of symbolic communicative phonemes to what a brain experiences, and their serialization as text, vocalizations, and actions.

Cellular biology has interfaces. But those constructions don't act like the interfaces we use in programming. The code interfaces we use are defined on the basis of symbolic names and structural signatures, and they are forced to bind deterministically rather than probabilistically. Out code signatures also largely conflate the  structure with the payload (eg the argument parameters). Cell biology may make packages in which the payload acts as the signature, but often uses complexes whereby the key signature is distinct from the payload: the interface acts as a carrier or wrapper or adjunct whose role diminishes once binding is accomplished.  That is, they often use monads.

Our code comprises a living system, for no other reason than it is an extension of us. No, it is not quite the same thing as dead skin cells, hair, or fingernails. Code is more akin to the living arrangement of dendrites in our brains, or the skeletal muscle... it can be remodeled, sometimes merely by existing.

Brains and musculoskeletal structures have been around for a very long time by comparison to code. Brains and skeletons scale as solutions, both in terms of performance and numbers of applications. Yet neither system architecture makes use of names as a principal organizing device. Names are created by brains, for the brain to recursively model, and muscles don't use naming systems at all. Molecular biology also makes do without the use of names, even though quite a lot of activity in that realm appears to be discrete - even tokenized.

Somehow these systems are able to perpetuate, grow, search solution spaces and address novel problem domains in ways that make our computational machinations look like toddler's toys. We know why we follow the use of currently popular programming language models - there exist effective processes for expressing solutions and analyzing them under these models - but it begs an important strategic question. If evolutionary pressures push our software systems toward closer and closer approximations of the real world, the designs will necessarily mean explicit names become secondary or disappear entirely from the architectural approach.