the little things

I use a great extension for Chrome called Ghostery to block tracking cookies. It does exactly what I want - guards my data from advertisers - and it has a particularly neat feature where it displays what trackers it blocked in an overlay bubble in the corner of the screen at page load.

On some sites this bubble can grow quite large, so Ghostery lets you configure the bubble to disappear after a certain amount of time so you can access site elements under it. However, the only time-to-hide options that Ghostery gives you are 3 seconds, 5-through-30 seconds in 5-second increments, and 60 seconds. This was slightly irksome to me as I found I liked seeing what trackers the extension was zapping but didn't like being blocked from interacting with a portion of the page for a full 3 seconds.

Fortunately, Ghostery's options page uses the "Save"/"Cancel" button scheme to store changes (as opposed to doing any asynchronous save-changes-as-you-make-them shenanigans) so that "Save" writes the contents of the input elements on the page to file. I was therefore able to use Chrome's dev tools to edit HTML for the <select> dropdown containing the time-to-hide numbers, place my custom 1-second value in, and use the "Save" button like nothing was different. Because nobody at Ghostery cares how long you display your overlay bubble for, there isn't any logic to validate the input and my bubble now shows for precisely 1 second!

Now that was only a tiny hack, but it's significant because I couldn't have done it without basic knowledge of how web pages work. Somebody without that kind of technical proficiency - somebody like the average Internet user - would be forced to just shut up and deal, ever so slightly annoyed. This experience has therefore been a good reminder to me to keep my audience in mind when doing design work because though a user isn't liable to thank me for using an <input> text box instead of a <select> dropdown, they might very well be annoyed because I didn't.

being a bum and getting stuff done

I have been a bum. 

Ever since I came to college I've had spontaneous ideas and desires that excite me, and ever since I came to college I've managed to avoid acting on them. This is how it infallibly went: I would imagine how very grand this latest idea would be, I would imagine how much work it would take to make said idea grand, I'd tell myself that I'd get back to it later .... and then I'd proceed to play games on my computer until the idea fizzled away. And though I've nothing against playing games in moderation, I wasn't happy with what I was doing. The months passed, and though I regretted stifling myself with my own laziness, I was too apathetic to to do anything about it. As a result, I became increasingly despondent about ever becoming a true hacker. 

Desperate to break the nasty cycle, I finally reached out to Harper Reed (one of the key figures in running the tech side of Barack Obama's 2012 election campaign) after reading an article on The Atlantic about some of the awesome stuff he's done. Here's the email I sent him:

Hi Harper,
I came across the article The Atlantic did about you and your team during President Obama's campaign, and you seem like a pretty chill guy who's been coding his entire life. I'm a 21 y/o computer science student right now and, though I've got more than a few ideas on things I'd like to build, I always found myself getting bogged down by lack of motivation from gaming or hanging out or whatnot. So a quick question for you: if that sort of thing has ever happened to you, how do you go about getting out of it? How do you motivate yourself to push forward and just get stuff done?
Best,
Kevin Today

And his response:

Getting stuff done. 
This is really hard.
Honestly, the best route is to just find something that matters to you and do it. i don't really play games, so i can't talk to that insanity - but there will always be distractions.
here is my rule of thumb: touch code everyday.
that is the best plan.  

That was it. But somehow, this little piece of advice clicked with me: if you want to do something, go and do it. I would work myself up thinking about all the time I'd spend on my new idea and fall back on gaming because it was just easier, but amid all the tallying of potential hours lost I'd lose of the real goal of having fun through learning. 

In the days going forward, I resolved to make a change - and only a tiny one at that. If I ever felt the urge to do something, I would simply go and get started on it. If that was learning a new language then I'd install the compiler. If it was building an app then I'd pop into Vim and start building a skeleton. Amazingly, that little resolution worked: I found myself wanting to continue my projects, and my desire to go and waste time began to subside. I even began to feel better. I stopped beating myself up over lost ambitions, and I started acquiring the gumption needed to getting something going in any aspect of life. 

Now, if something bothers me I try to fix it. I am more productive and less complacent. I feel energized, in control, and proud. And in the sixteen days since November 20th when I received Harper Reed's response I have pimped my Ubuntu to where I finally want it, started building my own network-attached storage box, taught myself basic competency in Ruby on Rails, Python, and Bash scripting, and coded up a hundred-odd-line Bash script that will be my first finished Github project. In short, I feel that I've taken the first baby steps on the road to becoming a true hacker. 

So though I'm undoubtedly preaching the same thing self-help gurus have taught since time immortal, I beg anyone who has a similar story: just jump in and do it. I promise you won't regret it.

Photo courtesy of rubybgold on Flickr

Google fiber and venture capital

The United States' ISP business has been in a strange place for many years. Giants like AT&T, Time Warner, and Comcast hold massively dominant market shares, and though large pie slices aren't of themselves prohibitive to rival companies - small, local service providers do exist - the high cost of setting up a data grid is a significant impediment to competition. Coupled with little FCC regulation and much to gain in profits, the cost of Internet service has remained artificially high in the United States when compared with other parts of the world.

Enter Google Fiber. While much has been promised and little delivered so far, the initiative is bold enough that it just might lead to real disruption in the industry. For a one-time $300 installation fee, any home in the targeted Kansas City area could have unlimited 5 Mb/s Internet - a speed just at or slightly below the entire U.S. average, depending on which year your data is drawn from. And though Fiber's 1 Gb/s offering is enticing, the $70-per-month price tag is the truly revolutionary part: Comcast's and AT&T's most cost-efficient service options were 20 Mb/s for $29.99 and $19.95 for 6 Mb/s monthly respectively. Quick division yields $1.50 per Mb/s every month for a Comcast subscription, and $3.32 per Mb/s with AT&T. To contrast, a paid Fiber Internet subscription of $70 for 1 Gb/s will run a user $0.07 per Mb/s. Those are some crazy numbers.

Here's the catch: Google - like the local contenders - must deploy its expensive infrastructure, and that takes time, money, and support. To maximize construction efficiency and ensure a profitable venture, they're wisely deploying only in neighborhoods that have enough subscribers. However, registration to become fiber-enabled is only available to residents of the Kansas City region. 

Now imagine that Google provides people outside Kansas City the ability to make non-refundable investments (i.e., money would be lost if Fiber fails) in some affordable dollar range and receive a proportional discount on their first year or so of paid Fiber subscription. Essentially, give the rest of us the power to be Google's angel investors. The win-win scenario is evident: 

• Google receives a welcome boost of income from readily-available resources during this critical, experimental phase of the project's life
• Enthusiasts get to personally advance the project toward nationwide deployment while receiving a discount when expansion comes
• Google's financial department can more accurately gauge interest and potential future subscriptions
• Google has ultimately accumulated no extra risk should the initiative fall flat

With the right incentives and a little marketing, Fiber could gain the momentum it needs to mount a bigger assault on the existing stable of ISPs.

likes, follows, and subscriptions

Maybe I'm particular. "Ornery" probably wouldn't be a far stretch. But the epidemic really has gotten out of control. Of course, I'm speaking of the "You should follow us on <insert social media here>!" banners that dot the bottoms of innumerable blogs, corporate websites, and products everywhere.


Now, I understand the logic behind these miniature billboards; they serve as a reminder to the viewer that he would probably like other things that the content producer has to offer. In this chaotic, information-drenched age, we're likely to forget to press that precious "subscribe" button anyways, right? And if that happened, we might miss  something that we're interested in! How fortunate we are, then, that the producer prodded us with their wonderful, embeddable icons. 


Snark aside, "Follow us here!" notifications aren't really about what you'd like; they're advertising. This might seem obvious, but it's worth pointing out because advertisements are generally bound by implicit rules. Two of these are particularly relevant:

1. Don't disempower the user. Declaring "You should buy MotoFlex Oil!" in your ad sounds like it originated from Don Draper's firm and simply wouldn't fly in 2012. If a consumer buys MotoFlex and remembers your ad, then he's merely a slave to propaganda in his mind and he'll resent it. But if your billboard reads "MotoFlex Oil has been ranked tastiest by OilGuzzlers weekly 5 years in a row", no imperatives are given; the consumer is satisfied that he has a free will and the power of choice. Furthermore, you as the advertiser have both reminded the user about your product and given a compelling reason as to why a purchase should be made.
2. Don't be annoying. As anybody who's received spam mail, seen Flo of Progressive, or heard the Geico pig can attest to, obnoxious advertising will leave a distinct negative impression on the viewer. Sure, he'll definitelyremember you - but as that one company with that one commercial that he hates. Not exactly the best PR, and he might not purchase your product just to spite you.

Let's take these tenets online: am I annoyed by these "Like us here!" banners? This answer might change depending on the person, but I'm guessing the general consensus is 'yes'. After all, the icons have become as near a fixture of the web as CSS. Now, the big one: are the banners telling me what to do? Absolutely yes. Just as in our second MotoFlex Oil example, you've probably already been given a reason for why you should like the media producer (e.g. you read to the bottom of the article, bought the product with the banner on the label, or watched the video all the way through). But instead of respecting you, the viewer, enough to acknowledge that you know when you want to subscribe for more of something, the producer thinks he has to tell you to get your +1.

Here's the error though: by the time the viewer sees the banner, he will have already evaluated your content. If he likes it, all you need to do is point him to the right medium for more of it and avoid scaring him away. If he doesn't like it, demanding that he subscribe can only harm you. To fix this advertising faux pas, change the hackles-raising "Make sure you follow us here!" banner to something more agreeable, like "For more terribly-written content, follow DarthVader here!" The revised version is original enough to stand out from every other copy-pasted banner, and it gives the user back his perceived freedom of choice. Ultimately, the viewer is happier and you have higher conversion rates.


Since you liked this post, you absolutely want to join my guild in Dark Age of Camelot!

why you shouldn't do things in your constructor

Last week I needed a free HTTP server for a project I was working on at my job.

Naturally, most folks would suggest Apache here, but I had the caveat that my server's footprint needed to be very low - no bells or whistles. After adventuring through Google for a while, I finally turned up a cute little free-to-use thing, a single Java .class file called NanoHTTPD. It was an ultra-lightweight HTTP server, built off the core ideas of the HTTPD monster but without all the bulk - where Apache is the big brother, NanoHTTPD is the anemic, weaselly stepchild. Simply compile and run the class file and you have a working web server on your machine. Need more functionality? Easy as cake: just override the "serve()" method, called when the server process an HTTP request. It was perfect.

All was proceeding as planned - I was extending the NanoHTTPD class and overriding "serve()", just as the creators intended - when I came across a problem. I had added several member variables to my subclass, so I had some initialization that I needed to do before the server ran. Problem was, calling NanoHTTPD's constructor was the trigger that started the server. But better yet, the creators didn't implement a default constructor. Any constructor I wrote would be forced to call "super(foo, bar)" as its first command, which would send the whole shebang on its merry way to serve the Internet's web page appetite.

There's a lesson to be learned here: never do non-initialization stuff in your constructor. NanoHTTPD didn't follow that rule, so it created a pseudo-final class for anyone in a situation like mine - in other words, completely defeating the purpose of an extend-as-necessary, bare-bones implementation. Pulling the server start code out into a separate method to be called after instantiation would have been trivial to do, yet such a small omission caused a good-sized headache on my end.

Whenever you're tempted to fudge other things into your constructor, remember the name of the method: constructor. It builds things; don't make it do more than that (I'll bet you'd get a hammer to the head if you tried to make a builder run a server anyhow, as you rightly should). When in doubt, extract the code into a public method and let the developers who build on your code decide when to use it. I guarantee they'll thank you.

As for my project, I was fortunate enough that NanoHTTPD was licensed under the Modified BSD license, so it was free-to-modify as well as free-to-use. I finally ended up copying the whole source code over to my project and began directly modifying it from there... no calls to "super" needed.