It's time we had a talk about the news.

From the first time I heard a modem chime, I've been on a mission to discover, curate, and editorialize as much news as possible. Over the years, I've written for a variety of outlets — called "web sites" at first, then "blogs" for a while, and now subsumed by the lifeless social media platforms to which we all contribute. From the mid-nineties until I graduated college, I slowly optimized this information funnel — broadening the aperture of content I could absorb each day, while tightening my own editorial voice. Being informed calmed my anxieties about the unknown world, whereas honing a distinct persona gave me a sense of control as I navigated it.

But optimizations that lack a limiting factor run the risk of becoming too successful. My voracious appetite for novel content was so far outside the norm that a developer working on Google Reader once contacted me to ask what I was accomplishing by using the service — apparently it was unusual that I'd been reading an average of 900 articles a day at an uninterrupted pace for over 7 years.

You'll never guess what happens next…

The degree to which we're constantly connected via our phones is well-documented, thoroughly-researched, and intuitively understood by over a billion people. But we tend not to do much about it, because the benefits of being connected seem far more concrete than the relatively intangible benefits of being disconnected.

This week, I was forced to reckon with this in a stark enough way to convince me to take action.

Let's dive in and find out…

I often tell people the only reason I blog or speak is to guard against having the same conversation over and over again. So, here I go again:

• The first thing I eat every day is dinner, meaning I don't eat breakfast, lunch, or daytime snacks
• I run 3 miles every day, without exception. In spite of my travels taking me all over the world, I'm pretty sure I haven't missed a run in two years

Doing these two things has improved my health considerably, saves a lot of time and money, and has improved my ability to focus on my work.

To be continued…

As an American that's regularly traveled to Japan over the past ten years — in trips ranging from 2 weeks to 7 months — I've accumulated a few observations and tips that have made getting around significantly easier.

Travel Light

I travel with a carry-onable back pack. Anything larger would be obnoxious when negotiating trains/bus stations. Specifically, I travel with an Osprey Porter 46. Even with that, I usually plan my day around dropping it off as quickly as possible (even if it's prior to check-in, hotels will always hold it for you). Large, hard-shell rolling luggage is popular in Japan but since they're probably only taking it straight to the airport or back, the same strategy wouldn't make much sense for touring Japan itself.

If you ever need to ditch your bag before arriving at wherever you're staying, search any major train station for coin lockers large enough to cram it in (coin lockers are typically deceptively deep and spacious). Typically, you insert your bag first (to ensure it fits), then insert coins to engage the lock and release the key. Increasingly, coin lockers are going digital, able to break change or pay with ICOCA/SUICA and alert you to other locker locations with vacancy, often printing a claim receipt with a keycode to unlock your locker with. All coin locker payments are per-use, so once you unlock your bag, you'd need to pay to use it again. If you can't find a bay of coin lockers, try asking a station employee: "コインロッカーはありますか？(coin-row-kah wa ah-ree-mahs ka?)".

Keep reading…

After spending 3 weeks abroad, literally afraid of opening anything resembling an article in Safari, I was eager to come home, install a beta operating system, and take advantage of iOS 9's now-famous content blocking API. There are a few projects on GitHub that do this, but the most evolved seems to be Block Party.

Let's try out installing a content blocker on an iPhone for ourselves. The instructions below are mostly complete and a bit inane, so it's up to you whether you're better off just waiting the 4–6 weeks until iOS 9 is released to the public.

First, there are some pre-requisites:

• Install iOS 9 beta; I'm using Public Beta 3 from beta.apple.com
• Install Xcode 7 onto a Mac (requires dev account)
• Clone or download a ZIP of the BlockParty repo

With these in place, it's time to open BlockParty.xcodeproj

Okay, I'm interested…

If you're reading this, then perhaps you enjoy having fast, easy access to the Internet. If so, and you're heading to Japan anytime soon, then perhaps this guide will be of use to you.

When traveling to Japan, access to their mostly-excellent wireless network is not always easily attained. In the past, I've used T-Mobile's free unlimited international roaming as well as mobile hotspot rental services, but both have significant drawbacks — extreme throttling and terrible battery life, respectively.

Here, I'll document a much more convenient way to get Internet access, by way of purchasing a prepaid data-only SIM card. First, a few prerequisites:

• An unlocked phone that can join international GSM networks (this guide covers my use of an iPhone 6, but virtually any GSM smartphone is supported)
• The means to make your way to the first floor of a Yodobashi camera, though other electronics stores ("Denkiya-san") may work as well
• (Somewhat ironically) an Internet connection, to download a configuration profile
• Roughly $35

Okay, I'm interested…

They're a million million worlds. All different and all similar. Constants and variables. -Elizabeth, Bioshock Infinite

A lesson I learned early in my career as a programmer was to be wary of accidental creativity. If you're the type of person who really cares about getting the details right, it's critical to first decide which details truly matter. Not doing so is a recipe for endless frustration, as one will inevitably be distracted and defeated each day — sweating more arbitrary decisions than meaningful ones.

There is a bunch of prior art on this point, from studies on the paradox of choice to cognitive depletion and even Steve Jobs turtleneck lore. It's pretty intuitive, after all, that eliminating routine decisions should free up energy for our brains to do other (presumably more valuable) things. However, we tend not to see many interesting examples of the types of constants people set for themselves. And even more importantly, there is rarely discussion on the aspects of our lives that people might intentionally keep variable.

I guess I'll go first.

Content warning: more content…

When I'm trying to read my iPhone (or iPad) in bed, I'm liable to wake up my spouse with the device's backlight, even when the screen is set to its lowest brightness setting. Moreover, it's hard for me to fall asleep immediately after staring at a relatively bright screen.

Up until last night I thought I was just out of luck unless I installed flux, which would never be worth the security and stability issues raised by jailbreaking a device. Fortunately, Olivier Lacan commiserated and relayed a tip that iPhone's accessibility settings can be lightly abused to decrease the strength of the backlight below its lowest setting. (We've known the hardware is capable of this given that iBooks has always allowed you to.)

Because the Lifehacker guide Olivier linked was a bit hard-to-follow, I figured I'd help by illustrating a how-to do this with a few GIFs.

And then what happened?…

I was interested in using videogames to practice my Japanese reading and listening comprehension, so after some initial thinking, I decided to buy an imported New Nintendo 3DS. Here are some notes on how I went about that and what I'm doing to use games primarily as an educational tool.

Buying the device

There are lots of import sites out there that will get you a good deal on Japanese game products, but I wanted to (a) get fast, reliable shipping, (b) have some kind of return policy, and (c) not risk customs headaches. As a result, I decided to buy the device off Amazon's US site from a third-party merchant using Fulfillment by Amazon so that I could get Amazon Prime shipping and Amazon support for returns.

I ended up purchasing this model (Amazon referral link) and then hunted for an Amazon Prime-able merchant under the sellers list, like so:

Next, I picked up a new 64GB SDXC card (Amazon referral link) and formatted it to FAT32 using Mac OS X's Disk Utility (here's an instructional video if you're not familiar with how to do this).

Content warning: more content…

When Apple announced iPad Air 2, I was most excited by the prospect of Apple SIM. That excitement waned when we learned AT&T would lock Apple SIMs to its network upon their activation (so much for that layer of indirection enabling competition). Still, I held out hope that maybe an Apple SIM could be used to purchase pre-paid data from an iPad and then be plopped into and used by an unlocked iPhone 6.

Let's see how that went.

And before you knew it…

This post presumes you're familiar with the concept of tools that introduce a module format (whether it's Require.js, Browserify, or something else) to JavaScript code that runs in the browser. I'll arbitrarily refer to the over-arching meme as capital-R "Require" for the rest of this post.

Also, keep in mind that this post is only discussing "JavaScript that runs in browsers". It's not at all concerned with Node.js or npm or anything having to do with dependency management of JavaScript in that ecosystem.

Okay, I'm interested…

Today, I had the good fortune to visit my friends at Sparkbox, where they host a Dayton JavaScript user group called Gem City JS. Today, I showed up to share some perspective on how to test JavaScript with Jasmine.

Folks have been asking me to share a screencast of how I write Jasmine tests for a few years, so I recorded the session and am providing it online, completely unedited:

This screencast (YouTube) is merely a conversation to provide an answer to the question, "Hey Justin, how would you write a test for ____ JavaScript code?" where that blank might be filled with "interacting with the DOM", or "binding user events", or "making AJAX requests". I cover each of those in a way that's similar to how I do it today; I trust that in six months, I'll have evolved and changed my tastes somewhat, but this reflects where I'm at right now.

You'll never guess what happens next…

Funny how just this week I felt compelled to blog about implicit knowlege, because a terrific example of the possible consequences of too much implicit knowledge came up yesterday.

Please forgive me for the length of this post, because this is a surprisingly subtle problem. As with most subtle problems, the context and relevant background knowledge are necessary to arrive at a clear understanding of both the problem itself and the causes.

But wait, there's more…

We lack much of a vocabulary to describe knowledge and how code can succeed to or fail at codifying it. The points made in this post are so popular as to be self-evident, but it seems I can always use more practice in articulating them. I'll start with an example that many of us are familiar with and then swivel into an issue I ran into today.

code comments

Inline comments in code are often maligned for two reasons: (1) well-factored code can be so expressive that additional comments shouldn't be too valuable, and (2) comments often fall out of sync with reality, as only the code must change to implement new behavior.

And then what happened?…

Today we set out to upgrade one of the third-party JavaScript dependencies on which our project relies and we inadvertently discovered that it had a number of custom hacks made against it. This blog post replays a similar experience and how we can reduce some of the risk in attempting to confidently upgrade the dependency with git diff and patch.

introducing a new dependency

It starts when we add a new 3rd party library to our project. Everything is new and exciting!

Turns out, there's more to it…

We've been hard at work on a tool called Lineman that helps you create web applications in JavaScript (and CoffeeScript!), and we're really excited to share it with you!

Tonight I recorded an 8-minute screencast to show you the ropes:

As time goes on, I'll go into more detail on both our motivations in writing Lineman as well as more advanced usage like overriding configuration defaults.

In the meantime, please give Lineman a spin and tell us what you think!

To be continued…

[Note: this post covers unreleased features of gimme, which are unreleased because of the issues described in this post. They need more time in the oven. You can peruse the feature branch on github]

Working on gimme with Mr. Karns made me realize I'd painted myself into a corner on gimme's API design. I thought I'd share here, for hope that either (a) someone will respond with an approach I like better, or (b) the topic might prove independently useful, and some good will come of this after all.

And then what happened?…

Lately I've been thinking a lot about how we can improve our code by reflecting on our mindsets and motivations with respect to software testing. A while ago, I wrote about the huge impact that prompts have on how we grow code (even the parts of speech we use to name objects). Later, I sat down to illustrate a taxonomy of the types of tests I tend to see in the wild. Recently, I wrote a bit about our natural tendency to misplace blame when testing gets hard.

What happens next will shock you…

"This test is too coupled to the implementation."

This complaint is commonly levied when—on account of test double setup—you have spec code that looks a lot like the subject's ("SUT's") implementation code. I hear this complaint most often in cases where the subject has little responsibility beyond passing a value from dependency A to dependency B and returning it.

Because isolation tests specify not only the externally observable behavior of the subject, but also the subject's contracts with its collaborators, it should be obvious that isolation testing is going to bring complex interactions with collaborators to the forefront in a way that an integrated test would not.

Okay, I'm interested…

I have a lot of empathy for people that work at big companies. No one should be required to use a crappy ThinkPad loaded with sluggish, productivity-monitoring software. No one should be forced to communicate through a regimented, politicized hierarchy to do their job. No one should have their actions decided for them by someone else, especially because no one else has a better chance of determining necessary actions than the person who is closest to the work.

And before you knew it…