Category: Computers & Technology - Page 34

The Raspberry Pi Arcade Project, Part 1: Introduction

If you’re bothering to read this, I probably don’t need to explain either the Raspberry Pi or emulators (specifically, MAME and Stella), but for the sake of completeness, I will.

Raspberry Pi

The Raspberry Pi is a tiny, inexpensive Linux-based computer that, after years of anticipation, was finally released to the public last year. It’s designed to be versatile and to encourage creative, educational programming and electronics projects.

Emulation Software

Emulators are software programs designed to run on modern computers that emulate the physical hardware of older, simpler video game and computer systems. When combined with ROM files, the programs that ran on those old systems, it is possible to play near-perfect recreations of those classic games on modern equipment.

Of course, while the emulators themselves are (usually) perfectly legal, there is a (charcoal) gray area of legality regarding the distribution and even the possession of these ROM files. Legally, you should only possess ROM files for games you physically own. In the case of home video game consoles, that would be the original cartridges or disks. For arcade games, that would be the actual hardware cabinet with all of its electronic guts… or, at least, the ROM chip from said cabinet that contains the actual game program. (I do actually own an original Asteroids arcade cocktail table, and a very large collection of original game cartridges for the Atari 2600, 5200 and 7800; the Intellivision; the Nintendo Entertainment System [NES] and others. These will be the focus of my efforts with this project.)

There are numerous emulation programs, representing dozens of arcade and home video game systems, and most have been ported to a variety of different modern platforms, including Windows, Mac OS X and Linux. My interest primarily lies with the classic games of the late 1970s and early 1980s; specifically, arcade coin-op games which are emulated by the Multiple Arcade Machine Emulator (MAME) project, and the Atari 2600 which is emulated by the Stella project.

One of the dreams of many aficionados of early arcade games is to own a “MAME cabinet” — a real arcade game cabinet (or modern recreation thereof) with a modern PC and display inside, programmed to work with an arcade-style control panel, and loaded with emulation software.

The Project

I’ve wanted to build a MAME cabinet for years. The biggest hurdle for me has been a willingness to dedicate an expensive (or even semi-expensive) and significantly overpowered PC to use solely as the “brains” of such a cabinet.

I’ve also been interested in the Raspberry Pi ever since I first heard of it. The idea of a credit card-sized Linux computer that could be embedded in a creative electronics project sounded amazing! But possessing a woeful lack of knowledge of the circuit board-level details about electronics, and being equally woefully inept at either soldering or construction, I wasn’t sure what I could really do with it.

But then it hit me… I could build a MAME cabinet! What’s really great about attempting a project like this today is that you don’t really need to solder or build anything. The X-Arcade Tankstick is an (almost) plug-and-play, arcade-quality control panel, and the Xtension Arcade Cabinet is a prefabricated arcade-style cabinet designed to work perfectly with the Tankstick, the PC of your choice, and a 22-inch TV or LCD monitor to create a MAME cabinet that’s still a fun DIY project without requiring the same levels of skill that have previously made this kind of thing unapproachable for me.

The Road Map

I am already well underway with this project, but from the beginning it has been my intention to create a series of blog posts detailing the process, so others who, like me, have an intermediate-or-better level of knowledge of command line Linux; a rudimentary understanding of electronics — at least, which plugs go into which ports; and above all a deep and abiding love of classic ’80s video games, can make this kind of thing happen.

I owe a huge debt of gratitude to Shea Silverman, who is several steps ahead of me in working with and blogging about using the Raspberry Pi for emulation, but whose blog posts come with a tad steeper of a learning curve than what I am hoping to lay out for the readers of these posts. I’ll tell you what I think you need to know to make this stuff work, but for a more in-depth exploration of the details, please check out his blog.

Now then, here’s an outline of the posts I intend to include in this series. (I’ll update this page to make each a clickable link as the posts get published.)

Part 1: Introduction
Part 2: The Essential Gear
Part 3: Get Raspian
An Interlude
Part 4: Up and Running with Raspbian
Part 5: Emulator Set-up — Stella
Part 6: Emulator Set-up — MAME
Part 7: Configuring the X-Arcade Tankstick
Part 8: Polishing Your User Experience
Part 9: Preparing the Cabinet
Part 10: The Finished Product

How to keep Internet Explorer from displaying your site in “Compatibility View”

Fortunately this is an edge case for me, but… there’s a time for everything. And that time was today.

If you build websites using modern, open standards-based techniques, the last thing you want is to have your Internet Explorer-using visitors see your site in the dreaded “compatibility view”. This monstrosity was created by Microsoft with the advent of IE8, to allow sites (mostly corporate intranets) that require the quirks of IE6 to still look like they’re supposed to when viewed in IE8.

The problem is, IE6 sucks, and it makes modern sites look terrible. So if your users accidentally view your site in compatibility view, it’s going to suck too.

The good news is, it’s easy to force IE8 and later to display your site the way you intended. You can disable compatibility view with this simple meta tag:

<meta http-equiv="X-UA-Compatible" content="IE=9; IE=8; IE=7; IE=EDGE" />

(Source: http://stackoverflow.com/a/10365780)

How to get iWork (Pages, Numbers, Keynote) apps to stop defaulting to iCloud when saving

Ever since I semi-fully embraced iCloud, I’ve found that the iWork apps — Pages, Numbers and Keynote — always default to wanting to save every new document in iCloud, which I never — well, OK, almost never — want to do. It’s fine that it’s an option, but I want the default to be saving to my local hard drive (which, actually, means saving to my Dropbox account).

It didn’t take much effort to find this thread on Apple’s support forums, but the first suggested solution — turning off “Documents and Data” in System Preferences → iCloud — seemed draconian. With this option you can never sync your documents to iCloud.

A little further down the thread I found the “real” solution, courtesy of “Bernie_uk”, which was important enough for me to want to share here.

It requires opening up Terminal, but it’s not too scary. You just have to run this command:

defaults write NSGlobalDomain NSDocumentSaveNewDocumentsToCloud -bool false

This command doesn’t turn off anything in iCloud; it just tells the system that your default should be saving files to disk, not to iCloud. Note that since this is a global setting, it will affect not just iWork, but any other apps that use iCloud’s “Documents and Data” syncing. (I guess.)

Fixing background “bleed” on elements that use CSS3 border-radius property

It’s kind of funny that I never encountered this problem before… it must just be extra-noticeable because of the colors on this particular website I’m working on. Anyway, I found that the nice buttons I was creating with CSS3 border-radius were displaying an ugly “bleed” of the background dark blue color beyond the edges of the white border. No good.

before

A little googling led to Mike Harding’s solution, a simple background-clip property in the CSS. (Yet another of the preponderance of new properties in CSS3 that I’m finding it harder and harder to keep up with.) If w3schools.com is to be believed, the vendor prefix is unnecessary. Let’s just go with this:

background-clip: padding-box;

Ah, that’s better!

after

How not to update a WordPress plugin

The meaning of this post’s title is twofold: 1) how, as a WordPress user, to avoid having a plugin show up in the built-in updater; and 2) how, as a developer, you probably should not approach releasing a major update to your plugin that is incompatible with earlier versions.

The scapegoat here is Elliot Condon’s excellent Advanced Custom Fields, which has become one of my essential go-to plugins for building highly customized WordPress websites for my clients. I don’t mean to pick on Elliot Condon. He’s clearly a tremendously talented developer and I have a ton of respect for his work and what it has allowed me to do in my work.

But I do feel that he handled the 4.0 release of Advanced Custom Fields poorly. I’m not sure the fault is really his, however, as it is just as much or more the fault of how the built-in updater in WordPress works. (Especially since at least some of the changes he made in version 4 were done solely to conform to changes in the official WordPress plugin requirements.)

Here’s the problem: WordPress has a central Plugin Directory that makes it easy to install and update approved plugins. Perhaps too easy. Because if an update of a plugin is made available, and it’s newer than the version you have installed, it appears as an option in the updater. Yes, there are links to information about the update, which you really should read before doing anything else, but it’s all too easy with a few clicks to just run the update and move on.

Most of the time, it just works. Which can be dangerous. Because users — even “experts” like me — come to assume it will always “just work.”

As it happens, the version 4.0 release of Advanced Custom Fields was made available while I was on a weeklong vacation out west with my family, with only my iPad (and SLP’s MacBook Air) along for the ride. And, based on my own recommendations, a client with a relatively newly-launched website went ahead and ran the update. This particular site is heavily dependent on ACF, and the update broke it.

The official ACF website offers a migration guide that makes it (somewhat) easy to convert your existing version 3 implementation to work with version 4. But it’s not a “click-it-and-you’re-done” kind of process. It takes time, and you need to know what you’re doing. Which is nothing like the general experience of using the built-in WordPress updater.

I was able to temporarily solve the problem for this website by rolling back to an earlier version (which required some hunting to locate, given the limited Internet access I had with hotel WiFi). Which leads to my first tip:

How to prevent a WordPress plugin from updating

How does WordPress know when a plugin has an update available? Well, it’s easy for it to check the Plugin Directory to see what the latest version of any given plugin is. But how does it know which version you have installed? Also easy. Each plugin’s main PHP file includes a comment block at the top, with information WordPress parses both to display in the Plugins area of the admin interface and for added functionality (e.g. knowing when there’s an update available). For Advanced Custom Fields, the comment block looks like this:

/*
Plugin Name: Advanced Custom Fields
Plugin URI: http://www.advancedcustomfields.com/
Description: Fully customise WordPress edit screens with powerful fields. Boasting a professional interface and a powerfull API, it’s a must have for any web developer working with WordPress. Field types include: Wysiwyg, text, textarea, image, file, select, checkbox, page link, post object, date picker, color picker, repeater, flexible content, gallery and more!
Version: 3.5.8.2
Author: Elliot Condon
Author URI: http://www.elliotcondon.com/
License: GPL
Copyright: Elliot Condon
*/

This is essentially a set of key/value pairs. Version is what WordPress reads to see which version you’re running, and compares it against the master version in the Plugin Directory to see if updates are available.

So how do you keep it from running the update? Simple: Change the version number to something higher. I like to prepend it with “999” so I still know what the “real” version number is that I’m running, like this: 999.3.5.8.2. This way the WordPress updater thinks the major version is “999”, which is almost certainly higher than whatever the real current version is.

Simply change this version number, save the PHP file on your server, and you’re done. The updater will never trigger for this plugin (as long as its real version number is less than 999). You may also want to update Description with an explanation of what you’ve done.

Bear in mind this is a temporary solution. You really should do whatever you need to do to get your site compatible with the latest version, then restore the original version number and let the updater do its magic.

How, as a developer, not to create this mess for your users

I have submitted a few, very simple, plugins and themes to the official WordPress repositories, so I have a bit of experience with this, but I’m no expert on the process. However, what is clear to me is that if you submit changes to a plugin as an update, the built-in updater will pick it up and make it available to any users who have an older version installed. This is dangerous. If your new version includes such radical changes as to make it incompatible with earlier versions, you have to assume that most users will not read your notes, and will believe they can just run the updater with no problems… especially if you’ve made a habit of releasing frequent incremental updates to the plugin in the past that “just worked.”

The only real solution I see to this is to submit the new, incompatible version to the Plugin Directory as an altogether new plugin, instead of an update to the existing plugin. The risk here is that you lose visibility. Your download count and ratings/reviews reset to zero, and anyone who’s using an older version may never know about the new version. So, it’s bad for marketing.

But an incompatible update breaking sites for unsuspecting users is bad for marketing too. It’s going to cause your ratings to take a hit, cause a lot of bad publicity, and turn off your loyal users. The migration is going to be work for them anyway; making them do it after they clean up a mess created when they unsuspectingly ran the update is even worse.

A few specifics as pertains to Advanced Custom Fields

Again, I don’t mean to pick on Elliot Condon for his work with Advanced Custom Fields. I will continue to be a loyal (and, yes, paid) user of this plugin. It’s brilliant. Nonetheless, it’s created a hassle for me this week. After returning from my trip, the first work-related thing I did was go through every client site that’s running ACF and apply my “version 999” trick so those clients won’t run the updater until I have a chance to migrate their sites to version 4.

The biggest challenge I had in rolling back was simply getting my hands on the old version. Sure, I had it on some of my other sites, but I access almost every client site via SSH/SFTP, and the hotel I was staying at had port 22 blocked. Luckily the site I needed to fix was one of the few I access via regular FTP, and port 21 was open. But I still needed to get a copy of version 3.x to reinstall on that client’s site.

As I found along the way, the WordPress Plugin Directory hides old versions under the “Developers” tab, where every previous version can be downloaded as a ZIP file or checked out with Subversion. Previous versions of ACF are available here.