Monday, August 16, 2010

Permanent Windows command-line aliases with doskey and AutoRun

On Unix, you can configure command line aliases, like this: "alias lls=ls -l". From then on, running "lls" will automatically run "ls -l", saving you a few keystrokes. The alias will go away whenever you open a command prompt; to make the alias permanent, you can save it in your .profile or .bashrc.

On Windows, you can do the same thing using the DOSKEY utility to create "macros" like this: "doskey ls=dir". Doskey macros are basically equivalent to Unix aliases (though they have different advanced features).

Automatically loading your Doskey macros is a bit more trouble, however. Doskey allows you to export a macro file, like this: "doskey /macros > my-favorite-macros.txt". You can then import your macro file like this: "doskey /macrofile=my-favorite-macros.txt".

Instead of your .profile, you'll need to configure your AutoRun registry value, in "HKEY_CURRENT_USER\Software\Microsoft\Command Processor". I have my AutoRun set to "c:\dev\autorun.bat" which runs a variety of helpful utilities.

I hope this helps!

Sunday, May 09, 2010

Customize Android Browser Scaling with target-densityDpi

It was hard to find this little gem, so I thought I'd share it with the world: the Android team has implemented a custom meta viewport property to allow you to customize browser scaling for high resolution (HDPI) screens, like the WVGA 480x854 Motorola Droid and 480x800 Nexus One. [This is as opposed to medium resolution (MDPI) HVGA 320x480 T-Mobile G1 or myTouch 3G.]

You can use it like this, for example: <meta name="viewport" content="width=device-width, target-densityDpi=device-dpi">

What's Browser Scaling?

Here, ppk explains why a pixel is not a pixel. The CSS "px" unit may differ from a device's actual pixels, as the browser "scales" images and fonts to a larger size than you requested. (The browser just naturally assumes you didn't really mean "pixels" when you said "px," and helpfully tries to resize your content to make it readable on high-resolution phone screens.)

The Nexus One and Motorola Droid (and any other WVGA devices) will scale pixels even if you use the <meta name="viewport"> tag to instruct it not to do this. Worse, they using a non-integer scaling factor (e.g. 1.5x zoom, to scale 320px to 480px) which makes images look really weird.

target-densityDpi to the rescue!

Use this new undocumented <meta name="viewport"> property: target-densityDpi. The only existing documentation is in the Android check-in comment:

Add dpi support for WebView.

In the "viewport" meta tag, you can specify "target-densityDpi".
If it is not specified, it uses the default, 160dpi as of today.
Then the 1.0 scale factor specified in the viewport tag means 100%
on G1 and 150% on Sholes. If you set "target-densityDpi" to
"device-dpi", then the 1.0 scale factor means 100% on both G1 and Sholes.

Implemented Safari's window.devicePixelRatio and css media query

So if you use "device-dpi" and modify the css for font-size and image
src depending on window.devicePixelRatio, you can get a better page on

Here is a list of options for "target-densityDpi".

device-dpi:    Use the device's native dpi as target dpi.
low-dpi:       120dpi
medium-dpi:    160dpi, which is also the default as of today
high-dpi:      240dpi
<number>:      We take any number between 70 and 400 as a valid target dpi.

Fix http://b/issue?id=2071943

So how do I use it?

Like this, for example: <meta name="viewport" content="width=device-width, target-densityDpi=device-dpi">

You may also want to add the "user-scalable=no" property to prevent the user from zooming in/out and to guarantee that your images are exactly as you designed them. You can read more about other viewport properties in Apple's documentation which originally defines the

Wednesday, April 14, 2010

Choice of Broadsides now available on iPhone, Android, Web

Choice of Broadsides, our newest game, is now available on iPhone, Android and on the web.

"Choice of Broadsides" is a multiple-choice swashbuckling naval adventure, in the spirit of C. S. Forester's Hornblower or Patrick O'Brian’s Aubrey/Maturin books, with a dash of Jane Austen.

We hope you enjoy the app, and we hope that you tell all of your friends about it! Our initial download rate determines our App Store ranking. Basically, the more times you download in the first week, the better we'll rank.

Share and enjoy!

Tuesday, February 02, 2010

The Code Bomb, or: The Newbie with Big Ideas

Are you considering making your first big contribution to an open source project? If so, don't make this mistake.

I've been working on open source projects for a number of years now. Sometimes, we've received feedback from potential new developers, saying something like this: "Your project looks great, and I'd love to help out. BUT your code is a mess. I'll help, but only if we XXX."

In this case, "XXX" is an expensive wide-reaching enhancement to infrastructure, something like:

  • Replace the automated build scripts
  • Refactor the code in a huge way
  • Add/remove a significant library dependency
  • Rewrite the code in another language

These are very risky infrastructure enhancements: they have a known large up-front cost, an unknown cost in bugs introduced during the enhancement, and unclear benefit, because typically the goal of the enhancement is to do exactly what the code already does, but in a better or more maintainable way.

In many cases it's very tempting to indulge in infrastructure projects like these, and as a result, I'm guilty of implementing my fair share of them myself.

But we have to say "no" most of the time; we're here to build something great, not to shave yaks. Especially since, in most cases, people who say "I'd like to help, but..." don't really want to help anyway; they don't usually stick around long enough to fix the bugs in the new infrastructure they suggested.

UPDATE: Newbie developers tend to want to propose big refactors partly because it's harder to read code than to write it, but also because it's easy to get used to crappy code over time.

In the worst case of this I've ever experienced, a developer "John" (not his real name) required a major refactoring of the code before he'd work on the project, but volunteered to do the entire thing himself. He decided to go dark; he returned, months later, with huge changes to the code, touching almost every file in the system.

In the open source community, we call this a "code bomb." A code bomb is a patch that's so large that no one can review it. Here's Ben Collins-Sussman on code bombs:

One of the main community "anti-patterns" we’ve talked about is people writing "code bombs". That is, what do you do when somebody shows up to an open source project with a gigantic new feature that took months to write? Who has the time to review thousands of lines of code? What if there was a bad design decision made early in the process — does it even make sense to point it out? Dropping code-bombs on communities is rarely good for the project: the team is either forced to reject it outright, or accept it and deal with a giant opaque blob that is hard to understand, change, or maintain. It moves the project decidedly in one direction without much discussion or consensus.

When a developer (typically a newbie developer) drops a code bomb, it's perfectly fine to just say:

Sorry, we can't accept this patch because it's too large; it's a code bomb!

The onus is on the contributor to break it up into smaller reviewable patches, each of which fixes a clear bug.

In our case, we had to just reject "John's" patch, wholesale. Months of work were simply wasted! Don't let this happen to you!

UPDATE: Good commentary on reddit

Wednesday, January 06, 2010

Choice of the Dragon iPhone App Available

Available on the App Store

Choice of the Dragon is now available as an iPhone app! Please download and review it.

Coming soon: Facebook integration. Sign up for other mobile versions here.

Sunday, January 03, 2010

Choice of the Dragon Android app available

The Droid Choice of the Dragon is now available as an Android app! Please download and review it.

(And if you haven't played the web version yet, well, what are you waiting for?)

iPhone and other smartphone versions are coming soon. Sign up for other mobile versions