The Sin of Tech Longevity  

Really great article by Brian Nemhauser on the topic of spending a long time at at tech company. Having just finished up my ~12 year run at a tech company, so much of this resonated with me. In the handful of times I took an interview/phone call in the past 4-5 years, I had to develop an answer to why I had stayed at the same place. My answer was similar to Brian’s—it wasn’t really the same place, nor the same job. I worked at a small startup, a mid-size company, a pre-public company, a public company, and a host of transitions in between.

Change was not something I embraced when my career started, but adaptation and anticipation quickly became second nature. My appetite for change did not come from lack of attachment to Adobe history. To the contrary, it was fueled by a deep loyalty and dedication to our mission built over many years.

One of the things I had to adapt to was that change wasn’t bad. Early on, I had a hammer, and everything was a nail. As a company changes, the logical thing for lots of folks is just to do it the way you’ve always done it. Eventually you realize that you can bring your existing ways with you, but can learn from the changing company (and changing world around you) and embrace that change.

Now I was learning about sales, marketing, finance, human resources, and corporate strategy. It was an MBA-in-a-box.

This is often how I’ve described my time. By being open to change and taking on new things, I worked with so many groups that I might not have had a chance to in a normal tech path. I used to refer to it as my MBA-on-the-job.

Longevity, however, need not equal stagnation. It can mean wisdom, passion, dedication, and sustained peak performance. That is what I see when crossing paths with most of the other marathon runners at Adobe.

Longevity, in and of itself, is not a bad thing. There are certainly employees who find their comfort level and will push back against any changes. Those employees can be toxic, and you need to find a way to help them see the value in growth and change, or find a way to minimize their toxicity. Those long-timers who are adaptable and embrace change, they are your keystones, bridging the past to the present.

How to Deal With North Korea  

Great article by Mark Bowden in The Atlantic outlining the complexities of dealing with North Korea.

It’s a long read, probably about 30 minutes, which is somewhat amusing when you read the first line …

Thirty minutes. That’s about how long it would take a nuclear-tipped intercontinental ballistic missile (ICBM) launched from North Korea to reach Los Angeles. With the powers in Pyongyang working doggedly toward making this possible—building an ICBM and shrinking a nuke to fit on it—analysts now predict that Kim Jong Un will have the capability before Donald Trump completes one four-year term.

Yikes.

For all these reasons, acceptance is how the current crisis should and will most likely play out. No one is going to announce this policy. No president is going to openly acquiesce to Kim’s ownership of a nuclear-tipped ICBM, but just as George W. Bush quietly swallowed Pyongyang’s successful explosion of an atom bomb, and just as Barack Obama met North Korea’s subsequent nuclear tests and missile launches with strategic patience, Trump may well find himself living with something similar. If there were a tolerable alternative, it would long ago have been tried. Sabotage may continue to stall progress, but cannot stop it altogether. Draconian economic pressure, even with China’s help, is also unlikely to curb Pyongyang’s quest.

This is the scenario I have feared with a Trump presidency. Does the President (and his administration) have the stomach to not look “strong” and to continue to sabotage and stall North Korea’s progress until an economic and diplomatic solution are reached? Or will they roll the dice on a riskier alternative?

Those alternatives, as the article lays out, all have high likelihoods of significantly worse outcomes for the Korean peninsula, the US West Coast, and the US at large.

Does the President have the patience to make the right decision, even if it’s the one that is the least flattering personally?

Building a Jekyll Plugin to Make Unique Footnotes  

One of the nice things about moving my site to Jekyll is how extensible it is. Everything related to Jekyll (and it’s ecosystem) is open source, so as I’ve come across things that don’t work the way I want, I can change them.

Recently, I noticed that when I used footnotes, they would work on the first post on the home page, and they would work on the individual post pages, but when multiple posts with footnotes were on the home page, the nice footnote popup 1 didn’t work.

I use Littlefoot from Octopress, a plugin that does the nice javascript-ness to pop in the little image and make the popup. There were a couple of issues. The first issue was that if I had named multiple footnotes the same thing (a common practice, when you might just name a footnote something like:

[^1] 2

The javascript gets loaded, loops through the text on the page, and pulls in the content associated with the footnote. However, now you’ve got two footnotes with the same id, so the javascript always pulls from the first. There was a brute force fix to that: just name the footnotes uniquely for the home page and assume that it’s probably not an issue on any other pages.

The second issue was that, on the home page (or any collection page), the Littlefoot plugin would find all the footnotes, but only hide the first set of plugins. That was something I could actually fix in the plugin. Again, what’s nice about the Ruby/Jekyll ecosystem is that I could fix it, put it up on Github, and then use my fixed version until the fix is taken into the mainline. The code change was pretty simple:

From this:

document.querySelector('div.footnotes').remove()

to this:

document.querySelectorAll('div.footnotes').forEach(function(note) { note.remove(); } )

That loops over all the footnote divs, rather than just hiding the first one.

So I made those code changes and put it up on Github.

After this was done, it stuck in my craw that I was going to have to remember to be smart about naming my footnote references. I spent a bit of time looking at how to build a jekyll plugin—I figured I could write some code that would loop through the page, find the footnotes, rename them (using some seed data; I chose the filename), and then write them out.

It took me a couple of hours, but I got it working (well, I think). When this post goes up, we’ll see if it all went swimmingly.

Assuming it works as expected, I’ll likely put the plugin up on Github and maybe make it a gem (just for the practice).

  1. Like this one. 

  2. Amusingly, I had to fake this reference because my plugin switched it out with the unique one. 

Testing From the iPad  

If you happened to have caught this post a bit ago, you would have seen some generic content. I was testing how well I could post from the iPad to my Jekyll site. Since I’m using a git deploy mechanism, that means using an app called Working Copy, and some automation via an Editorial workflow.

I based my workflow off the work of Kirby Turner, adopting it to meet my needs. The big difference I have is that I started with an Editorial Document Template1 which creates the framework of the post. I can then write the post, click a button to trigger the workflow, and it’s committed to the git repo locally. Then I pop into Working Copy, double check things, and push the changes to my git repo to trigger the post.

That’s an extra step or two, but it’s actually not bad. It forces me to make sure I’m reviewing things before they go live. Besides, I don’t tend to post a lot of just quick posts, so this isn’t really any different than doing it at my desk.

I probably will start to poke around with another version of this, triggered from the Workflow app (not to be confused with Editorial’s workflows), that maybe will take the most recent photo, create a post, commit it, and ship it up to the site without too much interaction.

I like my iPad being a nearly full fledged computer. If I didn’t use my iPad so much, I’d update to the iOS 11 beta to take advantage of all the new iPad goodness.

  1. The only downside to this is that I don’t think Editorial document templates are sync’d between devices (the way you can sync workflows), which meant I had to rebuild it on my phone. Not the end of the world, but a bit more work than I’d wanted. 

Nintendo's License to Print Money  

It’s 2017.

There are at least two stories12on major tech sites covering playing old console games.

Nintendo has the rights to many, many of these games (as they’ve released them on various iterations of the Virtual Console). Plus an even bigger backlog of games from various other consoles they’ve licensed (or already own, i.e. the N64).

Nintendo has a major hit with the Switch. It’s portable and a home console. They’ll likely have sold upwards of 10 million Switches by the end of the year.

Just charge us $5-10 a month for an on-demand virtual console service. Even at $50 a year, I would expect that, even very conservatively, 10% of Switch owners would pay. That’s $50,000,000, or about a 1% increase in Nintendo’s revenue.

(Now, assume a more likely 25-50% attach rate, and you’re talking potentially a 5% increase.)

I’m sure there’s digital licensing issues, i.e. the deals they have with the various game companies covers certain types of digital distribution, but not others. Maybe Konami is going to want a slice of the pie for every subscription. But then there’s the Spotify/Apple Music model here; give the producers a tiny cut of each subscription (since they’re used to help the marketing), and then slice them off royalties when games are played.

There’s free money sitting on the table, and the sooner the game companies realize it’s from the streaming(-ish) model, and not from the “let’s package up Sonic for the 10th time and sell another full game”, the sooner they get to make money off of all of their legacy IP.

Nintendo (and, probably Sony and Microsoft, but Nintendo more than most because of their classic IP) literally has a mint sitting in front of them, waiting to start filling their pockets with new money as soon as they are willing to. Striking now, while they have a system that is still hot, would let them capitalize and make the Switch into an evergreen system.

(And would make me very happy.)

Alfred 3.4 Released  

Alfred 3.4 was just released and the snippets functionality is improved enough that I can retire TextExpander from daily use. There are still a handful of snippet features that TextExpander does better than Alfred, but when I looked through the snippets I used, I was more than covered with Alfred’s functionality. Alfred also seemed to handle the replacements faster than TextExpander did.

While I’m transitioning between roles, I’m spending a little bit of time paying attention to how I use my computer, where things can be optimized, what I need/don’t need. Moving to Jekyll was one of those things. I’m now looking at the various workflows I can simplify with Alfred.

If you don’t use Alfred, it’s worth picking it up.

Trumpcare: Taking Care of Everybody  

“I am going to take care of everybody. I don’t care if it costs me votes or not. Everybody’s going to be taken care of much better than they’re taken care of now” — Donald Trump 1 Both the House and Senate Health Care bills destroy health care for the poor and elderly.

More moderate Republican senators, such as Dean Heller of Nevada, expressed their own qualms, as did the American Hospital Association, the American Cancer Society Cancer Action Network and the Association of American Medical Colleges. “We are extremely disappointed by the Senate bill released today,” the medical school association wrote. “Despite promises to the contrary, it will leave millions of people without health coverage, and others with only bare bones plans that will be insufficient to properly address their needs.”

Make it difficult for millions of people to get affordable health care. That’s definitely better that what we have today.

Some senators have concerns based on other issues specific to their states, including the opioid epidemic that has battered states like West Virginia and Ohio.

You know which single health care insurer covers the most opioid treatments? Medicaid.

State with the largest number of opioid deaths? West Virginia. Percentage of population on Medicaid? 30%.

State with the third largest number of opioid deaths? Kentucky. Percentage of population on Medicaid? 28%.

State with the next largest number of opioid deaths? Ohio. Percentage of population on Medicaid? 25%.

Once again, this is clearly better than what we have now.

It would also repeal most of the tax increases imposed by the Affordable Care Act — a capital gains tax cut for the affluent would be retroactive for this year — to pay for expanded coverage, in effect handing a broad tax cut to the affluent in a measure that would also slice billions of dollars from Medicaid, a health care program that serves one in five Americans, not only the poor but almost two-thirds of people in nursing homes.

The poor and elderly getting kicked so that the rich can have a tax break. All negotiated in secret by a small committee of 13 white men and lobbyists.

Better for everybody is what that group has in mind.

Who benefits? It’s all about the tax cuts, almost half of which will go to people with incomes over $1 million, the great bulk to people with incomes over 200K.

So, is this bill good for you? Yes, if you meet the following criteria:

1.Your income is more than $200,000 a year

2.You have a job that comes with good health insurance

3.You can’t imagine any circumstances under which you lose that > job or income

4.You don’t have any family members or friends who don’t meet those criteria

5.You have zero empathy for anyone else

Paul Krugman, June 23, 2017 2 Think what you want about Krugman, but he’s not wrong. This isn’t about health care. It’s about tax cuts for the wealthy. It’s perfectly fine if, as a citizen or representative, you want to argue that this is the right thing.

But don’t try to package it up in fixing health care.

And don’t try to sell it as taking better care of everybody.

Quick WWDC Thoughts  

It’s been a couple of weeks since WWDC wrapped up and there’s a couple of things that stuck out that I found interesting.

All the iPad Stuff

I’ve written a bunch about the iPad. I really love and get a ton of use out of my iPad, to the point that it’s my travel machine. The limitation has always been that you can’t get “real” work done without jumping through hoops. Real(er) multitasking, drag and drop, and the new iPad Pro are all steps towards the iPad’s ultimate destiny: a daily computer for the vast majority of people. I could probably do 90% of my work off of an iPad at this point, but it’s a bit painful. With iOS 11, it looks like it will be a lot more comfortable.

iOS 11 and High Sierra (and Siri)

Setting aside the dumb name of High Sierra, both new OSes seem like reasonable advances. There’s a few little things in each (new Control Center, APFS, all the machine learning libraries) are really nice evolutions from iOS 10.

The small improvements to Siri (although the Omnifocus integrations are going to be awesome) are worrying. I actually think Siri is decent (and has gotten considerably better in the past 18 months), but there’s still far too much that can’t be done with Siri. Apple needs to find a way to advance the ball faster.1

HomePod

Once again, setting aside the dumb name2 I’m cautiously optimistic about the HomePod. We have a handful of Sonos speakers in our living room, and we love them. I use them all the time. However, the lack of voice control and native Airplay3means they take a bit more thinking to use. So, even though we have these big, powerful speakers sitting there, my wife uses her phone to listen to music.

It drives me batty.

So, a HomePod, with Airplay (well, Airplay 2), that my wife can tell to play whatever music she wants, plus HomeKit integration (we’ve got a bunch of HomeKit devices), and some Siri integration, works for us.

We have an Echo Dot, which is handy for things like checking the weather and random facts, but we don’t use it to do much more than that. The HomePod should easily be able to replace that, plus native integrations with calendars, reminders, etc., probably fit in our life better than the Alexa device does.

The downside: it’s expensive. Like more expensive than getting another Sonos speaker expensive. Won’t have more than one in the house expensive.

The price will probably come down over time, and it’s capabilities will get better (presumably), so I’m hopeful this is the smart speaker that will fit best into our home.

Particularly given that, with two babies on the way, a good hands free device will be handy.4

iOS/MacOS updates.

  1. Siri is (mostly) a web service. This is a case where it should get better faster without needing to wait for 

  2. It’s really not a good name, but I expect it will stop sounding weird in a few months. 

  3. I’ve worked around that with AirSonos, but that’s a pretty technical workaround. 

  4. Pun intended. 

End and Start of an Era  

Friday was my last day (by choice, for what it’s worth) at the job I spent almost 12 years at. At some point, I’ll write more about it. At the moment, I’m just going to talk about the fact that I left my job so that I could be around when our babies (yes, plural) are born. I loved my job and devoted a lot of time and energy to it. Taking a break to prepare, help my wife, and be around for the babies was one of the easiest decisions I’ve ever made.

While prepping for the babies, I’m also hoping to spend some time re-learning Ruby (and Rails) and learning Swift. So, over the next few months, expect a random smattering of thoughts around infants (turns out twins are more complicated than having a singleton, like the fact you start using the word singleton in a non-computer science context) and programming, particularly Swift.[^swift-0-4ab44988af578fabc53b06d67136149e] [^swift-0-4ab44988af578fabc53b06d67136149e]: I’m particularly curious about the new machine learning libraries in Swift.

Shiny New Look  

I’d been meaning to play around with Jekyll for a while. When I started this site in 2004, I built it on Blogger. Sometime in 2007, I think, I moved it to Wordpress. This site has existed on Wordpress in some way for the last decade.

Wordpress has been a great tool, and has evolved considerably, but it’s always been something that I’ve needed to pay attention to from a security and performance perspective. I’ve also taken to writing more markdown, which works with Wordpress, but not as easily as with some of the various static site generators (like Jekyll).

It took a couple of days to get everything ported over. I started with the Wordpress.com importer, used that to bootstrap the site, and then spent a bunch of time figuring out how to get started.

First up was a theme. I screwed up a couple of times here—this is something Jekyll does that’s a bit more complicated than I would have expected. Basically, unless your theme is in a Ruby gem, you basically drop it over your existing settings. It took me a bit to get everything figured out, but I used the Hyde theme as the base for my setup and did a bit of tweaking to get the look right.

From there, I started to play with a few different things. By default, Jekyll doesn’t have the ability to group pages/posts in an archive, but it does have a nice plugin to take care of it. With a little configuration, I had setup an Archives page that has my categories and monthly archives.

I’ve been trying to get footnotes to work nicer than they had previously. Again, there’s a nice plugin for that that will work on all my posts moving forward. 1 Once I got all this working, I started playing with how to do deploys. I’m using git, running on my server, to do deploys. It’s using an adapted version of the method found here. I push my site live, and it builds it automatically.

That whole thing works awesomely, except that my builds were taking almost a minute, which is far too long. I used the jekyll profiler to find out it was spending a lot of time in the sidebar. Basically, it was looping through every single post to figure out that I have a couple of them that are defined as pages.

Replacing this code:

{% assign pages_list = site.pages %}
  {% for node in pages_list %}
    {% if node.title != null %}
      {% if node.layout == "page" %}
        <a class="sidebar-nav-item{% if page.url == node.url %} active{% endif %}" href="{{ node.url }}">{{ node.title }}</a>
      {% endif %}
    {% endif %}
  {% endfor %}

with this:

<nav class="sidebar-nav">
  <a class="sidebar-nav-item{% if page.title == 'Home' %} active{% endif %}" href="/">Home</a>
  <a class="sidebar-nav-item{% if page.title == 'About' %} active{% endif %}" href="/about/">About</a>
  <a class="sidebar-nav-item{% if page.title == 'Archive' %} active{% endif %}" href="/archive/">Archive</a>
</nav>

sped up my deploys by 75% (from 60 seconds down to 15).

I also made link posts (like this one) a little easier to discern. It uses this character—⚐—to highlight that it’s a link post and give you a way to access the permalink (the little flag).

The site is a lot faster, has no active dependencies, and could be picked up and redployed almost anywhere with little effort.

I haven’t ported over my comments yet (that’s next). I’m not sure what I’m going to do, whether bring them over as static content and not offer comments moving forward, or import them into some system, but that’ll be a project for another day.

If you notice anything out of sorts, broken, or otherwise gummed up, let me know.

  1. See how nice this is? Also, at some point I’ll try to fix up the old footnotes. But this is good for now.