Setting Up a Personal TiddlyWiki Server on OS X

For a new job, I decided to set up a personal wiki to keep notes. I wanted to keep it simple, meeting these requirements:

  • All the data is in a Dropbox folder (so it can be automatically synced between machines)
  • It must support Markdown syntax

After looking at the options, I settled on TiddlyWiki. I've used "classic TiddlyWiki" before, and liked its simplicity, but I was always a little annoyed with the weird steps you have to go through to save changes. The new version of TiddlyWiki ("TiddlyWiki5") includes support for running it as an HTTP server, so you can use it just like an online wiki.

But it took me a couple of hours to figure out how to set that up. The TiddlyWiki documentation is not clear ("not clear" is a euphemistic way of saying "terrible"). So I've written up these instructions in the hope it will spare somebody else all the frustration I had.


The following instructions assume you are using a Mac running OS X, and that you know how to use the Terminal to run commands and how to create and edit text files.

(If you're using Linux or BSD, you can probably figure out what you need to do differently. If you're running Windows, you have my sympathy.)


Dropbox is not required to run TiddlyWiki, but I use it so that my personal notes will be available on all my machines.

If you don't already have Dropbox, go to to get started.


The TiddlyWiki server requires Node, so you will need to install that if you don't already have it.

If you are already using Homebrew, then installation is as easy as this:

brew install node

If you aren't using Homebrew, then go to and click the Install button.

Time Machine

The first rule of using TiddlyWiki is back up your data. Using Dropbox serves as a rudimentary backup system, but it's not a real backup system.

If you haven't already set up Time Machine on your Mac, then go do it right now. See for details.

Installing TiddlyWiki

The TiddlyWiki server is available as an NPM module, so once you have Node installed, all you have to do is this:

npm install -g tiddlywiki

You can do this to verify it is installed and usable:

tiddlywiki --help

Initializing Your Wiki Directory

You'll need to decide where to store your TiddlyWiki data. As I'm using Dropbox, I'll store everything in /Users/kdj/Dropbox/tw, but you can use whatever directory makes sense for you.

Run this command to initialize the directory for a TiddlyWiki server:

tiddlywiki /Users/kdj/Dropbox/tw --init server

Note: you can run tiddlywiki --editions to see if any edition other than server might serve as a better starting point for you. I know that server works.

After running the above command, you should see that the specified directory contains a file. This is the configuration file that controls how the server works.

Enabling the Markdown Plugin

TiddlyWiki's Markdown plugin is included with the distribution, but is not enabled by default. To enable it, you have to edit your file and add "tiddlywiki/markdown" to the plugins section. When you have finished editing, the file should look like this:

    "description": "Basic client-server edition",
    "plugins": [
    "themes": [

Running the Server

With everything set up, you can do this to run the server:

tiddlywiki /Users/kdj/Dropbox/tw --server 19671

And then view it in a web browser: http://localhost:19671

Run tiddlywiki --help server to see what other options are available. You may want to use a different port, set a username/password, or otherwise customize the behavior.

Starting the Server Automatically When You Log In

It would get annoying to have to type "tiddlywiki /Users/kdj/Dropbox/tw --server 19671" every time you wanted to use your personal wiki. Let's create a launchd configuration file in the ~/Library/LaunchAgents directory that will cause it to be automatically started every time we log in.

Go to your ~/Library/LaunchAgents directory and create a file named com.tiddlywiki.plist with the following contents, substituting the appropriate path for your data directory and the paths to the node and tiddlywiki executables. (Run which node and which tiddlywiki if you don't know what those paths are.)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">

After saving that file, log out and then log back in, and try to visit http://localhost:19671. If it works, great! If not, look for an error.log or output.log file in your data directory that may explain what went wrong.

Restarting the Server

Unfortunately, using Dropbox to sync TiddlyWiki data between machines does not work as expected. The TiddlyWiki server does not monitor changes to the filesystem, so even though Dropbox will copy changed files between machines, each TiddlyWiki instance just keeps displaying whatever data it read when it was launched.

So, after saving changes on one machine, we have to restart the TiddlyWiki server on the other machines to have those changes displayed everywhere.

The TiddlyWiki developers may eventually fix this, but in the meantime, we can define some shell commands to make it easy to restart the server when necessary. Add these lines to your ~/.bashrc file:

export TWPLIST=~/Library/LaunchAgents/com.tiddlywiki.plist
alias twstart="launchctl load $TWPLIST"
alias twstop="launchctl unload $TWPLIST"
alias twreload="twstop && sleep 1 && twstart && echo 'TiddlyWiki restarted'"

With these definitions, you can just execute twreload and refresh your browser whenever you sit down at one of your computers, and that local TiddlyWiki will refresh itself from Dropbox.

Further Steps

Once you have everything working, explore the TiddlyWiki website to learn more about how to use it.

One of the first things you'll want to do is click the gear icon to go to the Control Panel and customize the site title and other settings.

Getting Root on Huawei U8665 Fusion 2 Phone

I've had an old Samsung Galaxy S Captivate phone, running Android 2.2, that I've used as a test device while developing Android apps. In my new job, I no longer need to support Android 2.2 (hooray!), but I do need to support Android 2.3 (boo!). I tried installing CyanogenMod to update the Captivate to Android 2.3, but I ended up bricking the device.

Rather than spend more time trying to figure out how to fix that, I looked around for a cheap new Android 2.3 device, and found the Huawei U8865, also known as the "Fusion 2", for $60. That seemed like a reasonable price for a brand-new old phone, so I purchased it and it arrived the next day.

Unfortunately, when I tried using it for development, I hit a snag. My work requires using adb shell and related utilities, and whenever I tried those, I just got a "permission denied" response. I couldn't even take a screenshot.

I looked around for instructions to "root" the phone (that is, get privileged access). They aren't hard to find, but the people who write up these instructions all assume that (a) their readers have no idea what they are doing, and (b) everybody uses Windows. Neither of those are true for me, so I had to translate those instructions into developer-speak.

So, anyway, if you are running Mac OS X and you already know how to use Terminal and adb, then here are instructions for you:

(These instructions are based on those at

  1. Download and extract the contents.
  2. Open Terminal and cd to the extracted Huawei-Fusion-2-Recovery-Root/Huawei-Fusion-2-Recovery-Root directory
  3. Turn off phone
  4. Reboot phone into fastboot by holding Volume Down and Power buttons simultaneously for 10-20 seconds. (It will freeze at the AT&T logo.)
  5. Connect phone to computer.
  6. Type fastboot devices to verify phone is connected.
  7. Type fastboot flash recovery recovery.superrecovery.img
  8. After it finishes, unplug phone.
  9. Remove back of phone, remove battery, wait 15 seconds, then re-insert battery and attach back.
  10. Hold Volume-Up and Power button simultaneously until it boots into recovery (15-20 seconds of holding both buttons)
  11. In recovery menu, select the "reboot device" option with the volume buttons (it should already start with reboot highlighted) and press the power button to reboot.

After that, you will "have root". So if you use adb shell to get a command shell on the device, you can run su to get superuser privileges. There is also a new SuperSU app on the phone.

But that's not really what I wanted. What I want to do is run adb shell <some-command> from the Mac. If you read the adb documentation, you might think you can run adb root to enable that, but you will just get an error message saying "adbd cannot run as root in production builds".

One needs to install an alternative version of adbd. I downloaded and installed this one from Google Play: adbd insecure. There is an option to have it automatically grant superuser access at boot, and I enabled that.

Monochrome Color Themes for Xcode and Sublime Text

A lot of programmers like brightly colored syntax-highlighting themes for their source code editors. I do not. I find colorful high-contrast themes to be fatiguing, distracting, and annoying, so I've gravitated toward low-contrast themes like Zenburn and Havenjark. But even those feel too "busy" for me.

I've been on a retrocomputing kick lately, and I've missed the clean look of source code on the monochrome monitors I used in the good old days. So I've created some monochrome Xcode themes. If you like them, you can download them from here:

and copy them to your ~/Library/Developer/Xcode/UserData/FontAndColorThemes directory, and then select them from the Xcode → Preferences → Fonts & Colors window.

These themes are also available as Sublime Text color schemes:

These were my simple rules for creating the themes:

  • All colors have the same hue. They differ only in saturation and brightness.
  • Comments are dim.
  • Keywords are dim, but not as dim as comments.
  • Numeric and string constants are bright, almost white.
  • Other textual elements all have the same color.

I use Source Code Pro Light as my font, as I like the way the thin lines give a vector-graphics look.


Amber theme screenshot


Green theme screenshot


Blue theme screenshot


Blueprint theme screenshot


daVinci theme screenshot


I'm writing this yearly update later than I usually do. A few things have been unsettled, and I didn't want to write until I had some idea how they would turn out.

A Backup Restoration Story

For most of my computing lifetime, I didn't bother with backups. They were too much trouble, and back when it took 20 floppy disks to back up a Mac hard disk, they took too much time. But now with services like Time Machine, CrashPlan, Backblaze, Dropbox, and Google Drive, it is pretty easy to keep redundant copies of everything. I had files in these locations:

  • my main laptop
  • my old laptop (given to stepson for schoolwork), which still had all my files on it from the time before I got the new laptop
  • family iMac, which in addition to having copies of my important files also had an external hard drive that held Time Machine backups for all home computers
  • CrashPlan (offsite backup)
  • Dropbox (which is not really a "backup", but it means it's easy to maintain multiple copies of important files)

So I thought I was pretty well backed up, until a few events happened in a short period of time:

  1. My main laptop's SSD filled up with work-related stuff, so I deleted some big non-work-related stuff (Aperture library, virtual machine images), because I knew I had copies of those things on my old laptop, our iMac, and in CrashPlan offsite backup.
  2. My old laptop died when the kid dumped a glass of milk on it. So that's one old copy gone, but hey, we have others, right?
  3. The external hard drive that held our Time Machine backups failed. So I bought a new external drive and reconfigured Time Machine on all our machines to back up to it. That meant we lost our old Time Machine backups, I didn't worry because I knew I had copies of important stuff on the family iMac, and we'd have fresh new Time Machine backups in no time.
  4. The old family iMac died. We were lucky in that Apple botched the repair, and gave us a brand new machine to replace it, but the downside was that we lost everything that was on that machine's internal hard drive.

These events all happened within a month. In hindsight, I wish I'd reacted faster, but at the time, I just thought, "It's OK, we still have other backups."

So, anyway, we get this new iMac, and I figure I can just plug the external Time Machine drive into it and we'll have all our data back. But no: apparently I when I configured all the other family Macs to back themselves up to the family iMac's external drive, I neglected to configure the iMac to back itself up.

I had to fall back to the CrashPlan backup. I am very glad we had it, because otherwise we would have lost our family photo archives and some other important stuff. But the downside is that it has taken about five days to restore everything from CrashPlan. I don't know whether to blame our ISP or CrashPlan for the slowness of the restoration, but being unable to use that new machine for five days has been annoying.

CrashPlan's restoration functions suck. When I set up the CrashPlan app on the new iMac, it asked whether I would like to synchronize that new iMac with the old iMac's backup. "Sure, that would be awesome" I thought, and I clicked Yes. Then it took two days for the synchronization to complete, and during that time I couldn't restore anything.

Then, when synchronization finally completed, I checked the box to restore the entire hard drive and clicked the Restore button. CrashPlan spent a couple of hours counting up how many files that was and how big they were, and then it crashed. I tried again, waited a couple of hours again, and it crashed again. (So you need to have a plan for when CrashPlan crashes.)

Because it apparently couldn't restore the entire hard drive at once, I selectively restored individual folders (Applications, /Users/kdj, /Users/pebble, etc.). This worked, but again I had to sit at the computer for a long time while CrashPlan counted up all the files, because after selecting something, you can't click Restore until it finishes counting them up.

And then after restoring, I noticed some files missing, so I had to go back into CrashPlan and play with the options to get it to restore files from the date our old iMac died, and to include deleted/hidden files.

So, lessons learned:

  • Make sure all machines are backing up to Time Machine. Check this every week or so.
  • Restoring from CrashPlan sucks. Maybe that's just the nature of restoring a few hundred gigabytes of data over the Internet, but I may look into other options when my annual subscription expires.
  • When some link in the backup chain breaks, fix it right away.

The Good Old Days and Tiny BASIC

This week, we learned that Dr. Dobb's Journal is shutting down after 38 years. Admittedly, I haven't paid much attention to Dr. Dobb's for the past few years, but back when I was a kid who wanted to be a programmer, I anxiously awaited each monthly issue so that I could read every single article multiple times. We didn't have the Internet to give us whatever training we needed whenever we wanted, so magazines like Dr. Dobb's were precious.

While reminiscing about Dr. Dobb's with other grieving Twitter users, somebody brought up the fact that the first issue was titled "Dr. Dobb's Journal of Tiny BASIC Calisthenics & Orthodontia: Running Light Without Overbyte" (which I think is the coolest magazine title I've ever heard). It started as a xerographed newsletter to tell people about Tiny BASIC, a simplified BASIC programming language interpreter that could run in 2 or 3 kilobytes of memory. That was an important feature back when personal computers had only 4 kilobytes of memory.

Having just completed an implementation of a Forth programming language interpreter in Apple's new Swift programming language, I got the idea of implementing a Tiny BASIC interpreter in Swift. It didn't make any sense. I didn't want to write any programs in Tiny BASIC. I didn't think anybody else would want to write any programs in Tiny BASIC. There are more important things I could be doing with my free time.

But, apparently, reimplementing 50-year-old programming languages in Swift is my thing now

I did it. I call it "Finch", and if you want it, you can find it here:

Useless as it may be, it was an interesting exercise. Most of the Tiny BASIC implementations you find are focused on the original goal: getting a full implementation to fit in a few kilobytes. That isn't an important goal anymore, but I liked the idea of implementing a very-simple programming language. I focused on these goals:

  • Use Swift's high-level abstraction features, rather than writing code that looks like C or assembly language.
  • Make it easy for new Swift programmers to understand, so it could be useful as a beginner's example or in a tutorial.
  • Make it easy for people to hack on to add new features.

I think I did alright. It's about a thousand lines of code (not counting blank lines and comments), which is smaller than a C-based Tiny BASIC implementation I found, and I don't think I did anything too complicated. I will have to wait and see if anyone else wants to hack on it.

BASIC was the first programming language I learned. I expressed an interest in programming after attending an IBM open house, and my father brought home a BASIC programming manual. I studied it intently, but there weren't any computers around, so it was a while before I could try out what I had learned. But eventually the Radio Shack at the local mall started selling the TRS-80, and I could walk into that store and write my very first program:

10 PRINT "TRS-80 SUCKS! ";
20 GOTO 10

With great power comes great responsibility.

SuwaneeForth: A Forth Implementation in Swift

Using a new high-level programming language to implement an old low-level language is a strange thing to do, but I've done just that. SuwaneeForth is an implementation of Forth interpreter, written in Swift. If you are interested in such a thing, you can find it here:

SuwaneeForth is a translation/port of the system described in "A sometimes minimal FORTH compiler and tutorial for Linux/i386 systems" (a.k.a. "JONESFORTH") by Richard W.M. Jones. I'd suggest that all programmers read the source to that, as it is a very readable tutorial for bootstrapping a programming language implementation.

I heartily agree with the first paragraph of jonesforth.S:

FORTH is one of those alien languages which most working programmers regard in the same way as Haskell, LISP, and so on. Something so strange that they'd rather any thoughts of it just go away so they can get on with writing this paying code. But that's wrong and if you care at all about programming then you should at least understand all these languages, even if you will never use them.

Markingbird: A Markdown Processor for Swift

Markingbird is a Markdown processor written in Swift for OS X and iOS. It is a translation/port of the MarkdownSharp processor used by the Stack Overflow website.

(If you have no idea what "Markdown" and "Swift" are, you can just stop reading now.)

F#'s Pipe-Forward Operator in Swift

Note: At WWDC 2015, Apple announced Swift 2, which includes changes and a new feature called "protocol extensions" that render much of the code below either irrelevant or incorrect. This article applies to Swift 1.x.

Apple's new Swift programming language isn't really a functional programming language. However, it does support generic types and functional-programming patterns, so many FP aficionados are implementing their favorite functional idioms and libraries from other programming languages in Swift.

I've been a functional-programming enthusiast for a couple of decades, and I'm playing with this myself. A feature I like in the F# programming language is its pipe-forward operator, |>, which helps to write readable functional code. This article explains what that operator is, why you would want to use it, and how to do it in Swift.

Disclaimer: The code in this article is based upon the versions of the Swift language in Xcode 6.3. Future changes to Swift syntax or its standard library may render all of this incorrect or obsolete.

KJTipCalculator: A Simple iOS Swift App


As an experiment in using Apple's new Swift programming language, I whipped up a simple tip-calculator app for iOS 8.

Yes, the world really needs Yet Another Tip Calculator, and it also really needs Yet Another Swift App Example.

In addition to using Swift, the app also uses an embedded framework, which is a new feature of iOS 8. The framework contains functions and classes for converting between numbers and text, and it might be useful in other apps.

Source is available on GitHub:

If you actually want to use this app, you'll have to build it yourself. But if you have iOS 8 on your phone now, you should know how to do that.

Syndicate content