Jean Teasdale on Twitter

September 3, 2014

Veteran The Onion writer Jean Teasdale describes Twitter in her latest opinion piece (emphasis mine):

It’s a free internet site where you can share a personal moment, crack wise, show a photo of a kitty, and beat people to caring about things that literally happened seconds ago, all in 140 characters or less.

This may be Jean Teasdale’s masterpiece.

While I’m praising Jean, I would be remiss if I did not link to her home page. The URL alone is genius.

Comments

Telefontornet and Software

September 3, 2014

DIG44975_5491480300_o

Today on the always wonderful Colossal I learned of Telefontornet, 1890s Sweden’s central telephone exchange and the enormous structure atop it at which all lines converged.

It reminds me of my early career as a software developer: ISO/IEC 13818 in hand, writing an MPEG-2 demultiplexer and stream parser from the ground up. Doing things I didn’t know couldn’t be done, to paraphrase Sirkis.

That work wasn’t stringing up telephone wires in all directions across the sky, but in software terms it wasn’t that far off. 13 years of professional experience down the line, I wonder how I would approach that same project today.

For one thing there would be some unit tests written.

Comments

iBeacon At The Arcade

February 18, 2014

A few years ago I got involved in pinball software development in a pretty big way. It’s faded over the past year, but it’s still one of my favorite cranial playgrounds for software ideas. I continue to be passively obsessed with contemplating new ways of writing pinball software (“Could you write good pinball software in Lua? What about Haskell? How would that look?”). Mercifully for my family they remain mental exercises.

There are two topics that tend to come up quite a bit in discussions about pinball technology, at least when I am involved. The first is that I should have a player profile on the pinball machine, like my iOS Game Center or Xbox Live account. This would allow for internet high score boards that go beyond initials, but also make it possible to change the open/closed nature of a pinball game. Suddenly my game could have persistent state (pinball RPG?). Stored power-ups for use in later games. Lots of really interesting possibilities here, both for home and location players.

Before I get to the second topic, there’s a problem to discuss. The problem with this player profile idea is that it’s hard for a player to sign into the game. Pinball machines do not have rich input devices. Usually it’s three buttons: flipper left, flipper right, and start. (“Was my password LLLRL-Start or LLLLRL-Start?”) For various reasons a touch screen is technologically hard or very awkward (it would get in the way of the flippers). RFID or mag stripe cards are an option but then you have to have some way of distributing the cards. I bet the Taco Mac bartender really wants to hand those out. (Jersey Jack tried something like this with ePlate. Something tells me it hasn’t taken off. Maybe it’s the part where I have to sign up for a credit card to participate.)

There’s a better option: quite a lot of us carry around very rich input devices in our pockets, of course, which brings us to the second topic: how can I connect my phone with a pinball machine? If your phone can communicate with the pinball machine then you suddenly have a very natural means of identifying yourself to the pinball machine. The trouble is that, until recently, doing this was also hard and awkward. The machine itself would need to be on wifi, maybe you’d have to join the same wifi network on your phone, or shoot a QR code to tell the app which game you’re standing next to… Like I said, awkward.

So what happened recently that changes this? Last summer Apple announced iBeacon as part of iOS 7. What’s fairly cool about it is that it isn’t just an iOS thing – Android phones support it too (it’s just Bluetooth Low Energy, BLE). iBeacon solves the problem of connecting your phone with the pinball machine by allowing the connection to take place over Bluetooth, without pairing. There’s proximity data and the devices can even exchange information.

The possibilities here are pretty interesting, even aside from the idea of signing in to your player profile. A pinball manufacturer could offer iOS and/or Android configuration utilities, making for a much richer management interface for owners and operators of these games. Technically you could even sidestep connecting the pinball machine to wifi at all, if you relied upon the player’s phone for relaying information up to a server. It would even allow co-located games to form a mesh network of sorts, for example for head-to-head play, although there are perhaps simpler ways of solving that problem.

iBeacon seems like a pretty natural fit for retail and vending machines. A lot of folks are excited about using it for payments, as an alternative to NFC. Imagine coining up a game using IAP on your phone. You could even take your credit balance with you when you get a great score. Free loyalty credits, social marketing possibilities (“Tweet this for five free credits” (yes, I hate myself a little for suggesting this)). Of course all of this can apply to video arcade games, jukeboxes and so forth.

As an aside, one of the great things about iBeacon is that it’s very accessible for experimentation. You can pick up beacons fairly cheaply (Estimote, Bleu), and you can also make your own device act as a beacon. The iOS APIs are pretty straightforward (Region Monitoring, CBPeripheralManager).

This is an interesting time for pinball. A number of new, smaller game makers have popped up, like Multimorphic and Dutch Pinball, just the kind of manufacturers that could be ready to try something like this. Here’s hoping.

Comments
Tags: ,

Musings On Creating Immutable Collections Mutably

April 3, 2013

Sometimes we need to create an array whose length and members are not known at compile time. Oftentimes that looks something like this:

NSMutableArray *things = [NSMutableArray arrayWithCapacity:numThings];
for (int i = 0; i < numThings; i++)
{
    [things addObject: ... ];
}
// use 'things'...

If our collection is not to be changed later, and we’re feeling particularly pedantic, we might do something like this:

NSMutableArray *mutableThings = [NSMutableArray arrayWithCapacity:numThings];
for (int i = 0; i < numThings; i++)
{
    [mutableThings addObject: ... ];
}
NSArray *things = [mutableThings copy];
// use 'things'...

But mutableThings is still accessible. Best to tuck it away:

NSArray *things;
{
    NSMutableArray *mutableThings = [NSMutableArray arrayWithCapacity:numThings];
    for (int i = 0; i < numThings; i++)
    {
        [mutableThings addObject: ... ];
    }
    things = [mutableThings copy];
}
// use 'things'...

But that looks pretty unpleasant. How can we improve upon this?

One approach would be to use blocks in a simple fashion. The compiler’s inference of the return type can make the equivalent of the above a bit more graceful:

NSArray *things = ^{
    NSMutableArray *mutableThings = [NSMutableArray arrayWithCapacity:numThings];
    for (int i = 0; i < numThings; i++)
    {
        [mutableThings addObject: ... ];
    }
    return [mutableThings copy];
}();
// use 'things'...

I like this, but there’s a downside: we can’t use Step Over in the debugger to step through this code (we can still Step Into). You could also consider that an upside, depending on what you’re debugging.

We can take this a step further by creating a category on our favorite collections objects, and use it like this:

NSArray *things = [NSArray ap_arrayViaMutableArray:^(NSMutableArray *things){
    for (int i = 0; i < numThings; i++)
    {
        [things addObject: ... ];
    }
}];
// use 'things'...

A strong advantage here is that we’ve abstracted away all of the alloc, init and copy noise. Debugging may be a bit more cumbersome, since Step Into is going to step into the implementation of our category method before it gets to calling the block.

Comments

SwiftText 1.1.0

October 30, 2012

I’m pleased to announce that SwiftText 1.1.0 is now available! Here’s what’s new:

  • Retina support.
  • Font is customizable.
  • SwiftText may optionally be kept on top of all windows until it is dismissed.
  • Added “Append to SwiftText” Mac OS X service.
  • Sandboxed.
  • Improved status item behavior.
Comments
Tags: