This is a simple app that I built with Apple Automator that I’ve been using to upload files to this blog. Overall, WordPress’s web page uploader works well, but it requires a browser window be open. Sometimes I just want to send a file quickly and not bother with that. One of the reasons people like my Post to WordPress plugin for Ulysses is that it avoids having to open up WordPress to save a draft post.
The Ulysses app can do a lot besides writing. I’ve written a lot about how I abuse the poor thing. Its export options offer a variety of formats. One that was convenient was the RTF option. It meant I had one click export to a standard rich text format that’s usually requested by publishers.
The v2.1 Ulysses update replaced RTF with DOCX, the new Word 2007 format. These files aren’t usually accepted via email because of the chance that they carry a macro virus. (Have you noticed all the email spam that includes an “invoice”? Yep, those
invoice.zip files come contain a DOCX file pre-loaded with a macro virus!) Even so, I was a bit miffed when the Ulysses developers made me resort to another app to deal with the Ulysses export.
But I also found that there’s a couple of ways this also helped me out.
I’ve made a significant update to my app Post to WordPress for Ulysses today.
I’ve improved it so that there’s no need to edit the Automator app or need two parts (app & code file) for everything to work. The blog information (user name, password, URL, and SSL preference) is now stored in a separate file. Also, all the posting code is now inside the app, and the user doesn’t need to create a
~/bin folder to keep the Ruby code file in.
The ReadMe file has all the updated information and the install will be much simpler.
Even though Ulysses is beta testing a WordPress posting feature, my solution will work with the current version. I’ve also tested it against the beta, and it works the same. The one thing I like most about my app is that it converts any links into ones that open in a new window. There’s no way for this to be done in Ulysses, and having to do it manually in WordPress is tedious at best.
I’ve also decided to quit fighting with WordPress about how it interprets timezones. Posts uploaded with the app will now be plain drafts instead of scheduled posts.
One of the neat things about Magna Studio EX (Clip Paint Studio EX if you buy the downloadable version) is it’s book making abilities. It shouldn’t be a surprise since the whole app revolves around making comics and comic books. The panel-based nature of comics also makes for a pretty neat layout tool for image heavy books or magazines.
In my case, it’s also a substitute for Adobe InDesign. For the occasional layout jobs I have, it’s not worth another subscription on top of Lightroom+Photoshop. So after fighting with Lightroom’s crippled book module1 I decided to build a template in Manga Studio that would work with Blurb’s magazine-sized books.
The one constant about indoor events is the poor lighting. It’s not usually bad lighting. The people that set up the stage want the event to look good. There’s usually plenty of light from the audience’s perspective. What the camera sees is a different story.
When Hillary Clinton campaigned in Phoenix the event was held in a high school gym. I’ll wait while you finish shaking your head. So you can imagine the base lighting. Overhead lighting was the basic fluorescent tubes. The event lights were two towers holding a couple of lights each which faced the stage.
Since none of my lenses are stabilized, I also have to keep the shutter speed up to get sharp photos. Usually 1/320 is the minimum speed to keep the 70-200mm sharp. So between the low light and need for shutter speed, I was looking at ISO 3200 for decent exposure. Starting off I used ISO 1600, knowing that I’d have to bump up the exposure in Lightroom. About halfway through the event I figured I had enough safety shots. Then I decided to try out ISO 3200 to see if the images would be salvageable.
There’s an old tech-support joke about important data.
Tech: Does this drive have important data on it?
Customer: Thanks for asking, it does indeed.
Tech: Good. I’ll erase it now.
Customer: Nooo! I’ll loose everything!
Tech: If it’s that important, you’ll have a backup.
Customer: What’s a backup?
In short, if it’s on a computer and it’s important, there should always be a backup.
We’ve gotten better about this. Dropbox was the first service to really break through the noise about backups. Since then a multiplicity of cloud-based backup services have sprung up. Now, cloud-syncing is an expected feature in a lot of apps. I’m glad about this. It’s an automatic layer of worry-proofing. But things can still go wrong.
Note: there is now a GitHub repository for this project. Get the latest code there, including a downloadable Automator app
After sleeping on this I decided there were a few things I could do better. Having to put raw source in the document was annoying. I looked into several ways to do this, but found Ulysses had the answer.
If a line of text is “marked” in Ulysses (that’s the
:: notation) it gets exported as its own paragraph, but no other HTML tags are applied. This worked out perfectly. It gives me a way to highlight the WordPress tags in the document, and doesn’t require complicated scripting.
Ulysses does a lot of things right as a writing tool. But it’s not designed to be a HTML or Markdown editor. It’s also not able to post directly to a blog.
But its export friendly nature makes it easy to build helper apps. So I wrote a Ruby script that will post to a WordPress blog. It’s also fast. It usually takes less than 5 seconds. That’s faster than the WordPress post editor loading time.
Being able to quickly write scripts like this is one of the reasons I’m convinced that Ruby was the language I was waiting for. It works in the same way I think.
After using GitHub to contribute to a project the other day, I got to thinking about other uses for Git. One was to keep a backup of my
~/bin folder. I write a lot of one-off scripts to make my life easier. Most of the time they’re under 20 lines and previous versions aren’t really needed. But sometimes1 I break things. Other times I’ll go back and wonder what the hell was I thinking.
I already use Dropbox, so why not put a repository there? I just prefer to have the files separate. There’s some talk about how the Dropbox backup version will conflict with the Git files. I’ll only be using it for a bare repository not a working directory. So Dropbox can do it’s thing and it won’t cause me problems.
Since I also use Bitcasa Drive, it seems natural to make that into my upstream repository. Bitcasa is different from Dropbox in that the files stored there are not on your local hard drive. They’re on the Bitcasa drive which is mounted as a network share. So it is true off-site backup. Access to it also depends on having an Internet connection. It’s a place for backups not daily work.
Once set up, I’ll be able to commit changes to either or both remote repositories. If I’m working offline I can push commits to Dropbox and have them synced up later. The reason to add Bitcasa is to have another backup and Git makes this easy.
I have a few projects up on GitHub, but it’s more of a “code storage” place than a “get work done” place. But the other night I ran across a project that I could make a quick contribution to. Besides helping out the project, I also learned a few things about how pull requests work. Including how to clone a pull request and work with the pull request author directly.