Skip to main content

Blog archives for December 2007

Meerkat preview: Setup Assistant

Posted in

Continuing in my set of blog posts previewing my upcoming application, Meerkat, I'd like to take a moment to show off another handy feature of this SSH tunneling utility.

I often find that when I'm setting up an SSH tunnel, even though I know my way around the tool pretty well, I have to consult the man page to figure out what flags to use and which direction to setup the hosts. It can get confusing.

That's why in Meerkat, I've created a setup assistant which helps guide you through quickly setting up a tunnel. While you can use the normal interface, particularly when you're editing an existing tunnel or are very used to the process, the setup assistant walks you through the basics quickly.

Meerkat Setup Assistant thumbnail

I'm hoping that this feature will help people more easily setup SSH tunnels with Meerkat. Stay tuned for more preview details soon!

Bait and switch? No, it's called software development

Yesterday I stumbled across a month old blog post advocating a hack to the excellent Twitterrific application, a client for the free Twitter service. The hack (Update: supposedly, but the point remains) removes the rather unobtrusive ads that the software developers introduced as a way to offset free use of the application. If you didn't want to see them, you could just register the application and they go away. The app didn't start out having them, but after it took off in popularity, the authors (you know, the people who put their time into the application's development and support) decided that this was a better model.

I should take a moment to point out here that as a whole, advertising in general strikes me in a negative light, but I didn't mind the ads in Twitterrific as it was great software and a fair tradeoff for my fifteen bucks.

Anyway, this hack and its associated "arguments" interested me particularly because my application Pukka is also a lightweight client for a free online service, so I left a comment. My initial argument was:

Just like a web browser, RSS reader, email client, FTP program, Aperture, iChat, blog editor… man, the nerve of those people trying to charge for a tool for receiving and delivering content created by others!

Also, I’m a Twitterrific user and I like the ads. Eventually I may pay for the app, but for now, they’re alright.

Try writing a program for which you charge little or nothing, getting a couple thousand users, then see what you do.

Since then, the discussion has gotten rather heated, as well as ludicrous in some cases, as acknowledgement and support of both software piracy and website attacking has been discussed. Seth Dillingham, whom I first got to know (at least virtually) last summer when I supported his bike ride for charity, posted a response and a challenge to users of Twitterrific: put your money where your mouth is. So I took him up and I registered Twitterrific. Money well spent!

If for no other reason (and there are plenty of other reasons), software piracy hurts developers from the support angle. Many users running an app means more support, particularly when a chunk of them are running a cracked version that could develop unforeseen problems. Users report stability issues on the popular software sites or, in the case of larger companies, call the support lines and demand resolution to their issues. I think John Gruber said it best when he wrote about the jailbroken iPhone phenomenon:

The mindset manifests in many forms, but what it boils down to is this: a sense of entitlement that users should be able to do unsupported things and yet still be supported. That it makes no sense to expect support after taking unsupported actions is why I’ve found it baffling.

Phooey. Get your copy of Twitterrific right here. And support software developers if you enjoy their products, but don't feel that you have the right to rip them off if you don't like how they do things. In fact, grab Apple's free development tools and write your own and let's see how it stands up.

Update: Craig at Iconfactory, the author of Twitterrific, weighs in with his take on the whole matter.

And for my next app... Meerkat!

Posted in

I'm happy to announce that I'm very near the beta stages of my next application -- introducing Meerkat! In this post, I'll cover a couple of the major features of this new utility, but stay tuned for more info in future posts!

Meerkat is an SSH tunnel manager designed for the developer or systems administrator with the need for multiple tunnels and advanced, automated management.

Meerkat thumbnail

Meerkat (click for larger screenshot)

Meerkat allows you to easily set up SSH accounts and associated tunnels and activate and deactivate them via the main window, the dock, or the status bar.

Meerkat's dock menu

Meerkat dock menu

Meerkat integrates with Growl to notify you of background tunnel management.

Meerkat's Growl notifications

Meerkat Growl notification

One of Meerkat's signature features is application triggers. Meerkat can automatically bring up or tear down tunnels in response to applications that you launch and quit.

Meerkat application trigger thumbnail

Meerkat application trigger (click for larger screenshot)

On top of this, Meerkat can optionally advertise your tunnel endpoints over the LAN via Bonjour, Mac OS X's convenient networking protocol. A great, practical use of this is connecting to your home computer's iTunes collection and having it show up in your local iTunes, no matter what kind of firewall you may be behind (providing it allows SSH, a secure, encrypted protocol).

Another use for Meerkat's Bonjour feature is to securely provide access to a remote database server to a local office for development purposes. The possibilities are endless -- Leopard's Finder uses Bonjour to see VNC servers, Safari recognizes web servers on the LAN using Bonjour, and Terminal uses Bonjour to find SFTP servers. And you can define custom Bonjour protocols to meet your own needs.

Meerkat Bonjour customization

Meerkat Bonjour customization

That's all for the Meerkat preview for now! If you'd like to be considered for the Meerkat beta, just leave a comment below. (Unless you put it in the body of the comment, your email address is only viewable to me.)

Happy holidays everyone!

Pukka 1.6.6 is out!

Posted in

Just a note that Pukka 1.6.6 final is out! Grab it here. For more details on the changes involved, see the last post. This release should iron out any remaining crash problems that users have been seeing on Leopard.

Pukka beta: Leopard reliability

Posted in

I've been hard at work trying to tackle some lingering Leopard stability issues with Pukka and believe that I have a solution. I'm releasing this fix as a prerelease (i.e. not advertised in the auto-update mechanism and not posted to the download sites -- please do not post it for me!) since the problems don't affect everyone and I'd like to have some feedback from those who are affected before making this version live.

Cut to the chase: download the prerelease version 1.6.6-pre2 for Tiger or Leopard. If you have any questions or concerns with this build, please contact me here.

(You may note that I'm using the same link for both OS versions -- I'm just trying to get some rudimentary usage stats by separating out the download URLs ;-)

If you're interested in some more technical info, read on.

It seems that Leopard has some lingering crash issues when using NSURLConnection, particularly when behind a proxy and/or using HTTPS and/or using authentication. Of particular concern are the last two conditions, as all Pukka traffic through, Ma.gnolia, and most alternative sites is over HTTPS with authentication. I have rarely been able to reproduce these crashes myself (which is the main reason I did not catch them in prerelease versions of Leopard), but I have received crash logs from issues with severity ranging from occasional problems to repeated crashing, including crashing on launch. Needless to say, this has been very frustrating.

Any other Cocoa programmers who use NSURLConnection will note that it is pretty much the way to do asynchronous downloads to memory (i.e. not to a file as NSURLDownload does) while easily working with requirements such as the ability to cancel, authentication, transparent proxy support, and cache management. I've been in a bit of a bind for a workaround, but after some discussions with (extremely helpful!) fellow Mac developers such as Daniel Jalkut, Jon Wight, and Fraser Speirs, I've settled on the solution of using CURLHandle routines in a dynamically loaded bundle when on Leopard for the time being, linking them against a Leopard-targeted CURLHandle framework to bypass cross-development issues with the framework. This required a fair amount of re-architecting since CURLHandle is not intended to be a drop-in replacement for NSURLConnection (in fact, it's a subclass of the Tiger-deprecated NSURLHandle class). It's a stable and reliable fix for Leopard until this bug is resolved, if not super-ideal for me as a developer. But them's the breaks!

For the reference of the Cocoa developers reading this, you can check out some bookmarks I've gathered (and will continue to gather) about issues with NSURLConnection over the years here and I've reported the Apple Radar bug and it resolves to the original at rdar://problem/5575834.

Update: I just released 1.6.6-pre2 to fix an issue that a couple people have noticed with double encoding of text when posting. The links have been updated above.

Performance release: Pukka 1.6.5

Posted in

I've just released Pukka 1.6.5 with a slew (or, as the changelog refers to it, a metric slew) of performance updates, bug fixes, and usability improvements. You can read on for (much) more detail or just head over and get Pukka now.

The bulk of the changes deal with Spotlight performance and strain on and responding to capacity issues with the (or other service) API. Hopefully this should make Pukka perform faster, be more responsive, and be a better network citizen.

Here are the changes in depth:

  • Removed a check on the local Spotlight cache that would run 30 seconds after launch and could cause unresponsiveness in the application. The Spotlight caching mechanism has been updated to perform in a more incremental fashion to avoid the need for this.
  • Pukka now waits at least five minutes between API requests of all bookmarks, preferring requests of the latest 15 bookmarks in the meantime, to ease strain on the API and to avoid getting throttled.
  • Added CFBundleShortVersionString to app bundle, which will make Pukka's version number show up in Finder's Version column.
  • Upgraded Spotlight metadata format to store bookmark data in folders organized by username instead of one big folder. This improves performance during local cache updating.
  • Resolved a Core Data issue that may have caused a delay between when bookmarks were cached and when they appeared in the application.
  • Changed the interval used to check for bookmark updates online from one minute to three minutes. Although this was a very slight hit on the API, it was reduced in the interest of scaling back a bit because we can.
  • A Growl notification is now shown when the bookmark cache on disk is updated. This occurs whether all bookmarks were re-parsed or just the latest 15, and for each account.
  • The successful post Growl notification was updated to include the page title and the account posted to.
  • A specific error message is shown if a post fails due to API capacity issues or throttling, as opposed to a general error when posting (network, internal server error, etc.)
  • Any kind of posting error shows a panel with a "critical" alert style to indicate that data was not saved and may be lost if the application is quit.
  • Fixed two small memory leaks related to tag sorting in the bookmark menus.
  • On first run, a modal panel is shown as the bookmarks are cached for the first time. When this panel was hidden, the animation would continue. For cleanliness, this has been stopped.
  • Trivial about box updates: Two issues were tweaked with the icon animations. The randomness of the selected animation was made better and a PNG representation of the app icon is passed to the animation instead of the .icns file directly. Lessons learned from Ironcoder ;-)
  • The HTTP timeout for sending posts was reduced from the default of 60 seconds to 10 seconds to avoid making the app unusable for up to a full minute in the event that the link can't be posted.
  • A bug was fixed in the debugging console which prevented it from always scrolling all the way to the bottom on appending new content.
  • During posting problems, we now report exactly the message that was received from the API to the debugging console.

That's it! Enjoy and please contact me with any problems or questions.

MacSanta knows if you've been naughty or nice...

Posted in

...but either way, you still get the good deals! Check out MacSanta for good deals on great Mac software during the month of December. If you're looking for a couple things to keep you busy this first day of a new month (or, like me, asking yourself, "December already?"), you can check out the legend in the classic verse A Visit From MacSanta, read about last year's visit here, here, or here, promote it on your own site with these badges, Digg this year, or even check out this unrelated picture on Flickr.

Happy holidays everyone!