There was a lot of buzz yesterday around the not-new, but recently renewed interest in, Placebase’s – and more specifically Jaron Waldman’s – joining Apple in their “Geo Team”.  

Putting aside the question about whether Apple purchased Placebase, it’s more interesting and worthwhile to consider why Apple is interested in pulling in and working with technologists like Jaron that obviously demonstrate the ability to pull together components and build a compelling, unique mapping stack.

Apple technology has increasingly added location capabilities. Address Book, Mail, and iCal all detect addresses and provide links to maps. iPhoto and Aperture understand coordinate tags and can provide maps as well. CoreLocation on the iPhone, and now in Snow Leopard, allow any developer to get the location of the device via a cascading order of geolocation: GPS, Wifi, IP, etc. Apple themselves developed the “Google Maps” iPhone application – just utilizing the Google API for tiles, location and routing.

More recently, Apple has provided for “lost iPhone” tracking via MobileMe. Enterprising uses and developers have used this for friend and family tracking services.

Looking forward, it’s clear that Apple sees the important potential of location to support and augment almost all of their applications and platforms. Like any good business, the less dependent a company can be on third-party’s for core functionality, the better. Therefore, it makes sense that Apple would investigate ways to own and control this key component.

And beyond pure business and strategy, there is a lot to gain by Apple controlling it’s own location and mapping stack. Apple obviously focuses on providing exquisitely crafted experiences. This should permeate through their maps as well. Look at the maps to your local Apple store for an example of how the cartography can fit into the look and feel of the Apple.com store interface. This same customization can exist throughout their product line. Maps applications and API can provide customized interfaces and styling.

And consider that Apple can also build out a MobileMe friend finding and family tracking service. There is now an inherent trust in Apple tools: easy to use, virus free, great for kids. These translate over to trust in sharing my location through my phone to my private family sharing portal.

So in the end, what this signals is a major shift to provide broad, consumer facing compelling geospatial technologies in a well executed interface. Apple is already responsible for enabling location-based services to cross the chasm, and is inducing the broad emergence of augmented reality. It makes perfect sense for them to ensure they control and can craft the entire experience. I’m personally glad they have someone as expert as Jaron on the team.

The new version of Mac OS X, Leopard, came with a much anticipated feature – an officially supported set of Ruby bridges to Cocoa (the Mac OS X Framework) and AppleScript. Digging around I couldn’t find the pre-installed versions, but it was easy enough to gem install rb-appscript

I’ve been playing around with the very complete examples over the last couple of days and am really impressed with how easy it is to build Cocoa apps in just a few lines of Ruby code and using the new InterfaceBuilder. You get full-fledged support of all OS X’s goodness without having to worry about Objective-C.

However, I hadn’t fully considered some of the implications of this until I was stumbled across the open-source OmniFocus-UI. It is a Rails app written as an iPhone interface to the Productivity application (GTD) OmniFocus. It essentially provides a very lightweight web interface to the application by way of the AppleScript interface. rb-appscript and RubyOSA are two Ruby AppleScript bridges that make AppleScript actually really nice to work with.

The fact that it’s a Rails app is almost silly. There is no database connection to speak of. All storage and primary functionality is handled by the app itself. OmniFocus-UI could probably be rewritten as a Camping or Merb application very easily with a much smaller footprint.

The way the Rails app works is that the controllers just route commands via rb-appscript. So when you want a list of contexts (organization of todos), the Rails app just needs to do the following in Ruby:

require 'appscript'
doc = Appscript.app("OmniFocus").default_document
doc.contexts.get.length

Or to see how many Inbox items you have:

doc.inbox_tasks.count

If instead you want to use RubyOSA, it’s really just the Class name that changes (and some more underlying bits):

require 'rbosa'
doc = OSA.app("OmniFocus").default_document

What this means is, it’s very easy to build web interfaces on top of any AppleScript-able Mac application. The one difficulty, however, is configuring your Mac to make it easily externally accessible from anywhere on the Web. If you’re handy on IT, you can always setup port-forwarding on your router.

However, if you just want setup & forget, you should check out Prism (http://goprism.com) – which creates secure, private web accessible connections to your home computer.

I haven’t tried it yet, but the new Mac OS 10.4.9 update fixes a problem in Aperture:

GPS metadata is preserved when image versions are exported.

And there was much rejoicing… Yay!

This is actually a really common problem with most photo-editing programs. You’re lucky if they retain much, if any, of the EXIF metadata for an image. All that time spent putting in Copyright, Headline, Caption, Location, Subject, etc. is usually probably lost the minute you export to JPG or upload to Flickr. It’s nice to see applications, especially professional-grade ones, supporting the additional metadata.

The Update addresses another issue I ran into the other day:

Addresses an issue in which incorrect encoding could be used for the files created by the “New Text File” Automator action on Intel-based Macs.

I was trying to setup Automator actions for my Pertelian X2040 LCD in an upcoming MacTech Magazine article. Now I can add lines for upcoming iCal events, Mail messages, and perhaps even pipe these out to my NabazTag!

Leopard will officially support Ruby & Python bindings in Cocoa which is terrific news. I’m a big fan of interpreted languages when appropriate.

Of course, there are about a dozen other very cool technologies for developers in Leopard that should really make application development, faster, better, and more fun. I’ve gotten a chance to play some with Leopard previews, and the actual User-facing improvements are minimal. But what users will eventually get will be lots of better third-party applications. (via Theocacoa and Michael McCracken)

It’s great to see how much effort is going into not just creating slicker UI’s, but better supporting the people that really make or break an operating environment – developers. Microsoft has had a lot of developer support for quite awhile, and I constantly hear about various .NET meetings/presentations/technologies etc. Apple really kicked it off by releasing XCode for free (no ‘professional versions’ need apply) and then having terrific Developer Documentation and examples.

The Leopard developer page makes some odd claims:

Mac users love to exchange quick messages, have video conferences, and collaborate on each other’s desktops across the network.

um… right, ok. I just love collaborating on your desktop. Anyways, I can’t wait to dive in and start developing on Leopard.

MacTalk Magazine is a new, print & digital magazine out of Australia. If you don’t happen to be down-under, you can grab the PDF for free. (via Theocacao)

Overall it has a very nice layout, though I think there could be a little more line-spacing. The Short story sections that look like Safari windows is cute though the double-url’s is redundant.

One thing about Mac magazines, there are quite a few out there now, and to be honest, the community just isn’t that big to warrant 4 or 5 monthly magazines. Especially when there are so many blogs. Really, you end up getting multiple reviews on the same new products, like an external hard drive. And which magazine is going to give a bad review of a new piece of Apple hardware.

Mac Talk also has non-mac specific articles, like Depth of Field for photography, and better movie recording techniques. There is even a Programming section, which is very welcome, but perhaps a little bit out of the mainstream.

Personally, I like the idea of various levels of Mac Magazines. You have your general audience magazine, like MacAddict or MacWorld. There is the sole surviving technical magazine, MacTech, and various photography and media Mac magazines.

I’m curious as to the readership trends of print magazines to online resources, and how magazines can better blend the two. Wired, for example, published their print magazine (of which I am a subscriber) with all of their articles, and excellent layout. However, they also push their articles out online, staged, after the print magazine. Sometimes the online article comes out before I’ve gotten a chance to read the print version. This is a case of the magazine still providing the easy to use, and pretty print magazine, but gaining a wider readership and use to the community by also publishing online.

Personally, I get a large amount of traffic through my articles that have been published online through Linux Journal, whereas I don’t know the amount of MacTech-inspired readers I get.

I hope more (all) magazines follow the trend of publishing their articles online.