4 ms·

Christ, I should be keeping a list over the course of my career, I'm sure I've forgotten some gems. Some that stand out: We had a NOSQL-esque backend that stor

Christ, I should be keeping a list over the course of my career, I'm sure I've forgotten some gems. Some that stand out: We had a NOSQL-esque backend that stored CSVs, as part of a data pipeline. (CSV in, data "Activity", csv out). You specified the file, if it had headers, separator, etc. As it turns out, you could not define a null separator, if you wanted to have a single column file. I needed something that would properly split what I knew to be well formed all alpha-numeric inputs within the valid ascii range, and would avoid spurious splits. The sep I used was naturally (the snowman unicode character, unicodesnowmanforyou.com, which as it turns out HN sanitizes on posting!) (The punchline comes when I started seeing this pattern show up in production code elsewhere in the company, using this exact same character choice.) Snowman separated files++ (.ssv?) Another fun bug, was working in a very large platform that had a common telemetry library that used perf counters. The original authors, and all of the platform authors consuming the lib, had gone on their merry way without realizing that perf counter instances have a disallowed character set, which the custom lib was _embedding by default_ when it added metadata to the instance name (#foo or something IIRC). Fixing the metadata appendation was easy enough, but to fix every place where the consumers had named something with an invalid char (and then consumed with the same invalid char on the read side) ended up writing a shim that sat between the perf counter lib and world and silently character replaced the invalid chars with something strange like _<charID> (Basically reinvented the wheel of slash escaping but within the perf counter allowed charset). And to end on an abysmal note, large project had VERY consistent naming scheme, had gotten quite deep filewise, was hitting max path len limitations on windows. Rather than break the consistent naming on a new, slightly longer file that needed to be added, or rename everything else, changed root paths from Workspace->w; Main->m; Release->r, etc. I am not proud of this one... Even as I type this I know there are tons of hacks I'm forgetting (using plastic knives as hard drive stabilizers in a significantly sized datacenter deployment) and will gladly expound if there's interest but for now I'll let this nostalgia get reburied :)

mdip 10y ago
I always wondered why the Unit/Record/Group separator characters were virtually never used. In the case of human editable files, I get it (a comma is actually on the keyboard, after all). But I'm curious, in your case, why you went with the snow man over the built-in options[0]? (and I have to admit that I got a laugh out of the "pattern show[ed] up in production code elsewhere in the company" -- I've seen that so many times) [0] http://stackoverflow.com/questions/8695118/whats-the-file-group-record-unit-separator-control-characters-and-its-usage http://stackoverflow.com/questions/8695118/whats-the-file-gr...
- existencebox 10y ago
  An exceedingly stupid act of paranoia; I knew the input _could not_ go above the normal ascii character set without errors elsewhere in the pipeline, it seemed therefore more robust to chose one that could by other invariants never be hit. That being said your group separators, had I thought harder about it might still have been a more valid answer. (but then I wouldn't be able to talk about it as quite so much of a dirty hack!) I imagine they aren't used much because frankly I hadn't even thought about their distinct function more than two to three times in my entire post-programming life.

mdip 10y ago

I always wondered why the Unit/Record/Group separator characters were virtually never used. In the case of human editable files, I get it (a comma is actually on the keyboard, after all). But I'm curious, in your case, why you went with the snow man over the built-in options[0]? (and I have to admit that I got a laugh out of the "pattern show[ed] up in production code elsewhere in the company" -- I've seen that so many times) [0] http://stackoverflow.com/questions/8695118/whats-the-file-group-record-unit-separator-control-characters-and-its-usage http://stackoverflow.com/questions/8695118/whats-the-file-gr...

existencebox 10y ago
An exceedingly stupid act of paranoia; I knew the input _could not_ go above the normal ascii character set without errors elsewhere in the pipeline, it seemed therefore more robust to chose one that could by other invariants never be hit. That being said your group separators, had I thought harder about it might still have been a more valid answer. (but then I wouldn't be able to talk about it as quite so much of a dirty hack!) I imagine they aren't used much because frankly I hadn't even thought about their distinct function more than two to three times in my entire post-programming life.