October 25, 2014 at 1:44 PM by Dr. Drang
One upside of getting older is that if you can avoid drooling, younger people often think you know stuff about the “olden days.” This is how I ended up explaining what it used to be like working with computers on the most recent episode of Technical Difficulties.
A downside of getting older is that although you can remember perfectly well an advertisement from the ’80s for Lightspeed Pascal, you can’t remember what you did a few months ago. This episode was recorded back in August, and while I recall enjoying myself and talking too much, I have no idea what I actually said. It’ll be as new to me as it will be to you.
October 24, 2014 at 10:02 PM by Dr. Drang
I don’t own an iPad, and I don’t much care for articles about the business side of the computer industry. But I do have a blog, which automatically makes me an expert on both.
When Tim Cook showed this slide during the recent Apple Special Event, it was a way of avoiding showing an updated version of this slide from last year’s October event:
In an updated graph, the downward curvature would be more prominent.1 For the past three quarters, iPad sales have been down from the year-ago quarter, and the unthinking wing of the tech press has finally picked up on it. Stories have shifted from “iPad will take over all of computing” to “iPad is a failure.” Tim’s slide comparing the iPad to all of Lenovo, HP, etc. puts this “failure” in perspective. A more nuanced view may be in order.
When the iPad was first announced, I gave it a lot of thought. My late-2004 iBook G4 was stuck on Leopard, the last version of OS X that supported the PowerPC, and third-party developers were starting the shift to Intel-only applications that would leave my old G4 even further behind. Even worse, the power supply connection was getting flaky, and it seemed foolish to pay for repairs to a machine that was on the way out.
The question was: could an iPad take the place of my iBook G4? After the iPad was released, the answer was clearly no. Luckily, Apple came out with the redesigned and actually usable version of the MacBook Air later that year, and that solved my replacement computer problem. I’m still using it.
The time I spend thinking about that first iPad wasn’t wasted, though. When the iPad 2, with its A5 chip2 and front-facing camera, came out the next year, I got one for my wife, and it’s been her main computer ever since. It fits her needs very well, but the areas where it doesn’t fit illustrate why we haven’t yet shifted into the post-PC era.
Second, there’s the printing problem. I know lots of young people think printing is dead, but adults still live in a world where forms have to be printed out and taken or physically mailed to offices. I solved some of this problem by getting an AirPrint printer, but pages printed from the iPad often come out poorly formatted. Some of this is certainly not Apple’s fault—the world would be a better place if form makers would just use PDF—but it could help out by giving users a little more control over printing. Even just allowing users to choose which pages to print would be a big step forward.
Finally, there’s the big problem: storage. How does someone on a iPad access all of the photos and music and video and other files that are part of the modern digital life that Apple wants us to lead? None of us can be post-PC until all of our stuff is where we can get at it without a PC. That there’s been no clean, obvious, and reliable solution to this problem is definitely Apple’s fault, and it’s kept the iPad from being a complete PC replacement.
The thing is, Apple is almost uniquely unqualified to provide the kind of online storage the iPad needs. The history of Apple cloud-based services is so laden with bad ideas and worse execution that it’s impossible not to be skeptical when a new service is announced. Still, I hold out hope that iCloud Drive is the solution, because the iPad Air 2, when combined with iOS 8’s new openness, is a compelling machine.
The performance of the A8X and the additional RAM really do make the new iPad look like a viable replacement for a notebook computer. Its Geekbench scores are well beyond those of the machine I’m typing this on. But that’s not the whole story. Apple’s always had a deep understanding that it’s software that makes hardware live up to its potential. Let’s hope it’s finally learned that network services are just as important.
October 20, 2014 at 11:45 AM by Dr. Drang
Driving along, listening to a podcast. My iPhone is plugged in to top off its battery. The message alert sounds, interrupting John Siracusa’s complaint about Apple still selling 16 GB iPads and iPhones.
“Read me the last text message.”
“There are no messages.”
“Yes there are! You just made the new message sound! What the hell is wrong with you? You used to know how to do this!”
October 19, 2014 at 10:10 PM by Dr. Drang
I’ve been adding more automation to my static blog publishing workflow.1 The scripts themselves are of no use to anyone else, but some bits and pieces may be of wider interest. For example, this morning I wrote a script using a library that converts Unicode strings to their nearest ASCII equivalent.
The script, written to be used as a Text Filter in BBEdit, automates the generation of header lines in the Markdown source code of a post. The header of this post, for example, looks like this:
Title: ASCIIfying Keywords: python, programming Date: 2014-10-19 22:10:00 Slug: asciifying Link: http://www.leancrew.com/all-this/2014/10/asciifying/
I write the Title and Keyword lines as I start the post, using a simple BBEdit Clipping. But before I publish, I need the other lines. The Date is easy to generate using the
datetime library. That’s also the library I use to generate the year and month portions of the Link URL. The tricky thing is automating the creation of the Slug, which also shows up in the Link.
Oh, it’s very easy to make a slug when the title is as simple as this one, but suppose we started with this:
Title: Çingleton/Montréal isn't done Keywords: test
Non-ASCII characters are allowed in URLs, but they can be troublesome, and I prefer to avoid them. Also, we can’t have the slash in there, and the apostrophe ought to go, too. Finally, I don’t want any spaces, because they cause nothing but trouble in the file system, and I hate seeing
%20 in a URL.
The function I settled on is this:
python: 1: def slugify(u): 2: "Convert Unicode string into blog slug." 3: u = re.sub(u'[–—/:;,.]', '-', u) # replace separating punctuation 4: a = unidecode(u).lower() # best ASCII substitutions, lowercased 5: a = re.sub(r'[^a-z0-9 -]', '', a) # delete any other characters 6: a = a.replace(' ', '-') # spaces to hyphens 7: a = re.sub(r'-+', '-', a) # condense repeated hyphens 8: return a
All of the lines are straightforward and obvious except the
unidecode call in Line 4. That is the one function exported by the
unidecode library, and it does the substitutions that make
slugify generate strings that are much more useful than anything I could write with the standard
decode methods. My script turns that two-line header above into
Title: Çingleton/Montréal isn't done Keywords: test Date: 2014-10-19 21:31:22 Slug: cingleton-montreal-isnt-done Link: http://www.leancrew.com/all-this/2014/10/cingleton-montreal-isnt-done/
which has a perfectly readable URL that includes nothing but lowercase ASCII characters, numerals, and hyphens.
unidecode library is a Python port of a Perl module, and its documentation is sparse. If you want to know what it does and why it does it, go to Sean Burke’s writeup of his original Perl module,
Text::Unidecode. It lays out his goals for the module, explains its limitations, and includes little gems like this:
I discourage you from being yet another German who emails me, trying to impel me to consider a typographical nicety of German to be more important than all other languages.
If you ever need to ASCIIfy some text,
Text::Unidecode or one of its ports (here’s one for Ruby) will come in handy.
“Static blog publishing workflow” may be the most jargon-filled four-word phrase I’ve ever written. ↩