Bruce ¬

2016-06-02

thedailyjaws referenced the “Jaws” movie crew having nicknamed the prop sharks “Bruce”. Upon reading that, it suddenly hit me that it must be the reason that the great white shark in Pixar’s Finding Nemo was named “Bruce.” Or another reason, anyway. I had always assumed that it was just because it’s a stereotypically Australian name.

Wikipedia and the Pixar Wiki corroborate this. I love movie references.

Meet the loyal Newton fans who keep the device alive and kicking ¬

2016-05-26

Many thanks to David Pierini over at Cult of Mac for interviewing me for this piece regarding those of us who have been helping preserve what bits of Apple’s Newton platform we can. I am honored to have helped carry the torch—from all those who came before, including Victor Rehorst—and be counted with the likes of Grant Hutchinson. Definitely worth the read and a gander at Grant’s amazing photos.

Keeping Up with Ever-changing Browser & Internet Security Standards ¬

2015-10-07

My advice on which browsers to run on which versions of iOS and OS X, from Small Dog Electronics’ Barkings! blog:

Third, and most important, is to run the most modern & secure web browser you can. Apple’s own Safari browser (which is included with OS X and iOS) is fast, efficient, and has excellent integration features, but it is only kept up-to-date for the current & previous version of OS X and the current version of iOS. Fortunately, there are other good alternatives which you can run on older, and current, versions of OS X (listed below by OS X version):

OS X 10.9 Mavericks – OS X 10.11 El Capitan (Intel):

OS X 10.7 Lion – OS X 10.8 Mountain Lion (Intel):

Mac OS X 10.6 Snow Leopard (Intel):

Mac OS X Tiger 10.4 – Mac OS X 10.5 Leopard (PowerPC G3/G4/G5):

How to Complete the Migration of Google Code Project Wikis to GitHub Wikis ¬

2015-03-15

As you probably now know, Google is shutting down Google Code in less than a year and are encouraging users to switch to other open source hosting platforms such as GitHub. They have a handy Export to GitHub tool, which is easy, if a bit slow. I had a couple stale projects on Google Code that I hadn’t moved to GitHub yet, so I gave the tool a shot.

It appears to do a good job on the source code side of things, but has a few issues for project wikis (despite automatically converting to Markdown):

1. It doesn’t preserve history or images.
2. It exports the wiki data into a separate ‘wiki’ branch, not the GitHub project wiki.

There’s nothing I can do about the former, but I was able to easily automate resolution of the latter since GitHub allows you to clone project wikis to local repositories for advanced editing.

Introducing finishGoogleCodeGitHubWikiMigration, a bash script which—given a Google Code project exported to GitHub—takes the ProjectHome.md wiki page and makes it into the project’s README.md file, plus moves all the wiki pages over to the GitHub project’s wiki, fixing page links as it goes. I don’t know why Google couldn’t have included that functionality in their tool since you have to give it access to your GitHub account anyway.

You can find finishGoogleCodeGitHubWikiMigration on GitHub at (see the README for usage instructions) and feel free to submit pull requests for improvements:

https://github.com/morgant/finishGoogleCodeGitHubWikiMigration

NOTE: While it works on fresh clones of the project repositories, it does modify the repositories. If you don’t like the changes it makes, DO NOT push the changes back to GitHub!

One final comment on the Google Code project export process: you can also set the ‘project moved’ flag on the Google Code project if you want it to permanently redirect to the GitHub project, but I’ve found you cannot revert the change, so only do so when you’re really sure you’re happy with the migration.

Diagnosing & Treating Bash "Shellshock" ¬

2014-10-13

My introduction to the Bash “Shellshock” vulnerabilities, from Small Dog Electronics’ Barkings! blog:

OS X is a descendant of a long lineage of UNIX operating systems, from which it inherits its incredible stability and enhanced security. However, the past two weeks have uncovered numerous bugs in a core piece of software relied on by many UNIX operating systems, OS X included: bash (Bourne-again shell). It turns out that these bugs have been very long standing and can be exploited in numerous ways to provide unchecked access to a computer (in some cases remotely) with an afflicted version of bash installed. Due to the surprise and scope of this vulnerability, many have dubbed it “Shellshock”, in reference to the combat fatigue experienced by soldiers, but it’s really not a fair comparison to the effects of war.

Read the full piece for my advice on applying patches to limit your risk.

Lying Twitter Statuses Badge to Rest ¬

2013-06-24

When I last touched on my Twitter badge’s future, I noted that Twitter was giving us roughly six months before they shuttered v1.0 of their API which was all that was keeping my Twitter Statuses JavaScript Badge alive. They actually gave us eight months, but finally completed the API v1 retirement on June 11th 2013 and my Twitter Statuses Badge functionality ceased along with it.

The Twitter Statuses Badge was an interesting project for me, but was in dire need of some modernization which I had not had the time to give it. While I understand the want for consistency, I’m still disappointed in Twitter for their restriction of artistic freedom with the Developer Display Requirements, the other death knell for my badge.

So, today I officially lie my Twitter Statuses Badge to rest and suggest the use of the official Embedded Timelines instead.

Twitter Statuses Badge 0.7.2 Released and a Few Words on its Future ¬

2012-10-13

In mid-August, Twitter announced there would be big changes coming in v1.1 of their API which they then released at the beginning of September (officially deprecating the v1.0 of their API). Well, three days ago my Twitter Statuses JavaScript Badge stopped working on all my sites and everyone else’s that uses it too.

Back when I first started its development in 2007, there was no official, versioned API and it’s managed to continue working this entire time. Clearly, Twitter decided that with v1.0 of the API deprecated, that anything using older calls than that would no longer need to be supported. So, I’ve updated to the v1.0 API calls and all is working again… for now (more on that in a sec).

Go download v0.7.2 now (the source code is also on GitHub), or you can just change the following line in your HTML:

<script type="text/javascript" src="http://www.twitter.com/statuses/user_timeline/morgant.json?skip_user=true&callback=makkintosshu.twitterStatuses.twitterCallback"></script>

To the following (replacing “morgant” with the appropriate Twitter username for your use, of course):

<script type="text/javascript" src="http://api.twitter.com/1/statuses/user_timeline.json?screen_name=morgant&callback=makkintosshu.twitterStatuses.twitterCallback"></script>

A Few Words on the Future

Now, v0.7.2 of my Twitter Statuses JavaScript Badge only brings us up to v1.0 of the Twitter API which is now deprecated and will be discontinued in roughly six months. Why not go straight to v1.1 of the Twitter API? Well, there are two major changes in v1.1 that would have a major impact on the JavaScript badge: requiring OAuth for all API requests and the display guidelines will become display requirements.

The latter, requiring the JavaScript badge’s display to conform to the specific display requirements, would require some minor CSS changes and is not too big a deal. That said, since the primary goal of the JavaScript badge is to allow customization of the styling, esp. integrating with a site’s theme, it could not enforce that only certain styling rules would be modifiable and so it’d be up to the developer using it to ensure that they too were meeting the requirements. This might be acceptable, but there’s also a chance that Twitter would object.

The former, requiring OAuth authentication for all API requests, is unfortunately a show stopper. OAuth requires registering an application with Twitter (easy) and using secret access tokens as authorization to the API (the problem). The reason this is a problem is that JavaScript runs client-side and can be fully inspected by any user, so the secret access tokens are not very “secret” and could easily be reused by someone else for nefarious purposes.

The OAuth issues could be worked around by implementing the badge server-side in PHP or another language, but then it would not be the same paste-in solution it currently is. I could create a web service that acted as the middle-man, allowing one to create badges that would be populated using a small amount of JavaScript and allowed me to control the majority of the CSS styling with hooks for specific theming, but then you might as well just use the official Twitter Embedded Timelines badges.

So, the future for my Twitter Statuses JavaScript Badge looks bleak. It’s highly likely that this is its last six months, which is too bad as I still had features planned. I’m not going to call it quits yet as I’ve got a number of months to consider my options, but discontinuing it is definitely on the table.