Google burns Campfire

In case you missed it, earlier this week Google created a big stir by announcing a new application called HuddleChat during one of their campfire sessions. It was intended as a working demo for their new App Engine service, but it quickly created an uproar from many in the development community who felt that Google developers had blatantly ripped off another application. As irony would have it, that application’s name happened to be Campfire, and it was created by some company called 37Signals (never heard of them, but apparently they’re big in the mining transportation industry). Anyhow, sensitive to the bad PR they were suddenly generating, Google quickly yanked the cord on HuddleChat.

That should have been the end of the story, but it wasn’t.

As soon as HuddleChat was shut down, a second uproar arose from users who insisted that HuddleChat was killed unfairly. Much of their anger was directed at 37Signals. With straight, albeit apoplectic, faces they argued that 37Signals somehow twisted Google’s arm, forcing them to kill HuddleChat in order to quell competition. The punchline is that 37Signals, this company that reportedly goes around bullying online behemoths only has 10 employees.

So in the span of a few days, two actions by Google created two angry groups who were angry for two different reasons: (1) developers angry at Google for creating HuddleChat, and (2) potential HuddleChat users angry at the first group for killing HuddleChat. To keep this simple, let’s come up with labels for these two groups. We’ll call the first group “the brewmasters” and second group “the freeloaders.”

Freeloaders

I’m not going to convince the freeloaders they’re wrong because they’re unlikely to listen to me, and not just because I’m calling them freeloaders. They cite idealistic principles like competition and unfair power wielded by The Man (apparently implying that DHH is, in fact, the man), but if you sift through their rants, it becomes clear that basically they’re just mad that someone took away their keg. You see, 37Signals actually charges money for Campfire, while Google was providing HuddleChat for free.

When HuddleChat was announced, the freeloaders came running (”Free beer!”). Unfortunately, the brewmasters who showed up recognized that Google was in fact giving away someone else’s beer for free, which just didn’t seem right. When the grown ups at Google learned this, they agreed and quickly pulled the tap. The brewmasters applauded the move, while the freeloaders cried party foul and started protesting. Of course, the freeloaders had done nothing special to earn free beer, let alone someone else’s beer, but to the adolescent mind offering something for free and not following through is akin to stealing something that already belonged to them. The freeloaders posted angry blog comments, insisting that they were important decision makers who would drive business away from 37Signals in retaliation, and to demonstrate this they went and created an online petition… via a facebook group. (Awww, how cute.)

So that’s the context. Next post I’ll elaborate on the value of design by extending this gratuitous beer analogy to brewmasters and brewers.

Antidote:

#!/usr/bin/ruby

require "hpricot"
require "open-uri"

def growl ( title, message )
    system "growlnotify", "-m", message, "-t", title
end

while (1)
    begin
        doc = Hpricot( open("http://www.woot.com/") )
        item = (doc/"h3#ctl00_ContentPlaceHolder_TitleHeader").text
        raise "Failed to parse title" if item == ""

        if not item =~ /Decker/
            growl "Woot!", item
            system "open -g http://www.woot.com/"
            break
        end
        sleep 30
    rescue
        growl "Ruby Error!", $!
    end
end

When I started this blog, I planned to primarily explore areas like bioinformatics where medicine and technology come together. However, over the past year my interests in programming and medicine have remained on distinctly parallel paths. They just have not come together.

Currently I am hard at work on a Mac app that should be out this summer (WWDC with any luck) and have had lots of ideas for strictly Mac programming posts. So for the near future this blog will primarily focus on Mac application coding.

If you aren’t familiar with them, DoubleClick is in the business of selling banner ads — those flashing, annoying advertisements that sit above, beside, and even above those web pages you visit. That, in and of itself, is not why I dislike them — in fact, thanks to Privoxy, I almost never see their ads. But I’ve been doing the web thing long enough to recall back in 2000 when DoubleClick announced an frighteningly Orwellian scheme to identify every single web user and track the pages they visit.

After DoubleClick’s announcement there was an uproar. Numerous organizations including EPIC and the ACLU filed petitions with the FTC, which launched a 10 month investigation. Eventually DoubleClick backed off of its position and the investigation was dropped.

Fast forward several years and the poster child of online privacy invasion is getting hitched to the poster child of online corporate responsibility. I suppose we could interpret this in a positive way and hope that Google’s values infect those of the DoubleClick unit more than the other way around. But I can help but feel a bit nervous.

The author of mogenerator is working on better Xcode integration for a future release, but I figured it was likely that I would still want to invoke mogenerator manually before compile time, if only to get the full advantages of code completion when I add new properties. My goal was to create something that would eliminate having to write any project specific commands or configuration. I wanted a single menu/key command that would run mogenerator against the data models in my current project.

Via AppleScript I found I could easily determine which project was open in Xcode, along with its path. The dictionary also said I could get the project’s data models — but didn’t work that reliably. Fortunately, the project path was enough, because it only requires a couple simple Unix commands to find all the data model files in the folder and run mogenerator against them.

The next step was to read through Using Scripts To Customize Xcode. I won’t go through the details, but ultimately I ended up with a menu item stuck right onto the end of the Design menu that let me run mogenerator. Cool, huh?

Except it didn’t work — you’ll notice that it’s inactive in the screenshot. That’s because, so far as I can tell, Xcode assumes that all custom scripts modify source code, so they’re only active when a source file is open — and the data modeler doesn’t count. When I first installed the script, it worked so long as I clicked on an *.h or *.m document before invoking it, but I recently decided to experiment with using TextMate as my primary editor, so now I never have a source file active in Xcode.

So I had to find a plan B. I turned to the system script menu — the one that lives as a status menu on the right side of your toolbar, which you activate via the AppleScript Utility. Installing the script there works pretty well, except that I haven’t been able to figure out how to assign it a keyboard shortcut.

In any case now I can easily run mogenerator against all the data models in any open Xcode project. No trips to the Terminal nor project specific configuration needed. Here’s the script.

Run mogenerator.scpt

(*
 * ----------------------------------------------------------------------------------------------
 * Run mogenerator script
 * Processes all .xcdatamodel files in whatever Xcode project is active
 *
 * by Scott Guelich 12-27-2006
 *
 * INSTALLATION:
 * Drag this script to ~/Library/Scripts/Applications/Xcode
 *
 * Note: The script will appear in the system-wide Script Menu,
 * which is different than the script menu that appears left of Help in Xcode.
 * If you don't see another Script Menu, Run the AppleScript Utility and
 * check "Show Script Menu in menu bar".
 *
 * mogenerator was created by Jonathan "Wolf" Rentzsch
 * and is available at http://rentzsch.com/code/mogenerator
 * ----------------------------------------------------------------------------------------------
 *)

-- Override these properties as needed on your system
property mogeneratorPath : "/usr/local/bin/mogenerator"
property showConfirmation : true

-- ----------------------------------------------------------------------------------------------

tell application "Xcode"
	set mogeneratorPathCheck to ""
	activate
	try
		set mogeneratorPathCheck to do shell script "
			if [[ -e \"" & mogeneratorPath & "\" ]]; then
				echo \"" & mogeneratorPath & "\";
			else
				echo `which mogenerator`;
			fi
		"
		if mogeneratorPathCheck starts with "no mogenerator" then
			display dialog "Could not find mogenerator script on your system. " & ¬
				"Please edit this script and set the mogeneratorPath property" ¬
				buttons {"Cancel"} default button "Cancel" with icon 1
		end if
		set mogeneratorPath to mogeneratorPathCheck

		set projectPath to the POSIX path of ¬
			(the project directory of the active project document as text)

		set output to do shell script "
			cd \"" & projectPath & "\";
			find . -name '*.xcdatamodel' -print | sed 's/^../  /';
		"
		if output = "" then
			display dialog "Could not find any xcdatamodel files in your current project. " & ¬
				"Is the right project active in Xcode? Also, note this script doesn't support " & ¬
				"referenced files that don't live in your project folder." ¬
				buttons {"Cancel"} default button "Cancel" with icon 1
		else if showConfirmation then
			display dialog "Run mogenerator against the following files?\\n" & output with icon 1
		end if
		set output to do shell script "
			cd \"" & projectPath & "\";
			find . -name '*.xcdatamodel' -print0 | xargs -0 \"" & mogeneratorPath & "\" -model
		"
		if output ≠ "" then
			display dialog "Unexpected error invoking mogenerator:" & output ¬
				buttons {"Cancel"} default button "Cancel" with icon 1
		end if
	on error number errorNumber
		if errorNumber is equal to -128 then -- user cancelled, do nothing
		else if errorNumber is equal to -1728 then -- can't get POSIX path to Xcode project
			display dialog "Unable to get the current project's path in Xcode. " & ¬
				"Are you sure you have a project open?" ¬
				buttons {"Cancel"} default button "Cancel" with icon 1
		else
			display dialog "Unknown error running mogenerator: " & errorNumber ¬
				buttons {"Cancel"} default button "Cancel" with icon 1
		end if
	end try
end tell

Update: You can also download the code for the original non-working solution (actually, it might work well enough if you use Xcode as your primary editor). To me it seems like a bug that the menu item for an Xcode user script which specifies that it doesn’t receive text input (via PBXInput=None) becomes inactive unless a text document is open. I filed it as rdar://problem/4905038 (rdar:// urls).

It’ll be interesting to see what this blog will look like and who the audience will be, if any. I don’t know that there are a lot of people out there with interests in both technology and medicine, and whether readers with expertise in one will mind sifting through posts about the other. Of course, there is a whole field of inquiry into bioinformatics, so maybe the combined interest is larger than I realize.

I already have a few programming posts in mind, which should be up shortly. I’ll also have lots to say about med school, but we’re still on holiday break and I’m enjoying the vacation.