You’ve probably seen this classic map showing a New Yorker’s view of the world:
Here’s how a New Yorker running iOS 6’s Maps app sees the world, courtesy of MAD:
Click to see the original.
This article also appears in The Adventures of Accordion Guy in the 21st Century.
The ThinkPad laptop — originally made by IBM, now made by Lenovo — made its debut 20 years ago. Industrial designer Richard Sapper (the guy behind the Tizio lamp, Lamy ballpoint pen and a lot of Alessi kitchenware) contributed to its initial design, taking his inspiration from traditional black lacquered bento boxes. When it came out, it stood apart from other laptops, in both looks, functionality and toughness. According to Wikipedia, the ThinkPad has been used in space and is the only laptop certified for use on the International Space Station.
Oddly enough, of all the laptops I’ve had, I’ve never had a ThinkPad. I came pretty close: in the spring of 2011, when I was still a Developer Evangelist at Microsoft, I got one assigned to me as part of my gear (I used to joke that my job meant that I had “one laptop for every limb”). The laptop arrived for me — three days before I left the company. I never even got to unbox it; the photo above shows how close as I got to the machine.
The ThinkPad 700 – the first ThinkPad, released in 1992.
Lenovo have put out a call on the internet — they’re looking for world’s oldest working ThinkPad. Have you got an old one that still boots up or may even be performing yeoman service in some corner of your office? Post a story and picture on Google+ with the hashtag #ThinkPad before Friday!
In an earlier post, I talked about a couple of changes to Objective-C that should reduce the amount of “yak shaving” you need to do while coding: syntaxes for NSNumber, NSArray and NSDictionary literals, as well as the new, shorter syntaxes for NSArray/NSMutableArray and NSDictionary/NSMutableDictionary item access.
Here’s the tl;dr version of this post: you no longer have to @synthesize properties! (Most of the time, anyway.)
In the early days of object-oriented programming, you were supposed to make a class’ public attributes accessible through public variables. Access was pretty simple:
previousSpeed = myCar.speed; myCar.speed = 50;
Then, it became a better idea to lock away all the variables and use getters and setters:
previousSpeed = [myCar getSpeed]; [myCar setSpeed:50];
It does the job, but it’s a little clunky.
Nowadays, the preferred way to expose class attributes in a number of languages is through public properties. With them, we’re back to accessing object attributes through this simple syntax:
previousSpeed = myCar.speed; myCar.speed = 50;
@synthesize Was ForCreating properties in Objective-C classes used to require statements in a couple of places. For a public property, you had to declare it in the interface (.h) file:
// Car.h @interface Car : NSObject @property int speed; @end
The @property statement tells the compiler that you want to expose a property; in the case of the code above, the name of the property is speed. Properties are by default both readable and writeable. If you like to spell everything out very explicitly, you can by declaring the property this way:
@property (readwrite) int speed;
If for some reason you wanted speed to be read-only, you can declare the property this way:
@property (readonly) int speed;
With every property declaration comes the need for the underlying instance variables — ivars in Objective-C parlance — and the requisite getter and setter methods, which go in the implementation (.m) file. All this setup for each property can get a little tedious, and the @synthesize statement saves you from that tedium. Instead of having to declare the corresponding ivar and write those methods, @synthesize lets you do all that in a single line of code:
// Car.m @synthesize speed;
By default, the name of the ivar created by @synthesize was the name of the corresponding property preceded by an underscore character. For example, the default name of the ivar behind a property named speed would be _speed. If you preferred, you could specify a different ivar name this way:
// Car.m @synthesize speed=someOtherIvar;
The general rule was that if you only needed a simple getter and/or setter for a @property, use @synthesize.
The version of CLang (the Objective-C compiler) that comes with XCode versions 4.3 and later (the latest version is 4.5), supports autosynthesis, which automatically does the synthesizing for any class properties you declare in the header. If your @property needs only a simple getter and/or setter, you don’t need to have a corresponding @synthesize anymore. The compiler takes care of that for you.
Properties with autosynthesis work like they did with manual synthesis. You access them using the self.propertyName syntax, and the name of the ivar that gets generated is still the name of the property preceded by an underscore character.
@synthesize is Still UsefulThere are some cases where you’ll still want to use the @synthesize keyword, and this article in the blog Use Your Loaf does a good job explaining these cases. Such cases are a little more rare; most of the time, you can simply skip added @synthesize to your code because the compiler’s taking care of that for you!
The title for this article comes from the chorus of Shriekback’s 1985 alt-dance number, Nemesis:
Priests and cannibals
Prehistoric animals
Everybody happy as the dead come home
3rd Place is a disturbing yet amusing coloring book really meant for adults.
Click the photo to find out more.
A conversation I had with a friend circa April 2011, shortly after I posted this article:
Friend: So why’d you leave? Was it the money?
Me: Are you kidding? The money’s awesome. In fact, the money’s making it hard to leave.
Friend: It was the incident*, was it?
Me: Actually, no. Even right after “the incident” [I made “air quotes” with my fingers while saying this], I was quite sure I was going to stick around for a while.
Friend: So what was it, then?
Me: A bunch of things. After everything that’s happened, I figured I was due for a change. Plus, there’s the whole being-the-Windows-Phone-guy thing. I’ve done too many 14-hour days and a lot of slogging around for what? A distant third place…if we’re lucky.
* The incident is a good story, best told in person over drinks.
“We have a clear shot at being the number three platform on the market. We’re not just another open platform on the market, we are BlackBerry.”
“Why go for the gold when you can go for the bronze?” said no one, ever.
To be fair, later in the article, it says:
Asked why he wasn’t aiming for one or two, Heins said “you climb a mountain step by step.”
That’s actually pretty reasonable. The next 18 months will tell the rest of the story, but the trends aren’t with them right now, according to Dan Frommer, who reminds us how far RIM has fallen with this graph:
Maybe RIM can borrow a page from AVIS’ book and come up with a slogan like “We’re number three, so we try harder”…
Click the photo to see the source.
Just like as the white zone at the airport is for loading and unloading only, my left pocket is strictly just for my iPhone (still a 4S — I got it in November, and I’ve no compelling reason to upgrade yet). That way, there’s considerably less chance for it to get scratched. Even so, I keep my iPhone in a case, even if Darth Gruber disapproves.
Click the photo to see the source.
With the iPhone 5, Apple ditched the “glass sandwich” design in favour of aluminum. The problem is that customers have noticed — and remember, it been available for less than a week — is that it scuffs, scratches and even chips a little too easily.
Click the photo to see the source.
Any aluminum product may scratch or chip with use, exposing its natural silver color. That is normal.
He must be channeling the spirit of Steve Jobs — this is “You’re holding it wrong”, version 2.0.
All this reminds me of an article by Khoi Vinh in his blog Subtraction, in which he talks about designed deterioration. He waxes poetic about his cast iron skillet and other things that look better when worn or used heavily:
…I have a US$20 cast iron skillet that I bought several years ago from a restaurant supply shop in downtown Manhattan. I’ve cooked hundreds of meals with it, and over time it has developed a coating from oil and food — the manufacturers call it ‘seasoning.’ It’s a little unbecoming when you think about it; in fact, though I clean it, it’s a dirty piece of cookware, and it resembles its original, store-bought state not at all.
…After cooking in it and cleaning it up, I’ve spent a lot of time just looking it over, marveling at how its very deterioration has been incorporated into the design of the object, at how it’s gotten more attractive — less ignorant — the more I use it. I’m not particularly sentimental about much in my kitchen, but I would be heartbroken if you took away this iron skillet…
He compares it to his technological goodies, for which the opposite is true:
I mention these things because I’ve noticed recently that the concept of what we might call designed deterioration is fairly anathema to digital hardware. The objects we purchase from purveyors of digital technology are conceived only up to the point of sale; the inevitable nicks, scratches, weathering, and fading they will encounter is not factored in at all. The result is that as they see more use, their ignorance may recede, but they wear it poorly. They don’t age gracefully.
Looking at the digital technology I own, what moderate deterioration to be found — dents in my laptop, a gash in the side of a laser printer I own, the accumulated grime on my computer keyboard — doesn’t make these items more desirable at all. In fact, when I see the way the corner on my aluminum PowerBook has been warped due to a nasty fall from a chair, I cringe. Through this obvious, glaring example of use, of accumulated knowledge, the object itself hasn’t attained an additional whit of beauty.
In fact, the damage is actually quite repulsive. This is because the laptop was conceived by Jonathan Ive based on an assumption that it would remain perfect forever. There was no designed deterioration factored in whatsoever, and so no real thought was given to how the laptop might change with use. Marks of knowledge, like the warped corner, aren’t meant to be embraced, but rather denied.
He also astutely observes that if you designed things like iPhones to look better with age and use, you’re discouraging people from upgrading to a newer model.
9to5 Mac have pointed to a “LOLWTF” video by “RIM Speedwagon”, a band consisting of some RIM VPs including Alec Saunders (VP Developer Relations and Ecosystem. When I was at Microsoft as a Windows Phone Champ, I used to say “Well, at least my job is easier than Alec’s.”
Done to the tune of REO Speedwagon’s 1981 hit, Keep On Loving You, the song in the video is a message to developers: just hang on a little longer, and we promise that you won’t be disappointed.
I don’t think it was a good idea to pick a tune that was already retro when many of today’s mobile developers had yet to be conceived, but perhaps they’re aiming at the enterprise developer demographic, who are an older crowd. The song may resonate with those of us who grew up in the ’80s, but to the millennial crowd, it may cement BlackBerry as “the old folks’ phone”. I remember growing up in the ’80s and being annoyed at all the ’60’s nostalgia that the then-guardians of pop culture were shoving down our throats; surely it must be like that for the young’uns today as we expose them to old MTV era tropes.
Still, I have to say that cheese-tastic as RIM Speedwagon’s song is, it’s still a damned sight better than the Bruce Springsteen homage in this internal “Sell more Windows Vista!” Microsoft video aimed at their sales team:
Come to think of it, I think the only techie-focused music video featuring an ’80s tune that ever made any kind of good splash was Here Comes Another Bubble:
I think it’s time to declare a moratorium on these things.
In the Seattle Times’ column Microsoft Pri0, Janet Tu points to the latest quarterly survey report of over 5,500 mobile developers conducted by Appcelerator and IDC. Among their findings:
In 5 Reasons Why Responsive Design is Not Worth It, Tom Ewer argues that in many circumstances, there’s no need for a web site to be responsive since the desktop version works just fine. The five reasons mentioned in his article’s title are:
Android Niceties is a Tumblr that showcases “screenshots encompassing some of the best, most beautiful looking Android apps”. If you’re an Android developer or designer, you’ll want to visit this site often for inspiration.