The Cocoa Diaries Part I

I've been slowly plugging away at a new iPhoto export plugin for exporting photos to an Ansel server.  This was really my first Cocoa project and my first C related project in quite a number of years.

 I found picking up the basics of objective C  not that difficult, but I was stumped trying to do something that should have been fairly easy.  For this plugin, I am using the Cocoa XML-RPC Framework to manage (surprisingly enough) a xml-rpc connection to the Horde server.  During development, I just had it linked against the framework in my Library/Frameworks directory - which obviously won't work on someone else's machine.  So, time to move the framework into the bundle for the plugin.

I decided I wanted to include the source for the framework in the same project as the plugin. This makes debugging easier and also makes distributed development with other developers easier.  Sure, no problem,  just add the source, add a new framework target, copy files etc... but no dice.  For the life of me, I could not figure out why this would not work. Googled, hacked, googled some more.  Then it hits me - this is a plugin, not a standalone application.  When setting the Installation Path build property for the framework target in Xcode, I was using @application_path and not @loader_path. Duh. 

So, seeing how that particular problem cost me so much time, I thought I'd document this in the hopes it will help someone else avoid the same mistake. Here are the steps required to add the source code for a framework into an existing Xcode project for a plugin. (These are all basically the same steps as an adding it to an application, except for the setting of the Installaion Directory property).

• Import the framework's source tree using the Import Existing Files command
• Create a new target for the framework. Obviously, this should be a Cocoa Framework target.
• Open the Build tab of the Inspector for the framework target, and set the Installation Directory property of the target to be: @loader_path/../Frameworks
  
• Open the target for the plugin so you can see the build phases - drag your framework product (not the target) to the Link Binary with Libraries build phase.
• Add a new Copy Files build phase and drag your framework product to the it. Open an inspector and set the Destination of the build phase to Frameworks.
• Select the application target, open an inspector and add your framework as a dependency. This will assure that the framework is built before the plugin so that it's available to link against.  This allows you to keep the target of the Xcode project set to your plugin.

Yep, probably all simple stuff for an experienced x coder, and it actually is mostly pretty simple stuff...except for the fact that I forgot that I could not use @application_path as the Installation Directory.

phpEnomUpdate - A small command line utility.

­Like many of us, I own a number of domain names.  I also have two servers that run out of my home in addition to a production VPS server located on the other side of the country from where I am. The domain registrar I use provides a 'normal' DNS service combined with a dynamic service that allows you to define any host on your domain as dynamic.  This has worked out well for me, allowing me to integrate my various home machines onto my domain. 

Recently (thanks to a server replacement project - but that's another story) I had to rebuild my main development server and in the process I decided I wanted name based virtual hosting on this box as well.  This presented a problem, as I have a number of domains that would need to be supported on this box. The protocol my provider uses for dynamic DNS updates allows any number of hosts on a domain to be updated at one time, but not mulitple domains (obviously).  I could have either updated the client that I was using (some really rough Perl script), find a better client, or write my own.

The enomupdate script was a poorly written tool that served a basic purpose. Update one domain. Period.  You couldn't even run it with different paramers or configuration files.  I could have modified it, but I'm not as comfortable in Perl as I am in PHP and I thought it a good way to emphisize the fact that PHP is not just a web server language.

The result was phpEnomUpdate.  You specify any number of domains (or zones in DNS-speak) each or which can have any number of hosts.  Each host will be updated to your IP. Now, I can have dev.example.com  dev.anotherexample.com  all point to my dynamic IP with one simple cron entry....and now I can keep my lighttpd server directory nice and neat on my dev box too, with simple name based virtual hosting.

 The script does have a few PEAR requirements and one Horde package (Horde_CLI), but they are very easy to install if they are not already on your system. See the INSTALL file in the download for more information.