I use Evernote in lieu of in-browser bookmarks. (You can read more about this project and how it works for me here.) I have two scripts I use to make this a little easier on me:

Append source HTML to selected notes: This takes selected notes with an associated URL and attaches the content of the URL’s page to the respective notes. If you change the “useIP” property to true, it will also trim down the source with the Instapaper service, thus eliminating ads, navigation, and comments before importing the HTML. I used this originally when I imported by Pinboard bookmarks into Evernote, but occasionally use it with other notes that I’ve just added my own comments to, so as to make them “full text searchable.”

Export Notes as HTML Bookmarks: This script takes every URL stored in Evernote and exports it into a simple HTML file that contains nothing more than a series of links, labeled with the title of the associated notes. I use [LaunchBar] to index this file (added it to LB’s index as a custom web bookmarks file), making it easy for me to quickly open bookmarks without even having to open Evernote. Use your favorite scheduling utility to make this happen on a regular basis. (I use Keyboard Maestro

Normally, AppleScript absolutely mangles rich text once it comes in to the system. I have recently discovered a workaround for this, which is the “pbcopy” terminal command. Anything piped to this command will be copied to the clipboard. Normally, this is done only as plain text, but if the incoming data is rich text (has an RTF header), it will come in as rich text. The second part of this is the use of the “textutil” command, which can take text of various formats and output them in, among other formats, rich text. Now, even if you’re limited to only plain text (as in AppleScript), textutil will happily accept HTML, so if you can generate formatted HTML, you can pipe it through textutil and end up with lovely rich text in your clipboard, and it even retains links!

So from the shell, your command is something like:

% echo [html text] | textutil -stdin -stdout -format html -convert rtf | pbcopy

Just make sure that your HTML text is properly escaped.

If you want to do this from AppleScript, you can simply encapsulate the whole thing in a “do shell script” command.

BONUS: You can also put Markdown or MultiMarkdown in the mix to take Markdown-formatted content and convert it to rich text on the clipboard. The following is an example of how this would work with MultiMarkdown:

% echo [markdown text] | mmd | textutil -stdin -stdout -format html -convert rtf | pbcopy

This AppleScript creates new files in the currently Finder folder, based on file templates you create. These templates are just documents of any sort that you put into the “New File Templates” folder in your documents folder. (This folder name can be edited as a script property.) This is basically equivalent to the “New…” contextual menu item in Windows.

I’ve gotten in the habit of attach meeting notes and brainstorming documents to my Evernote notebooks. They’re editable from the notebook and sync to all my computers and my phone, which is incredibly handy. One limitation that I’ve found is that it’s impossible to create a brand new document within Evernote… until now!

This AppleScript creates new files in the currently selected/viewed note, based on file templates you create. These templates are just documents of any sort that you put into the “New File Templates” folder in your documents folder. (This folder name can be edited as a script property.) When you run the script, it will let you select from those templates, set your file name, and then you’ll have a new file right there in your note! Easy peasy!

Note that you may want a premium Evernote account in order to handle the upload size of adding lots of files.

I recently discovered a great little service, ifttt. The name is a cute abbreviation of “If This Then That,” which is exactly what it does.

The service works on a simple macro-like structure where you add a triggering event (If This) and then a task to do (Then That). Triggers and tasks are both hooked into a wide variety of web services, including social networks, Evernote, DropBox, and more. I’ve already set up a handful of workflows, some of which archive my social networking posts in Evernote (since the social networks themselves aren’t all that searchable), and one that lets me phone in new tasks to OmniFocus.

Very cool service, currently free, and the potential uses of it are infinite. Definitely worth checking out!

Had to update a set of Facebook applications for WCM. (Yup, still freelancing a little for them.) This is the third time these applications have needed a major upgrade to meet Facebook’s ever-changing API – once to migrate from FBML to FBJS, and again to move to Oauth, and no again to meet Oauth 2.0 as iFrame tabs and apps.

Facebook, being the 800 pound gorilla, can do whatever it wants, and the developers who have invested so much in the platform will, ultimately, get in line or just fail entirely. But this really hurts the small developers with modest projects, especially as some of the standby Facebook apps like Static FBML die out and paid services start charging “enterprise” prices.

To Facebook’s credit, they’ve put effort into sunsetting APIs cleanly, with advance warning (sometimes as little as 4 weeks, but usually quite a bit better) and even letting old APIs continue to work… for a while. But they haven’t handled QA at all well, which is exactly where this problem hit.

In the case of this client of WCM, they have a handful of custom, fan-gated tabs, as well as a full blown contest application, which was custom designed to meet their jurisdiction’s gaming regulations. (Otherwise, they could probably get away with any of the other contest apps out there.) When Oauth 2.0 was introduced, Facebook accidentally introduced a boatload of bugs into the supposedly still-supported legacy authorization API, which meant that in the middle of a major promotion, the contest stopped working entirely. This led to a crunch day of moving to the new APIs, which were still buggy as heck and not nearly as feature-rich as the old APIs.

Due to these holes in the API, a great deal of the work had to be custom built using curl commands and manual decoding of returned data, and other nonsense that really shouldn’t have been necessary since Facebook’s published PHP library ought to handle that sort of thing. Luckily, the tab-based apps weren’t affected (they didn’t need to authorize visitors); and since the new API, inexplicably, couldn’t handle fan-gating, they weren’t transitioned.

So now Facebook has killed support for the old API entirely, and requires tabs to move to iFrames (just like applications always have). Because of this, the fan-gating on the tabs (remember, they COULDN’T transition to the new API when it was first released!) broke, and again, WCM was in a crunch with the client since they were in the middle of a major Facebook promotion.

This much is good: The new API, iFrame tabs, and Oauth 2.0, now that they’re mature, are a lot easier to code for than the old system, so the old apps were fairly easy to set up, even though one of them (due to its reliance on non-iFrame-compatible FacebookJS) had to be entirely re-written from the ground up. Everything was no longer on fire within 3 or 4 hours. But there are, of course, lingering bugs due to the major changes in how an iFrame app needs to be managed, which present a substantial challenge to fix, since Facebook’s documentation in regard to these little bugs is limited to the old API – entirely useless.

Okay, enough of my bitching. The end result here is that in order to be a Facebook developer, you need to be on the cutting edge of their API at all times, but only RELEASE when Facebook gets around to making the new API stable and complete, which sometimes doesn’t happen until after they’ve broken your app. Meantime, you’re praying that your clients don’t get stuck with something that just plain doesn’t work because Facebook accidentally introduces bugs/improvements into their legacy API.

As Facebook looks to extend the Facebook platform outside of Facebook, this becomes untenable. If I’m relying on Facebook for users to register for my site, it simply has to work 100% of the time. I cannot be required to update substantial portions of my applications and websites multiple times each year. Doing so doesn’t make me any money, so unless I’m Wildfire or another company that can spread that cost over a large number of clients, it ends up being a drag on resources and revenue. This, of course, is why Buddy Media and the rest can start jacking up their prices from hundreds of dollars each month to thousands, leaving smaller companies to use the low cost tools which end up falling behind the API… same problems. (Ironically, even Facebook’s cut-and-paste social plugins have fallen behind the API and required instant upgrades to new code.)

So what am I doing? Well, nothing at all that’s mission-critical is ever going to be integrated with Facebook. I know there are benefits in hooking these things up, but I can’t afford maintaining these things or losing functionality because I overlooked a blog post. For clients, it’s going to have to be a program built by one of the major Facebook app companies, and they’ll have to cover the cost.

It’s a shame, too. My clients have seen awesome results using some clever custom applications, but if I can’t guarantee a modicum of reliability and uptime, the hit on my reputation will far outweigh a handful of successful campaigns.

I just updated my site’s theme… again. Still orange, still looks like someone other than a designer (that’s me!) built it, but it’s a little better. If nothing else, I’ve jumped onboard the “Responsive Web Design” bandwagon, so this site looks pretty (if not “purty”) in mobile browsers. A good learning experience to set that up.

Hopefully I can rope a designer friend into building me a proper theme, but until then, this one will be in a perpetual Beta state, along with the rest of this site.

This script exports your TextExpander snippets as “.kmmacros” files, suitable for import into Keyboard Maestro 5 as typed key macros. Due to differences between the two applications, this is not a perfect conversion, so snippets that are likely to need additional work are marked with an asterisk after import.

This script uses BBEdit as an intermediary to build the files, but could fairly easily be altered to work with another text editor.

This handy little applet generates a pretty sitemap in OmniGraffle based on a standard XML sitemap file. This is extremely useful for web developers and designers who need a comprehensive diagram of an existing website’s layout. The graphical sitemap also contains hyperlinks and fully searchable text of each page it maps.

There’s plenty of password generators out there, but how many of them generate passwords that are both secure as well as convenient?

This script creates just such passwords.

Convenience: The passwords this script generates can by typed with just one hand on the keyboard, and can also be entered into an iPhone without going back and forth between letters and numbers and symbols and capital letters. The passwords also use normal dictionary words that are easy to remember.

Secure: Every password is at least 12 characters long and contains a combination of letters, numbers, symbols, upper case and lower case letters.

Are you sure that’s secure?

Okay, sure, a totally random string of letters and numbers and whatnot would be more secure than any password that uses dictionary words. However, by using two words, as well as numbers and symbols, these passwords meet a nice balance between convenience and security. It’s a lot easier for me to remember “fate64$!SWAGER” than “}Uc^nGRJ3X3F”, and of course it’s easier to type the former too.

The truly paranoid should move along, though. If an attacker knew you were using this system, then they would have a much smaller set of possibilities for a brute-force attack – and the ability to just download the script and steal the word dictionary.

Update: Added about a thousand more words to the list to make this more secure. There are now over four million potential combinations of words, letters and symbols.