Ghost (Still) Sucks as a Blog.

In my 30-something years as an engineer and product manager, I have never seen a better example of putting style over substance than ghost, the so-called blogging engine.

Yes, it looks clean and pretty. Yes it’s quick to write a post.

If your goal is to write, it’s all good.

But if you goal is to be read, you’re hosed, because Ghost has no way for readers to find relevant info on your blog such as “all post regarding heroku”.

No search. Still. And the Github thread discussing adding it is a joke. Let me summarize: “we can’t add ANY search until we find a way to incorporate a fancy query language, have a single-source solution that works for the (3 or 4) databases we support, that works well on Gigabytes of data.”

No Tag List. First, here’s what they say about their tag feature:

Ghost tags are intended to be a super-feature – a powerhouse of customisability for your blog. Tags are a single flexible and powerful concept of a taxonomy which should provide all the features a blog could need to categorise and list posts in interesting ways. (

So, tags are important, useful, so you can tag a post. And if you happen to know a tag you can see all the posts with that tag via but… and yes, I know this seems far too stupid to believe… they did not add a url to list the tags.

In summary, the Ghost team seems to be so busy drinking the “easy to write” Kool-aid that they seem to have completely ignored the reader your blog readers cannot search for a post… not by a simple keyword like “heroku” nor from a list of available tags.

Product mis-management like that used to be a shooting offense in silicon valley.

(My blog is now using WordPress.)

Highly recommended: site-by-site cookie cleanup for Macs using Cookie

Russell, at SweetP Productions, is the developer of Cookie, an outstanding $14.95 Mac app that lets you control and minimize the amount of hidden tracking that websites do.

The simplest setup is to tell the app to delete the cookies, flash cookies, silverlight cookies, and local databases for all non-favorite websites when you quit your browser.

For websites where you DO want to keep your cookie data (so you do not have to re-enter your username and password each time), perhaps Facebook and your blog, you simply check the “favorite” checkbox next to the website name.

There is also a handy pulldown menu added to your menubar to immediately wipe all non-favorite data.

There is a 14 day trial period so you can decide if it is your cup of tea or not, but having used it

To Speed up the First Time Machine Backup, Don’t Stop and Resume!

When doing the first Time machine backup to a network drive we saw average speeds in the 2-3Mbps range.

However, when we shutdown the Mac then resumed the backups, the speeds dropped dramatically (to 30-80 Kbps)… enough so that the estimated time to completion skyrocketed from 15 hours to 16 days.

Presumably, Apple does certain first-time back optimizations for speed, since the first backup is invariably large.

So the lesson is: do not stop the first backup. If you must, it is probably faster to just delete the partial backup and restart from scratch.

Recover User Data When Mac’s Filevault2 Won’t Boot

One of our Macbook Pros running Lion mysteriously stopped booting after a perfectly ordinary shutdown.

All of the advice online failed to help (such as trying Diskwarrior – which could not unlock the drive, running Disk Utility via the Recovery Partition, and even various adventures with Terminal, all of which indicated the System on the boot partition was corrupted).

The gist of advice online is that
(a) whatever is not backed up is lost,
(b) a full erase/system install will be required.

Turns out that (a) was not true at all… if (“when”) filevault corrupts your system, you can access/backup the user files via a different computer.

Removing the drive and plugging it into an external dock connected to another Macbook allowed full access to all User files. So we were able to copy all the files, erase the disk, then restore from an older backup, then replace the user files.

How to fix Time Machine when it confuses multiple backup drives

Being a “belt and suspenders” kind of guy when it comes to my data, I decided to start having Time Machine backup to two drives. But I wanted BOTH drives (TM1 and TM2) to contain the complete Time Machine history back to Day One.

If you simply connect a new drive (TM2) and add it to Time Machine’s list, the new drive’s backups will NOT contain all the history on the first drive. To get the history moved to the new drive, you need to copy the Backups.backupdb bundle from the first drive to the second drive before you enable the drive in Time Machine.

Finder does not seem to work for copying the Backups.backupdb to the new drive … in my case it took hours to “prepare to copy” only to subsequently refuse to copy them saying some items were “in use”.

SuperDuper, however worked fine to copy everything from TM1 to TM2.

The problem is, when I then added TM2 to Time Machine’s list, Time Machine was confusing the two drives. (TM1 would show up as both drives’ names, instead of TM1 and TM2.

The solution seems to be to do force one backup separately to each drive as the ONLY backup drive to “sync” the drive name and dataset, before enabling both drives.

Step by step (TM1 is the current Time Machine drive, TM2 is the new one):

  1. Turn OFF Time Machine
  2. Remove TM1 from Time Machine’s list (so Time Machine has no backup drives specified)
  3. Format the new drive, name it TM2
  4. Use SuperDuper to copy everything from TM1 to TM2
  5. Eject both TM1 and TM2,
  6. Physically disconnect TM2 so it will not mount automatically when you reboot
  7. (Reboot Mac just to ensure it’s in a fresh state)
  8. Mount TM1
  9. Leave Time Machine OFF, and specify TM1 as the backup drive
  10. In the Time Machine menu, do a manual backup “Backup Now”
  11. When the backup to TM1 completes, UNmount it.
  12. (IMPORTANT) Remove TM1 from Time Machine’s disk list
  13. Mount TM2
  14. In Time Machine specify TM2 as the backup drive (Time Machine is still OFF)
  15. Do a manual backup again, this time it will go to TM2.
  16. Mount TM1
  17. Add TM1 to Time Machine’s backup list.
  18. Enable Time Machine
  19. (to test, I then did two consecutive manual backups, ensuring that each time it picked a different drive)

If IE8 is displaying all Bootstrap columns full-width, here’s the fix

I see a lot of reports online that Bootstrap 3 is not correctly displaying on IE 8, for example two side-by-side columns get displayed full-width and stacked (instead of side-by-side).

If you’ve already added the required IE8 patch shown below, be sure you are adding that after the bootstrap.css file is loaded. (If you load it before boostrap.css it will not work.)

<!-- [if lt IE 9]>
<script src=""></script>
<script src=""></script>
< ![endif]-->


Getting Glyphicons to work with static Bootstrap 3 CSS and Rails 3.2

Glyphicons will not work correctly on production Rails apps in the default static Bootstrap 3 installation. The issue is that the compiled (static) Bootstrap CSS file has hardwired location ../fonts for the fonts that will not work with the default Rails asset pipeline. I’ve seen several solutions on the web that involve editing the Bootstrap CSS file, but I dislike that approach since it breaks the next time you install an updated Bootstrap unless you remember to re-make the same edits.

Copy the entire Glyicons /fonts folder to the app/assets/stylesheets folder, e.g., put the fonts in a fonts subdirectory of the stylesheets folder.

Add the following to bootstrap_and_overrides.css

/* Override Bootstrap 3 font locations */ 
@font-face { 
  font-family: 'Glyphicons Halflings'; 
  src: url('/assets/fonts/glyphicons-halflings-regular.eot'); 
  src: url('/assets/fonts/glyphicons-halflings-regular.eot?#iefix') format('embedded-opentype'),
  url('/assets/fonts/glyphicons-halflings-regular.woff') format('woff'), 
  url('/assets/fonts/glyphicons-halflings-regular.ttf') format('truetype'), 
  url('/assets/fonts/glyphicons-halflings-regular.svg#glyphicons_halflingsregular') format('svg'); 

We’re a fan –

One of our web apps relies upon over a dozen third-party api-based services,  and none are more impressive than, a service that gracefully handles the gnarly details of providing a user-friendly, sexy, full-featured UI for customers to upload images.


Integrating into our web app was a snap, due to their well-thought-out API and support for features such as upload-to-S3.

Their pricing has gone up quite a bit since the service was introduced in late 2013, but unlike some companies mentioned in this blog (yeah, I’m calling you out yet again, Zerigo) they grandfathered early adopters with a special plan.

Create a Lightroom 5 custom import preset to organize photos into year-month (YYYY-MM)

When importing my tens of thousands of photos into Adobe Lightroom 5 for Mac, I wanted to take advantage of import presets to automatically re-organize my photos  chronologically to replace the somewhat haphazard folder structure I had been using for many years.

I wanted the top level folders to be 4 digit year (YYYY), and inside each year I wanted one folder per month, with the year and month in the folder name, but not the date (YYYY-MM) since I don’t need 365 folders per year.

Desired Destination folder: YYYY/YYYY-MM Lightroom’s default import presets for the Destination do not have an option to have just the year and month as a folder name (without the date). It does offer a Destination YYYY/YYYY-MM-DD which is close, but too granular since I don’t need a separate folder for each day. So I want to remove the -DD day portion.

Desired File Renaming: YYYYMMDD-originalname In addition to storing the files in chronological YY-MM folders upon import,  also wanted to Rename the file on import to prefix the filename with the date, for example 20141201-DSCF1000.JPG, which fortunately IS one of the defaults for File Renaming.

Here’s how

I found several forum posts with users wanting to do the same thing, and some very out-of-date posts about editing a file called TranslatedStrings.txt which no longer exists in Lightroom.

The solution in Lightroom 5 turned out to be simple. What I did was select the”File Renaming” and “Destination” defaults closest to what I wanted, saved it as a user preset, then used a text editor to edit the preset file.

Step 1 – Save an almost-right User Preset After clicking Import, on the right pane I selected the two options show below: under Rename Files I chose Date – Filename and under Destination I chose into Subfolder by date with format YYYY/YYYY-MM-DD which gave me something to edit (all I need to do is remove the “-DD” part, as described below.

Then in the bottom Import Preset pane I clicked the popup menu and selected Save current settings as new preset and named the preset MyYYYY_YYYY-MM



Step 2 – Manually edit the new user preset to remove the -DD

Lightroom 5 on the Mac saves the custom user import preset in the location ~/Library/Application Support/Adobe/Lightroom/Import Presets/User Presets and the easiest way to open that folder is in Finder choose Go > Go to folder… then copy/paste that string. Finder will open the folder and you should see the file MyYYYY_YYYY-MM.lrtemplate

Open the file with any plain-text editor Since the extension is not .txt you can’t double-click the file to open a text editor, so right-click the fiel and choose Open with > Other and choose your favorite plain text editor, such as Text

Edit the line that says

shootNameFormat = “%Y/%Y-%m-%d”,

to remove the -%d which is the day number so it looks like:

shootNameFormat = “%Y/%Y-%m”,

Simply save the text file. Close Lightroom, then relaunch it.

Click the Import button and in the bottom Import preset pane choose your new preset MyYYYY_YYYY-MM option. When you import files into your catalog it will copy them to the new folder structure.

When using heroku toolbelt, use git remote name instead of app name

Heroku Pipelines is a great feature, letting you more easily maintain multiple environments such as a staging server and production server, for example typing heroku pipeline:promote to push from staging to production more easily (and more quickly) than re-pushing from your local repository up to production. As far as I can tell the heroku command does not document the useful option of being able to use git remote names (instead of heroku app names) when specify which app by using the -r option.

heroku config -r GITREMOTENAME

instead of

heroku config PRODAPPNAME

I find using git remote name useful, easier to remember, and less error-prone because our git remote names in a multiple-app environment are typically consistent and symbolic, such as “stage” and “prod” (as opposed to heroku app names which might or might not bear any relationship to whether they are staging or production, for example “bluebird” and “honeybucket”).

Especially when you are working on several web apps, being able to consistently refer to the ‘staging’ version of the app as ‘stage’ beats the heck out of remembering the specific actual app name (and inadvertently tweaking “bluebonnet” instead of “bluebird”).