One of those overdue OmniFocus tasks is to write a blog post.
Talk about taking the cheap and easy way to cross something off my list.
On the plus side WordPress for iPhone seems to work.
One of those overdue OmniFocus tasks is to write a blog post.
Talk about taking the cheap and easy way to cross something off my list.
On the plus side WordPress for iPhone seems to work.
The other day I went to check my email and found this waiting for me:
From: Mom
Subject: Guess what?
Always interesting when something like that comes through your inbox. I opened it up and was greeted with this line:
“Guess what I bought today? A new laptop computer!!!”
Hmmm. Spidey sense was tingling on this one a little bit. Mom has never been a computer person, in fact she has never been a huge technology person of any kind. But hey, trying new things is cool, good for her. And if this means we can bump the resolution up from 1024×768 on my Dad’s workstation that he does CAD/modeling work on more the better. More from the email:
“When I saw this computer on sale, I knew it was time to jump in.”
At this point I’m starting to get a little concerned. Does Packard Bell still exist? Do they make laptops? Is this a floor model from 2002 running Windows ME? All questions going through my head.
“Dad hasn’t even seen it yet.”
Uh-oh.
Now I’m officially worried. Dad is kind of my tech support safety net in that he is there to solve all the crazy Windows/printers/virus scanners/misc problems. My first reaction is that he doesn’t even know she bought this thing. My second is that there is the potential for big time trouble since he is on a fishing trip in the middle of nowhere Michigan for a week.
That’s right, all I need now is a headset and I’m ready to be first tier tech support.
Not good times.
So I call mom to try to get some more details and a funny thing happens, actually it is a funny series of things.
1. She’s got the machine up and running and on Dad’s wifi network.
2. It is a brand new Compaq Presario running the *just* released Windows 7.
3. She’s got Skype installed and wants to try out the built-in webcam.
Err, huh? Really? No way.
I fire up Skype do a search for mom, find her no problem, click the call button, Skype does its funny little Skype noise and tada:

Holy cow. Talking to Mom on Skype on a notebook computer she set up completely by herself with Dad standing in the middle of a freezing river somewhere. If you had asked to me bet money on this situation working out well, and on the first try, I would have lost everything I own.
So, even though I’m Mac guy, and I’ve only spent about 30 minutes total with Windows 7, it must be pretty easy and straightforward to use. In fact, I would say it fits the old adage of being easy enough for your grandmother to use.
(Well, my son’s grandmother technically but close enough.)
Today I decided to look a into a bug we encountered when using the Sun Java JRE 1.6 on certain distributions of Linux. When we first found the defect it became pretty clear that something somewhere had changed between JDK 1.5 and 1.6. In 1.5 everything worked like a charm. In 1.6, the best case was a hang and the worst case seemed to be the JVM exploding internally.
Either way my pronouncements that things worked just fine thankyouverymuch on the Mac weren’t going to cut it as far as getting the defect fixed.
So, in order to debug the issue I started installing a bunch of different Linux distros into virtual machines.
And then I sat around.
And waited.
And watched the progress bar.
And then finally complained on Twitter.

Thankfully my friend Mike took pity on my plight and replied back promising approximately two minute worth of diversion.

Boy was that two minutes well spent. His link led me to this blog post which contained this bit of YouTube powered awesomeness:
My reply Tweet to Mike pretty much sums it up:

Naturally this all got me thinking about how little gunpowder was needed to hurl this anvil into the air. That then led me of course to Wikipedia’s History of Gunpowder page. I knew that it had been invented by the Chinese a long time ago but I had no idea that it was probably done by some master alchemist who was searching for the “elixir of immortality.” (Boy did he miss on that one.)
In fact here is an artistic representation of the master right before he accidentally blew himself into smithereens.

I guess that’s why the original inventor of gunpowder is still somewhat anonymous. It must have been up to his surviving apprentice to be in charge of the story after his master blew up like a JDK 1.6 on Linux.
And we all know that the apprentice isn’t the one that specializes in blatant self promotion…

So over the last few months I’ve taken up running. Even stranger is that I am actually enjoying it. To those who know me this pretty much confirms that I’ve gone completely bat-$#&@ insane.
Unlike the old days of doing conditioning laps for soccer, now I get to use modern technology to keep a permanent record of just how slow I can be. To do this I’ve been using Runkeeper for my iPhone 3GS. It is a really great piece of software and brain dead easy to use to track and map out with GPS where you run. There is, however, one small catch:
Using GPS while running on an inside track is completely and utterly useless. As evidence I present some screenshots from my run last night.

The starting in Mason part of the map is right. I most certainly did not run to Dayton though. Even more telling is my distance and speed.

That’s right friends, I have unequivocal, irrefutable evidence that I can run at 221mph, which is just 3mph off the pole sitter speed for the last Indianapolis 500. That does explain why when I finished running I had a hankering for a drink of ethanol fuel and a burning desire to have my tires shoes changed though.
*Looks for words*
*Scratches head*
*Again looks for words*
I’ve got nothing. Watch this:
Rather than rehash a Snow Leopard review or for that matter even bother writing one up myself you should read the outstanding review at Ars Technica.
Ars super Snow Leopard review.
I will point out the three sections that if you are a developer you really want to read if going over their whole article is too much.
1. LLVM and Clang – Right now gcc keeps finding himself looking over his shoulder.
2. Blocks – Ruby, Javascript, and all the other modern scripting languages (and the not so modern like Lisp) welcome C to the party.
3. Grand Central Dispatch – Used with blocks this could be a mind blowing change to writing parallelized code. This is really wicked cool.
Oh, and Exchange support works with Mail.app and iCal. Like for real. Look I can even accept an invitation to play basketball without logging onto Outlook Web. *Swoon*

I make a Ghostbusters joke on Twitter, a bot sees the word “trap” and follows up with Admiral Ackbar. That is awesome on so many different levels.


So I’ve got a problem. And no, it doesn’t involve lawyers. I know, I’m surprised about that as you are.
My problem is that I want Xcode to automatically run my unit tests after each debug build. The trouble is my .xcodeproj is generated from a Qt .pro file using qmake. Unfortunately, qmake doesn’t have the ability to create a Xcode run script phase with its QMAKE_POST_LINK directive.
Seriously, even their docs say so.
And this bug.
And this one too.
That means to have a run script build phase that executes my UnitTest++ unit tests I would need expand the Target, right click, add a build phase, and copy in the shell script to run from somewhere every single time I regenerated the .xcodeproj from the .pro.
I mean, come on, that’s like at least 20 seconds worth of work. Plus I have to right click. And I have to type! What next, should I write C++ code in my own blood?
Luckily, Xcode has a great deal of Applescript support which means all I had to do was devote an evening of Applescript coding while watching a basketball game in order to save myself 20 seconds.
Anyhow, here is what you need to do to create a new run script build phase in an Xcode project using Applescript. Note that this example is pretty heavily Qt based since that was my issue but the general idea could easily be used for any other kind of post build script. (Ex: Copy the binary to a network share, send an email, make a bacon sandwich. Not sure how to do that last one, but man that would be EPIC.)
First, from the command, generate your .xcodeproj from your Qt .pro using qmake.
lammi-mbp:Unix lammig$ qmake -spec macx-xcode
In my case I was using a file named scmserver.pro. The result of qmake was then scmserver.xcodeproj.
Then, open up the new .xcodeproj in Xcode.
lammi-mbp:Unix lammig$ open scmserver.xcodeproj/
Notice how the project that was generated doesn’t have a Unit Test phase.

To get that we need to run my Applescript. (createunittestsforxcode.scpt)
lammi-mbp:Unix lammig$ osascript createunittestsforxcode.scpt
If we look back now in Xcode we can see that through the magic of Applescript there is a new build phase.

Double clicking on the new build phase shows that it has all the stuff we want. Rock. And even it works when I compile. Double rock.

Now while I was writing this script I came to the conclusion that Applescript is really hard to Google on and that examples of scripting Xcode itself are fairly few and far between. I blame the first on the Applescript language being so English-like. I blame the second on the Internet.
So to help spread the knowledge in the whole “man ain’t the Internet grand let’s all have a big group hug” kind of way here is a walkthrough of the script to show how it all works.
First we start out by saying that Xcode is the application we want to play with and that we should use currently active project.
tell application "Xcode"
tell project of active project document
Next we need to build the full path to the executable that Xcode will build. We need to do this because in order to run unit tests we run the debug binary passing the parameter UnitTest on the command line. We can get all this information generically from the Xcode project so the Applescript can be reused as-is against all our different .xcodeproj’s.
set myExecPath to path of executable 1 -- This gets the .app bundle name
set myExecName to name of executable 1 -- This get the name of executable binary
set myStartupDirectory to startup directory of executable 1 -- This gets the startup directory
-- Concate them all together with the UnitTest parameter. This is the command to run the tests
set myUnitTestCmd to myStartupDirectory & "/" & myExecPath & "/Contents/MacOS/" & myExecName & " UnitTest"
The next operations will be going against the Xcode Target for our project, so we need to tell the Applescript to operate against that.
tell target 1
Now we need to write the shell script that will run the binary with the UnitTest parameter to run our tests.
-- Write the shell script to execute during our new run script phase
set myScript to "if [ $CONFIGURATION = \"Debug\" ]; then
echo
" & myUnitTestCmd & "
fi"
All that’s left is adding our shell script as a run script build phase to our target. To do this we just need a single line. This is the line you’ll want to use if you want to run a different script of your own. Just replace the contents of the myScript variable with whatever you want to run.
-- Add new run script phase with our shell script
set myBuildPhase to make new run script phase with properties {name:"Unit Tests", shell path:"/bin/sh", shell script:myScript}
The only thing left is to wrap up our tell blocks and we’re golden..
end tell
end tell
end tell
Finally, here’s the script in full, have fun Xcode’ing and Applescripting. Oh and if you can somehow make a script that makes a bacon sandwich, GPL that sucker for the sake of all humanity.
tell application "Xcode"
tell project of active project document
set myExecPath to path of executable 1 -- This gets the .app bundle name
set myExecName to name of executable 1 -- This get the name of executable binary
set myStartupDirectory to startup directory of executable 1 -- This gets the startup directory
-- Concate them all together with the UnitTest parameter. This is the command to run the tests
set myUnitTestCmd to myStartupDirectory & "/" & myExecPath & "/Contents/MacOS/" & myExecName & " UnitTest"
tell target 1
-- Write the shell script to execute during our new run script phase
set myScript to "if [ $CONFIGURATION = \"Debug\" ]; then
echo
" & myUnitTestCmd & "
fi"
-- Add new run script phase with our shell script
set myBuildPhase to make new run script phase with properties {name:"Unit Tests", shell path:"/bin/sh", shell script:myScript}
end tell
end tell
end tell
Last night I was watching the War History Channel and a really helpful commercial came on. It offered to tell me how to use the Internet to uh, make money and stuff. I think. Or maybe it would help me take a vacation. It all runs together.
I’m a little dubious about their credibility though. I mean, don’t get me wrong, who doesn’t want fast cars and fancy houses while working at home part time? And I’ve always needed a boat, especially the kind that doesn’t require oars and a lot of sweating to make it go.
The problem: If they don’t know to use the spell checker on the ad they are spending thousands of dollars to put on TV they may not actually know how to use the Internet to uh, make money and stuff.
