Safe from the Losing Fight

Beta Testers for RSS Reader

Andy — Wed, 08 May 2013 17:56:24 -0700

I’m looking for beta testers for my RSS news reader. Right now the only client is a web app (mobile and retina ready) so that’s what you would be testing. If you are interested, email me: andy at fortunatebear dot com.

Bug fixes to VectorBoolean

Andy — Sun, 05 May 2013 20:02:41 -0700

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.

Just Say No to Hate, or at least the Google Reader API

Andy — Thu, 14 Mar 2013 15:00:44 -0700

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:

free
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.

Out with Wordpress in with Postword

Andy — Sat, 26 May 2012 16:09:02 -0700

At the risk of becoming part of something trendy (which my nerd contract expressly prohibits), I’ve finally ditched Wordpress in favor of static solution. Unlike everyone else though I’m not ditching it for performance reasons, because honestly, I don’t get enough traffic to bring down London bridge, which, according to a song I once heard is constantly falling down.

No, what prompted this change was my Wordpress install getting hacked for a third time (to inject spam links, of course). It’s not entirely Wordpress’s fault; each time my version was out of date, despite Wordpress making updating to the latest version super easy. Unfortunately I don’t go the Wordpress admin panel every day to check for updates, so I’m routinely out of date.

All of which to say, I needed something other than Wordpress to get around my update delinquency. Specifically here’s what I wanted:

Little to no code running on the server, with a strong preference for none. No database, either.
It should generate a static site, from flat text files.
It should be able to import all my Wordpress entries
Support the Wordpress site/link structure so that it wouldn’t break existing links into the site.

And a couple of nice to haves:

Support some version of Wordpress themes, or at least make it easy to port them.
Work with MarsEdit

In other words, I wanted Wordpress without the Wordpress.

There were a couple of solutions that got close, but none that did all that I wanted. So, being an engineer, I decided to write my own, which I codenamed Postword. I actually started the project back the last time I got hacked, and even used an early prototype for the blog on Hearts & Tactics.

Postword is more or less a collection of Ruby scripts. It has one to take a Wordpress XML file and convert it into a bunch of flat files (one for each post) that can be processed later by the build script. The flat files are nothing special; they have mail like headers for the categories and title, and then body which is just text with some HTML markup allowed. The build script takes these flat files and builds a full site that looks like Wordpress site structure wise. The script is unique in that it supports the idea of themes, whose API just happens to be the exact subset of Wordpress APIs that my custom Wordpress theme happens to use.

And that’s all Postword was up until a couple of days ago. But if was going to use Postword on this site, which I update somewhat frequently, I needed to reduce the friction. The first thing to do was to write a publish script that pushed the local static site to my server via FTP. I wrote my own script in Ruby, which actually turned out to be not that bad, since I could make a lot of assumptions. The important one was that the local site was always the truth. Which meant if the local and remote ever differed, the local overwrites the remote, and if the remote had a file which the local didn’t the remote gets deleted. In effect, the site becomes self-healing.

The last piece of the puzzle was create a local server that MarsEdit could talk to. MarsEdit supports a lot of different APIs, so I had to decide which one to implement. Wordpress was an obvious choice, but it offered a lot of functionality to I didn’t have or want, plus it was more complex than the others. I decided on MetaWeblog, with the Blogger API as a fall back for when MarsEdit tried to delete a post. It was surprisingly easy to implement, since almost all of the functionality was already in the other scripts, and Ruby provides an XMLRPC server out of the box.

The really nice part of all this is I now have the entire source to this site (flat post files + images + build scripts) in one Mercurial repository. I can download that and publish from any machine, as well as have instant back ups.

Not to say Postword isn’t without its flaws. The build script is slow; it takes a little while to generate all those archive pages that Wordpress creates on the fly. And if the build script is slow the publish script is glacial. When posting from MarsEdit, I can’t actually call the publish function after building the site, because MarsEdit will time out on the HTTP connection. That said, the pros easily outweigh the cons for me.

All in all, I’m tickled pink about how Postword turned out.

Announcing Skyscraper

Andy — Mon, 21 May 2012 13:37:25 -0700

I’m happy to announce that I’ve acquired Pandora from Positive Spin Media, and renamed it Skyscraper in order to reduce confusion with the music service. Skyscraper is a web scraper specializing in finding and downloading images. It can take advantage of Google Image Search to do keyword searches or simply scrape images (or other kinds of files) from a URL that you give to it. It automatically downloads the images into folders and allows you to perform some simple management. It also has a built-in slide show.

Skyscraper has a free limited trial, so there’s no reason not to give it a try. Skyscraper is free for existing Pandora customers, otherwise $29.99 for new customers.

You can read more about the acquisition in the press release.

Testing Pagesmith Footnotes

Andy — Thu, 17 May 2012 17:06:04 -0700

I have footnotes working in Pagesmith and polished enough that I can show it to other people. I need some help find bugs in the edge cases, so if you’d like to give footnotes a spin before everyone else, shoot me an email: andy at fortunatebear.

Illuminate 1.2 Overhauls the Window Switching UI

Andy — Wed, 09 May 2012 10:15:52 -0700

Illuminate 1.2 is out with major changes to how the cycle windows feature works. Since cycle windows is the main feature in Illuminate, I made an effort to streamline it and make it usable in fewer keystrokes. The most noticeable change is that Cycle (All) Windows and Cycle (All) Tabs have been consolidated into one feature: Cycle Windows. Cycle Windows cycles through all the windows and tabs using just one keyboard shortcut (Option-Tab), plus they’re now grouped by application, making application switching more obvious.

In order to speed up switching between windows, sticky mode has be turned off by default so the window selection happens as soon as you let up on the modifier keys. Also, there is now a configurable delay between when the keyboard shortcut is pressed and the UI shows up. This means you can quickly switch between windows or tabs without the UI flashing up or otherwise having to wait on it.

The 1.2 includes some other features and bug fixes:

Support for Google Chrome tabs
Ability to exclude certain applications from the window switching list.
You can now change the order windows appear in when switching windows: last time accessed or alphabetical.
Improved layout in the cycle windows UI so more space is used by the window thumbnails.
Fix for a crashing bug.

The update is free for existing customers, $9.99 for new customers, and is available from Fortunate Bear’s online store or Apple’s Mac App Store.

You can read the full press release here.

Log Leech 1.5 updates Mac version, introduces iOS version

Andy — Tue, 03 Apr 2012 13:11:50 -0700

A new version of Log Leech is out today. It updates the Mac version by doing some UI clean up, improving HTML export, adding a log entry detail view, and improving performance and stability. In addition, version 1.5 introduces a universal iOS version of the app. The iOS version is quite similar to the Mac version; the main difference is instead of providing an export function, it allows you to email the logs to the address of your choice.

The 1.5 release for Mac is free for existing customers, and $9.99 for new customers. It can be found either in Fortunate Bear’s online store or Apple’s Mac App Store. The iOS version is $4.99, and can be found in the App Store.

See the press release for more information.

Big Bag of App Store Bugs

Andy — Tue, 27 Mar 2012 16:19:24 -0700

I’ve been meaning to write about some of the major problems that I have with the App Store, both the Mac and iOS varieties. But honestly, I don’t have a whole lot to add to what Wil Shipley and Craig Hockenberry have already said. Instead, I’ll link to the bugs I’ve written up, and encourage you to do the same.

The App Stores need to support upgrade pricing. rdar://11131356 or Open Radar
The App Stores need to support free trials. rdar://11133210 or Open Radar
The App Stores need to support tracking statistics. rdar://11133330 or Open Radar
The App Stores need better discoverability of apps. rdar://11133573 or Open Radar

I know there’s been a lot of pessimism about writing up Radars lately, including from yours truly. But the truth is filing bugs is the only official way Apple will listen, so the pragmatic side of me wins out. It’s not that I necessarily think filing bugs will cause a change, but it’s the only possible way of affecting changing that’s been given to me.

Fortunate Bear Acquires Pagehand, renames it Pagesmith

Andy — Tue, 27 Mar 2012 11:15:07 -0700

If you follow me on Twitter, then you know that I’ve acquired Pagehand from Ross Carter (a.k.a. Pagehand.com), and renamed it Pagesmith. Pagesmith is a unique word processor that focuses on writing and typography. You can check out the product page here for more details.

I’m particularly excited about this acquisition because Pagesmith is the first really “deep” app that I have. I can’t wait to spend some quality time with it, growing it into something even better. In addition, I really love the direction Ross started Pagesmith off in: a focus on creating beautiful documents through typography and an innovative, clutter free UI.

Anyway, you can read more about the transition in the press release. And don’t forget to give the free 30-day trial a go.