How to use an older Flash player in Safari

Preventing users from harm is generally a good thing. Preventing developers from harm can be kinda annoying.

While debugging an issue with a Flash based product, I needed to downgrade Flash to the previous version. Downgrading flash itself was a surprisingly straight-forward process. Adobe has a list of its recent Flash updates all listed and downloadable. But once you install it, getting Safari to use it was a different story.

What, you don't use zombocom to check flash installed-ness?
Googling around, I found some solutions that no longer works, involving renaming some directories. But I did find out XProtect is likely what's preventing me from using this older version of Flash, and I ended up at /Library/Internet Plug-Ins/Flash Player.plugin/Contents/. Could editing Info.plist actually trick Safari into thinking this is a newer version of Flash?

I edited CFBundleShortVersionString and CFBundleVersion
It did!

Welcome to zombocom!

Sadly, this didn't help me debug the issue, but by writing this down I'm hoping it helps someone else with a similar problem in the future.


My experience getting started with golang + GAE

I had been itching to try go and finally decided to dive in tonight. The kids are asleep, glass of wine in hand, time to give this a go (no pun intended).

1. Downloading go

I had already done this a while back, but on a typical OS X dev machine, this is a one liner:
$ brew install go

2. Hello world

Martini was the project that pushed me over the edge to play around with go, so I went with their starter project:
package main

import "github.com/go-martini/martini"

func main() {
  m := martini.Classic()
  m.Get("/", func() string {
    return "Hello world!"
Running this worked without any issues:
go get github.com/go-martini/martini
go run server.go
And I had localhost:3000 up and running. Wee!

3. Hosting?

Coming from ruby/javascript background, I was hoping for a free/sandbox PAAS with a simple CLI like Heroku or Nodejitsu, but I wasn't able to find one. To be fair, I didn't really try too hard, but my guess is that with go being a Google project, most people just use Google App Engine. Side note: last time I used GAE, I set up a JRuby server at Tapjoy to fetch Android marketplace data before play.google.com was a thing (The app still exists, but I forgot the actual paths for the real stuff.)

4. Deploying

Getting GAE up and running was a bit more pain than I had hoped for:

1. Installation bash script:
$ curl https://dl.google.com/dl/cloudsdk/release/install_google_cloud_sdk.bash | bash

2. I had to set up a new project and was assigned a project ID of platinum-trees-564 and a git repo. That's nice, I would prefer to use Github but I don't want to muck around too much with the process until I'm comfortable with it, so let's keep going with it. Oh it looks like there is a deploy script built in to the git server? Let's try that.

$ git push
(...blah blah...)
remote: Scanning pack: 100% (3/3), done.
remote: Storing objects: 100% (3/3), done.
remote: Processing commits: 100% (1/1), done.
remote: Starting execution...
=remote: Created deployment: platinum-trees-564.clouddev.gaeTemplate-d981b975f1ecaa6d.deployment_1398662263832
remote: Dispatched
remote: Deployment '[email protected]@[email protected][email protected]' is in PENDING.
remote: Scanning files on local disk.
remote: Uploading 1 files.
remote: Sending batch containing 1 file(s) totaling 0KB.
remote: Cloning 2 application files.
remote: Uploaded 1 files.
remote: Initiating update.
remote: Deploying new version.
remote: Closing update: new version is ready to start serving.
remote: Updated successfully
remote: Deployment to App Engine successful.
To https://source.developers.google.com/p/platinum-trees-564/r/default
   611be7f..7b646ae  master -> master
3. Nope, deploy didn't work. Logs say:
Request failed because the app binary was missing. This can generally be fixed by redeploying your app.
4. From this Go doc I try fixing up the app.yml file. No luck
5. Found this other doc that talks about running the GAE server locally.
goapp serve
Wat. Where did this goapp come from?
6. Going through the logs from step 3.1 (installation script), I find that I installed some things at ~/dev/google-cloud-sdk. It turns out I need to run ~/dev/google-cloud-sdk/platform/google_appengine/goapp. I could probably add this to my path, but it would be nice if this had been mentioned somewhere before.
7. GOTO step 5. Oops, goapp doesn't seem to like martini. This seems to be a problem with martini as it's trying to default to port 3000, and goapp wants it to use 8080. Screw it, let's go with even more barebone helloworld:
package hello
import (

func init() {
    http.HandleFunc("/", handler)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprint(w, "Hello, world!")
8. Success! localhost:8080 is now working. This doc now shows me how to deploy my app:

goapp deploy .
9. Finally, I see the same page on platinum-trees-564.appspot.com.

5. Overall experience

A-minus? It wasn't the smooth Heroku experience I'm used to - but I went 5*-to-60 in under 2 hours, so I would say that's pretty damn good.

* since I already had go installed, and some previous experience with GAE.


Accept my accept-language

I have a pretty simple accept-language setting in Chrome:

Quick check reveals this to be "en-US,ko;q=0.8" and according to the RFC, this is roughly "I prefer American English, but will accept Korean." English has the default quality value of 1, while Korean has 0.8.

But for some reason this is a difficult concept for people:

My guess is either:

  1. the default quality value is being parsed wrong, and English is being assigned q=0 instead of q=1 or
  2. en-US doesn't match en and is being bypassed,
leading the server to believing Korean is my preferred language. To be fair, the RFC does state that "all languages are equally acceptable" but it's still somewhat annoying that my preferred order is being ignored.

Localization is hard.

updated 2014-03-16 18:08:00 UTC

Once I updated the Chrome settings again (with the same order), my accept-language now reads "en-US,en;q=0.8,ko;q=0.6" and everything works "as expected". #2 above was likely the culprit, and at some point between when I last changed language settings and now, Chrome must have fixed this behavior on the header settings.