How America Went Haywire - The Atlantic

Link

It will require a struggle to make America reality-based again. Fight the good fight in your private life. You needn’t get into an argument with the stranger at Chipotle who claims that George Soros and Uber are plotting to make his muscle car illegal—but do not give acquaintances and friends and family members free passes. If you have children or grandchildren, teach them to distinguish between true and untrue as fiercely as you do between right and wrong and between wise and foolish. We need to adopt new protocols for information-media hygiene. Would you feed your kids a half-eaten casserole a stranger handed you on the bus, or give them medicine you got from some lady at the gym? And fight the good fight in the public sphere. One main task, of course, is to contain the worst tendencies of Trumpism, and cut off its political-economic fuel supply, so that fantasy and lies don’t turn it into something much worse than just nasty, oafish, reality-show pseudo-conservatism. Progress is not inevitable, but it’s not impossible, either.

A fascinating historical perspective of how we got to where we are today by Kurt Andersen writing for The Atlantic. Andersen focuses on how the counterculture movements of the ’60s morphed into a widespread belief in conspiracy theories adopted and expounded on by the right. Long, but well worth the time.

The company isn’t a family – Signal v. Noise

Jump to Post

You don’t have to pretend to be a family to be courteous Or kind. Or protective. All those values can be expressed even better in principles, policies, and, most importantly, actions

I’ve worked with companies that do this, and it always felt… weird. I didn’t want to have a family, I just wanted to do great work for an organization with a mutually beneficial arrangement That’s not to say that you can’t form close bonds with those you work with, or have a deep appreciation for the company you work for, but it can never, and should never, take the place of your actual family.

Serverless Jekyll Hosting on AWS

This is a bit silly, I’ll be the first to admit. The contraption I’ve built to host this site is clearly unnecessary, especially when I could host the site on Github for free, with very little effort, but I was curious, so down the rabbit hole I went.

I thought it would be interesting to host my site on S3. The site is entirely static, no database back end or dynamic programming required to generate the site, it’s just HTML, CSS, and Javascript. I also wanted to understand the AWS CodeBuild service, and how I might be able to use it for other projects.

There are four components of this system: Github, which hosts the code for the state. The domain name is registered and managed through Route53, where I’ve configured an “A” record as an alias to point at the S3 bucket which hosts the site. Finally, CodeBuild is the glue which pulls the code from Github, runs jekyll build, and pushes the site to S3.

CodeBuild works by starting a Docker container and pulling the repository down. It then looks for a file named buildspec.yml which contains the instructions to build the project. This file contains arbitrary Linux commands, whatever you need to build your code. Mine looks something like this:

version: 0.2env:  variables:SITEBUILD: "yes"phases:  install:commands:apt-get update -y  pre_build:commands:gem install bundler    bundle install  build:commands:echo Build started on date    bundle exec jekyll build    aws s3 sync _site/ s3://jonathanbuys.com  post_build:commands:echo Build completed on date

The interesting thing about this system is that I could replace Jekyll with Hugo, Hakyll, or any other static site generator, even my own scripts, and the system would stay the same. I’d just need to update buildspec.yml with the new commands to install the right tools and build the site. Hosting costs so far have been pennies, my cost this month might reach $1.27, and for the past couple months the cost has been below one dollar.

I’ve been considering making this system more user friendly and monetizing it somehow. There’s a business model to be had in here somewhere, if I care to pursue it. Even though blogging in general appears to be in somewhat of a decline, publishing platforms will always be needed.

Recommending a New Mac

I got an email from my mom the other day asking me for a recommendation on a new Mac. The first question I asked was what her budget was like. She said she’d like to keep it under a grand, which right away narrowed the field quite a bit. Next I asked what she would be using the machine for, to which she replied with the standard home use cases of “income taxes, email, scanning, internet, etc”, as well as printing to a Brother ink jet.

At first glance, it would seem like she would be the perfect candidate for an iPad. Modest computing needs, tight budget, and she doesn’t want junk. Or, in her words, “I hate slow computers but don’t need top of the line either.” I considered steering her towards an iPad, but that first item in the list of things she uses a computer for gave me pause, “income taxes”. I don’t know exactly what software she uses to do taxes, but I started imagining scenarios where she would run up against the edges of what the iPad, or more specifically, iOS, can do. Would she need to download and import files from banks? Would she need to read files off a USB drive? She’s into wildlife photography in Montana, how would she get the photos on the iPad?1 My mom’s no slouch, but she’s not Federico Viticci either. Pushing the boundaries of iOS is not what she cares to be spending her time doing.

I imagine Mom just wants to use a computer like she’s been doing for the past thirty years. Given the budget, and after eliminating the iPad from the equation, I briefly considered the desktop options. Of course, all of those were thrown out almost immediately. The iMacs are too expensive, the Mac Mini is too slow, and the Mac Pro, uh, no. That leads us to the laptop line. The MacBook Adorable was considered, then eliminated for lack of ports and high price. The new MacBook Pro also suffers from a lack of standard ports and a price tag that’s far too high. That leaves us with the venerable MacBook Air.

The Air has been Apple’s best laptop, and possibly best computer period, for years. While the MacBook Pro is the workhorse of the lineup, the Air’s svelte styling and weight paired with an affordable price tag to make an extremely compelling offer. While the MacBook Adorbs is beautiful and portable, Apple is pushing the envelope with the single port, and consumers are footing the bill for the new technology with a higher price. While the Air is plenty fast enough for all but the most demanding tasks, I’ve heard more than one user complain that the mobile chip in the MacBook Meh is sluggish. Jony’s styling doesn’t win out over performance with my mom.

In the end, I found a 13” Air with 8GB RAM, 128GB SSD, and an Intel i5 for $850 on Apple’s refurbished site. I think Mom will be happy with this machine for many years to come.

Next, my daughter and I are going in on a Mac for her to take to college. That’s an entirely different set of requirements and a different use case, one that I’ll follow up with here, as soon as we decide what to get.

  1. Yes, I’m aware of the dongle. It seems like a wonky workaround. ↩︎

The Case of the Stolen Source Code

Jump to Post

So, I managed to download within the three day window during which the infection was unknown, managed to hit the one download mirror that was compromised, managed to run it and breeze right through an in-retrospect-sketchy authentication dialog, without stopping to wonder why HandBrake would need admin privileges, or why it would suddenly need them when it hadn’t before. I also likely bypassed the Gatekeeper warning without even thinking about it, because I run a handful of apps that are still not signed by their developers. And that was that, my Mac was completely, entirely compromised in 3 seconds or less.

This is how you handle a compromise in your systems. Full transparency, an explanation of how it happened, how they are handling the issue, and how their customers can stay safe. Panic, once again, doing the right thing.

JSON Feed

Jump to Post

We — Manton Reece and Brent Simmons — have noticed that JSON has become the developers’ choice for APIs, and that developers will often go out of their way to avoid XML. JSON is simpler to read and write, and it’s less prone to bugs. So we developed JSON Feed, a format similar to RSS and Atom but in JSON. It reflects the lessons learned from our years of work reading and publishing feeds.

I guess I’ll know it’s time to leave my favorite news reader when this format is adopted by Daring Fireball but not supported by NetNewsWire.

My Next Mac

So, yesterday I cleared off my desk and tried to work with nothing but my MacBook again. No standing desk, no external monitor. It looked great, but honestly, it felt terrible. I wound up hunched over the desk staring down at the screen. After an hour or so of this I decided, yet again, that this style of work is just not appropriate for me.

This leads me to a few interesting conclusions when considering what to buy for my next Mac. For one, I find a larger screen much easier to work with. The smaller screen is fine for when I’m loafing on the couch or traveling, but for day-to-day work it just makes getting things done harder. Secondly, the screen needs to be lifted to an ergonomically appropriate height. Photos online of beautiful desks with a single MacBook Adorable, a notebook, and a cup of coffee are nice, but I can’t see how anyone gets any serious work done on the computer in that environment. I always assume that whoever works that way doesn’t spend the majority of their day staring at the screen like I do.

So what’s next for me? I’ve been toying with the idea of only using an iPad Pro, and while I think I could work on it just fine, the overall experience would be ergonomically strenuous, and the workflows frustrating. The iPad shows promise, but until I can hook it up to an external keyboard, monitor, and touchpad, it’s not for me, not yet.

I love the look of the MacBook, but I just can’t work with it. I could leave it plugged into my external monitor all day, but there are a host of issues with that too. My monitor, a 24” Dell 4K, looks great, but it doesn’t have a built-in speaker or iSight camera like the old Apple Thunderbolt Display I was used to working with. The resolution is good for staring at text all day, but every time someone I work with wants to do a video conference or something similar I’ve got to either fish out my USB webcam or unplug the laptop. I could leave the laptop open to the side of the display, but I like having a single monitor to concentrate on.

Then there’s the wires. I’ve got a USB hub stashed in my desk drawer, which is plugged into a ScanSnap and a hard drive. The monitor needs power and a plug into the MacBook. The MacBook needs power. There’s too many wires.

Finally, since I have no speakers when the Mac is closed, I have an Amazon Basics bluetooth speaker on the shelf behind my desk. That works fine as long as I have sound being streamed to it. If I go for more then a few minutes without sound, the speaker turns off, which means I have to flip the switch on it to get it to pair again. Not ideal.

So, when considering my options for the next computer, I think there’s really only one choice considering my requirements.

  • As few wires as possible
  • Built-in iSight camera and speakers
  • Large Retina screen
  • Ergonomically correct for long periods of work

Sounds like an iMac to me.

Install Gems Without sudo in macOS

I came across a neat little command line tool via Rob Griffiths’ Robservatory this morning, a Ruby gem named iStats1. Install is easy enough in Rob’s example, sudo gem install iStats, except that when you use sudo to install gems you are using the default macOS Ruby, and installing to system paths.

  ~ /usr/bin/gem environment                            RubyGems Environment:RUBYGEMS VERSION: 2.0.14.1RUBY VERSION: 2.0.0 (2015-12-16 patchlevel 648) [universal.x86_64-darwin16]INSTALLATION DIRECTORY: /Library/Ruby/Gems/2.0.0RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/rubyEXECUTABLE DIRECTORY: /usr/local/binRUBYGEMS PLATFORMS:    ruby    universal-darwin-16GEM PATHS:    /Library/Ruby/Gems/2.0.0    /Users/jonathanbuys/.gem/ruby/2.0.0    /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/gems/2.0.0GEM CONFIGURATION:    :update_sources => true    :verbose => true    :backtrace => false    :bulk_threshold => 1000REMOTE SOURCES:    https://rubygems.org/

While that might be fine, my personal preference is to keep the core system as close to default as possible. I once ran into an issue keeping Jekyll up to date, so now I use the excellent Homebrew to install an updated version of Ruby and keep the gems in /usr/local, which is entirely mine and safe to write to.

brew install ruby

Also, I make sure that /usr/local/bin is called before /usr/bin in my shells PATH variable.

export PATH=/usr/local/bin:~/Unix/bin/:$PATH

Now I can call gem install iStats and the gems will be installed safely, keeping my core system clean and my gems easily updatable.

  1. As Rob points out, this is apparently not associated with iStat Menus↩︎

Free is Never Free — MacSparky

Jump to Post

Indeed in this case, where unroll.me is owned by an analytics service, it appears that the entire purpose for the service is to get access to user email data for monetization. So apparently Unroll.me, with access to its user email accounts, collected their Lyft receipts, anonymized them, and sold them to Uber. I’m pretty sure people signing up for unroll.me don’t expect that to happen.

David reinforces a point that we have heard so often it’s become cliché, “if you aren’t paying for the product, you are the product”. Shortly after reading this post I saw a recommendation for Readdle’s free Spark mail client. I’ve given it a try in the past, but it didn’t suit me. After reading the privacy policy, I think I should probably go back in and properly delete my accounts. From what I can tell, Spark:

  • Several analytics packages:

We use third party services, such as Google Analytics, Facebook Analytics and Amplitude, to collect and analyze how you use Spark. These services may collect information about you and your usage of Spark in accordance with their respective privacy policies.

  • Uses my primary email address to send me spam:

We might use that email address to reach out to you periodically with information about features, updates, announcements or to request your feedback.

  • Stores my email username and password on their servers:

Where OAuth is not supported we keep your account username and password on our secure servers.

  • Downloads my email to their servers:

We then use the authorization provided to download your emails to our virtual servers and push to your device.

Readdle goes on to explain that they primarily use the email headers to send push notifications for new mail, that they do not sell your information to third parties, and that you can unsubscribe to emails at any time. Readdle makes some great apps, ones that I use quite a bit, but I wish they’d reconsider using server-side processing for Spark. If they worked out a way to do what they needed to do on-device, Spark would be a much more attractive option for my email.