No Laptop: 2 Weeks


In the last two weeks I have travelled without a laptop. In that same two weeks, even while at home, my laptop has been on for a sum total of 5 minutes. It could have been zero minutes, but I had forgotten that a couple of my development projects (including my web site’s code) hadn’t been added to github and so were not available from my tablets. So I turned on my laptop long enough to create a couple new code repositories on github and perform a git push to rectify my oversight.

I hedged my bets on the first week by traveling with two tablets and decided the next step needed to be traveling with only one tablet. It ended up being the iPad Mini, primarily because of a need to work on presentations and the availability of Keynote on iOS.

I found myself wondering on a couple occasions whether or not traveling without a laptop is really such a good idea. Before going into that, though, let me explain why I am even doing this in the first place.

While the rest of the world seems to be gravitating to tablets, I have found it hard to make the case for a tablet for me, personally. Of any of the devices I use regularly – laptop, smartphone and tablet – losing my tablet would cause zero impact to my productivity. Through 33 years spending a substantial amount of time using a computer (rough, conservative estimate: 50,000 – 75,000 hours), getting it to do what I need it to do is nearly as easy for me as breathing. As long as my laptop is within arms reach, I will grab it as soon as working on a tablet requires even the least bit of extra effort. Extreme measures are required If I am ever to answer the question “why use a tablet?”

Two weeks in I’m starting to pick up hints of ingrained usage patterns. I’ve realized that I rely heavily on a file system to help me move between apps, whether it is combining several PDF files into one, creating an image that is needed in a presentation, pulling numbers out of a terminal session script to bring into a spreadsheet and then graph, or even just attaching a file to an email. My security blanket is easy file access, yet tablets work very hard to keep apps and data tightly integrated: especially iOS, though Android works pretty hard at it, too. This is not the usage pattern you are looking for. Move along…

Of course, this particular battle predates tablets. The file system has been decried as a flawed metaphor for decades, practically since the day Apple lifted the concept of a windowing system from Xerox PARC. Regardless, once you’ve used the approach as long as I have, calling it second nature is an understatement. This is why I feel compelled to force the issue.

It helps that I have become quite the gram weanie. Traveling 100% of the time, and getting into backpacking can have that effect. I’ve already planned a blog entry for about two weeks from know, reporting on my total travel weight for a one-week business trip to Brazil, sans laptop.

I know I’m pushing it a little, but the Personal Computer era is all but over. Creativity is still easier on a PC than it is on a tablet… in most cases. The tablet is still primarily a device for consumption, but I think the convenience factor will continue to provide an impetus for this to change. Even more disconcerting, though, is my expectation that the tablet won’t enjoy nearly as long of a run as the PC did. The only constant is change, accelerating incessantly.

And so here I am, heading into week three; still no laptop.

No Laptop: end of Week 1

It has been an interesting week. On Monday I thought I had made a serious mistake. That was rescued by Android’s excellent support of an external keyboard. However, Android is not without its warts.

I spent several hours configuring things on Android to get everything to work the way I expected. The last problem was the Escape key, which was used to approximate Android’s “Back” button. This was great until I was in a shell session, running vim and needed the Escape key to take me out of Insert Mode. I spent some time installing and configuring “External Keyboard Helper Pro” so that I could use the Ctrl and Escape keys as needed in a terminal session. I’m using Connectbot on Android which seems to work well, but it is fugly!

I could spend another several hours trying to setup a better color scheme, but that’s hard to swallow when iSSH on my iPad Mini looks gorgeous out of the box.

That’s the light color scheme. The dark color scheme doesn’t look bad either. I’ll likely switch between the two occasionally, depending on my mood… or something. In any case, my first “git push” was from the Nexus 7. That’s hardly a compelling use case, but it’s a start.

So I consider week one a success! My one crutch was bringing both my iPad Mini and Nexus 7, just in case using one of them ended up being an absolute disaster. I will take no such precaution next week; only one will accompany me on next week’s business trip.

But which one should it be?!

No Laptop, Day Two

When the new Macbook Air was announced a few months ago I gave it a serious look. I have been on a 2-year refresh cycle for many years. It was the right time to be looking for a replacement for my 2-year-old Macbook Air, yet I was having a hard time convincing myself of a need for an upgrade. Though I had followed this routine for the last 8 years I just didn’t feel compelled to upgrade this time around. I still haven’t, which is… odd.

Upon purchasing my first iPhone years ago I was shocked to learn that it actually took the place of my laptop in a few use cases. Since then I’ve gone through several tablets, finding it difficult to make room for the new form factor between my iPhone and my laptop. Increasingly, though, I find myself reaching for my tablet to the point that I recently asked myself “how close am I to not needing a laptop at all?” Traveling without a laptop this week is my first experiment to try and answer that question.

I nearly reneged. As I was drifting off to sleep Sunday night I found myself thinking maybe I shouldn’t go through with it. Can I really take a four day business trip with only a tablet?! On Monday morning I boarded the plane without my laptop. Burn the ships!

I did hedge my bets slightly: I traveled with both an iPad Mini and a Nexus 7. I decided to use the iPad Mini at the office on Monday. It was frustrating. By the end of the business day the battery was down to 37% and I found connecting a Bluetooth keyboard to be marginally useful. The keyboard is only good for entering text. I mean, I realize that is the primary reason to use a keyboard but on my laptop I’m used to keyboard shortcuts that make navigating an Operating System from a keyboard effortless. My iPad treats my external keyboard as an intrusion: “you don’t need that peripheral! I function perfectly fine without it!”

I left the office and headed back to the hotel feeling defeated. This isn’t going to work. I’ll limp through the next three days and pack my laptop next week. When I arrived at the hotel room I decided I might as well pair my Bluetooth keyboard with my Nexus 7, just for kicks. I leaned the Android tablet on my wallet to prop it up slightly and started exploring. I was flabbergasted! Using keyboard shortcuts I had learned through a decade of using Mac OS X, I found myself using the keyboard to control my Nexus 7 intuitively! Command-Tab pulls up the app switcher; the Esc key cancels out of things; the Tab key and arrow keys allow me to move around the user interface. In fact, it worked better than Mac OS X! After about an hour hope returned. Maybe this could work after all!

To me, this side-by-side comparison underscored something I already suspected: where iOS is designed with Apple’s “we know you better than you know yourself” attitude, Android seems to be designed assuming that, perhaps, just maybe there is more than one right way to use a device. I’ve read accounts of people using a Bluetooth mouse on their Android device along with their physical keyboard. I’m not feeling the need to add a mouse, but that isn’t even possible on iOS! To me, the Android OS has been built assuming that at some point someone might want to use their device with external peripherals. If my only option were iOS my hopes of replacing my laptop would have been dashed. Thankfully not every company is as close-minded as Apple (Yes, that was out loud)!

I’ve just scratched the surface. I have yet to reach the level of using just a tablet in anger. This first week is a simple trial, but I am optimistic that I can turn one week into two. I have some ideas for how to test my hypothesis further. It includes the use of my virtual development environment. For now, though, I’ll continue crawling; walking will come soon enough.

Living in the Cloud, Take 2

By one form of reckoning, this is my third attempt at living 100% in the cloud. I made mention of a first and second attempt several years ago.

In reality, though, it’s consistent evolution of the same attempt. Within the past several months I moved the last couple holdout documents out of desktop apps into Google Drive. I have been noticing that most of my time on my laptop is spent using web apps in Chrome, or using a shell session for coding. I have had pretty good success experimenting with moving my development to EC2 instances, but the annual cost for a single instance was just a bit beyond my pain threshold ($120 – $180 per year).

Several things have come together to push me to take this to the extreme. First, I purchased both a Nexus 7 and an iPad Mini late last year. I am much happier with either/both of them than I was with my full-size iPad. The form factor is perfect for my needs.

Second, I ran across Digital Ocean, a new cloud service that offers Linux VM’s for a maximum of $5 per month which easily dips below my pain threshold at (33% – 50% of the cost of EC2).

Third, I have an upcoming business trip to Brazil, which got me thinking about traveling light again. If I could eliminate the need for my laptop and its accessories – even my svelte 13″ MacBook Air – I could shave nearly 4 pounds off my backpack weight.

So this week I began an experiment: for my business trip to Houston I have left my laptop at home. I’m doing everything on my iPad Mini and an Apple Bluetooth keyboard. Assuming the next four days go well, I’ll try again next week. Assuming the next three weeks go well I’ll be taking the same approach for my trip to Recife, Brazil!

Apple’s iMessages Debacle


I have recently begun the process of attempting to disentangle myself from Apple’s boa constrictor of an ecosystem. The first step: get rid of all iOS devices.

Foolishly, I assumed this would be straightforward: I bought a Galaxy Note for my phone and a Nexus 7 for my tablet, both of which I am quite happy with (despite the lack of battery life on the Note). I diligently signed out of iMessages on my iPad 3 and iPhone 4, restored them both to factory settings, removed sim cards, etc.

Here is what is happening: when anyone with an iOS device tries to send me a text message, their iBS device dutifully reports that their message has been delivered successfully to my iOS device. At this point, there is nothing for the sender to do, even if they guessed that Apple was lying to them and something might be wrong. You cannot force the message to be sent as an SMS message after Apple, in it’s infinite wisdom, has proclaimed the message as successfully delivered.

This may seem like a niggle, but for someone who travels nearly 100% of the time and relies heavily on text messages for reliable long distance communication with clients, colleagues and family, this is a nightmare. I have scoured the Interwebs for an answer and there are many recommendations: have your buddy delete and re-add you to their contacts list (fail), remove the sim cards from your old iOS devices (fail), have the people who are now using your iOS devices sign out of iMessages and then sign back in (IT Crowd, anyone? And, epic fail), etc.

Furthermore Apple refuses to acknowledge this as a bug and claims that it is an incredibly rare occurrence that only happens when an Apple Genius doesn’t follow the rules (an Apple Genius has never come close to any of my devices).

It appears that Apple has grown too big to care, and too big to be brought to task for their growing monopoly. Trust me, the irony of seeing Apple get away with far more than Microsoft was charged with ages ago is not lost on me. It’s just not funny.

So I’ve sent off an email to Apple: the only way I can hope to get any answer. Of course, many have already tried this and have found Apple less than helpful (surprise, surprise).

It is incredibly frustrating to have a crucial mode of communication (for me personally, anyway) completely controlled by an organization who doesn’t give a rats ass whether their services actually do what they’re supposed to do and consistently tell customers to take a flying leap.

Alas, I am reduced to ranting which has very little chance of fixing anything. It’s the only recourse I have left, though. I’ve been slowly thinking I need to completely leave the Apple camp. The only thing that has changed in that regard is that now I’m in an awful hurry!

I usually put URL’s inline, but since the information I used was primarily from two sites, I’ll list them here:

Life will find a way

The book “Out of Control” by Kevin Kelly made a major impact on the way I view systems of all kinds: economies, cultures, networks, code designs. One of the things that I latched on to was the concept of “living things will find a way.” As I evaluate systems, I increasingly think of them as organisms leading me to ask questions like “what does this system want.”

An article was recently brought to my attention that demonstrates this brilliantly. Regulation can be important but often creates a lot of friction. What better way to deal with this than avoid regulation altogether?! I’m surprised it took this long for someone to decide to build a floating island just outside of regulated territory, in international waters.

When it comes to obstacles to evolving systems, whether organic or synthetic, life will find a way!

…it’s not a Unit Test

Riffing on Jeff Foxworthy’s “…you might be a redneck”, I present “…it’s not a Unit Test”:

  • If it requires manual setup… it’s not a Unit Test.
  • If it requires manual intervention… it’s not a Unit Test.
  • If it requires a network connection… it’s not a Unit Test.
  • If it requires a container… it’s not a Unit Test.
  • If it requires a database… it’s not a Unit Test.
  • If it accesses a file system… it’s not a Unit Test.
  • If it requires a service to be available… it’s not a Unit Test.
  • If it takes longer than a millisecond to run… it’s not a Unit Test.
  • If it lacks assertions… it’s not a Unit Test.
  • If it breaks on certain dates or at certain times… it’s not a Unit Test.
  • If it requires a UI… it’s not a Unit Test.
  • If it fails intermittently for an unknown reason… it’s not a Unit Test.
  • If it passes intermittently for an unknown reason… it’s not a Unit Test.
  • If it fails when you look at it funny… it’s not a Unit Test.
  • If the mock setup code dwarfs the actual test code… it’s not a Unit Test.
  • If you have to mock beyond immediate dependencies… it’s not a Unit Test.

I think that’s a pretty good start. What have I missed? Are there any that make you cringe? Let your voice be heard: leave a comment!

Backpacking Blunders

The Cascades are a very photogenic mountain range: a choice location for a first backpacking trip (you can see full resolution versions of these photos and more here). I have done plenty of camping and hiking in my lifetime, but until several weeks ago I had never combined the two. It’s something I’ve always wanted to do. Work has me traveling to Seattle currently and when a couple colleagues started talking about taking some weekend backpacking trips I jumped at the opportunity.

At the trailhead (from left to right): Greg “Hippie” Warren, myself, and Pat

I’m not in terrible shape, I know plenty about camping and hiking, and I’m a pretty smart guy. I was sure I had things figured out. Oh, but don’t worry: this didn’t go as bad as you might now be thinking. By comparison, Hippie is in great shape (long distance runner), and both Hippie and Pat have been on many excursions: they were fine.

Heavy forest canopy and lush ground foliage made for magnificent views.

We got a later start than I had expected and we decided the new guy should set the pace (that would be me, and normally a good idea). I was a man on a mission, knowing we wanted to make 7 – 9 miles in the first day and it was already 3:30 PM. We made the nine miles, but at the expense of my feet.

I’m pretty sure the moss in this forest had plans for total world domination!

You see, I knew (yet ignored) the four most important pieces of backpacking gear: footwear, footwear, footwear, footwear:

  • Shoes: the heel should lock, the toe-box should have ample room for your foot (fail, and fail)
  • Socks: moisture wicking is key to minimizing chances of blisters. This means NO COTTON (MAJOR fail)
  • Lacing: can greatly improve the shoe’s fit. I have narrow heels yet my foot is wide in front. Loosening the laces at the bottom and tightening them at the top would have worked well for me (see the first point)… and, fail
  • Camp shoes: I thought my Vibram’s would be a good idea (so did Hippie). Swollen feet and gloves for your feet are NOT a good combo. Flip flops are great for wearing around camp in the summer and they let your feet breathe.

All of those cascades add up!

I also made what I am sure is every backpackers first blunder: I brought way too much. I bought a great pack, then filled it with a bunch of heavy stuff. This has led me to my fifth backpacking axiom (after The Four Footwears):

When preparing for a backpacking trip lay everything out that you think you need, and eliminate everything you are not certain you’ll need. Then, get rid of half of what’s left.

Pat has since introduced me to the backpacking big three. I already had an ultralight pack (2 lbs, 3 oz.). I have since purchased an ultralight tent (2 lbs. 10 oz. with footprint) and sleeping bag (3 lbs.). Add to that eliminating a lot of extra stuff and my pack will be significantly lighter next time. Oh, and I bought some new boots that actually fit, so no bruises and blisters next time. Much of the gear I got on clearance, though I would have bought most of it anyway. I learned my lesson the hard way! I estimate I was carrying a total of 270 lbs. (body weight, plus 50 lbs. of gear, food and water). I’m pretty sure I’ll weigh in at 250 lbs. this weekend when we head into the William O. Douglas Wilderness near Mt. Rainier.

I really enjoyed my first backpacking trip despite barely being able to walk by the end (quite literally), and I learned a LOT. I’m sure this next trip will be even more enjoyable… and I’ll probably learn a ton again, which will make it even better!

Focused on Fast

I love the counterintuitive. Fortunately software development provides many opportunities to observe the phenomena. Of course it can be frustrating at times, but it is fascinating once you realize what is really going on.

A while ago I blogged about Jerry Weinberg’s Pickle Principle. The very next section of his book containing that anecdote tells the story of two brothers, Roamer and Homer. The basic premise is that Roamer wanted a quiet life at home and Homer wanted to see the world, but both of them ended up with the exact opposite of what they strove for. Jerry boils down the essence of this story in a paradox: “the best way to lose something is to struggle to keep it.” Thinking about this, I realized that software development projects experience this when it comes to delivery dates.

The only time I can remember having an indefinite period of time to finish a project was on the amortization application my friend and I worked on for a local accountant. We were in the 9th and 10th grade at the time and we had approached him about giving us an interesting problem to solve. In every project since that one, though, there has been time pressure and very often the team has succumbed to the temptation to focus on going fast. Invariably this ended poorly. In the worst cases (yes, more than one) the project was canceled with dozens of man-years expended and millions of dollars lost.

Think about your own experiences. How many times have you experienced situations where the push was to go fast? How many of those undertakings succeeded at going fast? How many of them succeeded at all? Probably not many. Yet the focus on going fast remains.

Recently I wrote the following on a team Retrospective card: “We are focused on going fast when we should be focused on going well.” I’m not sure where I first heard this phrase but it has stuck with me. Focusing on going fast will, at best, slow things down. At worst the focus on speed will derail the effort entirely.

Paradoxically, a focus on going well means regularly taking time to stop, step back and reflect. Whenever I succumb to the rush to make progress I find that I am slowed by missteps, miscalculations and misunderstandings. Whenever I focus on going slow and methodically, taking time to learn in the moment, I find that progress occurs apace.

So the next time you hear the crack of a whip and feel the pressure to redouble your efforts, consider stepping back and taking stock of the situation instead of running headlong into the unknown. I think you’ll find, as I have, that going fast occurs as a happy side effect of remaining circumspect.

EC2 Automation

A new colleague and friend of mine, Cosmin and I were talking at lunch the other day about EC2. He has been playing with AWS and EC2 for longer than I have and had some great suggestions. One of them was to prefer automating EC2 Instance creation and setup with shell scripts over using Instance Snapshots, because:

  • You don’t have to remember all the nit-picky details of getting the new instance configured exactly the way you like it
  • Every minute detail will happen the same every time
  • The script serves as a reminder of every step taken to create, start and configure the instance
  • You don’t have to pay the AWS charges for Snapshot storage!

So I started building an EC2 instance creator script. So far it successfully spawns a new instance, assigns the instance a static IP address, and SSH’es into the new instance: all by typing a single command at the command prompt! Here is the script:

I’ve been spending a lot of time creating and terminating EC2 instances, as well as having instances up and running for hours at a time (30 hours total over the last couple weeks if I’m reading the report correctly. The cost for all this experimenting? Ninety-Seven CENTS!

You’ll notice this script uses ec2-run-instances with the –user-data-file parameter, and that is where the magic happens. Once the instance is running, the script you pass in that parameter is automatically run. I intend to use that script to:

  • Setup my home directory structure
  • Run a package installer (in this case, yum) to add everything I need from the repository
  • Any other miscellaneous setup like creating users, assigning permissions, setting up daemons and starting them, etc.

My intention is to add a public project to github to accompany the gist cited above once I have this second script in decent shape. For now, feel free to poke holes in the script above. I do a couple quirky things, but I have reasons for doing them the way I did. Feel free to add your questions or suggestions for improvements in the comments section below!