Today I spent an hour or so trying to clean up some iPhone code that I’ve been working on for Carticipate. I found that I was having trouble with the build that I checked out from our Subversion repository for a bunch of different reasons.

The very first one was that the code was built on an older version of Xcode, as well as an older version of the iPhone SDK, and on top of that the build machine was running Leopard (10.5) while I’ve been running Snow Leopard (10.6) almost since the day it was released.

I tend to try and stay as up to date with software as I can, and most of the time it serves me well. In this case, I ran into several very interesting issues. First thing I did was to check out the code using the command line tools for Subversion. After a few false starts, I got the full directory from the server downloaded to my Projects folder.

I opened up Finder, double-clicked on the project file, and got a warning about the file being for an older version of the SDK. Since I had loaded the latest version of the iPhone SDK, it wanted to upgrade the project build files to the new format. I figured that would probably be OK as long as I didn’t forget and check things back in, so I went ahead.

Then hit “build and run” only to get compile errors. Seems a few of the calls on the code that is currently being used in the wild aren’t allowed for the latest SDK. A few edits and no more compile errors, but there’s some other error. By default XCode just shows this little icon at the bottom of the project that shows the number of errors, but you don’t really see the build log. Clicking on the little error icon, takes you to the log, and of course there’s more greek there.

Something about not being able to copy a file from a user directory (one that naturally doesn’t exist on my machine). More web searches and digging around to try and figure out where copies are specified. If you’re OS X centric, it’s really pretty intuitive, it’s hidden somewhere and you have to find the right properties page to update. Finally I find the setting in the build targets, change it to point to an existing file, and everything runs like magic.

Now I notice that on the build machine, there is a Carticipate settings page under the iPhones Settings app, and it looks different than the one that you see if you have a production version of Carticipate from the App store. The one on my machine looks like the production build, so I figure it must be because I’m building for the release target, but switching to the debug target doesn’t seem to change anything.

I stumble around a bit more and find a DebugFiles folder that has the Settings.bundle file with the extra settings on it. Seems like it is set up to copy the file from that sub-folder if I’m building for debug, but no matter what I do, I can’t seem to get it to change. I clean, I build, I switch, I clean, I build, nothing …

Finally just to make sure the files are coming from where I think they are, I edit the root.plist in both Settings.bundles to be different, and … Magic, the debug settings show up. I switch to the release target, and the settings pane changes to the production one. So apparently something in XCode was being lazy, and not copying the file from the DebugFiles folder until I touched it (must use Make under there somewhere).

In the meantime, I see a checkin email from another developer that has the entire build tree being checked in. I dig around on the web some more only to find that the way Subversion is configured out of the box on OS X, there are no default ignores, and apparently XCode doesn’t have any intelligence of it’s own around what it checks in. Turns out there is a  ~/.subversion/config file set up, but the global ignores is commented out so nothing is excluded by default.

By default the global-ignores is commented out, even though it seems to include most everything we would want excluded. I chose to copy the list from somebody else for now, making sure I added one for “build” to exclude that for sure:

[miscellany]

### Set global-ignores to a set of whitespace-delimited globs
### which Subversion will ignore in its 'status' output, and
### while importing or adding files and directories.
# global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store
global-ignores = build *.o *.lo *.la .*~ *~ ._* .DS_Store .Trash* *.pbxuser *.mode*

So all I had to do was remove that build folder from the repository, and give this same change to the other developers … Well, not quite …

After I deleted the folder from the repository, I had the other developer try and check it out. He got these really weird subversion messages that said something was locked. I’ve seen those before, and usually it just means you have to run an “svn cleanup” command to get things back in synch. But in this case that didn’t work, and eventually I found that I had to physically delete the folder on his machine before running the “svn update”.

Oh, and did I forget to mention, the other developer is using an older version of the client, so when trying to update he got this lovely message about his client being too old. We updated to the latest client from the Tigris.org site using the Mac OS X download, thinking that would work. Turns out that this update doesn’t replace the version that comes with OS X (in the /usr/bin folder), so you have to remove or rename that one, and add a symlink to the /opt/subversion/bin/svn executable in order to get the newly installed version to be run at the command prompt.

So with the newly updated checkout, the build worked on all machines, and the repository is fairly clean. Then came the next hurdle, the older machines (running the older version of the iPhone developer kit and therefore XCode) would no longer update the code using the built in subversion client. Found a small message about the version being too old displayed in the status line of XCode, so did some more searching.

Apparently on the older version of XCode, you could tell it which Subversion to use, but at some point, the developer tools started including a subversion library. Still haven’t figure that one out yet, but it looks like it might require some more moving files and setting up symlinks to get it to use the newly installed latest version.

Seems like one thing that I am continuing to learn is that it doesn’t pay to keep your software up to date on a Mac (unless you’re really brave) …

Today I read a blog that was a continuation of the series of ads that Microsoft has about why you should buy a PC instead of a Mac.

The article (see http://tinyurl.com/cncx73) was one of those cutesy marketing ideas that looked at the alleged difference in cost between a Mac and a PC and came up with an imaginary tax rebate based on the savings. The author used this whitepaper as the basis for the comparison. Like all of these comparisons, comparing apples to oranges results in the preferred hardware (in this case the PC) being shown to be a better deal.

I do most of my work on a MacBook Pro, after being a laptop user for more years than I care to count. I switched when it became possible to do so without giving up Windows. With the current crop of Apple machines, you have the option of running Windows directly, setting things up to dual boot (BootCamp), or running Windows in a VM (using Parallels, Fusion, VirtualBox, etc.)

Which once again leads me to ask why would Microsoft bash Apple ?

For me, nothing changed in what I buy from Microsoft – I still need a copy of the operating system, and application suite. I can choose to run some parts under the Mac OS, or just use the Microsoft products as I always have. Granted there are open source alternatives for many of these, but that is true for both the Mac OS and Windows.

When I bought the first Macbook, it was only very slightly more than a comparable IBM thinkpad (which at the time was the business laptop of choice). The only selling point for me was that I would have a second operating system on which to test my development work. In other words, I was getting a dev box that I could use for much less than buying a second machine would have been.

My other reason for buying the MacBook was that it weighed about half of what the ThinkPad did, and had that nice aluminum shell to protect it. Lugging a laptop with a power supply and extra battery around cost me about 10-12pounds in my backpack, so reducing that by about half was very attractive (especially on the 20 mile bike ride home).

What I learned after the fact has made me very glad about making the purchase.

Advantage 1 – Better battery life

I gained a great deal of battery life. My first MacBook Pro gave me 4-6 hours of life on a charge, meaning I could go from meeting to meeting and not have to worry about it dying because I couldn’t find a plug. I could also make it through most flights without the machine dying. I used to have to lug extra batteries for this.

Advantage 2 – Instant sleep

On some laptop PC‘s, when you close the lid, it will try to sleep, or hibernate. The problem is that it doesn’t always work, and even if it does, it seems to take forever to wake back up (and occasionally won’t wake up). With the Mac, I was pleased to find that as soon as I closed the lid, the machine went to sleep. On the MacBook, the little power indicator does a slow blink to let you know it is asleep, and that happens almost immediately.

Especially on days that I was rushing out of the office to catch the train, or hop on my bike, it was immensely gratifying to know I didn’t have to worry about whether the machine actually was sleeping or not. I can recall a few times getting home, unpacking my PC, only to find that it had been ON in my backpack for the whole ride home (and sometimes had overheated because of being in that enclosed space). I eventually learned to shut down the machine before leaving, which meant another 15 minutes or more of non-productive time.

Advantage 3 – Start up time

When I was lugging a Thinkpad to work every day, I would plug it in, dock it and go get breakfast. That was because it took around half an hour to fully boot up the machine from being powered off.  With the Mac, if I had powered it all the way off, it only takes a minute or so to boot up, and it is almost instant when starting from sleep.

Advantage 4 – Support

While having a Thinkpad and working for a large corporation, I never had to really think about hardware support. If something broke, I’d just take it to the IT guys, and they’d get it working again (or replace it). When I went out on my own, the very scary possibility that my work machine might die came into play. I bought service contracts for my first few machines, and learned that while they protect you, it is definitely not the same as you get with the desktop support guys.

To get support, you had to wade through a web site, and it was almost impossible to find a real person to talk to (other than the chat bots that everybody seems to use now). And if you had a hardware problem, it was: ship it back to us, we’ll fix it and if it was under warranty we won’t charge you, average turnaround two weeks.

To be fair, I’ve never bought a machine from one of the retail markets like Best Buy or Fry’s, and that’s mostly because of my experience when talking to the people that work there. My impression is that you’re not going to find stellar support there, since you’re basically working with a group that has a broader focus than just the PC’s they sell.

With my first Mac however, things were indeed different. I bought the machine through the web, and the first time I had a problem,  I was able to call support. And when I had my first actual issue (a hard drive failure that was caused by me dropping the Mac from about belly high), I took it to the store and they fixed it. Let me say it again: they fixed it, and I only left it with them for a couple of days. And this was before I bought an Apple Care contract!

Advantage Mac OS X

So for me, the advantage is clear, and Microsoft doesn’t even lose out since they don’t sell hardware. I gain significantly in productivity with the Mac, and have my VM for those Microsoft apps I need to stay compatible.

I still don’t get why Microsoft bashes the Mac, maybe they’re worried about the home user who might not need any PC software, but that seems like a sale they would have lost anyway. I’ll continue to buy solid hardware like Apple makes, and decide on which operating system based on the needs I have to interact with my customers, which will include Windows for the forseeable future.

I have been running my development for VolunteerCake with a database on my Windows box which sits in my office with my Mac. I went to meet some people at a coffee shop, and realized that I couldn’t show them the app running on my MacBook because I was no longer on the same subnet with my Windows box, so I decided to move the database to the Mac to allow me for this.

Since I had everything in place to run Cake on my Mac except for MySQL, the first step was to install MySQL. This turns out to be pretty painless. Just grab the DMG from the MySQL site, and voila, new MySQL running on my Mac. Checked everything out using the MySQL administration tools, and it all looks good (I can access the DB, set up users, etc.)

Next I need to put the data in the database, so I just do a quick export from the phpmyadmin page on the PC. I end up with a file that is the SQL needed to replicate the entire database on my Mac. I run this SQL into the Mac MySQL, and now I have an exact copy of the database on my Mac.

After that, I go to the SQL administrator tool and make sure I have the user set up to give access to that database and make sure the username and password are the same as I was using on the PC (if I were more of a DBA, I’d probably have done this with command line MySQL, but I like GUIs, especially for things I don’t do every day, and the MySQL tools are pretty cool).

Then I need to change my database.php to point at the local database in order for VolunteerCake to get the data from the Mac. This should be as easy as changing the name of the host name to ‘localhost’ from ‘monet’ since I’ve set up the user and access to the database exactly the same as what I had on the PC.

Finally, all that’s left is to fire up the same URL that I have established for my app on my Mac (http://test.lctd.org/VolunteerCake) and … wait, that didn’t work. It says it can’t find the table acos for the Aco model …

Weird, the table is there, I can connect just fine, what could this be? A quick trip to the IRC channel, and I get the suggestion of clearing my cache. OK, try that … But hit the URL again and no change.

OK, now I’m confused, so I try running ‘cake bake’ … Now something interesting: I get an error that tells me that it was unable to connect to /var/mysql/mysql.sock – what does that mean? I thought I was connecting with a TCP socket, why does it want a file? Is this some sort of file permissions issue ?

Back to the IRC chat for some guidance, thinking maybe it’s a common problem, a permissions issue or something, of course they tell me to do exactly what I’d tell somebody else to do: verify that you can connect from PHP first. Good idea – so I whip up a quick connection test page, and get the same error. So now I’ve confirmed that it’s a PHP problem, and not a Cake issue.PHP can connect to a remote DB, but not the one on my local Mac …

Now it occurs to me that I often have problems that end up being related to the open source software that came bundled with the Mac, so I do some Google searches on PHP connection to MySQL for Mac OS X, and with the connection error messages. Eventually I find what looks to be the issue: for some reason the MySQL configuration sets the socket file to /tmp/mysql.sock but the PHP that comes with the Mac is looking somewhere else (at /var/mysql/mysql.sock to be specific). So I basically have three choices, edit the php.ini, edit the mysql config file, or build symlinks to make the file accessible at both locations.

I decide to change the php.ini file, which turns out to be another excercise in hunting, since Mac OS X likes to hide the files you’d expect to find in the /etc directory. After some more Google searches, I find that the PHP5 install that comes with Leopard puts the php.ini file into /private/etc, so I edit that file, changing the part of the file that looks like the following:

To be:

In order to have PHP find the mysql.sock in the location that MySQL is actually creating it. Check my URL again, and voila, everything is working !!!

So, to make a long story even longer, I relearned that mixing actual open source with vendor open source is often problematic. It was suggested by at least one person (Mark Story) on the IRC channel that the best way to set up for Cake development on the Mac is to use MacPorts, since then you end up with matching versions of the software all in a “normal” open source location.

Enhanced by Zemanta