Haven’t totally been keeping up with all the grand slam tennis, but this is a darn nice catch by Australian Open ball boy.

Play mp3s on a Mac with a nicer interface than iTunes


Simplify lets you control iTunes, Rdio and Spotify from the player shown above or via custom keyboard shortcuts.

Mac App Store

This app looks nice if you’re well-invested into iTunes. But if you’re not, I recommend Vox. It’s small both in visual and technical footprint. It’s just an mp3 player. But it’s quite nice and it’s free.

(Image via this review.)

(via minimalmac)

Shit People in Silicon Valley Say!!!

"He had his first exit when he was nine."

The Android hardware fragmentation, support, orphan crisis

"Other than the original G1 and MyTouch, virtually all of the millions of phones represented by this chart are still under contract today. If you thought that entitled you to some support, think again:

  • 7 of the 18 Android phones never ran a current version of the OS.
  • 12 of 18 only ran a current version of the OS for a matter of weeks or less.
  • 10 of 18 were at least two major versions behind well within their two year contract period.
  • 11 of 18 stopped getting any support updates less than a year after release.
  • 13 of 18 stopped getting any support updates before they even stopped selling the device or very shortly thereafter.
  • 15 of 18 don’t run Gingerbread, which shipped in December 2010.
  • In a few weeks, when Ice Cream Sandwich comes out, every device on here will be another major version behind.
  • At least 16 of 18 will almost certainly never get Ice Cream Sandwich.”


The announcement that Nexus One users won’t be getting upgraded to Android 4.0 Ice Cream Sandwich led some to justifiably question Google’s support of their devices. I look at it a little differently: Nexus One owners are lucky. I’ve been researching the history of OS updates on Android phones and Nexus One users have fared much, much better than most Android buyers.

I went back and found every Android phone shipped in the United States1 up through the middle of last year. I then tracked down every update that was released for each device - be it a major OS upgrade or a minor support patch - as well as prices and release & discontinuation dates. I compared these dates & versions to the currently shipping version of Android at the time. The resulting picture isn’t pretty - well, not for Android users:

Other than the original G1 and MyTouch, virtually all of the millions of phones represented by this chart are still under contract today. If you thought that entitled you to some support, think again:

  • 7 of the 18 Android phones never ran a current version of the OS.
  • 12 of 18 only ran a current version of the OS for a matter of weeks or less.
  • 10 of 18 were at least two major versions behind well within their two year contract period.
  • 11 of 18 stopped getting any support updates less than a year after release.
  • 13 of 18 stopped getting any support updates before they even stopped selling the device or very shortly thereafter.
  • 15 of 18 don’t run Gingerbread, which shipped in December 2010.
  • In a few weeks, when Ice Cream Sandwich comes out, every device on here will be another major version behind.
  • At least 16 of 18 will almost certainly never get Ice Cream Sandwich.

Also worth noting that each bar in the chart starts from the first day of release - so it only gets worse for people who bought their phone late in its sales period.

Why Is This So Bad?

This may be stating the obvious but there are at least three major reasons.

Consumers Get Screwed

Ever since the iPhone turned every smartphone into a blank slate, the value of a phone is largely derived from the software it can run and how well the phone can run it. When you’re making a 2 year commitment to a device, it’d be nice to have some way to tell if the software was going to be remotely current in a year or, heck, even a month. Turns out that’s nearly impossible - here are two examples:

The Samsung Behold II on T-Mobile was the most expensive Android phone ever and Samsung promoted that it would get a major update to Eclair at least. But at launch the phone was already two major versions behind — and then Samsung decided not to do the update after all, and it fell three major OS versions behind. Every one ever sold is still under contract today.

The Motorola Devour on Verizon launched with a Megan Fox Super Bowl ad, while reviews said it was “built to last and it delivers on features.” As it turned out, the Devour shipped with an OS that was already outdated. Before the next Super Bowl came around, it was three major versions behind. Every one ever sold is still under contract until sometime next year.

Developers Are Constrained

Besides the obvious platform fragmentation problems, consider this comparison: iOS developers, like Instapaper’s Marco Arment, waited patiently until just this month to raise their apps’ minimum requirement to the 11 month old iOS 4.2.1. They can do so knowing that it’s been well over 3 years since anyone bought an iPhone that couldn’t run that OS. If developers apply that same standard to Android, it will be at least 2015 before they can start requiring 2010’s Gingerbread OS. That’s because every US carrier is still selling - even just now introducing2 - smartphones that will almost certainly never run Gingerbread and beyond. Further, those are phones still selling for actual upfront money - I’m not even counting the generally even more outdated & presumably much more popular free phones.

It seems this is one area the Android/Windows comparison holds up: most app developers will end up targeting an ancient version of the OS in order to maximize market reach.

Security Risks Loom

In the chart, the dashed line in the middle of each bar indicates how long that phone was getting any kind of support updates - not just major OS upgrades. The significant majority of models have received very limited support after sales were discontinued. If a security or privacy problem popped up in old versions of Android or its associated apps (i.e. the browser), it’s hard to imagine that all of these no-longer-supported phones would be updated. This is only less likely as the number of phones that manufacturers would have to go back and deal with increases: Motorola, Samsung, and HTC all have at least 20 models each in the field already, each with a range of carriers that seemingly have to be dealt with individually.

Why Don’t Android Phones Get Updated?

That’s a very good question. Obviously a big part of the problem is that Android has to go from Google to the phone manufacturers to the carriers to the devices, whereas iOS just goes from Apple directly to devices. The hacker community (e.g. CyanogenMod, et cetera) has frequently managed to get these phones to run the newer operating systems, so it isn’t a hardware issue.

It appears to be a widely held viewpoint3 that there’s no incentive for smartphone manufacturers to update the OS: because manufacturers don’t make any money after the hardware sale, they want you to buy another phone as soon as possible. If that’s really the case, the phone manufacturers are spectacularly dumb: ignoring the 2 year contract cycle & abandoning your users isn’t going to engender much loyalty when they do buy a new phone. Further, it’s been fairly well established that Apple also really only makes money from hardware sales, and yet their long term update support is excellent (see chart).

In other words, Apple’s way of getting you to buy a new phone is to make you really happy with your current one, whereas apparently Android phone makers think they can get you to buy a new phone by making you really unhappy with your current one. Then again, all of this may be ascribing motives and intent where none exist - it’s entirely possible that the root cause of the problem is just flat-out bad management (and/or the aforementioned spectacular dumbness).

A Price Observation

All of the even slightly cheaper phones are much worse than the iPhone when it comes to OS support, but it’s interesting to note that most of the phones on this list were actually not cheaper than the iPhone when they were released. Unlike the iPhone however, the “full-priced” phones are frequently discounted in subsequent months. So the “low cost” phones that fueled Android’s generally accepted price advantage in this period were basically either (a) cheaper from the outset, and ergo likely outdated & terribly supported or (b) purchased later in the phone’s lifecycle, and ergo likely outdated & terribly supported.

Also, at any price point you’d better love your rebates. If you’re financially constrained enough to be driven by upfront price, you can’t be that excited about plunking down another $100 cash and waiting weeks or more to get it back. And sometimes all you’re getting back is a “$100 Promotion Card” for your chosen provider. Needless to say, the iPhone has never had a rebate.

Along similar lines, a very small but perhaps telling point: the price of every single Android phone I looked at ended with 99 cents - something Apple has never done (the iPhone is $199, not $199.99). It’s almost like a warning sign: you’re buying a platform that will nickel-and-dime you with ads and undeletable bloatware, and it starts with those 99 cents. And that damn rebate form they’re hoping you don’t send in.

Notes on the chart and data

Why stop at June 2010?

I’m not going to. I do think that having 15 months or so of history gives a good perspective on how a phone has been treated, but it’s also just a labor issue - it takes a while to dredge through the various sites to determine the history of each device. I plan to continue on and might also try to publish the underlying table with references. I also acknowledge that it’s possible I’ve missed something along the way.

Android Release Dates

For the major Android version release dates, I used the date at which it was actually available on a normal phone you could get via normal means. I did not use the earlier SDK release date, nor the date at which ROMs, hacks, source, et cetera were available.

Outside the US

Finally, it’s worth noting that people outside the US have often had it even worse. For example, the Nexus One didn’t go on sale in Europe until 5 months after the US, the Droid/Milestone FroYo update happened over 7 months later there, and the Cliq never got updated at all outside of the US.

  1. Thanks primarily to CNET & Wikipedia for the list of phones.

  2. Yes, AT&T committed to Gingerbread updates for its 2011 Android phones, but only those that had already been released at the time of the July 25 press release. The Impulse doesn’t meet that criteria. Nor does the Sharp FX Plus.

  3. A couple of samples just from the past week: 1, 2 - in comments.

DevOps in the enterprise

DevOps. Many of us in enterprise IT look longingly upon the growing DevOps movement. We have a significant challenge: Often the “dev” in DevOps isn’t just another team or department, but in a completely different corporate group, with a different VP. Unlike a web company (often not big enough to have an IT department dedicated to internal technical needs), enterprise IT’s role isn’t necessarily equivalent to “operations,” but it more closely resembles ops than development.

There is also a culture in enterprise IT to learn vendors ahead of process. Cisco, Microsoft, VMware, RedHat… Enterprise IT is quick to recognize expertise in tools.

As a lot of the code enterprise IT runs is bought not built, it compromises our ability to really learn to dance to the rhythm of software development.

That said, enterprise IT has plenty of opportunity to benefit from DevOps. The trick for us will be not to burn too many cycles in meetings and bureaucracy before just trying some things out with our partners in the organization.

"If you find yourself squirming uncomfortably at the idea of developers deploying code to production environments, you probably work in an environment that discourages mixing of dev and ops roles."

The write-up below by Adzerk is a fantastic overview of DevOps and great way to diffuse many of initial concerns people have with the idea.

Perhaps a start for those of us in enterprise IT is to pass along their blog post internally. :-)


“A system of local optimums is not an optimum system at all.” - Dr. E. Goldratt

DevOps, the mutant offspring of software development and the subsequent operations to keep that software functioning, is typically an abberaration for most organizations. Most engineering groups create a cultural wall between the developers and the people tasked with installing and running the software. Instances where the disciplines are considered to be a unified skillset are few and far between. Looking around the landscape of technology companies I am happy to see that this artificial division is eroding.

At Adzerk there is no separation between development and operations. All engineers are expected to develop and master skills of writing code and keeping the business operations functioning. 


If you find yourself squirming uncomfortably at the idea of developers deploying code to production environments, you probably work in an environment that discourages mixing of dev and ops roles. Developers write the code. Operations engineers install the code.

Perhaps there’s a hand off, with a lot or maybe little ceremony. Perhaps you have coordinated release reviews where the heads of departments show up and grunt and nod and sign off on a release. Or maybe you also have a long verification process filled with checklists that takes days or weeks to finish. There’s probably also volumes of expected documentation which acts as a contract designed to insulate your team from blame.

Worse still, if there is a problem with the deployed code there is a frustrating delay to fix it. Developers can’t work on the systems to deug the problem easily, or at all. Production staff insist on overly complicated rituals before they will expose themselves to yet another risky release of code. The feedback cycle on the software lengthens further still, delaying the delivery of actual value from the software. 

Because the production staff is so overwhelmed with rising costs of complexity and risk of each deployment, they demand larger work buffers. In this case the buffers are carefully documented processes and ever more rigorous manual inspection of the product before they deploy. Since they cannot directly control the process of putting quality into the software, they react the only way they can - they must hire more people to make the workload manageable.

Meanwhile, the developers react to the demands of the production staff by grumbling about how production is “dragging their feet” on deploying fixes. Any problems in the deployment is clearly the fault of people who just don’t understand how to work with the product. They are unable to rapidly adjust the product to a changing marketplace. They lengthen their work buffers by creating longer cycles of “requirements gathering” and architecting features no one asked for.

The end result is that the business become slower to respond to change. Development costs begin to climb as projects become delayed. Engineers become frustrated and angry with the workplace. Attrition becomes a problem as the most talented people seek greener pastures. 

Everyone sees problems but no answers. Everyone complains “We can’t get anything done!”


As bad as this sounds, there are ways to turn it around. As Andy explained in a previous post, Kanban is a powerful tool for visualizing and inspecting the flow of software delivery. By creating large and visible representations of how we work, we were able to avoid the trap of dividing our engineering team into functional silos. Rather than focus on efficiency of each work unit (code created per developer) we chose to focus on the pace of the working, software delivered.

Eliminating the “traditional” specialization between development and production is an outcome of our Kanban adoption. Kanban is not the only way to address this problem, of course. Any framework that encourages inspection of how work is done and encouragement of explicit conversations about how to improve that work are necessary conditions.


As a corollary to devops as an organizing principle, we’ve adopted “Infrastructure as Code”. This says that the configuration and provisioning of our infrastructure is described and controlled by programming tools. We chose Chef, but there are many tools available such as Puppet and cfengine. Every developer has access to the infrastructure code and the server infrastructure itself. 

If the thought of easy access to the servers that run your business makes you uneasy, it just means you are sufficiently paranoid. We use that unease to develop our version of “poka-yoke”, or error proofing mechanisms. Since we are responsible for the availability of the production environment, we make engineering choices to minimize fear.


Our software is pulled from our Github source code control repositories into a continuous integration pipeline. We apply a battery of fast unit tests. If those tests pass, we immediately and automatically deploy the code to a test environment. The pipeline runs another round of API tests followed by our slowest functional tests. The pipeline shuts down when it detects a failure and notifies everyone.

If the tests pass then the code is promoted to a release. The pipeline then deploys the promoted code automatically to our production servers. 


Do we make mistakes? Of course! What we have found is that the longer the time a developer takes to commit changes, the bigger the changeset. And the more that changes, the greater the chance that a bug has been introduced. By forcing all changes to be applied as soon as possible we encourage small changes. 

Small, incremental changes are also easy to debug. If a developer makes a mistake in 3 lines of code, we know we only have to search 3 lines of code for the problem. If your release cycle takes a month, how many lines of code did you change? How many lines of code do you have to inspect to find and fix the defect? Thousands? Tens of thousands? Millions?

The other advantage to making frequent releases is that the time to fix a problem is usually about 15 minutes. We don’t petition a committee to make a change, or fill out a form, or create a ticket proposing the change. We make the change is made and it’s deployed immediately. Our build and deployment infrastructure creates and reports the information we need to audit changes and fix problems.

We think the ability to react this rapidly is an immense advantage. This stance forces everyone to have explicit conversations about what constitutes value to the business. We measure the impact of changes almost immediately, rather than in weeks or months. This culture creates an engineering culture of achievement and pride instead of fear and frustration.

We learn rapidly from our work. We serve our customers better. Win!

(Source: adzerk)

New conference: Consumerization of IT in the Enterprise in San Francisco

I’m sure it will have some boring parts, and some helpful parts. But how fantastic that there’s a mainstream conference like this about the topic of consumerization! :-)

Thanks rankandfile:

March 2012 brings the debut of the Consumerization of IT in the Enterprise (CITE) conference and expo in San Francisco, California.

Managed by IDG, and sponsored by Cisco and Citrix, the event will likely be a bit more staid and devoted to things bureaucratic. (The example agenda previews sessions on governance, asset lifecycle, risk management.) But it makes for an interesting compliment to Box.net’s lively Boxworks conference, and the long-running Enterprise 2.0 series of events.

You’re encouraged to submit a speaking proposal to CITE by November 18th, 2011.

(Source: rankandfile)

Michael Lewis’s new book Boomerang about the new third world

An interview with Moneyball author Michael Lewis about his new book, Boomerang. Boomerang is about how the first world increasingly resembles the third world,

Found on the addictive Infectious Greed.

Steve Jobs Apple tribute logo

Lots of Steve Jobs Apple logos and icons floating around, all done with great respect. They make me both sad and happy at the same time. Here is my favorite.

Beautiful job, jmak.

Awk book review: Awk One-Liners Explained by Peteris Krumins

In addition to being a thorough, fair review, it’s a great explanation of why and how Awk is so helpful.


A history lesson

As a target for writing code, the UNIX software ecosystem is strangely fascinating. Among its features, one standout is its reliance on text as a basic information storage unit. This sentence looks dumb out of context, because of course. But in the age of rich media and omnipresent design, the simplicity of carrying information on text alone is refreshing, comforting in its minimalism (doh! I’ve managed to bring up design; must resist). UNIX was also designed on the principle that software designed for it should be made to manipulate text streams in such a way that programs could be connected like stations on a train track. The text train would go out from the first station, stop at each station for some processing and arrive at the last station rich with the solution to some problem. It will brand me as stuck in the past, but I am utterly seduced by this paradigm of powerfully plain, point-free, simple-step-by-simple-step data processing.

This is why I jumped on the occasion to learn about the awk utility, when I heard of Peteris Krumins’ e-book Awk One-Liners Explained As curious as I am with text processing, I mostly do it with small Ruby programs and some simple uses of Sed. I know that Ruby, a language that I both love and hate (but mostly love) borrows from Perl, which borrows frow Awk, so I took it as a history lesson, at least.

A surprisingly useful tool

The book is essentially a cookbook, as the author teaches Awk by example. He starts on simple examples that show the basics and progressively ramps up the complexity of examples, showing clever use of various Awk tools. The onus of the cookbook is on one-liners, Awk programs that can easily and readably hold on a single line of code. This is highly relevant as I’ve never seen or heard about a very complex Awk program: the few invocations of Awk I’ve seen in shell scripts indeed carried all the editing code inline. What the author suggests is that more complex tasks are rather accomplished by stringing Awk one-liners in a stream processing sequence, an idiom of UNIX programming that can integrate other tools (e.g. sort, cut, “) to properly and elegantly solve the problem.

It is an excellent Awk tutorial. The author pushes no introductory theory or generality and dives right into the first example. As he carries into the text, the reader the general principles behind Awk programs are spelled out. This teaching approach works wonders and is well suited to showing Awk idiosyncrasies, when compared to a classical exposition. The style and structure of the book encourages the reader to try the examples as he reads, which facilitates the assimilation of the material (in my opinion, as far as coding goes, practical knowledge is competence and theoretical knowledge is warm wind) and allows the reader to better feel when he grows tired and stops learning effectively.

The book argues strongly in favor of the usefulness of the Awk text processor, as well as in the simplicity and the readability of Awk programs. While corresponding Sed one-liners would likely be more terse and compact, the C-like syntax has a flow and visual structure that makes Awk one-liners easy to understand, however concise they remain. Given that Awk is a standard POSIX utility, it is deployed in all UNIX systems that I care about (Ruby is not installed by default in even the most recent Ubuntu releases, which frustrated a few times), and so is a very welcome addition to my common scripting tools.

But the man page says there’s more!

The main criticism I address to Krumins’ otherwise excellent book concern aspects that I would have liked covered in the book, or at least completely covered. One of the staples of modern programming languages is iteration through lists or arrays using specific statements (e.g. for elem in array...). Awk has such an iterative form, which is relevant for one-liner programs and as to position Awk among the inspirations for modern languages. Other features of Awk that could have made for interesting one-liners are the next and nextfile statements, as well as the getline statement. The latter is one that deserves treatment, given that it looks useful for combining two text streams in one and it is as confusing as Canadian tax law.

In addition, while the book makes for an excellent Awk tutorial, it is difficult to use as a reference for the Awk language. Maybe it would be better for this purpose if the author would add more page links in the index of the book. In his defense, though, Krumins publishes a free Awk cheat sheet, which does make for a good quick reference. And that’s not counting the multiple other references that can be found on the web with just a bit of searching —- many of which are of much poorer quality than the author’s material, might I add.

However, Peteris Krumins set out to explain a bunch of one-liners, and he did so superbly. I have had the history lesson I had settled for, and came away with an exciting new tool as a bonus. Moreover, the book is quite short, so it may be read to satisfaction in one little afternoon. I recommend it.

Update #1

Peteris Krumins responded to my criticisms through Twitter, and I must retract on one of my points. In my defense, it has been two or three weeks that I’ve read the book, so hey. But the author does cover the next and getline statements. As for the latter, though, the alternative forms of the statement by which other files than the current input file, or even pipes, were not covered. These alternate forms are confusing: some change the $N fields, others don’t; some forms advance NR, others don’t. The documentation of GNU Awk, for instance, goes to great length to delineate the cases, and putting up a cheat sheet would come in handy. And it is these forms that could allow the combination of two data streams in Awk. Here’s a one-liner that alternates the lines from files named file1 and file2:

awk '{ print; if(getline < "file2") print; } END { while(getline < "file2") print; }' file1

The first block prints all lines from file1; then, calling getline < "file2" fills $0 with the next line from file2, which then gets printed. As a function, getline returns 1 on successful reading of a record, 0 when reaching the end of the file and -1 on error (meaning my one-liner does not handle errors correctly, but it’s not the point of one-liners, is it?). Thus, one the one hand, if file2 has less lines than file1, only the lines of the latter keep being printed. On the other hand, if file2 is longer, the printing of its remainder is handled by the END block.

Long digression, but in the end, I mean to insist on one thing: this Awk book is authoritative, concise and highly readable. I enjoyed it to the end.

Update #2

In yet another conversation with Mr. Krumins, he reminded me that the premise of his book was to paraphrase the bunch of one-liners originally published by Eric Pement. Thus, it is clear that from the beginning, he had no intention of covering the full extent of Awk features, which puts my no. 1 criticism somewhat beside the point. Indeed. But if this misguided comment put one more nice one-liner about getline out there (see update #1), I guess we’ll all see some good came out of it.

New Facebook layout deconstructed

Heh. Somebody thinks the new Facebook layout and design is more than a bit inspired by Google+ and Twitter. It may be a bit premature to see where Facebook is going with this though.

Supposedly the other shoe drops this week at F8, the Facebook developer conference.

The event is being livestreamed (video) here, starting at 10AM Pacfic.

People are already breathless saying “Facebook to be Profoundly Changed.”

from toptumbles

(Source: twitter.com, via thenextweb)