Coach Thrasher

jipCam for sale?

I was asked a very interesting question this week about jipCam that totally caught me off guard: Why did you give this away by open sourcing it?

The answer is that it wasn't thought to be the core competency of the company that created it. It wasn't the technology that we were driving for. jipCam was just code-roadkill on the way to delivering video search. So, with limited value to the company, and the potential to get many more people involved in testing it, it was released to the community. But today I met the CEO of a very interesting media company (actually I met several), and while reminiscing about the internet in the late 1990's remembered what a success Hotmail was and how it came about.

Hotmail was an artifact of a non-email related project. It was being used to communicate with people in an email-ish way. After all, who would use web based email when you had Eudora or Outlook? Then some investors viewed a presentation by it's creators in which Hotmail was just a "gee-whiz", and the investors lit up when the saw this little web-based email feature.

I wonder how many road-kill artifacts are created to solve larger rocket-science problems that, taken alone, are sufficiently valuable themselves to release as products? It must be a huge number.

Posted at 11:00PM Aug 18, 2007 by jason in General  | 

BarCamp Wikiality

At BarCampBase now... I'm noting on the Wikiality session. This is the first time I've been exposed to the business argument for wikis... conveniently thought through by Social Text and presented by Ross Mayfield. I had a good idea about this previously but Ross' arguments blow me away.

I'm having a Web 2.0 Moment (tm): I'm wikiing the session for the group, blogging, and SMS texting people in other sessions. Cool, but when will this make me money?

Hum... just added the word "refactoring" to my MS Word dictionary.

Update: Here are my wiki notes from Ross Mayfield's session.

Posted at 11:53AM Aug 18, 2007 by jason in General  | 

BarCampBlock

What do people in the tech republic do to party? Apparently they attend BarCampBlock. It's tomorrow, and it should be interesting...

Posted at 10:06PM Aug 17, 2007 by jason in General  | 

YAY, I Fixed my Facebook API :)

Like everyone and their little brother, I've been working on a killer Facebook app. The platform offers so much potential for revenue generation; I just can't pass the opportunity up. I found quite a few architecture issues with the Java Facebook API that Facebook released. It worked, but it wasn't enterprise ready... in particular there were no JUnit tests, no logging, HTTP connection memory leaks, it’s not thread safe, etc. It works for "Hello World", but not my app.

The Javabook API looks cool, but I needed desktop support. I also didn't want to use JSON since FQL returns buggy (ambiguous) results that way for queries (see the Facebook docs, I do like the name though, “JSON” == great name :).

Aside: what’s the business goal of releasing a 3rd party Facebook API? I don’t think the answer is anything close to the logic that created Apache.

So, I've finally fixed my API bug. I don't mean to beat-up on Facebook (because their site, app, business, and developers absolutely rock), but the issue was related to their API documentation. The references to "session", "session key", "session secret" and "secret" for desktop apps versus webapps are ambiguous in their API docs. They are used on different pages in different context to mean similar and different things, depending on the page. Ack! Good documentation is critically important for communicating with others, and this issue just highlighed that for me.

I posted a Mavenized Facebook api (the Facebook original code plus a few JUnit tests plus Maven wrapping) a few days ago. It's been interesting to see how many downloads per day there are... not many == ~4. But heck, there are downloads! So there must be demand for something like this.

If anyone is interested in a more robust API for desktop and webapps, using HttpClient with logging, and per-UserId sessions, thread safety, local callback support, and Maven let me know. It supports all Facebook API calls, including FQL. The code is fully documented with Javadoc. It'll do XML and JSON. It supports Spring-based configuration out of the box. It has a Facebook data model, with MVC style stateless API calls. It'll put your API key and secret through their paces for all API calls using JUnit. It's so good, it'll get you a beer when asked. I’ve got it humming right here and would be happy to license it out.

Posted at 11:14PM Aug 07, 2007 by jason in Software  |  Comments[1]

It Feels Like Everyone's Making Facebook Apps... But Me.

I'm totally sick of API's right now. Especially buggy ones. That is to say (tounge in cheek), especially ones that I didn't write (ha!).

I've been working an a Facebook app ties a bunch of disparate services together, that you wouldn't normally put together, and each service has an API. But, they don't play well at all. They are either stateful, stateless, are based on a web service, or Windows COM, and it's just spinning my head to glue them together.

Ack! It's time to step away from the computer for a while.

Posted at 08:36PM Aug 05, 2007 by jason in Software  |