# The importance and unimportance of ports

In the week since the formal, non-Gurman introduction of the new MacBook, there’s been a lot of talk about the ports. The initial reaction of many people has been that its having only one port—and a non-standard one, at that—makes the MacBook a non-starter. The re-reaction has been that while it may not be for power users, it’ll be a perfectly usable computer for lots of people.

I think the lack of standard ports has less to do with the “power” of the user than it does with the company the user keeps. Do you often trade files using USB thumb drives? You’ll want a regular USB port on your computer so you don’t have to hassle with a dongle. Do you regularly give presentations in a conference room outfitted with a projector or a flat screen TV? You’ll want an HDMI port. Take a lot of photos with a DSLR or other non-phone type of camera? An SD slot will be pretty important to you. None of this stuff has anything to do with how adept you are at setting up Hazel rules or Keyboard Maestro macros.

You might also want a bunch of standard ports as a means of protective coloration. If you work with Windows users who come into meetings with their inch-thick laptops bristling with ports, you’ll want your computer to have at least some of those ports1 so you’re not dismissed as a child with a toy.

Luckily, I don’t work in that kind of environment, so although I fit the profile of a power user, I could get along just fine with a single USB-C port and an adapter dongle of some sort. And although Apple’s adapters are expensive, the advantage of having a port covered by a non-proprietary specification is that third-party vendors will undoubtedly start offering reasonably priced adapters soon.

But that doesn’t mean I’ll be getting a new MacBook, even though my 2010 MacBook Air is getting long in the tooth. My problem with the MacBook isn’t with its single port or its somewhat sluggish processor or its limitations on RAM and flash storage. My problem is with its 12″ display. I had a 12″ iBook G4 for several years and I loved that machine, but the display worked because those were the days of the 4:3 aspect ratio. Today’s 16:10 aspect ratio is just too squat for a 12″ screen.

My current notebook has a 13.3″ screen, which makes it just over 7″ tall. The new MacBook’s screen will be less than 6.4″ tall. You may think that’s too small of a difference to worry about or that the higher resolution will make up for it, but I don’t think so. If you do a lot of writing or programming, vertical space is the most valuable commodity on today’s wide-screen displays, and I don’t want to give up any of it. Even with smaller, sharper pixels, there’s a limit to how small I can make the default text size in my editor before it’s uncomfortable to read. I’m not 25 years old anymore.

So while I look forward to the influence the new MacBook will have on future Apple notebooks, I won’t be taking the plunge. I’ll either get a MacBook Pro or wait until the MacBook grows up a bit.

1. I draw the line at VGA ports. I know lots of Windows notebooks still have them, but this isn’t 2005. I’d just as soon have a pair of PS/2 ports and a parallel port.

# Little date commands redux

Back in December, I wrote a short utility called ago, which calculated the number of days between a date given on the command line and today. It’s been useful, but too often I’ve found myself giving it input in the wrong format. Rather than retrain myself to match ago’s expectations, I rewrote ago to match mine.

As originally written, ago wanted two or three arguments: the month, day, and (optionally) year of the date. These were to be given as space-separated numbers, e.g.

ago 8 30 14


to get the number of days since August 30, 2014, or

ago 2 5


to get the number of days since February 5 of this year. The problem was the spaces. My natural inclination in writing a date is to use slashes or dashes between the numbers, e.g.

ago 8/30/14


or

ago 2-5


Using spaces was the lazy way out. Because Unix automatically parses arguments based on space separation, I didn’t have to write a date parser in ago. But after a few months of use, I realized that the time I saved by not including a parser was eaten up by the time I spent rerunning ago after giving it the wrong input.

And I didn’t even have to write a date parser. Although the Python standard library doesn’t include the kind of forgiving parser that would allow both slashes and dashes as separators, the well-established dateutil library by Gustavo Niemeyer does. It also allows dot separators and text, like feb 5. Using it even shortened ago’s code. And the best news is that even though dateutil isn’t in the standard library, it is included by default in OS X.

Here’s the new version of ago:

python:
1:  #!/usr/bin/env python
2:
3:  from datetime import datetime
4:  from dateutil.parser import parse
5:  import sys
6:
7:  # The date is given on the command line in American format.
8:  then = parse(sys.argv[1], dayfirst=False, yearfirst=False)
9:  now = datetime.today()
10:
11:  ago = now - then
12:
13:  if sys.argv[0].split('/')[-1] == 'til':
14:    print -ago.days
15:  else:
16:    print ago.days


The parse function in Line 8 returns a datetime object, as does the today function in Line 9. The subtraction in Line 11 returns a timedelta object, from which we return the days attribute in Line 14 or 16.

Because the ago code can also count days until a future date, I made a hard link to ago called til.

ln ago til


The logic of Lines 13–16 flips the sign of the result so I don’t get negative numbers if I use til to inquire about a date in the future. Instead of using

ago 12/25


and getting -284 as the result, I can use

til 12/25


and get 284. Not a big deal, but a cute little affordance.1

I should mention that the rules parse uses for two-digit years are a little different from what I used in the original version of ago. From the dateutil documentation:

When a two digit year is found, it is processed considering the current year, so that the computed year is never more than 49 years after then current year, nor 50 years before the current year. In other words, if we are in year 2003, and the year 30 is found, it will be considered as 2030, but if the year 60 is found, it will be considered 1960.

Now that it’s 2015, a year of 60 is considered 2060, not 1960.

With a rewritten ago under my belt, I decided to write a similar little utility that I’ve sometimes wished for: a quick way to get the difference in days between two dates. I call this script between. It’s used as you might expect:

between 8/23/1960 5/27


to get the number of days between August 23, 1960 and May 27 of this year. This is, as I mentioned in the post back in December, the day I become 20,000 days old. Jiminy.

The source code for between is

python:
1:  #!/usr/bin/env python
2:
3:  from dateutil.parser import parse
4:  import sys
5:
6:  # The dates are given on the command line in American format.
7:  day1 = parse(sys.argv[1], dayfirst=False, yearfirst=False)
8:  day2 = parse(sys.argv[2], dayfirst=False, yearfirst=False)
9:
10:  between = day2 - day1
11:  print between.days


There’s nothing in between that isn’t already in ago. I could, I suppose, modify between to act like ago when only one argument is given, but I think of the commands as distinctly different, so I don’t mind the redundancy.

If the second argument is earlier than the first, between will return a negative number. I could’ve added some logic to always return a positive number, but I didn’t see any value in that.

Back when Perl was my main language, I used its Date::Manip module for all kinds of date parsing and arithmetic. It was a huge module, and its load time was detectable—there was always a delay after issuing a command that used Date::Manip. But it was a remarkably full-featured library, and its parser was far more flexible and forgiving than dateutil’s. But dateutil is plenty good for what I need in these scripts and it doesn’t hesitate before giving me the answer.

1. The link can’t be called until because that’s the name of a bash command for looping.

# Tactile illusions

This short video at iFixit provides a decent and accessible explanation of the Force Touch trackpad that’s now in the 13″ MacBook Pro and will be on the just-announced 12″ MacBook. It’s sort of a followup to Steps 11–15 of iFixit’s recent teardown of the MBP.

The trackpad uses four force gauges, one at each corner, to measure the force you exert when pressing down on it. It’s remarkably similar to the way my bathroom scale works. The force gauges are themselves very simple: short cantilever beams with strain gauges on one side. The strain gauges change resistance according to the curvature of the beams, the curvature of the beams changes according to the forces acting on them, and the four forces on the beams add up to the total force of your touch. By putting a gauge at each corner, the force is measured accurately regardless of where you touch.

I’m going to pick a nit with iFixit’s description of how strain gauges work. The video says

A strain gauge works off of a principle called Poisson’s Ratio, which says that as you stretch a wire, the diameter will decrease and the length will increase and that’ll increase the electrical resistance of that wire.

Every individual fact in that statement is true, and yet I cannot agree that Poisson’s ratio is why a strain gauge works. The electrical resistance of a wire does increase with length and does decrease with diameter, but these two effects are independent. And Poisson’s ratio (which is a number, not a principle) has nothing to do with electrical resistance; it is purely a measure of the relationship between the longitudinal strain in the direction of the applied force and the lateral strain at right angles to the applied force. Poisson’s ratio does play a role in the value of a strain gauge’s gauge factor, but even if a wire had a Poisson’s ratio of zero, you could still make a strain gauge out of it.

More interesting to me is the feedback the trackpad gives you. A set of electromagnets along one edge of the pad shake it laterally according to criteria that are a complete mystery to me. Somehow, though, buzzing the pad laterally gives the user the impression of downward motion. Everyone who’s tried it out says the feeling is uncannily like pushing down on a regular trackpad.

I assume there’s a scientific name for this trick, but so far none of the millions of tech pundits who’ve written about the Force Touch trackpad have dug in and found out what it is. Until I hear otherwise, I’m going to call it a tactile illusion, the obvious analog to an optical illusion. If I had had a real education and knew French, I’d come up with an analog for trompe l’œil. Does trompe l’doigt work?

Update 3/15/15 9:33 PM
Readers come through.

First, I don’t think the common term haptic feedback is specific enough for the Force Touch effect. It’s used to cover all generated responses accessed through touch, and I’m looking for a phrase that applies just to those responses that fool your sense of touch.

Thanks to Yanik Magnan on Twitter and François Joseph de Kermadec via email for a correction to my cod-French. In real French, it would be trompe le doigt. Yanik says l’ is used as the article only if the following word starts with a vowel.

Rahul Bhagat pointed me to this paper by Margaret Minsky, which may be the starting point for the Force Touch system.

Finally Rob Trew, in his maddening way, sent me a link to a French page on “L’illusion tactile,” knowing full well I can’t read it.

Update 3/16/15 12:49 AM
New Scientist used the phrase tactile illusions several years ago, in an article about tricks that fool your sense of touch.

# Slippin’ and a-slidin’

Tuesday night I was sitting in a hotel room up in God’s Country,1 getting ready for a meeting the following day, when my phone dinged. It was an email from Glenn Fleishman, who was working on this article about the USB-C connection on the new MacBook and how it wasn’t going to be as trip-proof or snag-proof as the MagSafe power connection it was replacing. He was asking several people for their thoughts, opinions, and calculations and wanted to throw mine into the mix. It seemed like more fun than preparing for a meeting, so I sent him a short analysis. I assumed the details of the analysis wouldn’t be appropriate for a Macworld article, so I asked if I could go over them here after his article was published. He said yes, and that’s why we’re gathered here today.

I assume you read Glenn’s article yesterday. It got a lot of links and praise in the Mac corner of the internet, and deservedly so. It’s an exploration of a question that should worry those who plan to buy one of the new MacBooks: Given how light the computer is and how tight the USB-C connection is, are we returning to the days when tripping over a computer’s power cable meant a crash to the floor?

There are, of course, an infinite number of orientations and angles at which the cable can be pulled, so Glenn wisely decided to cut through the complexity and look at the most straightforward arrangement: a horizontal pull on the cable directly out from the side of the MacBook. Even with this simplification, there are two problems that have to be solved.

Glenn had already solved the first one, which is determining whether the friction within the USB-C connection was sufficient to allow the MacBook to be dragged along the table by pulling on the cable. As a first step, he had looked up the extraction force in the USB-C spec and found this:

The connector extraction force shall be within the range of 8 N to 20 N before and after the specified insertion/extraction or durability cycles.

In case it’s been a while since your last physics class, the “N” in that paragraph refers to newtons, the standard SI unit of force. One newton is a little under a quarter of a pound. My favorite way of remembering this is that a newton is roughly the weight of a small apple.

The next step is to determine the MacBook’s resistance to sliding. That’s going to be the product of the normal force between the table and the computer—which is the MacBook’s weight, 9 N—and the coefficient of friction between the computer’s rubber feet and the table. Glenn used a handbook value of 0.7 for the rubber-on-wood coefficient of friction, a number I thought was an overestimate based on my experience with my MacBook Air. I ran a couple of tests there in the hotel room and got a value closer to 0.4. In the article, Glenn politely used both values, but here I’m going to stick to 0.4. Because we don’t have a new MacBook to test, neither of us really knows.

(Glenn mentioned another wrinkle pointed out to him by Bradley Grzesiak: a 1942 study from the National Bureau of Standards that showed the coefficient of friction of rubber against various surfaces can vary wildly with sliding speed. In this first analysis, we’re looking at static friction only, so sliding speed doesn’t enter into the problem. But we will be looking into sliding later. Even so, I’m not sure how applicable this study is to our situation. It was concerned with soft rubber, and the feet on my MacBook Air are anything but soft. In fact, I’ve often wished they were soft so they’d be stickier. Again, until we know more about the new MacBook, we’re just making estimates.)

So the resistance to sliding is $0.4\times9\;\mathrm{N} = 3.6\;\mathrm{N}$, which is well below the minimum extraction force of $8\;\mathrm{N}$. So it’s pretty clear that you will be able to drag your new MacBook across a table by pulling on the power cord.

But there’s more to the problem than that. If the MacBook starts accelerating during the pull, then its own inertia will create another resistive force to be added to the friction. If the cable is jerked fast enough, the MacBook will move a bit, but the connector will come out before it moves much. In principle, this is like the trick of yanking a tablecloth out from under a table full of dishes.

It’s this dynamic problem that I analyzed Tuesday night and sent to Glenn. Here’s the solution I wrote out in my notebook:

The drawing at the top is a free-body diagram of the MacBook, looking a lot chunkier than Jony Ive would like. The forces acting on it are: $P$, the extraction force of the connector; $mg$, the weight (mass time acceleration due to gravity) of the MacBook; $N$, the normal force2 exerted by the table on the MacBook, and $f$, the friction force exerted by the table on the (sliding) MacBook.3

Because there’s no acceleration in the vertical direction, the normal force is equal to the weight. And because the MacBook is sliding, the friction force is equal to the product of the normal force and the coefficient of friction:

Using this and Newton’s 2nd Law in the horizontal direction leads us to the final equation,

What does this tell us? If we plug in the values for all the terms on the right, it’ll give us the acceleration of the MacBook as we pull the USB-C plug out. It is, therefore, the smallest acceleration of the cord for which the connector will come out.

We can calculate this acceleration for both the minimum and maximum extraction forces allowed by the USB-C spec:4

So you can yank out a connector at the loose end of the range with a cord acceleration greater than $4.8\;\mathrm{m/s^2}$, but one at the tight end of the range will take $17.8\;\mathrm{m/s^2}$. That’s where those numbers came from in Glenn’s article.

Now let’s figure out how far will the MacBook move as we yank the cord out. As an example we’ll assume the cord is being pulled at a $1\;\mathrm{g}$ ($9.81\;\mathrm{m/s^2}$) acceleration and we have the loosest allowable USB-C connection. Therefore, the plug at the end of the cord, which is 6 mm long according to the spec, is moving at $5\;\mathrm{m/s^2}$ relative to the MacBook. It will take

for the plug to pull out, during which time the MacBook will have moved

or about 6 mm. Is it a coincidence that this is about the same as the length of the plug? Sort of. It’s because I chose for this example a cord acceleration roughly twice that of the MacBook. Had I chosen a lower cord acceleration, the MacBook would move more; had I chosen a higher cord acceleration, the MacBook would move less.

We’re not actually done, though. When the plug pulls out, the MacBook is moving at a velocity of

It now has to decelerate to a stop. With a frictional force of $3.6\;\mathrm{N}$ acting to slow it down, it will decelerate at a rate of

and will come to a stop in another

or 7 mm. That means it moved a total of about 13 mm. Half an inch. Not bad, but remember we’re assuming

1. A straight pull out the side of the MacBook.
2. A pretty decent yank on the cord.
3. The loosest possible connector.

We’re not likely to get that combination in the real world. Most cord entanglements are slow motion disasters, where you immediately feel yourself getting caught but just can’t stop in time. And the pull is almost never straight out. Glenn is right to be pessimistic.

But let’s not end on a downer. You didn’t think I chose the title of the post at random, did you?

Jimmy Iovine is listed as engineer on the album, but its recording history is so fragmented, I’m not sure he worked on this track. But let’s say he did just to make a stronger connection to Apple.

1. Also known as the home of kraeusening, the most natural way to brew beer. And the most expensive.

2. “Normal” in this situation has the mathematical meaning of “at right angles to a surface.” It doesn’t mean “ordinary.”

3. Two reasons why I’m not accounting for the possibility of horizontal rotation as the cord is being pulled:

1. When the lid of my MacBook Air is up, the center of gravity of the computer is reasonably well aligned with the power plug.
2. I have no idea where the c.g. of the new MacBook is, so any attempt to handle horizontal rotation would be a lot of work with very little justification.

4. Yes, I’m pushing the significant digits further than I should.