• Driftwood: quickly start podcasting from your iPhone

    Driftwood is a tool I created to rapidly deploy the necessary tools for publishing a podcast: a website, a podcast formatted RSS feed, and hosting for the files. A secondary goal was to be able to do all this from an iPhone. I was inspired in part by Manton’s microcast Timetable, and from my own use of Jekyll and Github pages to host my blog. My final goal was to be able to “self”-host podcasts that I’m currently paying $100+ a year to a commercial company, especially on one that is mostly retired but not dead.


    • The demo page can be seen here.

    • My own page using this template is here.

    • The Github repository is here.


    The concept and execution is simple: Github is used to both host the source files, build the website and RSS feed from those source files using Jekyll, and host the audio files.

    The template design for the webpage is clean and elegant, thanks to Kiko by @gfjaru. I made a few tweaks but nothing significant. Since podasts are all about the audio and not the webpage1, I think a simple page is best, and the user can add additional features as needed.

    Getting started is simple:

    1. Clone or fork Driftwood to your own repository.
    2. Rename it.
    3. Edit _config.yml with your information.
    4. Edit about.md with your information.2
    5. Replace images/itunes.png with your own logo (1400x1400)
    6. Replace audio/ep1.m4a with your own file
    7. Edit the file in _posts with your information, date, shownotes, etc.

    And your first episode is up!

    Add future episodes by adding a new audio file to /audio/ and a new markdown file to /_posts/ making sure to follow the template of the original file.

    If you need further information on formatting post pages for Jekyll, you’ll find a lot of information at the Jekyll website or on Google, since the first thing one does after using Jekyll to publish their blog is to write a post on using Jekyll to publish their blog.

    Doing it iPhone only

    You can edit the files directly on Github in the browser, but I find it much more pleasent to use one of the awesome iOS apps for Github: Working Copy or Git2Go.

    You’ll need one of those apps anyway to upload the audio files and logo because there is no way to upload a binary directly to Github from the browser even on a desktop OS. Edit: Ten days after I wrote this Github announced they’re adding the ability to upload binaries from the browser..

    If you don’t have a logo, you can make one very easily using Pixelmator for iOS, which is a steal at $5.3

    Record your own episode. You can use the built-in Voice Memos app, which is free with very limited editing functionality, or use Ferrite, which is more expensive but very powerful with multi-track editing and other professional features. Again, use one of the above apps to upload it.


    1. Is Github the best place to host audio files?

      Probably not. It’s certainly not designed for that and if one makes changes to the files then the version tracking aspect of Git will cause those changes to be saved using up a lot of storage space. File size is limited to 100mb and anything over 50 will likely get a warning. Also, a repository size is soft-limited to 1 gig. In general, these will not likely be an issue, especially for small project podcasts. The purpose of Driftwood is a tool for rapid deployment. If you want to host the files somewhere else, it is a trivial problem. Merely put the full URL for the audio file in the YAML front matter for the episode page and change the podcast.rss file from <enclosure url="http://soitscometothis.net" length="" type="audio/x-m4a"/> to <enclosure url="" length="" type="audio/x-m4a"/>. You can Dropbox, S3, Internet Archive, or any other place where you can directly link to the url of your file.

    2. What about using Github Large File Storage for the audio files?

      I tried that and it didn’t work. Either I missed something or you can’t really link directly to the file url so it breaks. If you find a way to get it to work, please let me know.

    3. I want to use mp3 files not m4a files.

      No problem. Just change the audio type in podcast.rss to mp3.

    1. I don’t think I’ve ever been to the webpage of 95% of the podcasts I listen to. I even considered making this tool “headless”–without a website, just the RSS feed.

    2. Please leave the attributions.

    3. The “repair” tool alone is worth that in its ability to save any photo.

  • TextExpander Snippet for Title Case

    One of the benefits of TextExpander now being able to use Javascript is that you can make much more powerful scripts that run both on the Mac and iOS. One benefit of 1Writer using Javascript and being popular with the technocrats is you can easily adopt their scripts for TextExpander and use them in other apps.

    Brian Jones recently published a 1Writer script for changing selected text to the title case format of John Gruber.

    By removing the last three lines

    var selectedText = editor.getSelectedText();
    var formattedText = toTitleCase(selectedText);

    and replacing them with


    it can now be used with TextExpander on iOS or Mac.

    The code on Github.

  • Battery Versus Gasoline Energy Density

    Since before I bought my first sailboat several years ago, I’ve wanted a Torqeedo–an elegant, efficient, electric motor.

    The benefits of electric engines on a sailboat are numerous. To begin with, there are already many options for generating electricity on sailboats using wind and solar energy, thus providing a consistently renewable source of energy. Electric engines are much quieter, almost silent compared to a combustion engine. There are none of the pungent orders of gasoline and oil.

    There is however one major drawback that is astounding and is mentioned in the product video for the engine I bought (starts 41 seconds in):

    10 pound lithium battery = 35 grams of gasoline


    Still, I think the advantages outweigh the drawback, and I ordered one today, finally.

  • Twenty One - content blocker for age verification

    When content blocking apps were first released for iOS 9, they were of the type that most would expect: all-in-one apps that in theory would block all the bad and none of the good.1 As I expected, developers are now starting to release apps with narrower functionality aimed at a specific task that can be used in addition to a main blocker. Image Blocker blocks images only, thereby speeding up browsing of text only and saving on limited data cap plans.

    My new favorite is Twenty One by Greg Fiumara, the developer of Tappd That, a beer tracking app. Twenty One is designed to disable the age verification screens some brewery websites use. It gets its block list from the developers server from an open source list hosted on GitHub. I’ve already updated it with a few rules for some of my local breweries: Devil’s Backbone and St. George.

    1. With variable amounts of minor customization.

  • Posting to a Github hosted Jekyll site from iOS

    Using a Github-hosted, Jekyll blog, I normally write my posts on my laptop, committing and pushing the final product in terminal. While this works well enough most of the time, I do actually like to use my iPhone as my primary computing device and want to be able to do everything as well on it as on my laptop. Frequently I don’t want to carry my laptop with me. Sometimes an idea for a post will come to me while I’m out camping, on a walk, or sailing.

    So, how can you post to Github from iOS?

    Directly on the website

    As far as I can tell, there is no way to create or edit a text file on the Github.com mobile site.

    Directly on the website forcing desktop version

    You can create and edit text files on the desktop version of the website. The drawbacks are that if you are writing into the field form on the website and lose your connection, you will most likely lose your data. You cannot work offline. You cannot use shortcut optimizations such as TextExpander.1 Basically, the experience is non-native. You could write in a text editor and then copy and paste into the form field, but including the logging in and navigation, it is a clunky experience.

    Using a code editor

    I thought that something as powerful as Coda for iOS might be my answer. They support SSH and FTP. Their screenshots show them managing their own website with it. After downloading it and failing to get it to work, I shot off an email to support asking for help.

    Unfortunately Coda for iOS does not currently have support for git. This is something that we are considering for a future update but in all honesty I can’t say for certain when it will be added.

    I couldn’t get Textastic to work either.

    Using a Github client iOS app

    I’ve looked for Github apps before and never found anything that worked well, was being actively maintained, or looked halfway decent. That is why I didn’t start by looking at that solution, but I should have because that ended up solving my problem.

    Working Copy

    The first app I came across was Working Copy. This app is free to use up until the point you need to push commits, and then it is either $2 for 21 days or $10 for permanent unlock. This allows you to make sure you like the app and it works for you before committing to the purchase.2

    Working Copy easily logs into Github using your username and password, and allows you to clone your repositories. You can then browse and manage your files as needed. I won’t go into all the specifics of how it works as I’m not a Git power user, but for my purposes of creating and submitting text files, it works well. You cannot edit files directly in Working Copy (Update:) I was wrong. The developer reached out and showed me that there is an edit button in the share sheet), but it has been designed to work well with exporting to Textastic, Byword, or Editorial, and then bringing the files back into the app. All of the aforementioned apps are superior text and code editors, which I also already happen to own, so it makes a lot of sense to use them rather than having the Working Copy developers wasting valuable time solving already solved problems.

    Working Copy has been around since 11/2014, gets updates every 1-2 months, and has an impressive ★★★★★ review total for lifetime and current version.


    I subsequently came across Git2Go by Nerdishbynature. This app was just released a few weeks ago and is on version 1.03 with a ★★★★ and 1/2 review total. Only two reviews weren’t 5 stars, and the 1 star review basically said the app only showed repos and nothing else, which I can attest is wrong.

    Logging in to Github is easy and uses Oauth with Safari View Controller. It literally took me 3 clicks on my iPad and 1 click on my iPhone. You can edit files in the app and syntax highlighting for Objective-C, Swift, and Ruby is currently supported with the developers noting their plans to add others later. Oddly enough, they only charge for cloning private repositories. This is a bit of a “problem” for me since I don’t have any private repositories and therefore cannot give them any money unless I create one. I’ve requested they add a tip jar, but I also think they might want to figure out a different monetization strategy.


    I’m not sure if I’m going to stick with Git2Go or Working Copy. I like them both and will likely continue to monitor their development. Byword is my favorite text editor after BBEdit, and the ability to seamlessly move between devices using iCloud sync is nice. If you prefer a code editor, Textastic is great too. On the other hand, being able to make a quick change to some code, or a spelling mistake on a blog post, right from an app is going to be much easier and quicker with Git2Go as you won’t have to make a round trip to another app and back.

    Either way, it is now possible for me to publish and edit posts easily, quickly, and enjoyably on my Github-hosted Jekyll blog.

    This post was written in Byword on an iPhone 6.

    1. When I tried to use the TextExpander keyboard on iOS 9.0, Safari would crash.

    2. Unlike Coda for iOS that required I file for a refund.

    3. Literally while I was writing this they released 1.1.