Safe from the Losing Fight

I regretfully announce that most of Fortunate Bear’s products have been discontinued and support ended effective immediately. Specifically the products terminated are Illuminate, Skyscraper, Pagesmith, and Log Leech. When I acquired these products I had big plans for all of them, which suffice to say didn’t work out. I will spare you the details, but in broad strokes I was unable to make them financially viable.

My company, Fortunate Bear, has now switched to being primarily focused on providing software development services for Mac and iOS.

However, two products did survive the layoff: Black Maria and Newsline Pro. They did so because I still use them daily. Although I plan to improve them, I consider them side projects and will prioritize them accordingly.

I would like thank the customers of Illuminate, Skyscraper, Pagesmith, and Log Leech for their support. I am sorry that things didn’t work out better.

If you’ve followed this blog for any time you’re probably aware of my series of articles on how to implement boolean operations for vector graphics. As part of that series I created some sample code called VectorBoolean to demonstrate the principles.

If you used the sample code in one of your projects, you may have noticed it had several bugs of varying severity. Fortunately, I recently spent some time fixing many bugs, and adding enhancements to deal with some of the more complicated scenarios. You can find the most recent version in the BitBucket repo.

These fixes were possible due to the gracious funding of Mapdiva, makers of Artboard, which incidentally is using this new version of VectorBoolean. You might also recognize them as being the creators of DrawKit.

If you would like to use VectorBoolean but need some bug fixes or enhancements, I am willing to do them for a reasonable fee. If interested, email me at fortunatebear.com, with my first name as username. I don’t have immediate availability, and there’s already a queue, so please keep that in mind.

Ever since Google announced that Reader was going away, there’s been a lot of speculation and commentary on what the next RSS Sync API should be like. Several people have suggested the best thing to do would be to implement the Google Reader API on top of another server, since it’s already in wide use. I think this is a fantastic idea, assuming you’re never going to write a RSS client or server ever again, or if you’re some sort of RSS Hitler or something.

The Reader API is only used because its is:

1. free
2. from Google

but mostly because of #1. It is not some sort of fantastic API. It was written by engineers whom, I assume, took massive bribes from the Atom Format Worldwide Dominance Consortium, Cabal, and Trade Expo. So existing clients aren’t using it because of its ease of use.

My secret project for the past few months has been writing an RSS server and client. The API has gone through some major revisions, and I’ve learned some valuable lessons through this exercise.

First, making an HTTP request in any modern programming environment is trivial. Also, parsing the JSON or XML response is likewise easy. The difficult part of writing a client is processing the results of an API call, and matching it up to the internal data model. If the server can segment up data such that it matches up with the client’s data model, that becomes a huge win for the client. Likewise, having a single server call that can return all of the data needed to fill one screen on the client can make things massively more efficient.

The wrinkle here is that different clients will have different needs. A web app won’t have much local storage available to it. A desktop app might want to fetch the feeds itself, but have the server manage syncing of the subscription and read status. The second big lesson I learned is trying to write exactly one API to fit all clients is impossible or at least horrendously inefficient. Which is why the Google Reader API probably sucks for everyone but Reader.

In the end, the user doesn’t care about the what API or APIs are used by the client. They just want all their clients to sync to the same server, but the method to do so is immaterial to them. Clients will want an API that is easy to use and efficient for their data model. Therefore, I’m suggesting that its not only OK, but beneficial for everyone, for a server to have multiple APIs, each tuned for various clients.

Let us throw off the tyranny of the Google Reader API! ¡Viva la Revolución!

Or whatever.