Cabinet of Curiosities: Ars Technica on the Russian Infowar Against the U.S. Elections

I really read every article I look at from Ars Technica.

If you don’t read them, you should.

That said, I don’t read them as much as I should. Compared to the daily drivel I sometimes take in — CNN’s daily blast, for goodness’ sake! TechCrunch! — Ars Technica is technically meaty and deep. It’s substantive.

So when Ars Technica published a long account of how the Russians hacked the American elections in 2016, I read it with interest.

You should, too.

My favorite bit was the patient way the GRU teams worked on spear-phishing attacks until they nailed Podesta’s account. They were then able to operate without interference behind the DNC’s various firewalls for some time, although the DNC’s IT staff — who had originally poo-pooed two-factor authentication (which could possibly have averted some of the phishing attacks) — eventually caught on to them and shut the compromised servers down.

In any case, not the proudest hour for our country.

Themes for Work and Study, Week of December 30, 2018

OK, it was a nice holiday, and I had a great time writing some code (and solving some coding problems).

Time to get back in the saddle, back to work on 7 Hard Problems.

The basic idea for January is to vomitout the remaining “core” chapters of 7Hard. I’ll be kicking that off this week with “Pleasure vs. Duty”, which should be fun (no pun intended).

(With each of the chapters so far, doing the vomitout has raised a bunch of good points and questions and readings for further study. I’ve been complaining about the boatloads of new work churned up, but I’m basically pleased: the process is working basically the way I had hoped.)

“Pleasure vs. Duty” is a relatively new add-on to the list of seven problems, so I’m going to be scrambling for material, even core texts. Any suggestions are welcome.

So be it.

Summing Up the Week’s Work

There was lots of family and friends this past week, and comparatively little Deep Work, but the few(er) hours paid off: I was able to solve the “depth of project/depth of task” design problem that had been vexing me, and the MLO parser now emits properly formatted (well, formatted with printf(); a few more details outstanding, but the gist is there :-)) project and task records.

Next week: Generating actual stuff that could be input into Todoist.

Themes for Work and Learning, Week of December 23, 2018

It’s going to be a short week with the holidays and family coming in from out of town, but, still…

In the the time I do work this week, I want to try to break through on the depth of “project” and “task” nesting that I complained about last week. That’ll be the software part of the week’s work.

And I want to reflect and maybe generate something on the topic of using Todoist as a fresh start in terms of fitting the work I want to do into the life I have available. For this, I may review some of the stuff the Todoist folks have written on how to use their system, as well as just a bit of navel-gazing.

Hack of the Week: Adversarial Machine Learning

I heard about this one at a talk on Monday at our Washington DC CTO Roundtable on machine learning.

I had read about a kind of smackdown sport where machine learning gurus set to work trying to break the algorithms of their adversaries.

When I asked the speaker about it, he said, “Oh yeah, adversarial machine learning”.

Well, that was it, and here’s the Wikipedia article on it (flawed though Wikipedia seems to find the article).

Per this article, “AML” as we might call it has been with us for some time, mainly in the form of the fight between spammers and spam-filter developers.

You know:

  1. Spam filters add the phrase “penis enlargement” to their algorithm. Any email with “penis enlargement” in it gets flagged.
  2. Spammers start spelling it “penis enl@rgement”
  3. Rinse and repeat

Since the spammers just have change some generated text and the spam filters have to change and train a changed algorithm, guess who’s more supple?

The Roundtable speaker alleged that there was a sticker you could put on a stop sign that could fool a self-driving car algorithm into thinking it was a “Yield” sign. Think of the fun you could have with that if you were intent on getting self-driving cars to hurt people…

Summing Up The Week’s Work

Not much to say here.

It continues to be fun to code (yes, I can hear the professionals saying, “Yeah, I’d have fun coding too if I didn’t have to worry about deadlines and layoffs and burnout…”).

I’m surprised how much trouble I’ve had with the following problem:

  • Increment a “Project” count every time we go into a sub-project, with the wrinkle that a sub-project need not be a child of a super-project; it could be a grandchild or even a great-grandchild
  • Call panic() if the Project depth gets to be greater than 4
  • Unwind the Project count as we backtrack on the XML tree

I’m not doing justice to it, but that’s the gist of the problem.

Probably just hyper-rustiness. Can anyone help/

How I Gave Up Smoking

I gave up smoking thirty years ago, when my son was born.  It was easy.

I tried to give up smoking for the fifteen years before that.  It was impossible.

OK, you might say.  Birth of your son.  Who wouldn’t be ready to give it all for their child?

Except that my daughter had been  born three-and-a-half years before my son, and I wasn’t able to give up smoking then, even though I wanted to.

What changed?  How did it work?

Well, first of all, all of the things I tried when I succeeded were things I had tried when I failed.  As I recall, I used nicotine gum.  And I put a pack of cigarettes out on the mantle of the fireplace so it was crystal clear that I was giving it up, foregoing this vice.

But I think there were two key things, one of them slow and gradual and one of them sudden.

The gradual thing was that my opportunities to smoke were diminishing.  We lived in California then, which had a pretty staunch anti-smoking portfolio.  You couldn’t smoke in bars.  You couldn’t smoke in workplaces, unless you went outside.  So my smoking habit was experiencing habitat destruction.

The sudden thing was that all of a sudden I was ready to quit.  And I don’t know much more about it than that.  Maybe it was the accumulation of the various restrictions.  Maybe it was thinking of my son becoming a smoker. 

Some switch inside me had flipped, and I was ready.

I won’t say that quitting was easy, but it was a no-brainer in a sense because I was determined.  More than that: going back to smoking was unthinkable.

I’ve tried to use this two-part formula for other vice removal — habitat destruction and recognizing when I’m ready.  I’ve had some luck lately with weight loss.

But I’m still puzzling over what happened with smoking… and how I could bottle it.

Pimcraft: The Difference between a Project/Goal and a Multi-Step Task

Porting over from MLO to Todoist has forced me to think about the distinction between a multi-step task and a project.

The distinction is forced upon us in Todoist because Projects and Tasks are two different entities in Todoist although each may have up to three levels of sub-<X> (either sub-project or sub-task).

On the one hand, this is a slap in the face to orthodox GTD.  David Allen is pretty clear that any multi-step process should be considered a project.

But being forced to partition my PIM into projects and sub-projects on the one hand and tasks and sub-tasks on the other got me thinking.  And thinking is the mother of More Refactoring Work On The PIM.

There’s a lot of things I do now in MLO that hardly merit the title of Project.  A mundane (and degenerate in the mathematical sense) example is reading a book.  This is a multi-step process for the most part, in that you read some every day until you’re finished.  But it’s really stretching things to call it a project.

Slightly less degenerate is getting together with a friend.  This is a multi-step process, but it doesn’t really involve much ingenuity to do it; it just requires tracking the steps so I know where I am in the process.

You know:

  1. Propose some dates
  2. Hear back from your friend
  3. Close on one date
  4. Book a venue
  5. Go to the get-together

I include the last because it ends up as a calendar entry as opposed to a task, but it’s all part of the same PIM.

Again, this is a multi-step process, but it’s pretty stereotyped.  You could almost have a template for it.

Which is a good rubric for what’s a project and what’s a multi-step task.  If you can gen up a template for it, it’s a multi-step task.  If you can’t, then it’s a project.

So what are some projects?

Projects have several moving parts.  A project — for example, building traffic to my blog — may involve:

  1. Measuring traffic, which is a multi-step task
  2. Pinging influencers, where each influencer ping is a multi-step task
  3. Buying traffic (I’m not there yet, but Facebook, for one, is always urging me to buy traffic for my page, and they have my best interests at heart, no?  :-))
  4. Brainstorming how to get to “1000 True Fans”.
  5. etc.

This kind of multi-step process naturally decomposes into a set of subsidiary multi-step processes until you get to the point where you’re basically dealing with multi-step tasks.

(Sorry to belabor this. I can’t help myself :-))

What happens as we travel up the tree?

The projects become more and more:

  • General
  • Long-term
  • Goal-like

So the first four levels of the tree are essentially goals and projects.  The bottom four levels are essentially tasks and sub-tasks.

One might have a goal of Health whose subgoals are Control Weight, Strength training, Feel Better, etc.  Strength Training may go directly to a multi-step task of finding time to lift and lifting (since I already have a lifting routine in place).  But Feel Better is still pretty abstract, and its subs may be:

  1. Control Fear
  2. Master Pouting
  3. Feel what you actually feel
  4. etc.

These sub-projects are in turn complicated, and may consist of still further sub-projects or may go directly to a multi-step task.

Well, so the next step for figuring out the port from MLO to Todoist is mapping my multi-step things to either projects or tasks.

I thought at first I would do it automatically, but that began to seem like more elegance.  So I’m just going through my PIM and marking up multi-step things manually, some as projects, some as multi-part tasks.

It’s a good exercise in any case, since it forces me to look at a lot of projects I’ve become numb to in my daily and weekly grind.

And, in my book, no amount of effort spent on PIMCraft is too much.

Cabinet of Curiosities: Farmer Cheese

I’ve blogged at this site — and, in the past, at crummycook.com — about my escapades in cooking, growing, and making food.

My latest attempt is farmer cheese.  This is a soft, bland cheese that is quite similar to cottage cheese but does not have a discrete curd structure.

I wanted to make it because my grandma had served it at breakfast years ago when I was a boy, and I, who didn’t like anything very strongly flavored, took a liking to it and asked her for it when we visited.

Her farmer cheese was a block of solid somewhat like halvah in texture, but easier to cut.

I ran across a recipe in Mother Earth News last year for making farmer cheese, and decided I would give it a shot.  Which I’ve finally done.

It didn’t come out 100% like Grandma’s.  In the first place, the lemon juice and buttermilk made the product slightly but noticeably sour, which would have dismayed young Danny but didn’t bug me.

More importantly, the cheese was too granular to slice.  You could scoop it up and spread it (like Boursin, perhaps), but I wanted to slice it as I had sliced my grandmother’s farmer cheese so many years ago.

My daughter and her vegetarian boyfriend put it on some vegetables my wife had whipped up and it crumbled nicely on top and was a great complement to the veggies.  Happiness all around.

Next?  I’ll make farmer cheese batch 2 or perhaps try a companion recipe for cottage cheese.

Themes for Work and Learning: Week of December 16, 2018

I had originally thought to spend another week on the MLO Parser front end.

I wanted to really get an elegant abstraction of the division of labor between the parser guts — which presumably would be independent of output and dependent only on input — and the app itself, which might use the input data to generate XML for updating MLO views on multiple platforms, for example, or might use the data, as in the current use case, to port the data over from MLO to Todoist.

But, as Einstein said, “If you are out to describe the truth, leave elegance to the tailor.”  I thought it over, and I thought better of it.

In the first place, I’ll learn the most about the various use cases for the MLO input data by actually working the cases rather than by mulling about them in the abstract.

Plus I know that, left to its own devices, my mind over-abstracts.  There’s an old FORTH cartoon I love (which I couldn’t find online) showing a device labeled “Processor” with a keyboard, a “system unit”, and a bowl.  On the front of the device is a three-way switch which says “DATA/WORD/FOOD”.

That’s where I was headed.

So, to ground myself, to gain experience with one definite use case, and to actually get closer to my goal instead of messing around, I’m going to focus this week on parser output for Todoist from the MLO data.

There are a bunch of sub-problems here:

  • Generating the actual bytes that Todoist needs as input.  These are mostly in JSON, so 
  • Dig in to the JSON library in Go
  • Todoist makes a distinction between “projects” which are higher in the hierarchy and tasks which are lower.  Projects are allowed to have sub-projects up to four levels and Tasks are allowed to have sub-tasks up to four levels, so I have to somehow split my lovely MLO hierarchies into higher-level “projects” (with multiple levels) and each project ultimately owning a bunch of “tasks” with sub-tasks.
  • Set up a streaming connection to the todoist sync server to load the data
  • Regulate the flow of the data so that it doesn’t overload the server (or, what is the same thing, break any of the server’s load-throttling rules).

Should be fun.