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


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 Airplay3 means 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.1

  1. 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 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>

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. 

Getting to CD In An Org Predisposed To Hate It  

I thought this presentation by Dan McKinley was really interesting and resonated heavily with my experience in helping to shepherd an organization that was pendulum swinging from everybody hacking production, to nobody getting to do releases until you filled out a form in triplicate, to an org that was doing 8–10 releases on most days.

We never got to continuous delivery (CD), for a bunch of reasons, but mostly:

  • Cultural (it scares the crap out of the systems and support teams, even if it might be better for them)
  • Technical (it requires good tests and good dev/beta systems, and we’ve always been underinvested in the resources to help there)
  • Organizational (we’ve rarely settled into a structure that allowed our teams to develop the discipline)

But we did continually get better, and I’m guessing in another year or so, with the right people pushing, I don’t think a real CI (continuous integration)/CD pipeline is unreachable.

Some bits from the presentation that were particularly resonant with me …

Namely, we had a lot of process that was prophylactic. It was built with the intent of finding production problems before product

As your organization gets bigger (and not even, like, really big, but just bigger), there are lots of people who think their job is to protect the production org by creating all sorts of process to make it really hard to get something to production. In reality, all that process just makes people pay less attention, not more attention. There’s always somebody else who is more responsible for the code going live, being tested, being right. The further away you are from being on the hook, it’s natural that you pay less attention.

Which is why, smaller, more frequent releases, with less friction and less overhead, makes a lot of sense. It’s your responsibility to make sure you don’t break production, and if you’re going to be responsible, don’t you want to make smaller bets? That leads to this tenet …

Deploying code in smaller and smaller pieces is another way. In abstract, every single line of code you deploy has some probability of breaking the site. So if you deploy a lot of lines of code at once, you’re just going break the site.

And you stand a better chance of inspecting code for correctness the less of it there is.

There’s a lot of goodness in this presentation, resulting from the scars of helping to drag an engineering team into something that works, that has buy in, and increases the velocity and performance of the team (and helps keep everybody happy because they’re working on stuff that actually gets to production). There’s some bits towards the end of the presentation that make sense for one big team, but less sense for multiple teams. Multiple teams is a huge way to help solve this problem. If you can break up your application into smaller, separate applications, or services, or microservices, or trendy term du jour, then you can reduce your dependencies between teams.

That lets each team reduce it’s risk and some teams can ship 50 times a day, and some 10, and some 2. It increases a bit of coordination between teams, but with good documentation and smart API design (ideally with good versioning so that team releases don’t have to be coupled), you can get to a point where teams can all be really efficient and not beholden to the slowest of teams.

Anyway, it’s a long presentation, but I think it’s a really great, real world example of how to get a big challenging org into CD (or at least on the path to it).

Making RSS More Readable  

The JSON Feed format is a pragmatic syndication format, like RSS and Atom, but with one big difference: it’s JSON instead of XML.

For most developers, JSON is far easier to read and write than XML. Developers may groan at picking up an XML parser, but decoding JSON is often just a single line of code.

This is such a good, simple idea. In general, I hate dealing with XML (I actively bias against SOAP interfaces too). JSON isn’t more verbose than XML, but is decidedly easier to read, and far less fragile. I’ve added JSON feed to this very site.

"The Miracle on Dirt"  

Really loved this little documentary on Virginia Tech softball’s no hitter over Team USA. Amazing numbers from that article:

It was the American team’s first loss in a pre-Olympic exhibition since May 3, 1996. During that span, the U.S. team outscored opponents 1,475–24.

Angela Tincher is one of VT’s greatest athletes (and she should have been pitching for Team USA …). I remember following the team intensely that season.

Look Where We Went  


Random things that have been collecting in my brain the last few weeks:

  • The last time I headed abroad, I realized AT&T had finally caught up to the competition and offered a reasonable international plan (use your data, $10/day).
  • I also realized I didn’t want to waste my data on stupid things I could wait to pull over wifi, so I made it so a bunch of apps could only update over wifi (most notably, Facebook). A couple of months later, when only using Facebook over wifi, and only using it sparingly (I’m ready to be done with Facebook), I noticed I’m using about half as much cell data as I was before. Thanks, Facebook, for preloading all your shit content, and for your huge app updates.[1]
  • I traded in my hybrid for an electric Chevy Bolt. It’s been a pretty interesting experience (more on that in the future), but I did find one odd bug: plug in your iPhone (after using Carplay) before the car is turned on, and it doesn’t seem to be able to boot the Infotainment system. Unplug the phone, and life is back to normal (and then Carplay is usable again when you plug it back in).
  • I’ve enjoyed listening to Crimetown, one of Gimlet’s many podcasts, but their production schedule just destroys my ability to remember what’s going on. Same goes for StartUp. Anything that’s sort of serialized just gets trounced by the seemingly random release schedule. I think the all-at-once-model (like for S-Town) is much better for stories that are serial. Or, at least be ready to release it every week.[2] I probably should have just saved up all of Crimetown and binged it.
  • I bought a Zelda-Mario Player. It’s really fun.

  1. Time to switch to the mobile web interface, perhaps.  ↩
  2. The on-off schedule is fine for non-serialized shows like Science Vs. and Every Little Thing.  ↩