Programming

Fighting XCode and losing

by

One of the reasons I haven’t been blogging much lately (aside from enjoying my 4th of July holiday weekend and getting ready for my trip to Vancouver) was because I was spending the last two days dealing with an XCode problem which kept some of my code from compiling.

Since I’m dealing with multiple cross platform projects, there are lots of header files called StdAfx.h that are local to each project. For some reason, XCode decided to use the wrong header include path for one particular project.

I removed the offending include path from my project, cleaned all targets, and emptied XCode’s caches and tried building again… it was still using the wrong header! I opened the project.pbxproj file in a text editor and found no references to the offending path. Searching the source directory tree also showed no reference to that path. Yet when I build, the command line clearly shows that it’s using -I with the offending path, and precompiling a source file shows the wrong header being included.

I finally admitted defeat and added an #ifdef to the offending StdAfx.h to include the proper one when building a Mac version.

A waste of time

by

It turns out that my work on Watermark was a complete waste of time. After I released it, everyone told me that Aperture has a built-in watermark feature (which I was completely unaware of), hidden in the export format window. If I had known, I wouldn’t have released it. I most likely won’t release any future updates since it landed with such a thud.

Plugin Progress

by

I had a chance to do a lot more work on my watermark plugin this weekend and I made lots of progress. Most functions work, but I still need a few days of QA & testing before I can release it.

Success!
Uploaded with plasq‘s Skitch!

Black Star Rising tells why you should add your name and copyright notice when posting a photo, which is the reason I wrote this. I noticed that almost all of the pictures by the professionals from last week’s photowalk have a copyright notice, so I wanted to make it easier to do with Aperture.

Photowalk: what you need to know

by

Paulo Jordao posted some final details about this Sunday’s Photowalk. We are going to meet around 9:45am in front the water fountain at Las Olas Riverfront, rain or shine. This is a FREE event; you can bring friends, family and even kids. Everyone should have a camera, even if it’s just a cheapie disposable.

The question: what should you bring (other than a camera, of course)?

I was debating whether or not to bring a tripod, but now I’m definitely not. It would only be extra weight, since we’ll be walking.

I haven’t decided which lenses to bring, but Paulo is only bringing a 17-55mm. I’ll definitely bring my 18-55mm, since it’s the most useful general purpose lens. I’ll probably bring the 55-200mm, but I probably won’t bring the 50mm, since it takes too long to set up a manual focus shot.

The walk is 1.7 miles, and at the end we might stop for brunch or drinks.

For the full details, check Paulo’s blog.

SproutCore + Fluid = Wonderful Synergy

by

The most exciting thing that came out of WWDC wasn’t Snow Leopard or the iPhone 3G; it was SproutCore, an open source JavaScript framework. When Steve Jobs demonstrated Mobile Me during the keynote, he didn’t say how Apple was able to make those web applications look as nice & responsive as desktop apps, but we found out a few days later in a session introducing SproutCore.

I’ve been looking at SproutCore and playing with the demos for the last few days and I’m very impressed. The photo sample looks like a stripped down iPhoto. I think with a bit of tweaking it would make a great online photo gallery.

One thing that takes a bit of getting used to is that SproutCore uses a ruby gem to build your application and serve it during development, but you can build a static version that doesn’t require Ruby and can be deployed to any web server.

While web based applications are starting to look and act more like desktop apps, Fluid lets you bring your favorite web sites or applications to the desktop. With Fluid, you can build a site-specific browser that you can double click to open that web site immediately. Fluid also adds some additional functionality to web apps, such as showing dock menus, badges, and growl notifications. You can even make your web app a menu extra so it’s available anywhere by a single click.

The two pieces work together beautifully as a new way to deploy applications. Write your application in SproutCore, deploy it on your web site, and build a Fluid desktop app that your users can double-click from their desktop to run your web-based application just as if it actually was a desktop app.

Off to WWDC

by

I’m getting ready to leave for San Francisco early in the morning. My flight is at 6:45 so I’ll probably have to be up around 3AM. I change flights in Atlanta and arrive in San Francisco around noon, so I’ll have plenty of time to pick up my badge.

FriendFeed's room for improvement

by

FriendFeed has become very popular lately, in part due to Twitter’s unreliability. FriendFeed still can’t replace Twitter, since it can’t be accessed via SMS or IM, although FriendFeed can be more conversational, since you can comment on a particular item rather than just reply to the user as you do on Twitter.

A few days ago, FriendFeed added rooms, a good idea although it still seems a bit rough around the edges. The big limitation of rooms is that there’s no way to see a list of rooms or find a particular room unless you know the name, although Andy Beard found a way to find rooms through Google.

The API seems to be lacking some features needed to fully support rooms. In particular, it isn’t possible to get all rooms a user belongs to. You also can’t get messages from multiple rooms. I’m sure they’ll continue to refine this feature.

I’m trying to decide how to add room support to my FriendFeed iPhone app without making it too cluttered. I’d welcome feedback & suggestions on how the application can be improved.

APIs should be free & open

by

Many websites which provide an API require developers to register and request a key, while others like Twitter and FriendFeed are completely open. Flickery, a new desktop client for Flickr, demonstrats why restricted APIs are bad. Flickr decided to revoke the developer’s API key because it was causing too much traffic, causing the Flickery application to stop working.

Requiring developers to sign up for a key before they start developing applications for a website will stifle development and make it less likely that we’ll see new and innovative applications. Twitter has maybe hundreds of third party applications thanks to their open API, while Pownce, which requires a key (even though it’s quick & free to sign up), has very few.