Archive for May 2010
Thursday, May 27, 2010
Daniel Jalkut:
What they have done is alienated developers, and ultimately deprived users of software they want to see on the platform. My fear is these botched decisions are hurting Apple, but they aren’t feeling it. Pain is a gift: the signal that prevents a burned finger tip from becoming a body engulfed in flames. Apple is numb from success, and I hope the emerging competition from Google and others will re-sensitize them to the threat of failure.
I have a different fear (or, rather, belief): that Apple is doing enough things right that they will not have to alter their course, just as Microsoft never had to make an operating system that appealed to Mac users. Apple is ignoring some very low levels of pain because they have their eye on a prize. They don’t care about alienating developers, even top ones, so long as they’re selling lots of devices and apps. They can thrive without pleasing everyone.
Some Mac developers, myself included, see Apple as holding the iPhone platform back. There are lots of apps, but there could be more and better ones. The SDK and tools are good, but Apple is retarding innovation. The App Store is helping some developers make money, but Apple could be a business partner that we like and admire. It’s frustrating to see unmet potential.
But, as a user, the iPhone is good enough. I’m not tempted by Android in the least. I like the way my iPhone works, and I like that it syncs with my Mac software. That said, it can only be good for iPhone users if Google makes a great competing product.
Wednesday, May 26, 2010
John Gruber:
Go through Twitter’s trending lists to read tweets from random users, and notice how the ones with the generic Twitter bird avatar are generally just full of hashtag gibberish. More often, I run into it as the avatar representing spambot accounts. So I’ve come to associate this icon with something mildly unpleasant, sort of like the “missing image” icon in a web browser. If this is a logo mark Twitter wants to associate with the company, they should stop associating it with their worst users.
Tuesday, May 25, 2010
Christian Sunesson (via Jonathan Rentzsch):
The funny thing is that the OOP world have found one way to manage the complexity and the code-bases that grow ugly: They are using unit tests, and practice the art of writing testable code. […] What they are doing is that they are making as much of their code as possible to be side-effect free and placing all that code in one method so it can be called from a unit test. They are concentrating side-effects to well-defined places, carefully avoiding mixing side-effects and testable/test-worthy logic. What they are doing is that they're reinventing functional programming.
I think he’s right. To a first approximation, code that’s more functional is easier to get right, easier to test, and easier to maintain.
Matt Drance:
Think about the number of iPhone commercials you’ve seen that demonstrate using apps while a call is active. Now imagine those commercials vanishing because the iPhone is on Verizon. The ability to—wait for it—multitask while on the phone has been a critical selling point of the iPhone experience since the iPhone 3G launch almost two years ago.…Apple is not the kind of company that takes huge steps backward just to win a few more customers.
Everyone seems to be making this argument, but I just don’t buy it. This is not a huge step backwards. I bet that the average iPhone user doesn’t know about this differentiating feature and doesn’t surf much, if at all, while on calls. Verizon makes potentially millions of customers available to Apple, customers who won’t miss this feature because they never had it. The existing AT&T customers would lose nothing. If iPhone users ever do have a choice of carriers, AT&T will do the work for Apple in making it clear that this is a network feature rather than a device feature.
Joe Damato:
So the action is to a handler at http://dailywish.amexnetwork.com/preid2.aspx?ct=7. The lack of https doesn’t make me feel very good.
The implication is that with JavaScript validators and Ajax, Safari’s lock in the title bar is not sufficient to tell you that the session is secure. And running a browser with JavaScript off is becoming less and less palatable.
Joe Kissell:
The problem is, none of these methods are fool-proof. Even uninstallers that rely on lists of files provided by the developer. And the fact that an application created or modified a file doesn’t necessarily mean it owns that file, or that it’s safe to delete.
Whenever I read about one of these utilities, I wonder what problems they might cause by partially removing some software or by removing too many files. The effects are not necessarily easily detectable right away. If the goal is to reclaim disk space, Spotlight is probably sufficient. If you don’t know how to use Spotlight and interpret its results, I’d look for a product-specific uninstaller or instructions. Absent those, my general recommendation would be to leave the software installed.
Damian Conway:
As for Perl 6, I think it’s impossible to accurately estimate just how valuable a built-in grammar mechanism is until you actually have one. It’s true that XML and YAML/JSON cover a lot of data representation needs, but there is a vast amount of data that isn’t available in those formats and will never be unless it’s parsed and converted. And a grammar is unquestionably the best way to do that.
Lukas Mathis:
In a way, gestural user interfaces are a step back, a throwback to the command line. Gestures are often not obvious and hard to discover; the user interface doesn’t tell you what you can do with an object. Instead, you have to remember which gestures you can use, the same way you had to remember the commands you could use in a command line interface.
Great post.
James Iry:
If only Java didn’t have covariant arrays. Or, since it does, if only the designers had used something other than arrays to carry varargs. Woulda coulda shoulda. This article shows just how hard it can be to extend an existing language without shooting yourself and your users in the ass. Runtime checked array assignment + varargs in arrays + type erasure == pain.
An interesting cascade of design decisions. It’s not clear to me why Sun was so resistant to evolving the bytecode.
Thursday, May 20, 2010
Matt Drance:
Google is a publicly traded corporation that controls the flow of more and more information every day. It’s very troubling to watch them rewrite history in such a self-serving manner.
Wednesday, May 19, 2010
Kellan Elliott-McCrea (via John Gruber):
With Flickr you can get out, via the API, every single piece of information you put into the system.
Every photo, in every size, plus the completely untouched original. (which we store for you indefinitely, whether or not you pay us) Every tag, every comment, every note, every people tag, every fave. Also your stats, view counts, and referers.
Bravo.
Tuesday, May 18, 2010
Pierre Igot:
Using a non-standard alternative animation instead of the SBBOD is not going to do anything to improve the performance, perceived or real, of the applications. It just looks like a really poor way to try and mask the applications’ responsiveness issues instead of actually dealing with them.
Using the standard Mac OS X indeterminate progress spinner as a cursor is just bizarre.
Update: Jesper’s take.
Update 2: Igot’s follow-up post.
Dave Girard:
Aperture 3 includes a ton of workflow tweaks and improvements—so many that covering every little one would be excessive. Sure, the new feature page has some padding like “Space Bar Playback”—that’s a bit of a stretch as a feature. But there are lots of touches that make version 3 a more comfortable, well-rounded workspace for importing, sorting, tagging, developing, and exporting images.
Aperture 3 is really, really good, except that it’s so much slower than Aperture 2. If you have a notebook, even a recent MacBook Pro, I think you pretty much need an SSD, whereas Aperture 2 worked fine for me with a 5,400 RPM drive.
Since there’s no standardized metadata format for faces and names, Aperture 3 lets you export the names in photos as IPTC keywords, which can then be embedded into image for Spotlight or image bank searches. Nice to see that this feature was thought through so well.
Unfortunately, Aperture does not store the faces information as securely as the other metadata. Also, there’s no way to organize faces. I continue to use keywords instead.
Aperture Mac
Steve Jobs (February 2010):
Something like HyperCard on the iPad? Yes, but someone would have to create it.
Kevin Miller, CEO of RunRev, a HyperCard successor (May 1010):
Steve Jobs has now rejected our proposal and made it clear that he has no interest in having revMobile available on the iPhone or iPad in any form.
It sounds like they had proposed to compile revTalk, much like Adobe did with Flash, and support all of the iPhone OS APIs. Not a surprise, given Section 3.3.1, but it’s too bad because the iPad seems like the perfect way to deploy a HyperCard stack.
Monday, May 17, 2010
Gary Bernhardt:
Mercurial’s repository model is clunky and stays hidden in the background (this is a bad thing; don’t let anyone tell you otherwise). If you have a Mercurial repository whose size is dominated by a single, 20 MB directory, and you then rename that directory, your repository just doubled to 40 MB. This has limited my ability to manage real-life Mercurial repositories. Git’s repository model is so good that I only hesitate slightly when calling it perfect.
John Gruber:
I can’t tell whether Geschke is being dishonest, or whether he truly is under the impression that Mac users don’t have serious, long-standing complaints about the quality and UI design of Photoshop (and the entire CS suite). And Acrobat? Acrobat is despised by Mac users. If not for Apple’s Preview (and Mac OS X’s Apple-written PDF implementation), Mac users would despise the entire PDF format.
Indeed, I didn’t much like PDF files until I started using Preview.
Saturday, May 15, 2010
Dave Dribin:
But because these are anonymous variables, you can take the address of them:
int * iPointer = &(int) {3};
This can be useful for some Core Audio APIs, such as AudioUnitSetProperty. Typically you create a variable for the sole purpose of taking the address of it…
C Programming Language Programming
Friday, May 14, 2010
Mike Ash:
Ultimately, this will be a collection of common problems in API design and implementation, and large chunks of any real application count as APIs. While I really want Apple to follow these ideas, if you follow them as well, they should make your life much easier.
A good list. I wonder whether Apple prefers void * user data for performance reasons (no need to allocate wrappers for non-objects), but certainly it would be lower friction if they just used id.
Somehow, it’s totally unsurprising that Panic would have an Apple IIe at their office and use an iPad to load source code into it via the audio input port, and yet I wouldn’t believe this in a Hollywood blockbuster.
Mike Ash:
These ideas almost all fall under the category of “utilities.” And this is no coincidence: utilities are largely tools which work in concert with other software to offer more power in combination than you get separately. Apple prohibits third party apps from influencing anything outside themselves, so this sort of utility is impossible. The Utilities section of the App Store is a joke. Most of what it contains is either useless or miscategorized, because Apple forbids the creation of any true utility software for this platform.
Some interesting ideas there, and I, too, would like to be able to buy and develop utilities for the iPhone. However, I believe the larger problem is the uncertainty regarding apps that do follow the developer agreement. Is anyone maintaining a list of all the rejected apps?
Wednesday, May 12, 2010
Matt Gallagher:
The reason for separate regions for tiny and small allocations is that it allows the region’s metadata to be more efficiently tuned to tracking the size of object it contains. For “tiny” allocations, tracking memory down to 16 byte units is worthwhile (it allows freed space to be reclaimed better and doesn’t waste large amounts of memory around allocated objects). For “small” sized objects though, tracking at this resolution would be a poor tradeoff between CPU time (traversing through lists of freed or allocated blocks) and memory efficiency—the coarser 512 byte resolution is more efficient.
Tim Bray:
There are really two choices: Put the ISO on the cool funky ring around the lens and the aperture compensation on the fiddly dial on the back; or the other way around. And the problem is that it’s hard to hold the camera without jostling that dial at the back.…So I’ve ended up parking the exposure compensation on the too-accessible back dial, because those adjustments are reflected in the CRT and you can tell when you’ve accidentally cranked it.
The camera’s great, but I accidentally hit the back dial, too. Setting it to exposure compensation seems to be the best way to minimize surprises.
Camera Canon Photography
Monday, May 10, 2010
Jakob Nielsen:
When you combine these three usability problems, the resulting user experience is frequently one of not knowing what happened or how to replicate a certain action to achieve the same result again. Worse yet, people don't know how to revert to the previous state because there's no consistent undo feature to provide an escape hatch like the Web's Back button.
Sunday, May 9, 2010
Steve Huffman:
The way we’ve changed is we use an “open schema”. Sometimes it’s called “entity attribute value”. It’s basically a large key value store. We have two types of tables for every data type. There is a “thing” table, and then a “data” table.
Thursday, May 6, 2010
Daniel Vik (via Mike Ash):
Considering the only change that was made was to change the type, the different output may be a bit confusing. But there is a very good reason for the behavior, and you guessed, it is spelled integer promotion, and the variables a and b are promoted to integer before the addition is executed, and thus the result is always greater or equal to the right hand operand in the comparison.
Sunday, May 2, 2010
