Red Sweater Blog Official blog of Red Sweater Software Thu, 08 Oct 2015 16:11:04 +0000 en-US hourly 1 Medium’s New API Thu, 08 Oct 2015 15:46:19 +0000 Yesterday, Medium CEO Ev Williams announced a number of new features for the publishing service, but the one that interests me the most is of course the debut of a new publishing API. The “API” for any publishing service is a sort of interface for 3rd party apps that allows the content of a blog to be read, amended and edited outside of the service’s own web interface. Without an API, a desktop editor like MarsEdit cannot connect to and edit a blog’s posts.

Support for APIs used to be very strong not only for blog publishing services, but for photo sites like Flickr, and micro-blogging sites like Twitter. That enthusiasm seems to have waned in recent years. Popular publishing services such as WordPress, Blogger, and Tumblr still support relatively robust APIs, while Squarespace completely abandoned their API, and Medium has kept us on pins and needles, until now, as to whether they would ever support one.

The new API, which is well-documented on GitHub, seems off to a good start. It’s a REST based design that shares some design similarities with Tumblr’s and Blogger’s APIs. There are also some interesting decisions that set the API apart from any others I’ve seen. Here I present my impressions based on a short tour of the API documentation, and a bit of tinkering with it at the command line.


The API supports authentication by way of the relatively standard OAuth2 web-based scheme, through which users are able to authorize a client without ever providing their password. In addition, it supports a “self-issued token” solution through which a user can obtain a token on that a client app or service can then use to directly access their Medium content. Currently, Medium is limiting access to the full OAuth based system, so anybody who wants to play around with the API will need to do so using a self-issued token.

License & Attribution

One of the most unique aspects to Medium’s API is the provision for specifying a canonical URL and license on a post being submitted to the service. The canonical URL refers to another web location that should be considered the original, or most authoritative version of a post, while the license designates whether the post’s copyright terms stipulate a post is sharable as public domain or under a particular Creative Commons license. These attributes together indicate that Medium expects and encourages users of the API to contribute content that is not intended to be exclusive to Medium.

As a blogging enthusiast, I like the presence of these attributes because it implies support for a broad range of API client uses, and also because it acknowledges the value of diversity of web content. One of the criticisms of Medium over the past couple years has been the extent to which it encourages writers to abandon their own custom domain names in favor of a proprietary based soapbox. These attributes encourage writers who favor their own canonical web sites to nonetheless engage in Medium’s network of readers, writers, and commenters.


The extent to which the API supports working with posts boils down to a single mechanism for submitting a post to the service. It’s not possible to enumerate the list of existing drafts or published posts, e.g. to crosspost to another service or backup your posts to a local archive.

Because of the REST design for the API, there is a natural improvement that would solve this problem. Currently, Medium supports POST access to add a new entry to the collection of posts:

POST /v1/users/<userID>/posts

A typical REST based API for managing assets would also support GET access to this same URL, to facilitate reading the list of existing posts.


Unfortunately, the interface also does not support amending the contents of any post that has been published. So, for example, if you’ve discovered moments after publishing that you left a nagging typo, or got a link wrong (it happens all the time), the API offers no capacity to redo the submission, replacing the contents of the post with updated values. Again, REST conventions have the roadmap for this functionality pretty clearly outlined: while a POST request is typically used to add a new post to a collection, a PUT request to a specific post’s resource URL should be interpreted as updating its content.

Markdown Support-ish

A welcome feature for Markdown fans is the option through the API to specify that the post’s content should be interpreted as either HTML or Markdown formatted text. As far as I know, Markdown is not supported in Medium’s web-based interface, so this may be the debut of “official support” for Markdown on Medium.

Unfortunately, the Markdown support through the API seems to be a one-time conversion from Markdown to HTML, at the time of submission. This means users can write in Markdown for the initial composition of a post, but any further edits (through the web interface only, see above) will need to be done using Medium’s default rich WYSIWYG editor.

A more attractive long-term solution for Markdown fans would be to support storing Markdown text literally in Medium’s database, and converting it to HTML only for presentation on the web. This leaves the pristine Markdown available for perpetual edits either moments or years after the post is first published. This would require updating the web interface to support editing content as plain text, but would be a welcome change for anybody who favors editing in Markdown.

Image Uploads

The API exposes a mechanism for uploading images, but permission to use this aspect of the API will be granted by Medium on a case-by-case basis to applications that Medium deems suitable. This means that for self-issued tokens, image uploads are not possible.

Because I’m using a self-issued token for the time being, I wasn’t able to test this aspect of the API, but it looks relatively straightforward. I appreciate that they support a variety of image formats, including animated GIF, and even TIFF. I have to wonder if at least the TIFF files will be converted to PNG or something more web-friendly.

In response to an image upload, the API vends clients a URL and MD5 hash of the image so that a client could take care to reuse an existing resource rather than upload it again. This is a nice touch, but it would be aided by also supporting a mechanism for listing all the existing images on the blog. Again, using the conventions of a REST API for collection data, a GET against the images URL could do the trick to vend a paged list of existing resources.

In any case, the support for image uploads is very welcome, especially in comparison with Tumblr’s long-standing, nonsensical omission of a similar API mechanism for arbitrary image uploads.


The API has a funny caveat about the “title” attribute supplied for a post:

Note that this title is used for SEO and when rendering the post as a listing, but will not appear in the actual post—for that it must be specified in the content field as well.

This leaves client developers is an awkward position where they will need to muck around the user’s content in order to obtain the (likely) desired outcome that a post should show its own title. When I write a new post in Medium’s web-based editor, the title I type into the Title field is respected and sticks with the post as a bona fide title. Through the API however the title must be snuck into the content of the post. It would be better, in my opinion, if the API designated a more fail-safe mechanism for ensuring that a specific title is used as a visible title heading for a post.

A Good Start

My interest in the new Medium API is obviously based in my hope to support the service from MarsEdit. The current limitations, particularly with respect to listing or existing posts, would make it difficult to support Medium at the same level of functionality as other publishing systems. I’m encouraged by the progress though, and am hopeful that in response to feedback from myself and others, they will continue to develop the API into a truly first-class experience for a wide range of 3rd party solutions.

]]> 0
OS X El Capitan Tue, 29 Sep 2015 16:44:45 +0000 Tomorrow, Apple will release the latest version of OS X: 10.11 “El Capitan.”

All Red Sweater apps have been tested against the forthcoming release, and there are no known incompatibilities.

Please let us know if you run into any problems or have specific questions about our apps.

]]> 5
Cmd-Number Shortcuts For Safari 9 Thu, 09 Jul 2015 18:49:46 +0000 If you’re a Safari user and you’ve updated to the Safari 9 or OS X 10.11 beta, you may have noticed a minor change in the default keyboard shortcuts for the app.

In Safari 8 and earlier, keyboard shortcuts combining the Command key and a number, e.g. Cmd-1, Cmd-2, Cmd-3, would open the corresponding bookmark bar item. So if you arranged your most-frequently-visited sites in the first few bookmark bar slots, you could easily jump to those pages by muscle memory thanks to these shortcuts.

In Safari 9, these shortcuts now switch to any open tabs you have in a Safari window. This will come as a surprise to folks who have gotten used to e.g. using Cmd-1 to quickly jump to e.g. Google News, or Yahoo Stocks.

The implicit shortcuts for bookmark bar items are still available, but you have to add the option key into the mix. So where you used to press Cmd-1, you must now press Cmd-Opt-1.

This may not be a big deal to you, and you may choose to simply adapt, but for those who got used to the old behavior and want to preserve a similar functionality, FastScripts can do the job of putting things back into order for you.

Safari’s scripting interface doesn’t support selecting a specific bookmark bar item by number, so FastScripts can’t exactly replicate the old behavior. What it can do though is bind (just about) any keystroke to a script that opens a specific URL in Safari. You might find after getting used to doing things “the FastScripts way” that you prefer it to the old Safari way, because you won’t be limited to using numeric shortcuts, and will instead be able to choose whatever shortcuts you like. For example, I use Ctrl-N as my shortcut to quickly jump to Google News.

Here’s a step-by-step procedure for adding shortcuts to Safari to open a specific URL:

  1. Download FastScripts. It’s free for up to 10 shortcuts.
  2. Launch FastScripts and find its icon in the upper-right corner of your Mac’s screen. It looks like this: MenuIconGray 2x
  3. Launch or activate Safari so it’s the front-most app.
  4. Click the FastScripts icon and select FastScripts -> Create Safari Scripts Folder.
  5. Download this script and copy it to the Safari scripts folder.
  6. Double-click the script to open in Script Editor.
  7. Change the URL in the script from “” to whatever URL you like, e.g. “”
  8. Save the script and rename it to e.g. “Open Google News”.
  9. Back in Safari, hold the Command down and select “Open Google News” from the FastScripts menu. This is a shortcut to quickly change a script’s keyboard shortcut.
  10. Set the desired keyboard shortcut in FastScripts’s preferences.
  11. There’s no step 11! From now on, whenever you’re in Safari and want to jump to that URL, just press the keyboard shortcut, and you’re done.

This sounds a bit more complicated to set up than it is in practice. Once you get the hang of it you’ll be able to quickly replace however many Cmd-Number shortcuts as you like in Safari, and it might even open the door to overriding behaviors of other apps. This is an area where FastScripts really shines. Enjoy!

]]> 0
MarsEdit 3.7.1: Finessing Apple Photos And Google Authentication Wed, 24 Jun 2015 18:16:18 +0000 MarsEdit 3.7.1 is available now on the MarsEdit home page, and will be submitted to the Mac App Store approval for approval by Apple.

This update addresses a couple issues that affect a minority of MarsEdit users. One fix is for Blogger users who ran into mysterious “JavaScript disabled” errors when trying to log in to their blogs. The other should eliminate a crash that could occur while loading the contents of an Apple Photos library in MarsEdit’s Media Manager.

  • Fix a crash that could occur while reloading Apple Photos Library
  • Fix a rare issue where users could encounter a “JavaScript disabled” error when trying to log in to Blogger

Let me know if you run into any trouble with the update!

]]> 0
MarsEdit 3.7: Blogger Functionality Restored Tue, 02 Jun 2015 16:51:54 +0000 I’m happy to announce that MarsEdit 3.7 is available now from the MarsEdit home page and will be submitted to the Mac App Store approval for approval by Apple. If you are an existing Mac App Store customer, you can download and use the direct-download version immediately. Just switch back to the App Store version after you notice it’s been approved.

One week ago today, MarsEdit compatibility with Blogger was broken by a change in Google’s authentication requirements. I’ve spent the past week adding the required changes to MarsEdit so that Blogger blogs can be authenticated with the most modern mechanism Google offers: their company-wide OAuth2 implementation.

The big change for Blogger users is that instead of the usual MarsEdit authentication panel, requesting your Google username and password, you will see a larger window pop up with web content served directly from Google:

Sign In

While updating MarsEdit to use the new system was not a trivial undertaking, it is a valuable change for the long term. The new authentication scheme offers two significant improvements to protect your Google account’s security:

  1. Your password will no longer be stored (or even handled) by MarsEdit. The Google web window authenticates you using your login information, and then shares with MarsEdit a unique authentication token, which is now stored securely in the OS X keychain. This token allows MarsEdit to connect to your Blogger account without prompting you again for permission.
  2. You retain the option to revoke that access at any time, without even opening MarsEdit. Although MarsEdit always stores passwords securely in the OS X keychain, this additional level of security ensures that even if somebody were able to gain access to your keychain contents, they would not obtain unfettered access to your entire Google account.

This has been a wild week, but I’m very relieved to be able to offer this update for Google Blogger users. Folks who don’t use Blogger should also update, because there are a few minor fixes that will, in particular, improve the experience of using the MarsEdit Media Manager for some workflows.

Complete list of changes in MarsEdit 3.7:

  • Restore functionality for Google’s Blogger blogs by supporting their modern authentication scheme
  • Fix handling of dates to ensure proper post scheduling in all locales/regions
  • Fix some visual flickering of the Media Manager’s album/folders lists while clicking them
  • Refinements to Apple Photos support in Media Browser
    • Prevent a crash that could occur in media manager when no Photos library was created yet
    • Fix a problem where some groups could be expanded even if there are no contents inside

Please let me know ASAP, either in the comments below or by other support channels, how the update is working out for you.

]]> 7
Preliminary MarsEdit Blogger Fix Fri, 29 May 2015 17:51:23 +0000 Since learning on Tuesday about MarsEdit’s sudden failure to connect with Blogger blogs, I have been working to restore functionality.

I’m happy to share that I’ve published a working (I hope!) beta release with preliminary support for connecting to Blogger through their newer authentication system, OAuth2. You can download a pre-release of MarsEdit with this functionality here:

Download MarsEdit 3.7b2

Be aware that when you first go to publish to your blog, upload an image, or delete a post, MarsEdit will pop up a login window for Google, right in the app. This is expected and is part of the new method for accommodating Google authentication:

Sign In

Be sure to use the Google account that is associated with your blog. After you sign in once and approve the connection, you shouldn’t need to sign in again.

There are a few rough edges in this beta release, but I want to make sure those of you who are waiting for a fix get something to try as soon as possible. Please let me know if you run into any major problems, particularly problems that prevent you from connecting to and editing your Blogger blog.

]]> 8
Blogger Connection Failures Wed, 27 May 2015 03:42:52 +0000 I am disheartened to confirm that as of today, May 26, 2015, MarsEdit will fail to connect to any blogs hosted on Google’s Blogger/Blogspot service.

MarsEdit has supported Blogger for many, many years. A side-effect of having supported it for so long is the app uses an authentication method, ClientLogin, which has been phased out over time, and is no longer supported by Google.

Although I knew that Google was encouraging developers to adopt a newer authentication method, I was not aware that the ClientLogin mechanism would be shut down this month, or even this year.

I am committed to maintaining support for Blogger in MarsEdit, but adapting to a new authentication method is a non-trivial change, and not something I can turn around immediately. I will make it a priority to update MarsEdit as soon as possible, and will post again on this blog when a beta release is ready for testing, so that Blogger users who are anxious to return to MarsEdit can give it a try.

In the mean time unfortunately I don’t know of any workaround that will allow Blogger users to continue using MarsEdit. I appreciate your patience while I work to update the app.

]]> 9
MarsEdit 3.6.9: Apple Photos Support Fri, 15 May 2015 21:37:34 +0000 MarsEdit 3.6.9 is available now from the MarsEdit home page and will be submitted to the Mac App Store approval for approval by Apple.

This update adds support for browsing images stored in Apple’s new Photos app, released with OS X 10.10.3.

Other changes include bug fixes affecting the post editor, application of the preview filter to posts on some blog systems, and an issue with pasting URLs copied from another application such as Safari.

  • Fix to include photos from Apple’s new Photos app to Media Browser
  • Fix “Apply Preview Filter Before Publishing” for Tumblr and Movable Type blogs
  • Fix a rare crash that could occur when a document window’s content changes while closing
  • Fix a problem with dragging images from Flickr or Catalog panes of Media Manager to HTML Text edit area
  • Fix an issue pasting HTML e.g. from a copied link in Safari
  • Fix a bug that prevented find/replace from working when replacement string contained a single quote (‘)


]]> 2
MarsEdit 3.6.8: Retina Image Uploads Thu, 05 Mar 2015 04:57:59 +0000 MarsEdit 3.6.8 is available now from the MarsEdit home page and the Mac App Store.

This update includes a large number of bug fixes as well as one important change in the way that MarsEdit handles the uploading of images intended to be displayed at a “Retina” compatible resolution.

One of the problems with handling Retina graphics well is that there is a huge variety of solutions in use by different web sites, depending on the priorities for bandwidth, ease of editing, backwards compatibility, etc. My expectation that MarsEdit users would want the app to support this variety has kept me thus far from releasing any solution at all to the problem. In the interim, I have been adopting the workaround myself of uploading images at twice the resolution I wanted them to display at, and hand-editing the HTML to reference them at half-size. So, if I wanted a 400x400pt screenshot on my blog, I’d upload an 800×800 image and hand-edit the HTML to look like:

<img src="..." width="400" height="400" />

As of MarsEdit 3.6.8, a checkbox when uploading or inserting an image to Treat as Retina image will enable behavior like the above, completely automatically.

That is to say, if you want a 400×400 image on your blog to look nice on Retina displays, just supply an image at least 800×800 and check the “Treat as Retina image” checkbox. MarsEdit will produce the expected HTML and upload the image at twice the width and height.

This solution will not meet everybody’s expectations for how Retina images should be handled, but it’s a good step up from what MarsEdit has offered thus far. This solution has the benefits of being both simple and backward-compatible. The main downside is that readers with standard-resolution displays are forced to download a higher resolution image than necessary. As high resolution displays become more and more popular, and bandwidth use becomes a less typically critical issue, I think the adoption of a compromise like this one will be common.

Here is a list of all the specific changes that went into this release:

  • Address issues with images being uploaded for display on Retina screens:
    • Images are now uploaded at 2x specified dimensions when Retina checkbox selected
    • Width and height fields now show size as “points” instead of “pixels”
    • Width and height fields now limited based on size of image and Retina setting
  • Rich and HTML Editor bug fixes
    • Fix a bug where pressing return in a blockquote could cause a new blockquote to be created
    • Fix a bug where smart quotes, etc. were erroneously allowed in plain HTML
    • Fix a bug that prevented images from being pasted into post editor content
  • Other media-related fixes
    • Fix a bug that caused Tumblr images to publish at constrained size even if the size is changed in Media Manager
    • Fix a bug where media style macro was not applied to re-inserted, previously uploaded images
    • Fix a bug where media style macro with prefix and suffix did not wrap the active selection
  • Other bug fixes
    • Fix a bug that prevented post documents from showing unsaved changes after changing custom field contents
    • Fix a bug in “Show Text Statistics” sample script that caused inaccurate word count to be shown
    • Fix a bug in Media Manager that failed to show the entire folder name for folders with periods (.) in their names
    • Default newly added Blogspot blogs to “Apply Preview Filter” before publishing, to ensure paragraph tags are added if needed

Let me know if you have any questions or run into any problems!

]]> 4
Clarion 2.1: Modern Times Mon, 12 Jan 2015 16:20:51 +0000 Clarion 2.1 is available now from the Clarion home page. I also intend to submit this version to the Mac App Store, for what will be Clarion’s debut on the store.

Clarion is Red Sweater’s utility for practicing the recognition of musical intervals (the distances between two pitches). It’s the oldest of my shipping apps, and over the past several years I had lost sight of how far into disrepair it had fallen. Very cool features such as its ability to customize from a variety of built-in synthesizer sounds were no longer functioning. I’ve brought that back in Clarion 2.1:

Screenshot of the Clarion musical instrument chooser.

Additionally, Clarion had not seen any updates since the advent of Apple’s high-resolution “Retina” displays. I’ve updated the graphics in Clarion’s main quiz window to look sharp on these screens:

Screen shot of Clarion's main window.

The playful VU-meter-styled gauge in the middle of the screen reflects your overall accuracy for a given quiz session. Up until now, the “needle” just jumped to its new location whenever you made a guess, but starting with 2.1, the needle animates smoothly to the new location, making a further approximation of its real-world equivalent.

Complete list of changes in 2.1:

  • Screen graphics optimized for Macs with “Retina” displays
  • Slight update to UI incorporates always-on piano keyboard in main window
  • Fix a bug that caused many instrument names to be listed as “Unknown Category”
  • Now recovers gracefully from bad synth settings that could be set in previous versions
  • Fix a bug that prevented changing Apple Synthesizer settings on recent OS X versions
  • Now supports automatic checking for future software updates

If you want to develop your ear for musical intervals, give Clarion a try!

]]> 0