Universal Remote With Programmable Button Labels

When a remote control for a piece of equipment is purpose-built for that device, the remote's buttons have functions that exactly match the functions of the device, with labels that clearly indicate those functions, and in many cases with a shape that represents the function (for example, a forward button in the shape of a right arrow). In addition, the buttons provide tactile feedback.

It's hard to beat those ergonomics, except that the coffee table winds up cluttered with a bunch of dedicated remotes.

To consolidate the remotes into a single remote, users turn to universal remotes.

Universal remotes fall into three categories:

• Assignable hard buttons with permanent labels, and no display.
• Assignable hard buttons with permanent labels, plus a touchscreen/display.
• No hard buttons, just a touchscreen/display.

There are drawbacks to all of these approaches.

If a universal remote has only hard buttons, then it must have a gazillion of them in order to support every possible function. This degrades the ergonomics of the remote because now it is a giant unwieldy wand cluttered with way too many buttons, only a small subset of which apply to any particular piece of equipment.

In addition, because there are always functions for which no button exists on the remote, manufacturers have to provide generic buttons (F1, Spare2, etc.), but then the user has to remember what functions are assigned to the generic buttons, because the labels are of no help, nor are the button shapes.

If a universal remote has a touchscreen/display, this allows manufacturers to have hard buttons for the most-common functions, with the touchscreen/display handling whatever is missing.

But this also degrades the ergonomics of the remote. Touchscreens don't provide tactile feedback, and they're not as crisp as hard buttons. (Users with touchscreen remotes will tell you they love soft buttons, but what they're really saying is they are willing to put up with soft buttons if it means they only have to have one remote on the coffee table.)

Manufacturers try to perfect universal remotes by varying the ratio of hard buttons to displayed buttons, trying to find the right mix. The problem is, there isn't really a right mix. Something is always a bit off.

But there is a fourth approach. Instead of having a touchscreen/display in order to have a way to define "buttons" that aren't represented by the available hard buttons, make each hard button a little display itself, and use that display to change the label on the button.

There are already keyboards that do this, for example http://www.artlebedev.com/everything/optimus and http://www.unitedkeys.com. There's no reason it wouldn't work for remotes as well.

Another advantage of this approach is that it doesn't need a backlight.

The remote could still have a display for miscellaneous information, but now it could be just a few lines of text, and wouldn't have to be a touchscreen.

This approach doesn't solve the button-shape problem, but perhaps the set of buttons that benefit from having a special shape is small enough that they could be in the set of hard buttons from the start: skip left, rewind, play, forward, skip forward, up, down, left, right, page up, page down, channel up, channel down, volume up, volume down, maybe a few others (jog shuttle--does anyone still use that?).

Synthetic-tooth Pool Balls

The balls used for billiards, snooker, and pool used to be made from ivory.

With a dwindling supply of elephants, manufacturers turned to plastic as a replacement.

Plastic is superior to ivory in many ways: it isn't as fragile, it doesn't require humidity and temperature control (ivory balls were notorious for cracking if they got too dry), it's less expensive, and it doesn't contribute to the extinction of a species.

But plastic suffers from being too slick.

If you drag a natural pearl gently over the face of one of your front teeth, you will feel a grittiness. That's caused by the surface of the pearl being rough (at microscopic dimensions), and the roughness matching the roughness of your tooth. Similarly, if you drag a piece of ivory over your tooth, it feels rough.

If you drag a plastic pearl over the same spot, it just slides. There is no grip.

Billiards, snooker, and pool require fine cuts--shots where the cue ball and the object ball barely touch. When the balls are slick, there is a limit to how fine a cut can be before the contact patch slips instead of gripping. When the contact patchs slips, spin is not transferred correctly from the cue ball to the object ball, and the shot suffers through no fault of the player.

What we need is balls with a surface that is microscopically rough, like ivory. This surface should not wear off, or wear down. Perhaps it could be implemented by embedding fine particles of something hard and gritty in the plastic.

This seems like the kind of thing 3M could knock out in an afternoon.

Power-outage Power Cutouts For Electronics

We live in the Santa Cruz mountains, and the power up here is bad (overhead lines, trees that fall down, etc.). So we tend to get power outages and brownouts, particularly in the winter.

When the power goes out and comes back on, some of our electronic devices turn back on. In the case of a plasma TV, this is bad, because we might be away from the house when it happens, and an image could be burned into the TV.

We tried to find a power conditioner that would turn off if it encountered an outage, requiring a manual reset to turn it back on. No such conditioner seemed to be available.

A UPS could be used for this, but they are too big to fit in the wall behind a plasma TV, and generally not a good fit for this application.

X10 devices used to fail open on power-off, but now they restore their previous state when powered back up.

We wound up having to make our own with a RIB01P DPDT relay from functionaldevices.com:a PAC521P from chiefmfg.com:and a momentary rocker switch typically used for garbage disposals:
We were given superb pre-sales support by the engineers at Functional Devices, including a circuit diagram:But it really shouldn't have been that difficult.

Power conditioners, both in-wall and rack-mount, should have a mode where they don't restore power unless reset.

For rack-mount, the reset could be done with a pushbutton, IR, RS-232, X10, or Z-Wave.

For in-wall, a button would be difficult to reach, so the reset would have to be done with IR, RS-232, X10, or Z-Wave.

Legacy Code Conversion Service

Companies that have legacy code often want to convert the code. They want it to conform to modern standards (for example, web services, JEE, etc.). They want it to be easier to work with (structured, layered, Mavenized, etc.). They want it to interoperate better with other internal and external systems.

Companies that have legacy code often have made an effort to replace, rewrite, or refactor the code. Often these efforts were paid for by reducing funding for new-product development. Often those efforts have failed, leaving them with the same legacy code they started with, behind in the market, and frustrated.

A consulting firm could specialize in making legacy-code problems go away for companies, for a handsome fee.

The consulting firm would not need to advertise. Contracts would come to the firm through referrals from CEOs, CIOs, CTOs, and boards of directors of companies that had their legacy-code problems fixed by the consulting firm.

The consulting firm would not need to be big. It could consist of a small team of experts, working remotely. There wouldn't even have to be a central office.

The consulting firm's engineers would use powerful analysis and refactoring tools running on 64-bit machines with huge amounts of memory. Some of the tools could be from open-source projects, and others could be developed internally. The tools would not have to be polished, with nice GUIs. They could be command-line based. They would just need to do the job.

The consulting firm would only need two or three contracts at a time to be making money hand over fist.

Because maintaining source-control history while massively refactoring code is a pain, the consulting firm should charge extra (a lot extra) to do that.

The best thing about this idea is that a consulting firm could describe in public exactly what it plans to do, and how it plans to do it, and nobody would compete with the firm. Even if somebody did compete, there would be more than enough work to go around.

Why is that? Because engineers don't want to work with legacy code. Legacy code is a dead end, they think. Cream-of-the crop engineers especially don't want to work with legacy code. They want to create. They are artists. Maestros.

Competent engineers who are willing to work with legacy code are rare, which leaves the field pretty much wide open.

Which is odd, really. There is a lot more legacy code in the world than new code (and new code has a way of turning into legacy code over time). Most code is legacy code. And it can be quite satisfying to convert troublesome code into good code.

Super-tool For Refactoring

One of our projects at work involves refactoring the code into layers (UI, business logic, data, service, and so forth), and then vertically into components within each layer.

In many cases, the work involves mechanically moving classes to their correct layer, splitting classes, moving methods, and sometimes adding listeners or Spring initialization to remove upward dependencies.

The work is tedious. There's nothing particularly creative about it. It's just a slog through a million-plus lines of code.

Refactoring tools are available, but they are basically tedium reducers. They automate mechanical transformations at the lexical level, but they don't understand anything.

I want more. A lot more.

I want semantics instead of syntax.

Somewhere in the Platonic realm, our program exists in the form of its true, perfect nature. I want refactoring tools that make it easy to move a program towards its ideal form.

Imagine standing in front of a big display like the one in Minority Report, lighting up a long sequence of nested if/then/else/case statements, and selecting "Infer Rules Engine".

Imagine pointing to other sections of the code and being able to select operations such as:

"Infer State Machine"
"Recode Without Side Effects"
"Remove Programming By Exception"
"Replace Static Initialization With Spring"
"Make Stateless"
"Extract Declarative Configuration"
"Replace With Annotation"
"Manage In Cache"
"Substitute Composition For Inheritance"
"Reimplement With [Name of GOF Pattern]"
"Extract To Presentation"
"Canonicalize To JEE"
"Promote To Web Service"
"Internationalize"
"Make Testable"

all while maintaining source-control history.

(Moved from http://jimshowalter.blogspot.com/2010/03/one-of-our-projects-at-work-involves.html.)