On Net Neutrality and Stupidity

by Rob Kitson

While trying to catchup on some work tonight, I happened to notice a quote equating net neutrality to the Obamacare of the Internet. As a diabetic, I think Obamacare is great but I'm having a hard time equating the two; honestly, Net Neutrality is about protecting consumers, startups, established businesses, and data (in general), from the predatory practices of a few monopolistic companies.

By now you probably know which jackass politician said this; if you don't you can Google it (or read my first quote below), I'm not going to do him any favors by linking to him/it.

This sparked a couple of relatively-heated Facebook posts from me. The first being:

What's on my mind? What a fucking idiot Ted Cruz is. How many times does he have to PROVE it?

How can the cable companies proposal to create a 'fast lane' on the Internet be seen as ANYTHING less than anti-competitive? Disruptive startups would find themselves priced out of the market before they could even get started because their established competitors would already have negotiated bulk discounts for 'fast lane' access, and would have the means to pay for the access. Net Neutrality is the only way to keep the Internet fast for everyone and to force new and existing services to innovate to keep/gain our business.

Honestly. How can any consumer of content on the Internet think this is a good idea?

I'm actually (kinda) at a loss for words.

Followed by:

Need a way to explain why Net Neutrality is good for you? Listen up, I've got a couple of scenarios that may help when talking to the uninformed (or misinformed).

SCENARIO 1: CableTown decides that they don't like that their customers will be able to get HBO GO directly from HBO because they will miss out on their cut, so they slow HBO GO streaming down to the point where it takes twice as long to load a video as it does to watch it. Forcing you to re-subscribe to HBO through the cable company so they get PAID.

SCENARIO 2: CableTown has inked a 'fast lane' deal with streaming video provider Netflix, but you prefer the selection at Flics'R'Us (who is either too new, or unwilling, to pay CableTown's exorbitant fast lane fees). Prepare for a life of watching the 'buffering' wheel because the only company you can buy Internet access from has decided that Netflix is a better choice for you.

I'm scared for our future as Internet users.

  • The role of CableTown is played by AT&T, ComCast, Cox, TimeWarner, Verizon, or any other relatively large customer-despising cable/internet provider.

I think that the scenarios that I present in the second post are what should scare everyone about the potential future of our Internet because they demonstrate the conflict of interest that IS being a content provider and a data provider at the same time. These companies have a vested interest in making your paid video streaming service experience worse than the equivalent service that they provide because (duh!) they make money from theirs and lose money when they're simply pumping bits around for other companies (Netflix, HBO GO, etc.).

Over the past 20+ years we have become accustomed to, and relatively comfortable with, the restrictions around which companies can provide us with Internet service (it can get pretty complicated, and I'm not going to go into the details here, so I'll just refer to these companies as ISPs). But that comfort has come from the fact that we've been able to decide who is providing our content (music, images, videos, IMs, websites, etc.) and have been confident that we've had unfettered and unthrottled access to that content because we paid good money to our ISPs for that Internet access. Knowing that our ISPs may soon have the ability to make back-room deals with other companies which will guide (nay force) me to make decisions about which other companies I give my money to, well that is simply an untenable situation which we cannot allow.

sudo gem install geektool_kit

by Rob Kitson

I've had a few spare cycles recently, so I've been messing around with GeekTool. The first thing that I did was look for geeklets that I could use or that would inspire me to create my own. I found a lot of shared geeklets on the Geeklets page at MacOSXTips.co.uk and remembered that Brett Terpstra had posted an unsolicited GeekTool showcase recently, so I took a look at both and installed a few geeklets from each.

After installing a few from the gallery at MacOSXTips.co.uk and re-creating Terpstra's 'Top CPU Processes' and 'Top RAM Processes' monitors, I found myself pretty comfortable with the process of sharing, installing, and running geeklets. Comfortable enough, in fact, that I started feeling friction.

I hate friction. One geeklet (or what appeared to be one geeklet) was actually comprised of 6 disparate geeklets that had been laid out in a very particular way. Since GeekTool doesn't allow you to select multiple geeklets at once, moving this composite geeklet after all of it's components have been imported is more effort than I'm willing to exert. The installation of some other geeklets require that you replace a substring in their massive conglomeration of piped bash commands in order to make the results relevant to you. Another one that bothered me used two geeklets to display one piece of information; one was in charge of displaying the information, while the other displayed nothing and simply used GeekTool to act as a cron, firing a script every few seconds, that changed the file that was going to be displayed.

After installing and configuring the two previously mentioned Terpstra geeklets, I noticed that the data in the right column (percent or size) didn't always line up even though I'd chosen a mono-space font. Instead of figuring out how to 'fix' his scripts, I decided to rewrite the scripts in a less script-y, more unit-testable, style.

This would be the part where you say "Wait a tic, I thought you said you hated friction?" and you'd be right, I did and I do. A rewrite does SEEM like more work/friction than necessary to accomplish my goal. But I didn't mention that I love unit testing and know that, done well, it can greatly reduce friction; given the option to write a script and run it a bunch of times to see how it may screw up, or to write a few tests that fully exercise the interesting parts of a class that encapsulates the functionality of a script, I'll take the latter any day. Unit tests, done well, are fast, repeatable, and their intentions are easy to understand. Running the script by hand to test for bugs require institutional knowledge of potential bugs, which does not lend itself to maintainability by anyone except the original author (provided they still remember what edge-cases they were coding around, and what to look for) or someone that has worked with the code for long enough to know how it's supposed to behave and when it should (and should not) break.

After breaking the scripts into a few well-tested classes, I fixed the intermittent spacing issues and put a half dozen specs in place to ensure everything works as expected. I quickly realized that, though I was totally comfortable having inter-file dependencies, sharing these files/classes/geeklets was going to introduce a similar amount of friction, that I was trying to avoid, to anyone that might want to use my geeklets. So I started thinking about ways to write geeklets the way I would write (and test) production code for myself or my employer, and how I could reduce the friction for people that would want to use, or extend, them. It dawned on me, relatively quickly, that an opportunity to reduce friction for GeekTool users had presented itself. My willingness to accept the challenge, that was the question.

Paternity leave has afforded me a few spare cycles recently and, though sporadic, I've been able to use those cycles to create a ruby gem called GeektoolKit and have kicked it off with scripts and geeklets for a CPU monitor, a RAM usage monitor, and a calendar of the current month (with the current day displayed in a different color). The source can be found on GitHub and the gem is hosted at RubyGems.org. Feel free to download, use, and submit pull requests!

Future Geeklets

I'm looking forward to incorporating versions of the most popular geeklets into GeektookKit over the next few weeks. Off the top of my head I'd like to have geeklets for CPU load averages, system uptime, a process monitor that would display CPU and RAM usage at the same time, current and fore-casted weather, the current song being played by iTunes or Spotify, a count of unread email messages, and the next few items in your todo.txt file.

Future Functionality

More than anything I think it would be cool to be able to generate a 'composite geeklet' by providing base coordinates and have the gem create the individual geeklets with the appropriate offsets so that we won't have to manually move multiple individual geeklets. I'd also like to have the individual geeklets automatically import themselves into GeekTool after being generated.

Coming to Grips with My Grips

by Rob Kitson

I was listening to "The Load-Bearing Finger", episode 84 of The Accidental Tech Podcst, when they (Casey, John, and Marco) started talking about the usability of the 4.7" form-factor that the new iPhone 6 is sporting. This wasn't the first time that I've heard people on podcasts describe how they hold their phones but it was the first time I'd heard a description of a phone grip while I was laying on my couch, using my phone.

One of the guys, I think it was Casey, was describing how he holds his phone when I realized I was holding mine the exact same way. Then I realized that this was probably one of those "a picture is worth a thousand words" situations, so I figured I'd take some photos of the different ways I hold my phone and put them on Twitter - this post is just a follow-up of those photos.

The photos I took feature my 5s, since I don't have a 6 yet, but I'll post an update when I get my 6-series (I still haven't decided on a size).

One-Handed Use

The majority of my smart-phone screen-time is spent with the phone in one hand or the other. As an ambidextrous phone user, I let the pocket that I'm holstering my phone in determine what hand is driving the phone that day.

I know that some people will ask why I don't simplify my life and just use the same pocket all the time. Beleive me, I wish I could. But as a pump-wearing diabetic, pocket priority goes to my insulin pump whose infusion-site (the place on your body where the pump delivers insulin) finds a new home on my abdomen every few days. These constant relocations mean my infusion-site is constantly switching between my left and right side. I don't wear devices on my belt, so the easiest way to manage the pump and the 3-4 feet of tubing that runs between it and the infusion-site is to simply put the pump in the nearest pocket and stuff the extra tubing in there with it - which displaces the phone every few days.

What I'm physically doing, where I am, and the task I'm trying to accomplish, all come into play when I'm deciding how I'm going to hold my phone when I take it out of my pocket: * Am I doing something active? * Am I in a crowded place, with bunch of trustworthy people, where I may bump into someone and accidentally drop my phone? * Am I in a part of town where someone may run by and try to grab my phone out of my hand? * Am I casually browsing content? * Am I playing a game that requires a little dexterity?

Passive Grip

The main feature of the 'passive grip' is that you use your pinky as a "load-bearing finger" - supporting the phone by its bottom edge, instead of wrapping it around the side with your other three fingers. It allows you to relax your grip on the phone without worrying as much about dropping it, but it also makes reaching the top of the phone much harder because you have to stretch your hand over it's entire height in order to get your thumb to the top.

I typically use this grip when what I'm doing requires relatively little interaction with the phone, activities like reading (blogs, email, Facebook, Twitter, Instagram, etc.) and light browsing (web, photo streams, my calendar). Activites that require enough concentration that when I'm doing them I'm usually either sitting, standing in a line, or laying down, so I feel comfortable using a more relaxed grip. I've also noticed that many of the apps that I use leverage gestures, and very little top-opposite-corner interaction so I'm not as concerned about corner-to-corner thumb stretches.

Left-Handed Passive Grip

Left-handed passive grip

Right-Handed Passive Grip

Right-handed passive grip

Active Grip

The 'active grip' involves wrapping all four fingers around the phone, which means how high you hold the phone is decided by where you decide to put your hand and not how far apart you can spread pink and ring-finger. Gripping the phone tightly, though, can make it difficult to hit the bottom-corner where your thumb is; using a more relaxed 'active grip' alleviates this a bit.

I find myself using this grip most often when I'm doing something 'active', like walking or running, for fear of tripping and dropping my phone. But I also find it comes in handy when I'm using apps that require more dexterity (tapping all over the screen).

Left-Handed Active Grip

Left-handed active grip

Right-Handed Active Grip

Right-handed active grip

Two-Handed Use

The only time you'll find me using my phone with two hands is when I'm typing more than a few words. In that case, I typically move my primary-hand toward the bottom of the phone and bring my other hand behind it such that my thumbs are at almost the same level and each bottom corner hits me in the palm of their respective hands. Two-handed grip

Hands-Free Use

Recently I've found myself using Siri, and the improved dictation, more and more often. Last week I dictated 2-weeks worth of action items into OmniFocus while walking my dog. I thought it went really smoothly, even though my dog kept looking back at me thinking I was talking to her.

99% of the time when I use Siri my phone is in my pocket and I simply hold down the middle-button on my headphone remote until I hear the telltale alert, then I tell Siri to do something and wait for her confirmation. The other 1% of the time my phone is plugged-in (on my desk) and I say "Hey Siri" and do the same dance with Siri as when I'm wearing my headphones.


by Rob Kitson

Unlike Casey Liss, I'm all thumbs when it comes to Emoji. Probaly because I suck at them. My infrequent use causes me to forget what my options are and where they are in the 'keyboard'. And, to be honest, I find the similarity of some of the faces to be too close and not entirely representative of what I'm trying to convey.

The other day, I saw Leveled Up Emoji, and realized I've been doing it wrong this whole time. I really like Casey's approach, taking the time to pick out and assemble some winners that I can mentally map to words is really going to take my Emoji-ing to the next level. I got a kick and a chuckle out of a lot of his shortcuts and was thinking some of them were great candidates to seed my own collection of Emoji shortcuts.

But I use TextExpander. So I re-created all of his shortcuts in TextExpander and have saved the folder so that, if you're a novice like me, you can import it into your TextExpander library and start your own collection.

You can download it here.

My thanks to Casey for the inspiration and the jump-start.

Upgrade Silverlight? Not like this.

by Rob Kitson

I was just prompted to upgrade silverlight, and (when I accepted) was redirected to a page that looked like this:

Screen Shot 2012-07-13 at 12.53.09 AM.png

Not the most complicated instructions I've seen. But seriously, it's 2012. Shouldn't our browser plugins know how to install themselve's by now? And shouldn't they know how to override their predicesors?

Tracking commits across branches in Git

by Rob Kitson

Recently I had to give a few colleagues a tutorial on how to figure out which branches a particular commit has been applied to in a Git repository. Not hard-core git by any means, but useful nonetheless.

Local Repos

If you want to see which branches in your local repo contain a commit use this command:

  git branch --contains <commit SHA>

The results, if there are any, should be a list of local branches :


In the example above the commit I'm looking for was a part of the work done on "feature_branch1", which has been merged to other_branch and master using merge branches. Since the changes were pulled into master (and I'm constantly pulling master to get the latest changes) the next time I branched from master to work on a new feature (other_feature_branch) the commits from feature_branch1 were included.

Remote Repos

If you want to see which branches on your remote repo(s) contain a commit simply add the -r switch to the command:

  git branch -r --contains <commit SHA>

The results, if there are any, should be a list of fully-qualified branch names:


In this case it appears that the work that was done on featurebranch1 and has been pull-requested to stage, and 3 new branches have been started since: acid_burn, crash_override, and zero_cool. It would be awesome if the engineer responsible for feature_branch1-TO-env_stage and feature_branch1-TO-other_branch would delete those merge branches since we still have the feature branch, and the changes have been merged to master. feature_branch1 should not be deleted until that feature ships.