MASON MARK (.COM)

cloud backup sucks less now

2013-05-01T05:05:00+09:00

In the (very) boring world of backing up your computer(s), something genuinely cool happened recently: it finally became feasible to back up the whole computer to the cloud. Feasible, at least, for people with a first-world income and a decent Internet connection. (Sorry, bandwidth-challenged US residents! (Where by sorry, I of course mean neener neener.))

Until the end of 2012, there were two problems with trying to back up all one's bits to the cloud:

too fucking slow, or:
too fucking expensive

Happily, it is now 2013, and both of those problems have been ameliorated!

For several years, there have been cheap solutions that purport to be able to back up your computer to the cloud: Mozy, Backblaze, CrashPlan, etc. But in my real-world experience, none of these are actually capable of backing up more than a few piddlebytes of data. CrashPlan is said to be the best of the consumer-priced services, but the only time I ever used it in real life, it took more than a week to restore a mere 60GB of files (and, it fucked up all my folder mod dates for good measure).

It's debatable whether the software 'worked' in that case. Let's be generous, and say I didn't need my data in a hurry and didn't care about restoring the metadata accurately, so it 'worked' for backing up a 60GB home dir. Still, there is no fucking way you can say it 'works' when confronted with a whole computer's worth of data:

If your backup has been running for weeks, and still has 11.1 months remaining, it is not going to be very helpful when one of your hard drives dies next month.

The size of "a computer's worth of data" depends, of course; my Mac Pro holds a lot more data than my notebook, which in turn has a lot more than my sister's iMac. But I'll use my creaky old Mac Pro at home as a guide:

The pain of the caveman backup systems of yesteryear is reflected in my drive/partition scheme. The whole point of the JUNK volume is to store shit that doesn't really need to be backed up: Internet downloads, pr0n, anything easily replaced. Then I have a (poorly-named) BACKUP volume for OS X's built-in Time Machine snapshot system.

So what really needs backing up? SSD and STUFF. Potentially 3TB and change, although STUFF is actually only using 1.12TB of data right now.

Until recently, I've used the previously raved about backup tool Arq, to encrypt and back up my data to Amazon S3. Arq has a fairly efficient storage scheme, and it does a decent job of de-duplicating the data prior to transmission, so actual storage on S3 is substantially less than the actual amount of data being backed up: a month's worth of daily backups of my 1.12TB STUFF drive above actually uses 836.5 GB of storage in Amazon's cloud. (UPDATE: Oh oops, the actual size is 893 GB, so dedup is only saving 60GB. But still.)

That's nice, but still, 836.5 * $0.10/GB/month * 12 months == $1,004 per year to back up all this stuff. Maybe that would make sense if this computer was storing the irreplaceabe manuscript for my three-hundred-million-page novel. But what is actually stored on this Mac is mostly gigabytes of multi-angle video footage of me cooking, and shit like that.

Mmm... とんかつ...

So since that was too expensive, I didn't do that. I just dealt with having local backups and spent time futzing around with them every once in a while, getting more hard disks, configuring rsync to clone my shit to a spare machine at work (which is technically off-site, but not off-site enough to withstand a Godzilla attack on Tokyo), then having to debug why rsync would sometimes fail, etc.

Then one magical day, all that shit was solved.

Amazon came out with Glacier, their slow-by-design, long-term archival-oriented version of S3. Arq, naturally, released an update to support it.

The end result is: now I just back up all my shit to the cloud. The end.

$10.98. That is the total AWS charge for the month of March 2013, to back up that ~~1.12TB~~ terabyte-or-thereabouts. So, roughly $132 a year not to have to think about it.

Well worth it to me.

以上

Why iCloud can't ever be as good as Dropbox

2012-12-18T17:17:17+09:00

John Gruber has a blurb on DF today about how Apple should buy Dropbox, in part because iCloud sucks major asshole and Dropbox is OK (to paraphrase).

That second bit, at least, is accurate, and even if iCloud is someday engineered to synchronize files more quickly, easily, and reliably than Dropbox, it will still always be fundamentally worse than Dropbox. That is because iCloud comes with an intrinsic show-stopping, shit-splattering, critical flaw: vendor lock-in.

There are a lot of good things about Apple's integrated-hardware-and-software way of doing things. It is a key reason that they've consistently made the best PCs in the world for almost a decade now, and also the least-shitty overall smartphone OS yet developed.

But, of course, this approach isn't optimal for every possible goal. Competing with a product[1] like Dropbox is something that Apple is fundamentally disincentivized to do, and consequently sucks at (cf. every online service and every cross-platform app that Apple has ever produced).

Dropbox is awesome because -- even with some fairly glaring flaws (sporadically abysmal performance, data duplication/corruption on platforms that have symlinks) -- it provides this awesome cloud filesystem that works across all kinds of devices and platforms. I can create a document on my Dell XPS notebook running Ubuttnu 12.4, edit it on my toilet using my iPad, then later email it to somebody from my Nexus 7, incorporate their feedback while on the train with my iPhone, and then open it on my Mac Pro when I get to work. Oh, and if I had to boot Windows 8 for some reason, the document would be there, too.

iCloud will never work well on other platforms. I'd love to be proven wrong about that, but I'm not wrong, so I won't. Furthermore, iCloud doesn't even fully work on Apple's own OS X platform -- it only works for apps that submit to the fairly onerous financial terms and severe technical limitations dictated by Apple's app store.

Apple wants their awesome features to be available exclusively on their platforms, and exclusively on their terms. That innate characteristic of Apple completely prevents them from making certain kinds of awesome in the first place. Like the Dropbox kind.

There's nothing necessarily wrong with that; it's just the difference between a platform vendor wanting a feature, and a software vendor trying to reach a larger audience. But, for this kind of idea at least, one approach produces something a lot more useful and interesting than the other.

So if Apple were to buy Dropbox, that might help Apple, but it would be bad for the world, and a fucking disaster for Dropbox users. Gruber frets that Dropbox might get acquired by Google, Microsoft, Amazon, or Facebook. But as a daily Dropbox user, I'd be more concerned for its future if it were acquired by Apple than any of the first three of those companies[2]. Dropbox is the kind of product that Apple just wouldn't be able to restrain itself from fucking up.

-----

[1]: Steve Jobs was completely wrong (or perhaps more likely, lying) about Dropbox being a 'feature' instead of a product. It is exactly because it is not a feature of one device or OS that makes it really cool, and life-changing for a lot of people (like the guy Gruber is linking to in the piece above)

[2]: Of course, if Facebook bought Dropbox I would just cancel my account and switch to Google Drive or something.

Version 2.0a1

2012-11-14T05:05:00+09:00

Although admittedly a dilettante when it comes to evolutionary algorithms, I've been poking around (ahem) in that area, and recently managed to produce a new release.

Strictly pre-alpha functionality at this point, but I expect the final 2.0 to be ready around Q3 2047.

QRWTF

2012-03-16T15:57:00+09:00

So let's talk about the weird hating on QR codes thing that's going on.

As a former (and future(!) (just not this year (sigh))) Mac software developer, I tend to end up on a lot of Mac-related websites when out traversing the tubes.

Via these sites, I've gradually become aware me of a strange memetic condition that seems to be metastasizing to various organs of the macosphere: "Dude, QR codes are like, lame-o robot barf, dude." (I think the epidemiology of this outbreak of hateritus probably goes back to a mass googallergenic reaction to the QR code that was printed on the back of the original Nexus One, but that's speculation.)

At any rate, I was reminded of this while shirking some boring responsibilities and plowing through my RSS feeds earlier today. I came across this opinion from Brent Simmons, on his inessential blog:

Here’s the thing about the CueCat: it wasn’t that the hardware sucked, it’s that people aren’t going to scan things to go to a web page
And yet now we have QR codes, which we’re laughing at, and which will disappear like an American Idol contestant.

I like Brent (everybody likes Brent), but I think he's wrong on this one. (And, judging from the hilarious wtfqrcodes.com, perhaps America as a whole is doing QR codes wrong.)

I don't think QR codes are going away, nor would I want them to.

Because here's the thing: QR codes are simple and great.

Originally for Toyota to track vehicles throughout the manufacturing process, they were popularized (in Japan, years ago) for the purpose of avoiding having to type shit into your phone on its dinky and shitty little keypad.

And they've been working great for years and years, here in Japan; long before the iPhone existed -- before 'smartphone' was even a thing, really -- pretty much every phone in Japan could point its camera at a QR code and bookmark the URL. (Virtually always a URL, though QR codes can carry an arbitrary text payload.)

So I'd say that it was the CueCat hardware that sucked. Or rather, the concept of needing special hardware to scan URLs sucks. But when it can be done easily with the one generic piece of hardware that everybody carries with them all the time, I think that a 2-second barcode scan beats fucking around with a dinky little keyboard hands down.

Yes, yes, QR codes are for machines, not humans. But machines are for serving humans. So I don't see an inherent problem. Just like with karaoke, maybe Americans are discovering the QR code a decade late and aren't good at it. Plastering your promo -- or your clothing for fuck's sake -- with QR codes doesn't make you look like a hip high-tech badass the way some seem to think it does. But blaming the harmless and useful QR code for that is like blaming the colors green and pink for this guy.

One of the quirky deficiencies of the iPhone is that it~~'s the only phone I know of (in Japan) that~~ doesn't grok QR codes out of the box. A plethora of QR code scanning apps are available for iOS (most of them insufferably shitty and ad-ridden, of course). The app I use is Scan -- mostly because I can easily remember its name, the three or four times per year that I actually want to bookmark a website that I see on an ad in the subway. But it's also fast^[☠], simple, and fuckery-free -- much like the Quick Response Code itself.

UPDATE 2012-03-16: Horf tells me that many US or Korean Android phones sold in Japan also tend to make you install an app to get QR code scanning functionality.

[☠] So fast that it took me five tries to take that screen shot above, because the first four times by the time I could snap the shot, it had already recognized the code and moved on to the website.

More Xcode4 Fuckery...

2012-01-17T11:11:11+09:00

2012-01-17 after work: updated for ranty tone, petulance, spelling

This post describes a bug in Xcode 4.2.1, and a way to work around it. If you find it useful (for debugging the source code of your IDE, say) please come to my house and clean the grout in my shower.

This is not what a day's work should look like:

Today I enountered a [expletive] bug in Xcode, uncomfortably similar to the last serious^① Xcode bug that submitted me via rear naked choke.

Executive summary:

Xcode 4.2.1 (and I think maybe all 4.x versions so far released) will shit all over itself and become unable to edit .xib files, if there is header file that exists somewhere in your source tree (even one not actually included in your project), that contains an unterminated comment in it.

The symptoms are that you add an outlet to a class in code (e.g. in a MyViewController.h), but the outlet does not appear in the UI editor. So you cannot connect the outlet to whatever view or entity it is supposed to point to. If you quit and re-launch Xcode it tends to fix the problem. But you will end up having to quit and re-launch Xcode every single time you add any outlet to anything.

That's a workaround much like eating a piece of dogshit is a workaround for being hungry.

You can look at the bug reproduction demo project for an example.

That's it. You can stop reading here. If you can't edit .xib files in Xcode4, look for a stray header in your source tree, and not in your project, that has an unterminated comment in it. Or maybe some other sort of fuckery going on with it.

What follows are just my own posts on Apple's dev forum from today as I figured out what the fuck was going on with this bug, for the benefit of present and future search automatons^②.

More Extended Blather

Last time, what made the bug heinous was how hard it was to debug and find out which esoteric implementation detail of my Xcode project was triggering the issue. I couldn't reproduce the issue in some of my projects, but could in several others.

It turned out that some unknown thing Xcode does at launch time determined whether or not the bug would occur during that launch. The next time Xcode launched, it would again randomly determine whether or not the bug would occur. So to test any change you made, and see if that change helped prevent the bug from occurring, you had to quit and relaunch Xcode TEN MOTHERFUCKING TIMES. (And of course, by the time you figured this out, you would have already been fucking with it for some hours.)

It thus took me several hours to figure out that we could easily work around that bug by making sure that the project name did not contain the name of any command line tool that the project built. (So if your project builds a tool called "DiskEncrypter", you just have to make sure that the name of your project file is "Disk_FUCKYOUXCODE_Encrypter" or similar, and you're safe. Simple to work around; quite hard to find the workaround.)

Today I met another Xcode bug that completely broke a key IDE feature: editing the .xib files that define the UI for modern Mac applications. Once again, the underlying trigger is simple; once you know what to look for, you can work around the bug easily. But if you don't know what to look for, figuring it out will cost you about a day.

The main reason I write posts like this one is so that future people suffering from the same problem as me can just google the answer and save themselves the horror of wasting hours on pointless fuckery like I had to do. (And, obviously, to indulge in some cathartic ranting.)

This time, I'm too tired to embellish the bug report with a gripping human drama about magical fairies, sexism, and recreational drug use, so below, I'm just going to paste the series of my own comments from the thread I started on Apples (lame, slow, closed, un-googleable, etc, sigh) developer forum.

(Like most things Apple, that thread exists in a closed, walled garden that you may only access with Apple's permission and in ways they approve of: https://devforums.apple.com/message/605066)

How to manually force IB to reload a class definition

IB's automagic reloading of class files doesn't work, and it wastes a lot of my time. I hope there is a manual way.

Suppose I have FooViewController as the owner of FooView.xib. I add an IBOutlet to FooViewController.h, but it doesn't show up in IB. IB's notion of the class is generally some previous version that does not reflect the current contents of the class header.

This happens almost every day, and the only way I know to fix the situation is to quit and relaunch Xcode, which takes a long time. I often have to quit and relaunch Xcode each time I add any type of outlet to a view controller. This means quitting and relaunching Xcode dozens of times per day.

Is there any trick to force IB to re-examine a class's header? I know it is supposed to work magically, but it doesn't (and has never worked reliably on any of my machines on any Xcode 4 release; I am using 4.2.1 currently).

I see this behavior even for new classes, with no cruft in the header.

I notice, though, that if I select the File's Owner and then show the Connections inspector (View→Utilities→Show Connections Inspector), below the incorrect list of outlets in the "Outlets" section there is a small spinning progress indicator labeled "Updating...". It spins forever... the updating never finishes, and the newly added outlets don't appear in the .xib editor until I quit and relaunch Xcode. So the spinner never gets done, for me.

Sigh. Filed as bug #10698256.

Thanks for the suggestion. That didn't actually solve, but it is a clue. And, although the bug hits seemingly at random, I've now managed to create a test project that seems to reliably trigger the bug within a minute or two of adding outlets to a .xib's File Owner object.

After nuking the Derived Data dir manually, I notice that Xcode's car-dashboard display gets stuck saying something like "Scanning Classes | Processed 151 of 1072 files". Once in this borked state, .xib editing no longer works. The exact number where it stops changes from launch to launch. A screen shot is below -- Xcode never gets past this stuck state. If I quit and relaunch, it will get stuck again at a different point, but the outlets added the previous launch will show up in the .xib editor.

So it seems like you are suggesting that if Xcode cannot generate the project index -- or perhaps if Xcode corrupts the index -- the .xib editing features might stop working as I've described. And that seems to be corroborated by my experience.

If so, for me the next step would be try to figure out why Xcode cannot index my project. I have no idea -- nothing strikes me as too unusual about it. But nib editing does work in a trivial project (the default Cocoa.app, adding outlets to the nib) and doesn't work (as described in my bug report) in any of my real projects. What's the difference? All my real projects:

~~use git submodules. So some of the code being indexed is in repo A, and some is in repo B which is a git submodule of A.~~ (I tested this theory by creating a non-version-controlled copy of the demo project; bug still hit.)
use .xcconfig files, which inherit from a base .xcconfig file.
??? (Any suggestions of things that might affect Xcode's indexing process would be very welcome.)

I guess I can also attach my bug demo project to the bug report, for ease of reproduction, though I'll have to get approval to share the source code with Apple.

Searching the web, I find a tweet from Steve Streeting (whose fucking awesome work coincidentally happens to be showcased in the first screenshot in this blog post): "I'll make you a deal Xcode: if you don't leap into 'Scanning Classes X of 1670 files' again today, I won't punch you in the face."

Also, one solitary Stack Overflow post, wherein the author had the same problem (Xcode getting borked in the 'Scanning Classes' phase), and then answered his own question. The cause was a malformed header file that was choking Xcode. Unfortunately, he said he basically had to use trial and error to find the header file.

So maybe there is a file or files in my source tree causing this problem. Probably a file used in most of my projects, that being the reason I tend to see this bug all the time in various projects.

I checked what files Xcode has open right now, in its borked state, but unfortunately no clue there...

1/17/12 11:33:11.169 AM Xcode: _AMDDeviceAttachedCallbackv3 (thread 0x104f9e000): Device 'AMDevice 0x400315900 {UDID = 0f00d513253e35c985daffd8f3663a1b1939dceb, device ID = 11, location ID = 0xfa410000, product ID = 0x129f}' attached.
1/17/12 11:33:12.210 AM Xcode: _AMDDeviceAttachedCallbackv3 (thread 0x109439000): Device 'AMDevice 0x40139ac20 {UDID = 0f00d513253e35c985daffd8f3663a1b1939dceb, device ID = 11, location ID = 0xfa410000, product ID = 0x129f}' attached.
1/17/12 11:33:12.275 AM Xcode: Unable to find either a loadable database or a Nodes.xml configuration file
1/17/12 11:33:12.277 AM Xcode: Error loading docSet file://localhost/Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.DeveloperTools.docset/: Error Domain=com.apple.DADocSetAccess Code=12 "Documentation set could not be read." UserInfo=0x4001db180 {NSLocalizedDescription=Documentation set could not be read., NSLocalizedFailureReason=Unable to find the database or 'Nodes.xml' configuration file.}
1/17/12 11:33:12.552 AM Xcode: _GCDSearchPthreadOnceRoutine (thread 0x109439000): Looked up GCD symbols, got addresses: 8e42f884, GCD_AVAILABLE is 1
1/17/12 11:33:12.665 AM Xcode: <DVTSplitView: 0x4019f9280>: the delegate <DVTSplitView: 0x4019f9280> was sent -splitView:resizeSubviewsWithOldSize: and left the subview frames in an inconsistent state:
1/17/12 11:33:12.665 AM Xcode: Split view bounds: {{0, 0}, {600, 325}}
1/17/12 11:33:12.665 AM Xcode:     Subview frame: {{0, 0}, {260, 500}}
1/17/12 11:33:12.665 AM Xcode:     Subview frame: {{261, 0}, {378, 500}}
1/17/12 11:33:12.665 AM Xcode:     Subview frame: {{640, 0}, {260, 500}}
1/17/12 11:33:12.665 AM Xcode: The outer edges of the subview frames are supposed to line up with the split view's bounds' edges. NSSplitView is working around the problem, perhaps at the cost of more redrawing. (This message is only logged once per NSSplitView.)
1/17/12 11:33:13.101 AM Xcode: The class 'IBLibraryObjectTemplate' overrides the method identifier.  This method is implemented by class 'NSView'
1/17/12 11:33:13.101 AM Xcode: The class 'IBLibraryObjectTemplate' overrides the method setIdentifier:.  This method is implemented by class 'NSView'
1/17/12 11:33:14.129 AM mds: (Error) Task: Can't init <MDSClient 0x7fbf94c09a50 shutdown:NO got shutdown notification:NO> -- too many objects for MDSTaskRegistry
1/17/12 11:33:14.130 AM Xcode: BUG in libdispatch: 11C74 - 1819 - 0x4

The above is what Xcode logs when opening the project and getting into its borked state.

~~~

Interesting... I just noticed that after adding an outlet to my view controller, it did not appear in the .xib editor, per the bug. But after about 30 minutes of waiting, it did finally show up. So it isn't hanging infinitely, it is just hanging for 30 minutes or so. That made me wonder what Xcode is doing when it is in this borked state, since it seems not to actually be permanently hanging the process. I omit the irrelevant-looking threads in the sample below, but these are similar to two more samples five mintes apart, and looks like something is just making the indexing process take an extreeeeeeemely long time, rather than failing completely:

2035 Thread_15942608   DispatchQueue_1251: com.apple.dt.Xcode.IBHeaderScanningClassProvider  (serial)
+ 2035 start_wqthread  (in libsystem_c.dylib) + 13  [0x7fff84fdcb85]
+   2035 _pthread_wqthread  (in libsystem_c.dylib) + 316  [0x7fff84fdb3da]
+     2035 _dispatch_worker_thread2  (in libdispatch.dylib) + 198  [0x7fff8e42c760]
+       2035 _dispatch_queue_invoke  (in libdispatch.dylib) + 54  [0x7fff8e42cf66]
+         2035 _dispatch_queue_drain  (in libdispatch.dylib) + 264  [0x7fff8e42d10a]
+           2035 _dispatch_call_block_and_release  (in libdispatch.dylib) + 18  [0x7fff8e42b8ba]
+             2035 __block_global_5  (in IDEInterfaceBuilderKit) + 630  [0x10542fa41]
+               2035 -[IBSourceCodeParser parseFile:errors:]  (in IDEInterfaceBuilderKit) + 136  [0x10537db6a]
+                 2035 -[IBObjcParser parseData:fromFile:errors:]  (in IDEInterfaceBuilderKit) + 165  [0x10537d821]
+                   2035 nextRealToken  (in IDEInterfaceBuilderKit) + 83  [0x10537c9f6]
+                     2035 IBObjCLexerNextToken  (in IDEInterfaceBuilderKit) + 31  [0x10537a4bb]
+                       909 skipSpacesAndCR  (in IDEInterfaceBuilderKit) + 141  [0x10537b7a1]
+                       ! 909 parseGetc  (in IDEInterfaceBuilderKit) + 18,67,...  [0x10537b81f,0x10537b850,...]
+                       724 skipSpacesAndCR  (in IDEInterfaceBuilderKit) + 141,193,...  [0x10537b7a1,0x10537b7d5,...]
+                       402 skipSpacesAndCR  (in IDEInterfaceBuilderKit) + 171  [0x10537b7bf]
+                         402 parseGetc  (in IDEInterfaceBuilderKit) + 11,0,...  [0x10537b818,0x10537b80d,...]

2035 Thread_15948863   DispatchQueue_2425: com.apple.dt.Xcode.IBHeaderScanningClassProvider  (serial)
+ 2035 start_wqthread  (in libsystem_c.dylib) + 13  [0x7fff84fdcb85]
+   2035 _pthread_wqthread  (in libsystem_c.dylib) + 316  [0x7fff84fdb3da]
+     2035 _dispatch_worker_thread2  (in libdispatch.dylib) + 198  [0x7fff8e42c760]
+       2035 _dispatch_queue_invoke  (in libdispatch.dylib) + 54  [0x7fff8e42cf66]
+         2035 _dispatch_queue_drain  (in libdispatch.dylib) + 264  [0x7fff8e42d10a]
+           2035 _dispatch_call_block_and_release  (in libdispatch.dylib) + 18  [0x7fff8e42b8ba]
+             2035 __block_global_5  (in IDEInterfaceBuilderKit) + 630  [0x10542fa41]
+               2035 -[IBSourceCodeParser parseFile:errors:]  (in IDEInterfaceBuilderKit) + 136  [0x10537db6a]
+                 2035 -[IBObjcParser parseData:fromFile:errors:]  (in IDEInterfaceBuilderKit) + 165  [0x10537d821]
+                   2035 nextRealToken  (in IDEInterfaceBuilderKit) + 83  [0x10537c9f6]
+                     2035 IBObjCLexerNextToken  (in IDEInterfaceBuilderKit) + 31  [0x10537a4bb]
+                       905 skipSpacesAndCR  (in IDEInterfaceBuilderKit) + 141  [0x10537b7a1]
+                       ! 905 parseGetc  (in IDEInterfaceBuilderKit) + 18,67,...  [0x10537b81f,0x10537b850,...]
+                       749 skipSpacesAndCR  (in IDEInterfaceBuilderKit) + 157,141,...  [0x10537b7b1,0x10537b7a1,...]
+                       381 skipSpacesAndCR  (in IDEInterfaceBuilderKit) + 171  [0x10537b7bf]
+                         381 parseGetc  (in IDEInterfaceBuilderKit) + 0,28,...  [0x10537b80d,0x10537b829,...]
2035 Thread_15950867   DispatchQueue_5158: com.apple.dt.Xcode.IBHeaderScanningClassProvider  (serial)
+ 2035 start_wqthread  (in libsystem_c.dylib) + 13  [0x7fff84fdcb85]
+   2035 _pthread_wqthread  (in libsystem_c.dylib) + 316  [0x7fff84fdb3da]
+     2035 _dispatch_worker_thread2  (in libdispatch.dylib) + 198  [0x7fff8e42c760]
+       2035 _dispatch_queue_invoke  (in libdispatch.dylib) + 54  [0x7fff8e42cf66]
+         2035 _dispatch_queue_drain  (in libdispatch.dylib) + 264  [0x7fff8e42d10a]
+           2035 _dispatch_call_block_and_release  (in libdispatch.dylib) + 18  [0x7fff8e42b8ba]
+             2035 __block_global_5  (in IDEInterfaceBuilderKit) + 630  [0x10542fa41]
+               2035 -[IBSourceCodeParser parseFile:errors:]  (in IDEInterfaceBuilderKit) + 136  [0x10537db6a]
+                 2035 -[IBObjcParser parseData:fromFile:errors:]  (in IDEInterfaceBuilderKit) + 165  [0x10537d821]
+                   2035 nextRealToken  (in IDEInterfaceBuilderKit) + 83  [0x10537c9f6]
+                     2035 IBObjCLexerNextToken  (in IDEInterfaceBuilderKit) + 31  [0x10537a4bb]
+                       855 skipSpacesAndCR  (in IDEInterfaceBuilderKit) + 141  [0x10537b7a1]
+                       ! 855 parseGetc  (in IDEInterfaceBuilderKit) + 18,67,...  [0x10537b81f,0x10537b850,...]
+                       740 skipSpacesAndCR  (in IDEInterfaceBuilderKit) + 155,141,...  [0x10537b7af,0x10537b7a1,...]
+                       440 skipSpacesAndCR  (in IDEInterfaceBuilderKit) + 171  [0x10537b7bf]
+                         440 parseGetc  (in IDEInterfaceBuilderKit) + 0,67,...  [0x10537b80d,0x10537b850,...]

Thanks for your responses. I will definitely file additional info in the bug report -- I'm just sort of "live blogging" the bug here while I figure out what's what.

My first priority is to work around this Xcode issue -- because this is a show-stopping bug that is preventing me from getting the work of my actual job done, since I really can't develop these apps if I have to reboot Xcode every time I modify a .xib. (I'm modernizing a set of legacy apps, with dozens of nibs, so re-creating all the UIs in code isn't really feasible).

So posting here might actually garner some useful feedback that will help me find a workaround (and later I'll write this up on my blog where it can be googled, unlike this forum). I've very rarely gotten any feedback from a bug report other than an autogenerated "Thanks for the report, this is a known issue, closed as Duplicate."

Secondary to an immediate workaround, though, I'd love to see this fixed and so I will do what I can, including updating the bug with the best repro case I can come up with, samples, etc. But I really need Xcode to work ASAP -- I assume Apple isn't going to fix my bug release a new version of Xcode tomorrow.

Doing a binary search does indeed sound arduous but I don't see any other choice, except maybe for reverting the .xib format on the files and using Xcode3 to edit .xibs.

So I will probably try it. What does make it especially arduous, and very similar to the previous major bug I discovered in Xcode in December, is that to see if the bug manifests or not takes a couple of minutes. You have to do the following process to see if a change you made causes the bug to disappear:

Quit Xcode, then re-launch it.
Open MyViewController.h and add an IBOutlet in code.
Open the .xib and see if the outlet appears.
Go back to the header and add an outlet.
Go back to the .xib and see if the outlet appears.
repeat steps 3 and 4 three more times.
If an outlet added in code didn't appear in the .xib editor, the bug has manifested. If all the outlets you added in code did appear, then the bug did not manifest.

So performing that process for every change I try is going to make a binary search take at least the rest of the day, unless I am very lucky...

Therefore, before the binary header-elimination search, I'm first going to try the 'take a 20 minute nap while listening to rainstorm sounds and see if anything comes to you after you wake up' debugging technique.

Whew. OK, I found the culprit. It was indeed a malformed header, from 2006, similar to the one reproduced below.

The bogus header doesn't even have to be included in the Xcode project, it apparently just has to exist anywhere Xcode looks for headers. If such a header is present, the .xib editing features of Xcode 4.2.1 completely break. If you delete the header from disk, or fix the problem with it, things work again.

This particular header was in a work source tree that I use for almost all project -- that's why to me it seemed that Xcode4 was just totally broken, since this bug hit almost all my various projects.

For people encountering this bug, finding the malformed header might still be a challenge. Also I don't know that this particular kind of syntax error -- a typo-induced unterminated comment -- is necessarily the only type of malformed header that will bork Xcode, but it was in my case. A header with nothing but comments in it was accidentally terminated with /* instead of the proper closing */.

Because the header was not part of the project, and wasn't imported, so I never got any "unterminated comment" compile errors. This header would cause an error (or a warning, depending on how you roll with with your build settings) if it was actually included or imported by your project's code.

So if you have this problem and need to fix it, I recommend that you start by looking for header files that are not part of your project, but exist in the source tree next to headers that your project does use.

I've updated the bug report ( rdar://10698256 ) to include a reproduction demo app, screenshot, and sample output, and I have also uploaded the bug demo project to github just in case anybody not working at Apple is interested:

XcodeXibEditBugDemoApp

As a final note, if you do hit the bug and then delete or fix the header file triggering it, you do indeed need to delete the Xcode "DerivedData" directory. Just deleting the header but leaving the (presumably corrupted) index data around will not fix the problem.

/*

    THIS MALFORMED HEADER WILL COMPLETELY BREAK XCODE'S .XIB EDITING

    This is a bug report demo app for Apple Problem ID: 10698256 

    If this header is included in your project the .xib editor will
    stop seeing newly added outlets. For this demo app, follow these
    steps:

    1. Quit and re-launch Xcode.
    2. Navigate to XcodeBugViewController.h and add an outlet, like
       "IBOutlet NSView *foo1" and save the header file.
    3. Navigate to XcodeBugViewController.xib and right click the "File's.
       Owner" icon to pop up the list of outlets.
    4. Note whether or not the outlet appears in the list.
    5. Repeat steps 3 and 4 five times. 

    You should see that outlets are no longer showing up in Xcode.

    If you delete this header, then quit and relaunch Xcode,  the problem 
    will go away.  (You have to literally delete the file from disk. It does
    not need to be included in the project to trigger this bug.)

    BONUS BUG: Editing this header within Xcode will cause it to crash or freeze.
/*

①: -ly annoying, at least.

②: I assert that this is the correct American spelling.

以上

UFC 141 Predictions

2011-12-31T11:57:00+09:00

I've been meaning to commit my predictions to the ether for the last few UFCs, but this is the first time I've managed to do it. I think this is largely because the UFC FINALL-FUCKING-LY has a decent web-based pay-per-view system. It's really great; the adaptive quality claims to support up to 3000Kbps and on my typical Japanese fiber line it looks great--as good or better than the bootleg 720p PPV rips that one might find out there on the interweb tubes.

The UFC's new system means that I can reliably watch the bouts LIVE (for $20, which feels a lot more reasonable than $50), whereas before I was always having to somehow procure a decent copy of the event after the fact, meaning that the matches had actually already happened by the time I got around to thinking about who would win, at which point 'predicting' them seemed pretty stupid, even if I knew not the outcome.

So without further ado:

Alistair Overeem will beat Brock Lesnar

Overeem will dominate Lesnar, exposing him for what he actually is: a massive, ultra-athletic monster of a human specimen -- but still an inexperienced fighter who gets concerned and loses his focus when he starts getting smashed in the face by another huge man's fists (or kicks). Gotta think Overeem's strikes are gonna be the actual killing advantage, even if it ends up that a barrage of strikes leads to a sumbmission. Overeem is bulkier than I remembered, too: 263 lbs (119.3 kg) at the weigh-in to Lesnar's maximum allowed fighter weight of 265 lbs (120.2 kg).

I am excited about this fight on its own merits, but also because it begins the process of seeing how good Overeem really is. A lot of top-teir fighters from other promotions suddently look a lot more human when they get to the UFC. (Mirko Cro Cop, Wanderlei Silva, and virtually all Japanese fighters who, with the exception of Yushin Okami, consistently get their asses kicked around the octagon... )

Confidence: $100

Wife disagrees: "What! What. What is thaaat...?!" I'm not sure if she was talking about the hulking Lesnar himself, or the alien-seeming muscle ripple he did as he stepped to the scale. But she picked the decidedly meaner-looking Lesnar to win the bout.

Nate Diaz will beat Donald Cerrone

This should be an awesome fight, and I can see it going the distance. The UFC has recently (and sensibly) decided that main-event fights should be 5 rounds instead of 3... does that apply to "co-main event" fights like this one? Hope so.

Diaz can submit people but Cerrone knows what he's doing, both of them can brawl and both can take a beating. I think Diaz has slightly better come-back-from-getting-beat-on-and-choke-you-out skills, though. The madder he gets, the more fun the fight is to watch.

Confidence: $50

Wife agrees: "Huh, 'Nate'... I like that name. Nate will win."

Jon Fitch will beat Johnny Hendricks

Happy Beard Guy is good, but you know he'll never be the champion. Still, the beard make me wantto root for him. But it's not impossible to imagine Fitch wearing the belt. I mean, you can conceive of it. If St. Pierre like, fell out of an airplane or something. Fitch is a grinder, who I can't remember ever knocking anybody out, so I expect a decision. Hendricks does knock people out but I have never seen him fight anyody awesome. Fitch has fought St. Pierre and BJ Penn, although he didn't win. Still I predict he'll ground and pound Hendricks and take a decision victory.

Confidence: $20

Wife agrees.

Vladimir Matyushenko will beat Alexander Gustafsson

This is just a gut call, as I have never seen Gustafsson fight or even heard of him. But the Janitor is a wily old (older than me!) Soviet National Wrestling Champion with tons of MMA eperience. Gustafsson will be faster I am sure, and probably more technical, but then if it gets out of the first round, which it should because Matyushenko is tough, then the old dude will start to wear on him and at some point get a dominant position leading to a ground-and-pound referee stoppage.

Confidence: $3

Wife agrees.

Nam Phan will beat Jimy Hettes

Nam Phan prepped for this fight by watching Nacho Libre, so of course he will win.

Confidence: $0.75

Wife: Yep, Nam.

Well, event starts in 3 min. so no time to predict the undercard--and you need to log into facebook to watch the prelims anyway, so fuck that. No time to proofread, posting this to the tubes as-is! ☆

'droid ragers make me sigh

2011-12-29T11:53:11+09:00

Mini-Gruber Siegler, over on his personal blog, gets his panties all knotted and sticky over Andy Rubin apparently deleting a comment he had posted on Walmart.com or somewhere like that, about Android being open and how to check out the source code.

220 melodramatic and pointless words and one failed attempt at a snarky joke about 'open' later, we find out that yep, the comment was deleted, because the open source repo had been relocated and the instructions included in the comment were no longer accurate.

Of course, Android is still open, for any reasonable value of open, and you can still check out the source if you're so inclined.

(Unfortunately, though, Android's still not that great at running one's pocket computer/phone gizmo. Maybe in Android 5.0, Turducken Potato Pizza? Here's hoping.)

[via professional Apple frother John Gruber]

merry atheistmas! ♬

2011-12-25T05:05:05+09:00

☃ ☃ ☃ ☃

2011 was a good one for me... we enjoyed a secular xmas celebrated in the finest Japanese tradition: by flying to Hawaii to play in the ocean and buy ourselves lavish and unneccessary presents in an orgy of 円高-fueled consumerism. A+++ WOLUD LUXURIATE AGIAN!!!

"Holy shit, fifty feet from shore and I'm already exhausted... maybe Heineken and Sno-balls isn't the breakfast of champions??"

the interwebs are down

2011-12-12T11:40:11+09:00

OMG github is down:

OMFG downforeveryoneorjustme.com is ALSO down!!

Maybe the US government's internet kill switch installation isn't going as planned?

The Xcode Fairy

2011-12-05T11:11:11+09:00

This post describes a bug in Xcode 4.2.1 and a simple way to work around it. If you find it useful, please send me $5,000.00.

Xcode 4.2.1 has a bug (actually a set of related bugs) that can break the automated testing functionality for a project in certain conditions, such that the following things happen:

0.) Xcode gets confused, and uses the wrong executable for the project's Test action. This prevents the automated tests from being executed. This is the actual core of the bug.

1.) Compounding things somewhat, when this bug manifests, Xcode will tell the programmers that all their tests passed, when in fact Xcode didn't actually run any of their tests. That's bad, because it can easily go unnoticed for a while. The programmers may waste significant time writing code, thinking all tests are passing, only to then have to backtrack and rewrite when they realize that their new code is actually all wrong (something the failure of their existing tests would have alerted them to, had the tests actually been run).

2.) But those things are nothing compared to the insidious violence that this bug visits upon the programmers who try to figure out the cause and make it stop happening. This software defect can snare its victims in a web of deception that can take hours to unravel, and can result in the brutal and premature demise of any keyboards, mice, and even monitors that happen to be nearby.

A professional programmer has to have automated tests. Programmers argue about what kinds of tests to write, and when to write them, but not having tests at all is pure fuckery. Writing serious code without tests is for dilettantes and winos. Programmers need tests, which are typically run automatically by the programming toolchain when the code is built or run.

Mac programmers (and those iOS programmer weenies, too, as far as I've heard) pretty much have to use Xcode. There are insane convolutions that one might go through to avoid Xcode -- and indeed, most Mac programmers fantasize about this from time to time -- but generally speaking, Xcode is really the only game in town.

Mac programmers need Xcode and they need tests, so naturally they want Xcode to run their tests.

Therefore, when the programmers eventually notice that Xcode isn't running their tests, they will likely stop whatever else they are doing and try to fix it, by fiddling with the project settings. Most programmers would start by editing or recreating the project's Xcode schemes, which is logical, because the Xcode scheme controls, among other things, how and when to run the tests. They'll make a change or perhaps give up and rebuild the scheme from scratch (a minor pain in the ass), or maybe quit Xcode and revert the project file to the last checked out version. Most likely, they will see that after their changes, Xcode again properly runs their tests. The programmers will resume their work, and life will once again be fine, or at least okay.

But Xcode isn't through with those poor assholes. No, it has only just begun to fuck with them.

A bit later -- minutes, hours, days in some cases -- the bug will hit them again. With a little bad luck, their git commit log might end up looking something like this:

[broham@IT-PC-MACPRO-01 my-rad-tool (master)]$ git log --pretty=format:"%h%x09%x09%ad%x09%s"
6ce5b76  Mon Dec 5 15:27  SOLVE, really this time, the Xcode random project corruption problem.
114b116  Sun Dec 4 21:50  FUCK XCODE FUCK XCODE FUCK XCODE FUCK XCODE FUCK XCODE FUCK XCODE FUCK XCODE FUCK 
0d87a5f  Sun Dec 4 21:46  die xcode die
1010c1e  Sun Dec 4 21:24  What the fuck is the deal with Xcode
08e67fb  Sun Dec 4 20:57  Document the way I finally seem to have worked around the Xcode unfixable project 
6b5dfb4  Sun Dec 4 20:49  Xcode 4 is just garbage.
a878a75  Sun Dec 4 20:31  Rename the Xcode scheme and document the two things you can do that will cause Xco
9b19a92  Sun Dec 4 20:17  Rename project 'objj-indexer project.xcodeproj'. It seems Xcode doesn't shit on it
3c0fa9c  Sun Dec 4 20:13  Get fucked in ass by Xcode again. Renamed project file to 'project.xcodeproj'.
71d2d13  Sun Dec 4 18:32  Attempt to convince Xcode to please stop corrupting the project.
7296a96  Sun Dec 4 17:33  Resolve the Xcode issue by giving up having the command line tool be the executabl
608bc70  Sun Dec 4 17:24  Fuck Xcode to hell. I think it is working now, though.
2bdc22b  Sun Dec 4 17:09  Fuck with Xcode for 4 hours to try to get it to stop corrupting this project such 
39f396e  Sun Dec 4 14:08  Waste several hours fixing Xcode self-corruption and rebuilding project from scrat

That's a whole Sunday there. Looks like they (*cough* I) didn't get any actual work done all day. That's because this bug is a motherfucking son of a bitch. It comes and goes on a whim, at random, which makes it hard initially to figure out what is going on. A programmer might try something, test it, see that the problem is gone, and think they fixed it. But really what they did had nothing to do with anything. And then the bug comes back. Over and over and over.

"Which of you jackasses merged the beer-goggles topic branch without running the test suites?" one programmer might call out. "Five tests fail. FAIL!"

"No way dude, I ran the tests before I pushed the code. Maybe something... ah, shit, it's not fucking running the tests again. It just says 'Test Succeeded' and 'No issues'. Again! Xcode is a lying ass bitch!"'

Maybe at this point a mouse or empty soda can gets thrown against the wall.

"Okay man, look, tests are working on my machine, let's diff the project files and see if we can find something that might be why its not working on your machine but is on mine."

"Man, this file is just a list of thousands of UUIDs, we're not gonna make sense of this... let me just get a copy of your project file and replace mine. I'll quit Xcode and move it into place... Okay, that worked. Fuck though, why does the project keep getting corrupted? I don't see anything that looks like a clue when I diff the good one and the bad one either."

"Well, at least it's working now."

By that time, though, it might be 4:00 PM, and with energy waning, they might just commit what they've done so far with a message like "Work around Xcode bugs" and leave early to go get drunk.

The next day, though, the situation might well begin to rapidly deteriorate.

"Motherfucker!" one of them might scream. "Did you fuck with the scheme definition in your last commit? Now I have to delete it and re-create it again."

"No, bitch," the other might retort indignantly. "I didn't change jack shit, except for turning off parallel builds. And it is still working fine for me. If you broke the build again, you fix it. Revert your Xcode project file again, it was working fine an hour ago."

"I already did that, genius! There aren't any changes to the project file. Check out the diff right here on the screen, asshole."

At this point, the programmers would probably decide that something is just irredeemably fucked with their on-disk project file itself. It wouldn't be surprising; the project file in question was originally created with the older Xcode 4.0, a notably buggy and half-baked release, and has also been subjected to dozens of instances where Xcode crashed while various operations were in progress. Maybe something got borked.

Concerned about their slipping productivity and the growing amount of time lost to fucking with their IDE settings, they embark on the unenviable task of recreating the project from scratch. Create the project bundle, add each target, set each target's build settings, set the Bundle Loader and the Test Host, the Info.plist path, and other such drudgery.

Finished, they quit Xcode and painstakingly move all the little niggly .xcscheme and .pbxproject files into the correct places within the .xcproj bundle.

"All tests pass, fuck yeah, commit that shit."

And so, back to work.

With a gray and gloomy tone having already been set for the week, what with all this hapless rejiggering of settings and a marked lack of in-the-zone progress, the shit will likely hit the fan and splatter all over everything in the room the next morning, when one of the programmers git-pulls and sets to work.

"What the fucking motherfuck who fucking added another build target to the motherfucking scheme and broke the motherfucking goddamn tests again! Jesus motherfucking Christ!"

"The fuck are you on about? I don't know what you're doing, but you're fucking Doing It Wrong, dude. It works fine on my machine."

"Motherfucker, stop lying! You added another fucking target to the scheme! Look, it's right fucking here in the Build panel! LOOK!"

"Hey man, fuck you--"

"NO FUCK YUO!!!"

Now, the reason that these hypothetical hackers are on the verge of breaking into fisticuffs is that this bug hides itself like fucking octopus in a coral reef. It's really not their fault; it's a hard bug to track down.

Since they live in imagination-land, though, we can just help them out.

Programmer: "Ohmyfuckinghgod, dude, look out for that huge fucking bug above your head!"

Programmer: "If you hit me in the head with that rolled up newspaper I'm gonna kick you in the balls, jackass."

Programmer: "I'm serious, dude!"

Magic Fairy: "I'm not a bug. I'm a magical fairy from the Kingdom of Menlo. I'm here to help you out with your Xcode problem."

Programmer: "Oh shit, you weren't lying. What the fuck is that!"

Programmer: "Look, sweetheart, thanks for the offer and everything, but we're professionals here. I don't believe in fairies, and even though I now see that I am obviously wrong about that, I still don't think there's a whole lot that a flying miniature hottie with butterfly wings and a wand can tell us about--"

Magic Fairy: "Change the name of your Xcode project."

Programmer: "Look, we already did that, and more. It had no effect. We rebuilt the project, we renamed the project, the targets, the schemes, etc. and it had no--"

Magic Fairy: "Change the name of your Xcode project file."

Programmer: "I told you, we--"

Programmer: "Dude, this shit's been biting us in the ass for days on end. If a fucking magical fairy from another dimension appears and tells us to rename our Xcode project file, we might as well fucking try it. Here, I'll do it. What should I rename the project to?"

Magic Fairy: "I'm not from another dimension."

Programmer: "Okay. Rename the project. Here, I'll append 'v2' to the name."

Magic Fairy: "No. Change it to my name."

Programmer: "She's totally fucking with you, dude. Come on, now."

Programmer: "Fine! Whatever. What's your name?"

Magic Fairy: "My name is Slut."

Programmer: "Sloot?"

Magic Fairy: "Yeah, Slut. S-l-u-t."

Programmer: "Wow, that's not how we'd tend to pronounce it. But I mean that's cool, totally cool, and stuff. How did you uh, come by that name?"

Magic Fairy: "My name used to be Alianna, but as soon as I entered this programming-related blog post, my name was transformed. An evil golem named Choad'wan cast a spell on the whole IT industry to make sure it remains a totally sexist bro-fest for all eternity."

Programmer: "Yeah, I've been reading a lot about that lately."

Programmer: "But dude, she is actually pretty hot though! I mean kinda too small to uh, I mean, anyway you should really put on your glasses, dude."

Programmer: "Seems like Choad'wan's spell is working fine. Can we get back to the Xcode thing."

Magic Fairy: "You say it like you're the one waiting for me."

Programmer: "Okay, should I rename the file in the Finder, or do it in Xcode?"

Magic Fairy: "In Xcode."

Programmer: "Okay, s-l-u-t it is. But you know, we did this before."

Magic Fairy: "You named your program after me before?"

Programmer: "No, but we renamed it at some point."

Magic Fairy: "Why?"

Programmer: "Well, at some point when the project file got corrupted again, I uh, renamed the project FUCKXCODE.xcodeproj because I thought that Xcode was maybe internally referring to different types of entities by name, instead of uuid, and getting confused. Since the project was named after the the command-line tool it builds, they had the same name. So I changed it to 'FUCKXCODE' and things the tests started running again."

Magic Fairy: "Well, wasn't that a clue?"

Programmer: "I thought so, but no, because later I changed the name back and everything still worked. So it wasn't the project name. But just in case I appended ' project' to the name. But the problem came back. And then later, we renamed all the targets and that fixed it. For a while. Tweaking the target or the scheme seems to fix it for a while, but somehow the project is getting corrupted when Xcode writes it out to disk. But we can't figure out exactly how it's getting corrupted, or why."

Magic Fairy: "My spiritual guru used to say something from time to time that I think applies to your situation."

Programmer: "Who's your spiritual guru?"

Magic Fairy: "Microsoft Word 6.0.1 for Macintosh."

Programmer: "I get it, fuckface. You put LSD in my Dr. Pepper. Really fucking funny."

Programmer: "Wait, your spritual guru is Microsoft Word 6.0.1 for Macintosh?"

Magic Fairy: "She liked to remind me--"

Programmer: "Wait, Microsoft Word is a chick?"

Magic Fairy: "Sometimes things that go away by themselves--"

Programmer: "--can come back by themselves! Of course! Dammit! How could I be so stupid!"

Programmer: "The fuck are you guys talking about?"

Programmer: "I think she's saying all our debugging of this issue has been a total fucking waste of time."

Magic Fairy: "Right."

Programmer: "Okay, I renamed the project like you said. What's next."

Magic Fairy: "Add a single test that asserts 1 equals 0, so tests shouldn't pass. Then relaunch Xcode. Hit Command-U to run the Test action."

Programmer: "Tests fail."

Magic Fairy: "Quit Xcode. The do it again."

Programmer: "Tests fail again."

Magic Fairy: "Again."

Programmer: "Tests fail again. Okay, we get it, it works with your name."

Magic Fairy: "Again!"

Programmer: "Okay! Fuck! Tests fail again! Quit, relaunch, test, fail! Quit, relaunch, test, fail! Same thing again! Again! Again! Again! I've done it ten times now. It's working!"

Magic Fairy: "Now rename it back."

Programmer: "Okay. Renamed it back to the original babe-rater.xcodeproj."

Magic Fairy: "Wait, the name of your program is babe-rater?"

Programmer: "Uh..."

Magic Fairy: "You're writing a command line UNIX utility to rate babes?"

Programmer: "Never mind that! Look! Launch Xcode, test, the tests fail as they should. So what does that prove?"

Magic Fairy: "Again."

Programmer: "Fail."

Magic Fairy: "Again.

Programmer: "Fail!"

Magic Fairy: "Again!"

Programmer: "Tests... the tests pass. Shit. It didn't run any of the tests. But the project file hasn't changed at all. The project was never actually corrupt in the fist place!"

Programmer: "Motherfucking motherfucker! What the fuck!"

Programmer: "So the bug can go away by itself..."

Magic Fairy: "And come back by itself. Yeah."

Programmer: "And the project file doesn't change at all. So all our recreating he targets and build schemes, which seemed to fix it for a while, wasn't really doing anything."

Magic Fairy: "Yeah."

Programmer: "And you're saying that once the bug goes away, it won't come back until you quit and relaunch Xcode. And vice versa."

Magic Fairy: "Yeah."

Programmer: "And that the bug actually never actually affects the project file on disk."

Magic Fairy: "Right. The bug exists only in the spirit world."

Programmer: "You mean the computer's volatile memory."

Magic Fairy: "Whatever. You can use any abstraction that let's you wrap your little mind around it."

Programmer: "So to really test whether something -- a scheme setting, a target name, the project name -- affects whether or not this bug manifests and breaks Xcode's test functionality, you have to make the change and perform the quit-relaunch-test sequence a bunch of times."

Magic Fairy: "Ten times."

Programmer: "Ten times."

Magic Fairy: "Yeah."

Programmer: "So how did you figure this out?"

Magic Fairy: "Well, chicks tend to be more methodical about this kind of thing. No need get all furious like some testosterone-overloaded roid-rager and smash your mouse down on the desk, or throw your beverage can against the wall. We don't tend to get so... emotional. I mean, it's just a software bug. That makes it easier to keep a clear head and debug what is really going on."

Programmer: "We don't really have to name the project after you, do we."

Magic Fairy: "No."

Programmer: "But the name cannot be the same as the command line executable."

Magic Fairy: "Correct."

Programmer: "How about 'babe-rater project.xcodeproj'?"

Magic Fairy: "No. The project name must not even contain the name of the command line tool that it builds. Otherwise this bug will be summoned. Sometimes."

Programmer: "But that's fucking lame! The project builds a tool called 'babe-rater'. Doesn't it make sense that the project should be named 'babe-rater.xcodeproj', or at least 'babe-rater something'?"

Magic Fairy: "It's not a matter of what makes sense. It's a matter of what stops the bug from being summoned."

Programmer: "Well, did you at least file a bug?"

Magic Fairy: "Sigh. No I did not file a bug. I find Apple's bug reporting process pretty odious, to be frank. Their system is slow and cumbersome. Most bugs are marked 'Duplicate' and they don't even show you the courtesy of giving you read permissions on the bug that yours is a dupe of. It's like throwing your effort into a black hole. A black hole with no manners."

Programmer: "Well, I don't want to have to keep giving my Xcode projects names that don't reflect what the project actually builds!"

Magic Fairy: "Then why don't you file a fucking bug, sweetheart."

Programmer: "Big mouth for such a little girl, eh?"

Programmer: "Shut up, dude. Okay, I'll file a bug."

Programmer: "Okay, let's see... bugreporter.apple.com. Okay, here we go:

Title: Xcode randomly uses wrong executable for
Test, runs no tests, reports tests pass

Product: Developer Tools 

Version: 4.2.1

Summary:

Xcode 4.2.1 becomes confused internally, and
uses the wrong executable during the Test
action. Instead of executing the executable
specified in the Xcode scheme, and injecting the
test bundle into it and running the tests, it
picks a different executable and tries to use
that. This can lead to no tests being run. But
Xcode reports that the Test action has
succeeded, as if all tests have passed, when in
reality no tests have been run. Worst of all,
though, this bug has a random component (it will
happen say 3 to 6 times out of 10 launches of
Xcode). The random component can make it
extremely time-consuming for the developer to
debug, since they may try various things to make
it stop happening and get a false positive
result.

Steps to Reproduce:

We have determined reproduction steps as
described below. Note that these are not the
only reproduction steps, as we've seen this bug
hit in the wild when we didn't follow these
exact steps. These are just the most succinct
ones we could come up with. It is kind of
complicated, so there is a bug demo project with
a git commit at each step, located at:

https://github.com/masonmark/
XcodeCorruptOnOpenBugDemo

You may find it easier to just check out that
version to see the bug in action. Otherwise:

1. Create a new application project using the
built-in "Cocoa Application" template. Check the
"Include Unit Tests" option so it also creates a
test bundle. Use the project name
"XcodeCorruptOnOpenBugDemo".

2. Run the Test action (Cmd-U) to be sure the
tests fail as they should (the default test
fails).

3.  Add a new Target to the project, using the
built-in 'Command Line Tool' template. For the
product name, put
'XcodeCorruptOnOpenBugDemoTool'. Hit Cmd-U,
confirm 'Test Failed', quit Xcode.

4. Reopen project. In the 'Manage Schemes'
dialog, delete the scheme
'XcodeCorruptOnOpenBugDemoTool' that was
automatically created in step 3. Hit Cmd-U,
confirm 'Test Failed', quit Xcode.

5. Reopen project. Rename the original
'XcodeCorruptOnOpenBugDemo' target (the .app
bundle) to 'XcodeCorruptOnOpenBugDemo-app'. Next
rename the original
'XcodeCorruptOnOpenBugDemoTool' target to
'XcodeCorruptOnOpenBugDemo'. (NOTE:  The reason
for doing this in the real world is that we
really want to build a command line tool, not an
.app bundle. But since Xcode 4.2.1 cannot run
tests against a command line tool, this project
will also build an .app bundle against which to
run the test. The test host .app will include
all the classes from the command line tool, so
that they may be unit tested.)

6. Reopen project. Hit Cmd-U. Note that you now
get 'Test Succeeded' even though you shouldn't.
Xcode is now using the command line executable
instead of the app bundle to run the tests. 
(This is the mild form of the bug.)

7. Rename the project, from within Xcode. Append
" project" so that the project name becomes
"XcodeCorruptOnOpenBugDemo project". Decline
Xcode's offer to rename other things for you.
Quit Xcode.

8. Now, do the following ten (10) times:

8a. Reopen the project. 8b. Cmd-U to run the
tests. 8c. On a scrap of paper, if Xcode
indicates test failure, write 'OK', otherwise
write 'BOGUS'. 8d. Quit Xcode.

Expected Results:

The expected results are that Xcode runs the
test bundle as specified in the scheme. That is,
it should launch the
'XcodeCorruptOnOpenBugDemo-app.app' executable,
inject the test bundle, run the test, and report
the failure. Your scrap of paper should say 'OK
OK OK OK OK OK OK OK OK OK'.

Actual Results:

The actual result is that Xcode sometimes, at
random, decides to run the
'XcodeCorruptOnOpenBugDemo' command line tool
executable instead. In this case, no tests will
be executed, so no tests will fail, so Xcode
will report 'Test Succeeded'. In my test while
writing this bug report, I just got 'OK OK OK
BOGUS OK BOGUS BOGUS BOGUS BOGUS BOGUS'

Regression:

We can reproduce the bug at will with an Xcode
4.2.1 project, created from the Xcode 4.2.1
built in templates, that has one .app bundle
target, one .octest bundle target, and one
command-line tool target.

We have not investigated whether it happens with
a project with two .app bundle targets and no
command-line tool targets.

Notes:

1.) If the bug was just as we left it in Step 6,
it would still be a bug, but not such a big
deal. A programmer could probably figure out
that if the project name was the same as the
command-line tool's name, Xcode would mistakenly
use the command-line tool to run the tests.

But the fact that the project need only CONTAIN
the name of the command-line tool executable,
combined with the fact that the bug only occurs
30% to 60% of the time, made this take HOURS to
figure out.

2.) For whatever reason, whether or not the bug
occurs is somehow decided when Xcode launches.
You have to actually quit and relaunch Xcode to
have a chance at getting the opposite behavior.
Simply closing and reopening the project doesn't
do it.

3.) For the exciting story of two hapless
programmers who encounter this bug and find
their lives turned upside down in a frenzy of
violence, magic, and poignant human drama, see:

htt<em>Programmer:</em>//masonmark.com/the-xcode
-fairy

4.) The demo project is on GitHub at the URL
below. However, please ignore the commentary
about copying the command-line executable into
the test bundle. That step turns out to be
unnecessary to trigger the bug.

https://github.com/masonmark/
XcodeCorruptOnOpenBugDemo

5.) I think there are two related bugs here:
Xcode sometimes lying about test results, and
Xcode no longer being able to run tests against
command line tools. I'll file those separately."

Programmer: "You will, huh? You up your Adderall dose or something?"

Magic Fairy: "I think you should add 'Thanks.' at the bottom."

Programmer: "Okay, added. Now I'll just click Submit here, and... fuck!"

Magic Fairy: "Ha ha ha! Typical!"

Programmer: "What? What does it say?"

Programmer: "It says 'java.io.EOFException Broken pipe'."

Programmer: "Hit Submit again."

Programmer: "Now it says, 'Broken pipeBroken pipe'."

Magic Fairy: "Ha ha ha! Ha ha ha!"

Programmer: "Okay, I'm gonna log out and log back in and paste that in. And... Okay. Filed. Bug ID# 10532871."

Programmer: "Fuck it dude, I'm outta here. You and your little friend can file all the bug reports you want. All I care about is that we can work around it, which we now can. I'll see you Monday. "

Programmer: "Whatever. Bye."

Magic Fairy: "I don't like your friend."

Programmer: "We're not exactly friends."

Magic Fairy: "Okay."

Programmer: "You wanna like, uh, go get a drink or something?"

Magic Fairy: "I'm not really much of a drinker."

Programmer: "Oh. Well, um, I guess--"

Magic Fairy: "I'd smoke a little weed if you got it, though."

Programmer: "What? Uh, sure, sure! I don't have any on me, but my place is only a few minutes away. Let's go."

Magic Fairy: "What about those other bug reports?"

Programmer: "Fuck it. One good deed per day's enough for me. Come on."

Magic Fairy: "♪ ♬ ☆ ♡・・・"

At this point, as the programmer gathers up his gear and his bag and heads for the exit, from her vantage point floating along behind him, the magical fairy might see him tear off and crumple up and discard a piece of graph paper from his notebook, upon which was scrawled:

Rename project to 'FUCKXCODE':

10 launches, OK.

Rename project to 'FUCKXCODE babe-rater'
1.  BOGUS
2.  OK
3.  OK
4.  BOGUS
5.  BOGUS
6.  BOGUS
7.  BOGUS
8.  BOGUS
9.  OK
10. BOGUS

Rename project to 'FUCKXCODE-babe-rater'
1.  OK
2.  BOGUS
3.  OK
4.  BOGUS
5.  OK
6.  OK
7.  OK
8.  OK
9.  BOGUS
10. BOGUS

Turn off parallelize:
1. OK
2. OK
3. OK
4. BOGUS
5. BOGUS
6. BOGUS
7. OK
8. BOGUS
9. OK
10. OK
(turn it back on since it made no difference)

Rename  project to 'babe rater'
1. OK
2. OK
3. OK
4. OK
5. OK (cleaned here)
6. OK
7. OK
8. OK
9. OK
10. OK

Rename scheme to same as tool
0. OK
1. OK
2. OK
3. OK
4. OK
5. OK
6. OK 
7. OK
8. OK
9. OK

Conclusion: scheme name actually not relevant.

Rename project to known problem
'babe-rater project' and run ten times
without quitting:

1 - 10. BOGUS each time

Same as above but with Clean Build Folder
between each run:

1. BOGUS
2. BOGUS
3. BOGUS
4. BOGUS
5. BOGUS
6. BOGUS
7. BOGUS
8. BOGUS
9. BOGUS
10. BOGUS

Next launch of Xcode, the same project
happened to work, so I wanted to see if it
would work over and over again if I didn't
quit Xcode (still doing Clean Build Folder
between each try).
1. OK
2. OK
3. OK
4. OK
5. OK
6. OK
7. OK
8. OK
9. OK
10. OK

Quit Xcode, and the next launch it hit the
BOGUS again. So it really does apparently
involve something Xcode does when loading
the project. How about if we close the
project but don't quit Xcode(still doing
Clean Build Folder between each try)?

1. OK
2. OK
3. OK 
4. OK
5. OK
6. OK
7. OK
8. OK
9. OK
10. OK

At this point I launched Xcode, hit Cmd-U,
and quit a few times in a row. OK, BOGUS,
BOGUS, BOGUS, OK... so cleaning also seems
irrelevant.

Somehow, Xcode decides at launch time
whether or not it is going to corrupt the
project when it is opened. If so, it
reliably does it every time that project
is opened, until Xcode quits. Then the
next time Xcode is launched, it again
randomly decides whether or not to corrupt
the project upon opening it.


Now is it the target name or the
executable name (or both) that must differ
from the project name? I suspect the
executable but lets test. With project
name 'XcodeCorruptOnOpenBOGUSDemo project'
and target name
'XcodeCorruptOnOpenBOGUSDemo' and tool
executable name
'XcodeCorruptOnOpenBOGUSDemoTool':

1. OK
2. OK
3. OK 
4. OK
5. OK
6. OK
7. OK
8. OK
9. OK
10. OK


Now, the reverse: With project name
'XcodeCorruptOnOpenBOGUSDemo project' and
target name 'XcodeCorruptOnOpenBOGUSDemo
target' and tool executable name
'XcodeCorruptOnOpenBOGUSDemo':

1. OK
2. OK
3. OK 
4. OK
5. OK
6. OK
7. OK
8. OK
9. OK
10. OK

Interesting! Now let's rename them both
back to sanity check. With project name
'XcodeCorruptOnOpenBOGUSDemo project' and
target name 'XcodeCorruptOnOpenBOGUSDemo'
and tool executable name
'XcodeCorruptOnOpenBOGUSDemo':

BOGUS
BOGUS
 OK
BOGUS
OK
BOGUS
BOGUS
BOGUS
BOGUS
 BOGUS

However, the BOGUS did manifest with these
params: project name
'XcodeCorruptOnOpenBOGUSDemo' and target
name 'XcodeCorruptOnOpenBOGUSDemo target'
and tool executable name
'XcodeCorruptOnOpenBOGUSDemo' (exact same
name for project and executable). I didn't
test 10 times because at this point I am
just looking for a workaround.

THE END

mail fail

2011-11-11T11:11:11+09:00

It is OK that the Mac OS X 10.7 Lion version of Mail.app takes an hour to upgrade my few-hundred-thousand-message mail database from the old 10.6 version.

It is not OK that the database regularly becomes corrupted in such a way that the search feature silently fails to function, necessitating a repeat of this hour-long process every few weeks.

When Mail.app's search function stops working -- no longer allowing a search on criteria other than 'message contains' and no longer finding the messages that do match -- this is the only procedure I know that fixes it:

[mason@IT-PC-MACPRO-01 ~]$ cd ~/Library/Mail/V2/MailData/
[mason@IT-PC-MACPRO-01 MailData]$ rm Envelop*

This works every time[1], but it has the lousy side-effect of rendering Mail completely unusable for the hour-plus time it takes to recreate all the index files.

Wah, bitch, moan, etc.

[1]: Except this one time, where Spotlight itself was broken, and any app using Spotlight failed weirdly. That time, even mdls on the command line yielded the message

The Spotlight Server is disabled.

Rebooting (grr) cleared it up, though.

Keywords: Milk in the batter, milk in the batter, Mail.app sucks and that's what's the matter

NIGGERHEAD

2011-10-12T00:08:16+09:00

So Rick Perry likes to take his white friends down to his Niggerhead hunting camp. I don't think that's a big deal. I mean, really: what the fuck did people think this fucking jesusfreak Texas hillbilly does in his free time?

With all the preposterously offensive qualities Mr. Perry has so far exhibited, I'd say leasing a camp called Niggerhead doesn't even make the first page of the list.

What I find more notable is how almost all mainstream American media outlets have prevented themselves from being able to sensibly cover this story. The New York Times says, "...a hunting camp where Mr. Perry hosted guests that had a racial epithet painted on a rock at its entrance has forced Mr. Perry’s campaign off message." What the fuck does that mean? "The hunting camp whose name we can't say here," intone the white anchors on TV. I had to google '"Rick Perry redneck moron hunting camp" to even figure out what the fuck they were talking about. I get it that you don't want to say "nigger" but when the entire fucking point of the story is the word "niggerhead", I think you have to make an exception.

Tasty Tokyo Tacos

2011-09-30T00:00:00+09:00

As some kind of cosmic reward for sitting through hours of bullshit at the local equivalent of the DMV, I stumbled upon a killer little taco shop today. Is is nestled in the sprawling underground shopping-and-train-stations complex at Otemachi. A tasty homemade taco in Tokyo is a rare beast inded. The (Mexican?) lady behind the counter was nice. I will fucking definitely be going back. Mmm!

Nobody Canna Cross It

2011-09-28T14:05:23+09:00

* STEP 1 *
Watch the first one minute of this news report. Acquaint yourself with Mr. Clifton Brown, the black dude in white hard hat.

* STEP 2 *
Turn your hi-fi up to 10, and put this on:

[via sakura1]

Drm Clusterfuck

2011-08-10T05:05:05+09:00

An increasing percentage of the shit we buy today is encumbered by DRM. The acronym stands for 'digital rights management', but the 'digital restrictions management' moniker that freedom zealots came up with is probably more apt. That term never really caught on, though; most people don't have a real understanding of what DRM is, nor do they really give a fuck. And perhaps that's as it should be. Life is too short to waste much time on understanding bullshit, especially if you aren't going to use that understanding.

But one basic thing that people should understand is that virtually all DRM is broken. That is, if you buy a product restricted by DRM, at some point it will malfunction, and not only will you be prevented from doing all the things you aren't allowed to do, but you'll also be prevented from doing those things you are supposed to be able to do—-the things you paid to be able to do. This may happen through the incompetence or negligence of the party implementing the DRM. It may happen because they are sued, regulated, or go out of business. Or it may happen because they are just a bunch of fucking ass-clowns.

Today, for me, was a reminder of that--an infuriating exercise in DRM shit making my life just that little bit worse.

For all the happy things that have been born of humanity's digital two steps forward, DRM takes us the corresponding and inevitable one step back.

Act I, in which our hero's kindle shits all over itself in a new way

I slept in late this morning. As a consequence, I was in a smidgen of a hurry, so I decided to take the subway to where I needed to be, instead of walking. Not wanting to be bored on the subway, I tried to download a book I had purchased (Russ Olsen's pretty great Eloquent Ruby[1]) onto my Kindle.

"License Limit Reached" the fucktarded little piece of cheap Chinese plastic told me. That was fucking bullshit, though. Not only did I not have this book installed on five devices simultaneously, I had never even installed it on that many devices total. Kindle was wrong.

I strongly suspect this malfunction was caused by the embarrassing and frankly disgusting bugs in Amazon's Kindle for Mac application, which I have previously detailed. It doesn't matter, though; whatever the underlying cause, Kindle's DRM had malfunctioned and there was fuck all that I could do about it, before dashing out of the house, other than send a terse and angry complaint to Amazon.

Act II, in which our hero is reminded that we've been using DRM for decades

Arriving at my destination, I resumed the task of setting up my recently-purchased MacBook Air. This work I have spread out over the past few days, installing little bits throughout the day as I work on other stuff on my main machine.

Because working on a computer that doesn't remember the last few hundred things you've copied/pasted is as batshit insane as using only your pinkie fingers to type on your keyboard, I always install a clipboard history application when setting up a Mac.

For this, I've been using PTHPasteboard Pro for years, and it has performed admirably. It's a very ugly little app whose inner beauty shines through when it is put to use. I have recommended this app because I use it every single day, and have always liked it.

Until today, when its shitty DRM system rudely told me to go fuck myself. "Too many registrations," it said in rude little red text. Too many for what, you fucking little piece of shit? Again, I had no recourse other than to send a terse and angry email.

And—boom!—just like that, PTHPasteboard went from a trusted piece of software that I install on every new Mac to one that I will probably never install or recommend again.

That isn't an overreaction. It is an appropriate reaction. Wasting my time is an offense that I should and do take seriously. Even though in this case it was only a few minutes--so what, fuck off. Plenty multi-clipboard utilities in the baller-user matrix.

This reminded me, though, that for all the bitching about DRM on songs and movies and books, we've suffered DRM on our commercial software since commercial software was invented.

Act III, in which a pioneer of broken DRM pushes the needle on the irritometer into the red, causing our hero to waste the remainder of his morning writing a cathartic rant to post to his blog

Grog want play music. Grog have new Mac. Grog new Mac not authorized. Grog try authorize. Grog get error message! Grog ANGRY!! GROG SMASH!!!!

The trouble with software is that no matter how much of an asshole it is, you can't bash its motherfucking head open with a huge rock, peel off the skull, and feast on its brains. That's just not possible, even though the more primitive parts of your own brain might seethe with bloodlust when confronted with the dialog above.

That's what happened when I tried to authorize my new laptop for iTunes content. It was only 11:00 a.m., and I'd already run up against three different DRM fuckups from three different companies.

Across its hundreds of millions of users, iTunes has probably cumulatively wasted a hundred man-years of human potential with DRM fuckery. iTunes is the archduke of DRM. With iTunes, Apple popularized comercial downloadable music, and with it, DRM.

Years ago, iTunes inflicted upon me what I hope was the most idiotic DRM-related experience I will ever have.

I was in Tokyo, hanging out with a beautiful young woman. She asked me about something she heard in a song, called Diggin' On You. I wasn't familiar with the song, it being some kind of crappy chick music, so I suggested we download it. This was before Japan had its own iTunes store, so she was also interested in this buying-music-online concept.

So I fired up iTunes. The laptop I was using was my work machine, so iTunes wasn't set up. I accepted the EULA (without reading of course), entered my username and password, did a quick search, found the song, entered my credit card number, and bought it.

Cellular data wasn't quite as fast back then, so I explained the iTunes store while the song downloaded. See, I said. We buy this song sitting here in this bar, and then I can play the song here, at home, on my iPod, or whatever.

Neat, she said.

But then the download finished, at which point iTunes told me, "Hey, shithead: go fuck yourself. You have already authorized 5 computers to play your restricted iTunes content. Even though that number includes your last three laptops that you don't even have anymore, and even though I just took your money and let you buy the song on this computer, I am not going to let you play the song on this computer. So fuck off." Or words to that effect.

The beautiful girl yawned. Huh, she said. Lame.

And it was lame.

Epilogue: wherein our hero extracts a halfassed moral from his tortured narrative

One day, iTunes just up and stopped inflicting this particular flavor of horseshit on its customers. Steve Jobs wrote one of his letters, waved his scepter, and the DRM was gone (from music).

That was a big milestone for digital music. Apple no longer sold broken music that was guaranteed to stop working; they now just sold music.

I started buying music from iTunes around that time. Sure, I had bought a few broken DRM-encumbered albums up to that point, but it was mainly to get a feel for the iTunes ecosystem or for times when I was stuck with no music and was okay with paying for temporary access to some. After the elimination of DRM, iTunes music was no longer worse than music bought on CD or bootlegged off the pirate bay--it was suddenly better.

Something that sucked suddenly became something that didn't suck. The world got unambiguously better!

Well, that is always good, but it is not always the way it goes. Things don't tend to get better for no reason. They get better because people want them to get better. iTunes music got better because the users preferred that it get better.

So, if there is any moral to this story, it is that same old moral that various life lessons have imparted to me, and that I in turn tried to impart to my angry, teary-eyed wife the other day when, in the midst of a debate about something or other, she threw her kitchen apron on the floor and shouted, "I hate your complaining!"

"But baby," I said, genuinely surprised. "Complaining is the root of all human progress!"

And it is, with a liberal enough definition of the concept. When you envision how something could be made better, you are implicitly teasing out a way in which it currently sucks.

Now, complaining about something trivial or tangential is, perhaps, not something one should do to one's wife while she cooks one's dinner after a long day at the office. I concede that point.

But those motherfuckers who sell us shit that is broken by design? They deserve it. They even need it--how else will they know that even though we buy their shitty products, we hate their fucking guts, and maybe even occasionally want to bash their motherfucking head open with a huge rock, peel off the skull, and feast on their brains?

They will know because we tell them. None of us, alone, is likely to make a difference, no matter what we do. But the cumulative ire of millions of mildly irritated customers can make an impact. By firing off an angry email, even if it just says "hay ass hols i bought XYZ and now it gives me a fucking error FUCK YUO FIX IT!!!' you're helping them.

And in a small but concrete way, helping the world.

Those bastards have knocked NERV offline!

2011-07-14T00:00:00+09:00

UPDATE: it's back

The pretty (and utterly weird) NERV Power Supply Monitoring System now reports that TEPCO is generating 'NaN kilowatts'... (x_x)

I guess I have no recourse but to visit 東電's pathetic official offering, where I am told that we've got "5,270 10 thousand kW" available to sustain human society in Tokyo today.

Parsing that isn't made any easier by the sweltering heat and lack of civilized air conditioning, let me tell you...

9 lifetimes

2011-06-14T00:00:00+09:00

wha?!? a google product with a good user interface?

2011-05-31T00:00:00+09:00

I visited Google Groups today, to read some archives and think about posting a question to the PhantomJS (awesome, btw) group. I was startled to find that the UI was not the deplorable piece of shit that I was used to, nor was it the completely dysfunctional 'new' version that didn't work at all and yet was foisted upon me automatically from time to time and had to be manually disabled repeatedly.

Instead, it was something totally new (to me), and actually quite good, as far as web-based email list interfaces go:

Any decent email client is still better for a list you read a lot, but at least this thing isn't inferior in every single conceivable way anymore. Good use of avatar pictures (albeit without Gravatar support, which is retarded), attractive and responsive layout, and a good-looking and functional threaded discussion view when you click on a thread topic.

good job goog, now try a little harder on your phone OS pls

Tokyo Nuclear Clusterfuck Update

2011-05-30T00:00:00+09:00

So, does my rant about Amazon's staggeringly awful Kindle book reader mean that the Japanese Nuclear Clusterfuck of 2011 is over? No. Things are still fucked. The food chain is suspect, some areas are ruined. From my selfish Tokyo perspective, the main problem is the looming electric shortages. We haven't had blackouts for a while, but it's not the hot summer yet. Even though we don't have the blackouts yet, the entire city (and basically eastern Japan), is doing setsuden (節電), or electricity conservation, which completely fucks up a city like Tokyo. It's hot in the buildings, most escalators are stopped, and it's dark on the streets at night as if it was fucking China or something.

So it still sucks. But in one important way, it has improved:

That's the levels of cesium and radioactive iodine in the drinking water in Tokyo. None detected. While I don't tend to drink that water (even before Fukushima), I do have to shower in it, and recently since it is looking better I have started to cook with it again.

And then there is the rain:

That's looking good, too. It really sucks when you can't walk around in the rain and get wet without tripping out about what kind of radioactive shit might be giving you cancer and harming your unborn children, etc. I walked to work this morning, got wet, and didn't worry about it.

Those numbers are from http://atmc.jp (which we all still check every day), and are clearly good news.

This summer is still gonna fucking suck, though.

Holy fucking shit Kindle for Mac fucking sucks

2011-05-16T00:00:00+09:00

Amazon is one of my favorite companies, but they sure make some shitty fucking software.

I don't often use the pathetic Kindle for Mac application, because it is a fucking steaming pile of shit. But occasionally, when programming in one of my non-native languages, say, I want to look something up. But every other time I launch this shitty app, I am rudely shown this message:

I grit my teeth and try to remove the book from the 'device', per those shitty instructions, but always get this:

At that point, I try to nuke my Kindle registration and start everything over. I have gone through this process at least a dozen times. It usually goes like this:

...and stays like that indefinitely (it "may take a moment" indeed, it has been hung like that throughout the process of launching MarsEdit and writing this blog post up until here), until I quit the app... at which point, of course, it crashes:

AMAZON: PLEASE STOP WRITING MAC APPS. YOU JUST SUCK TOO MUCH. THE EXISTENCE OF YOUR KINDLE APP MAKES THE WORLD WORSE. STOP IT. STOP.