nothing2fancy

In Other News…

I’m going to try and blog once a day. We’ll see how it goes.

Sure Fire Investment Tip

I’m closely watching Google’s Chrome OS. Whichever computer company who throws all their eggs into that basket will be the ones that come out ahead of all other manufactures (with the exception of Apple, I’d say).

Here’s a demo of the OS:

The key here is that this OS is a differentiator in a pretty homogenous market. Pop Quiz: Who makes the best laptops, Sony, HP or Dell? Trick question, nobody gives a fuck because they all run the same shitty operating system.

To quote Gruber (emphasis mine):

Apple’s ability to produce innovative hardware is inextricably intertwined with its ability to produce innovative software. The iPhone is an even better example than the Mac. It’s not just that Apple is different among computer makers. It’s that Apple is the only one that even can be different, because it’s the only one that has its own OS. Part of the industry-wide herd mentality is an assumption that no one else can make a computer OS — that anyone can make a computer but only Microsoft can make an OS. It should be embarrassing to companies like Dell and Sony, with deep pockets and strong brand names, that they’re stuck selling computers with the same copy of Windows installed as the no-name brands.

There is the key. As much as folks talk about Apple’s sexy packaging, ask most Mac users and they would almost entirely rather use OS X on a cheap laptop than Windows XP on a fancy laptop. Google OS is offering manufacturers the opportunity to differentiate themselves, stand out from the crowd.

One caveat. Chrome OS is open source, which means that computer manufacturers can (and will) put their own special brand of turd cream on this OS. Just because HP releases a Chrome netbook does not mean that they didn’t foul up the OS so much that it’s borderline unusable.

Look Familiar?

Then:

Now:

Failed tests for architecture ‘i386′ (GC OFF)

I’m setting up unit testing in my current project (following Apple’s pretty-much excellent directions) and keep running into this mysterious “Failed tests for architecture ‘i386′ (GC OFF)” that nobody on the entire internets knows how to solve.

Turns out you need to adjust your build configuration before you set the test host and bundle loader. Set that bad-boy to “Debug”!

Remote Version Control with Subversion and Xcode

I split my development time between my MacBook and iMac, so I’ve been using some form of source control for the last few months (previously to that I was copying the files back and forth manually… ugh).

Up until last month I was using iDisk and Mobile Me to keep things straight. This actually works pretty well, which is why I kept using it for so long. Turn on iDisk sync and you’re given a new web-based drive on your desktop. Store your projects in there and they’ll always be up-to-date, no matter where they’re stored.

I had a few problems with this setup, thought.

1. iDisk doesn’t handle symlinks well. This didn’t make any difference to my project, but some of the sample code I’d download wouldn’t work when it was running from the mounted iDisk volume.
2. References to bundle resources are flakey. I never did figure out what caused this. Loading images from files worked fine, but trying to load sample data from an .XML file was completely broken, unless I stored the file somewhere besides the mounted iDisk volume. Since the file was small and never changed I got around this limitation by storing it on the Desktop on every computer I used, but it was still a janky solution.
3. Xcode snapshots are broken. First, snapshots didn’t move from computer to computer, so if I made a snapshot on my laptop, it wouldn’t show up on my desktop. Second, the snapshots didn’t seem to persist when the project was stored on the iDisk volume.

I probably could have overcome all these issues with some effort, but why not save myself the headache and do proper SCM with subversion? Since it already has built-in Xcode support, I figured it’d be a breeze to set up. And for the most part it was.

The instructions I followed were from Jeff LaMarche and his excellent iPhone Development blog.

The helped me set up the repository, but didn’t go quite far enough. Since I’m working from two machines at the same time¹, I need to be able to access my code from whichever machine I’m on. Most tutorials out there seem focused on either setting up local repositories, or setting up shared repositories on OS X Server, neither of which quite give me what I need.

Creating the Shared Repository

Since subversion is installed in OS X by default, setting up the repository is simple. These instructions are ripped from from Jeff’s blog. Open up Terminal and run the following commands.

cd /Users/Shared
mkdir subversion
cd subversion
mkdir HelloWorld
svnadmin create HelloWorld
chmod -R 777 HelloWorld

Setting up Remote Login in OS X

In order to securely access your repository remotely, you’ll need to turn on remote login in OS X. Navigate to the Sharing tab in Preferences and turn Remote Login on.

While you’ve got preferences open, find out what your computer’s local hostname is, you’ll need this later. You can find it in the text towards the top of the Sharing window, mine is Grover-Cleveland.local. By using this name to access your repository, you will be able to access the source even if the IP address of the server changes and you should be able to access it from outside your LAN if you’ve got Back to My Mac enabled with Mobile Me (I haven’t tested this yet).

Accessing the Shared Repository in Xcode

Open up Xcode. Hit Command-, to open Preferences. Navigating all the way to the right, you should see an SCM window. Click the “plus” sign at the bottom window to create a new repository. Give it a name, the name doesn’t have to be the same as what you set up earlier. Hit OK and create the new repository. In the URL box type the path to your subversion repository like so:

svn+ssh://username@your-computer.local/Users/Shared/subversion/HelloWorld

where username is your current login and your-computer.local is the address of your computer that we located earlier. For your first connection you’ll be prompted to add the SSH key and Xcode will ask to use your confidential information. Go ahead and let it, and you’ll be set!

Read through the rest of Jeff’s post to get some more details on using Subversion and Xcode, or read Apple’s documentation if you’d really like to go in-depth.

After a few weeks of using this system, there is no doubt that it makes the process of working on code from two different machines much more seamless. The one problem I’ve been having, and I’d be grateful if anyone knew a solution to this, is that the Commit All Changes… command will not work for me. I’ve got to go through, select all the modified files and commit them in batches. In order to commit the .xcodeproj file I need to use the SCM Results command to browse inside the .xcodeproj package and manually commit the files it contains. Vexing…

Anyway, I hope this helps some people!

Edit: I’ve had some problems with the following error, Error: 155005 (Working copy not locked; this is probably a bug, please report). After ignoring it for a few months and finally trying to figure out what’s wrong, I realized that you need to delete the “Build” directory from your repository after you delete it. After this you should have no problem doing full project commits from the menu bar.

Footnotes:

Now you know what I’d do if I had a million dollars↑

My Sister: Funniest person I know

I take 2 types of naps.  A lazy nap and a serious nap. The lazy is just how it sounds, no time limits just pure relaxation. The serious nap is more stressful. I have an alloted time that i must finish by and i first have to rid my room of distracting qualities such as the cat and phone. My life is very difficult, obviously.

mandykubicek.com

Square America

Collection of slightly creepy animated 3D images.

http://www.squareamerica.com

(via shane lavalette)

NSPersistentStoreIncompatibleVersionHashError

Man. This error has been driving me nuts for a few days now. I’ve got my iPhone app up and running, everything works great until I try and run a

[managedObjectContext save:&error]

Without saving everything works just fine (though it doesn’t restore data when I restart, obviously). Whenever I try and save, though, I get the following error.

This NSPersistentStoreCoordinator has no persistent stores.  It cannot perform a save operation.

After finally looking in what turned out to be a pretty obvious place, the declaration of the Persistent Store Coordinator in the App Delegate, the default code generated by XCode doesn’t do any error handling. Here’s what I replace it with:

if (![persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeUrl options:nil error:&error]) {
        if ([error code] == NSPersistentStoreIncompatibleVersionHashError)
            NSLog(@"Persistent Store Incompatible Version error. Please check %@", storeUrl);
        else {
            NSLog([error description]);
        }
    }

Check it. Turns out that changing your data model after you’ve already run the code once will render your database inoperable. Of course, there are techniques to upgrade your database to the new model, but at this point I don’t care. Delete the old database and next time you run the code, everything will move through smoothly, and your new database will be saved.

Cock Cock Train

In its defense, it does look pretty fun.

(not especially safe for work)

Full of Awesome

Indeed

(via Hello_Nurse)