Category Archives: Developer stuff

Developer stuff, Lifehacking

Hack of the Week: Rebooting Your Router, 3 Ways

An article this week in How To Geek on “10 Annoying Problems You Can Solve with Smarthome Devices” has this to say about resetting your router:


You can spend a lot of time troubleshooting a router. But you probably should just reboot the thing. This is, amazingly to this day, still a valid solution that is most likely going to solve the problem.

They go on to suggest two ways to do so: the eas(ier) way and the hard(er) way:

https://www.howtogeek.com/367785/use-a-smart-plug-to-power-cycle-your-router-without-getting-off-the-couch/

https://www.howtogeek.com/206620/how-to-automatically-reboot-your-router-the-geeky-way/

And for the ultimate in geekery, you can build your own router-resetting circuit from Hackaday.

Happy hacking!

Developer stuff, Personal Information Management, Programming

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.

Deep Work, Developer stuff, Programming

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.

Cybersecurity, Developer stuff, IT Futures

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…

Deep Work, Developer stuff, Programming

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/

Deep Work, Developer stuff, Programming

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.

Developer stuff, Programming

summing up the Week’s Work

Well, I just spent a good chunk of this week writing code, which I haven’t done this consistently for some time.  Two hours on Monday, four hours on Tuesday and Wednesday, and an hour today.  Not a marathon, but not too shabby for a code re-nube.

First of all, it’s a big kick.  I forgot how much I enjoyed coding and I’m glad to decided to spend some time on it in December.  I especially enjoy debugging, for the same reason you love hitting yourself on the head with a hammer: it feels so good when you stop!  Wanting to a solve a software bug is a deep itch that nags at you and nags at you, and, when you solve it, it feels terrific.

Actually working at writing code, moreover, is teaching me a lot about the Go language that I didn’t grok from just reading the book.  It forces you to make your ideas execute.

Not much more to say about it than that.

Deep Work, Developer stuff, Programming

Themes for work and Learning — Week of December 9, 2018

Continuing this week with work on MLO Parser.

It turns out I had gotten a basic parser turning over which could echo some fields to the output and visit every node of the XML, but not much more.

Task this week is to turn that raw prototype into something a bit more robust.

First order of business?

Many years ago a software mentor told me, “Dan, the problem with software is that entropy seeps into it, and so you always have to be pumping the entropy out.”

She hit the nail on the head.  Of course, entropy probably seeps into everything, but software is nothing but entropy-waiting-to-happen, so the seepage is much more obvious.

“Refactoring” is part of entropy control, but really only a part.

In this case, the main thing is going to be getting the parser to visit every node, and getting it to do something uniform at each node.

Developer stuff, Personal Information Management, Programming, Self-criticism

Themes for Work and Learning – Week of December 2, 2018 (and a Self-Criticism)

Well, that has been quite the extended Thanksgiving holiday!  It’s been two weeks since I’ve posted.

(Which calls for a word or two of self-criticism.  At the end of the post.)

This week I’m continuing to work on the Go Language and the MLO parser.  I think I’m going to continue with this through the Hannukah and Christmas holidays.  So I’ll probably pick up 7 Hard Problems in January.

The goal this week is to find the right architecture for the parser now that I’ve read most of the Go Language book (except for the sections on concurrency, which I’m not ready for and which is not an issue for my parser project.)  I’m wrapping up the book this week (again, except for those concurrency chapters 8 and 9).

This week is going to be a combination of reading and work on the parser, which I haven’t done since September.  So there’ll be some context switching and dusting-off to do.

After the dusting-off I want to find the right way to handle the key problem of the parser, which is how to treat the various actions the parser might perform in response to the same input for varying contexts.

For example: I want to be able to parse an MLO file and output just the “views” from the file in a way that they can automatically synchronize with MLO instances on other computers and platforms.  Right now I have to do this manually.

Another example: I want to be able to translate an MLO file into a nearly-equivalent ToDoist file (which is complicated because the ToDoist paradigm isn’t really hierarchical.)

We’re traipsing through a giant XML file in the same basic fashion for both of these, but the actions to be taken for each node in the XML couldn’t be more different.

I’m looking to use Go’s interface capability to represent these similarities and differences in a uniform manner.

Enough said.  Happy to say more offline if you’re interested in Go, interfaces, MLO, my parser, and anything else related.

Now for the self-criticism…

I don’t know whether or not I’ve blogged about self-criticism, but I have a couple of non-standard ideas about it:

  1. It’s actually a good thing, provided
  2. You do a real self-criticism.

What makes a self-criticism real?

  1. You have to cotton to the problem: “I screwed up.  I shouldn’t have called you those names.”
  2. You have to say something about why the problem happened: “I get defensive when I feel like it’s my fault something bad happened.”
  3. You have to say how you think the problem can be averted in the future: “I think I can keep from lashing out if I take a moment between feeling responsible for stuff  and reacting.”

So here, what’s the self-criticism:

  1. I didn’t really process that I was going to be on the road and on vacation during the week of Thanksgiving, so I should have said up front that I wasn’t going to be able to keep up my pace of blogging.  In the week after, I thought to myself, “well, in a dime, in for a dollar” and decided to not blog last week either.
  2. It’s a cycle familiar to me from diets and other attempts to break bad habits: you realize you’ve screwed up and so you give yourself permission to screw up big time!  “What’s another week of not blogging?”
  3. I think I can avert the problem in the future if I’m straight with myself beforehand about what I can and can’t do.

I think that’s a decent self-criticism.  What do you think?

Deep Work, Developer stuff, Programming

Themes for Work and Learning, Week of November 18, 2018

Because of the holiday this coming week, I’m trying something different.

Instead of working on the next chapter of 7 Hard Problems I’m going to give myself kind of a treat and flip over the Deep Work to learning how to program in Go.

Actually, I’ve been at this for a while.  I’ve done the basic tutorials.  I’ve carved out a project — writing a parser to take input from MyLifeOrganized and use it for a variety of outputs — and I’ve got the bare bones of the parser turning over.

I ground to a halt by “death of a thousand cuts” because I basically wasn’t very fluent in the language.  Each time I hit a snag — and they were often basic snags about syntax — the wind would go out of my sails and I’d lose time on the project.

So I decided it was time to read The Go Programming Language, as near as I can find to a definitive reference, from cover to cover.

I’m about halfway through.  In Chapter 5 (“Functions”) to be exact.  I’ve been fitting it in around the edges of the work on 7Hard.

Well, I’m going to shoot my Deep Work wad this week on Go, and hopefully bull through the rest of the book.

Where will I be at after that?  An expert in Go?  Maybe.  What I’m hoping is that I’ll now be fluent enough that I can work away on the parser in smaller dribs and drabs — a Pomo or two at a time, say — and not lose my gumption every time I hit a snag.

Because I have a mission.  My next weight-loss treat.

I’ve been using tech toys to spur my weight loss.  An Android tablet.  An Android watch.  A Sonos sound system for our house.  Etc.

Well the next tech toy is not going to be a product, it’s going to be having permission to finish the MLO Parser.

Why reward myself for writing software?

  1. It’s off-purpose.  I’m supposed to be mainly about 7Hard this next six months or so.
  2. It’s a treat.
  3. It’s not harmful

So off-purpose treats that aren’t harmful are great weight-loss rewards.  And that’s what I’m going to do.