Vincent Gable’s Blog

September 21, 2009

Best Mosquito Bite Remedy

Filed under: Announcement,Tips | , ,
― Vincent Gable on September 21, 2009

The past few rainy days here in Austin have been a welcome respite from the drought, but it means mosquitoes. The best remedy I know for a mosquito bite is Thayer’s Superhazel,

Most importantly, it numbs mosquito bites quickly, and seems to help reduce swelling. It’s most effective for me when I use a little spray bottle to apply it; then blow on the bite or put it under a fan. Airflow + menthol = instant relief.

What do you think works best for treating mosquito bites?

September 18, 2009

Strange AOL Instant Message Filtering

Filed under: Announcement,Bug Bite,Security | , , , ,
― Vincent Gable on September 18, 2009

You can’t send a message over AIM that has a JavaScript event handler name, followed by = in it. The message seems to be blocked on the server, not in the client, as this behavior was observed in different AIM clients (iChat, Adium, and meebo.)

Examples

The following messages can’t be sent over AIM:

onclick=

onclick =

Yo dawg, I heard you liked onclick= in your JavaScript…

Interestingly, using a newline, instead of space, between the handler name and = allows the message to be sent, even though it is still valid HTML/JavaScript. For example, you can send,

onclick
=x();
/*this is fine*/

I suspect there is an interesting security story behind all of this. If you know how and why this filtering came to pass, I please leave a comment.

Thanks to Dustin Silverman for helping me investigate this. In case you were wondering how I stumbled onto this behavior — I was sending snippets of HTML from twitterglyphs.com/ over AIM.

September 17, 2009

Installing Mac Apps

Filed under: Accessibility,MacOSX,Programming,Usability | , , ,
― Vincent Gable on September 17, 2009

Today’s Daringfireball article on the shortcomings of the Mac application-install procedure is worth a skim. Gruber’s suggestion that Mac OS X automatically move 3rd-party applications into the /Applications/ folder on first-run, (a la the dashboard widget install process) is a good one1. Since Mac OS X already prompts you on first run (“Are you sure you want to run a program Apple didn’t write?”) it’s hard to see any downsides to this idea.

But that’s not the behavior we have today1.

Don’t Use a Damn .dmg!

As it stands today, I don’t see a good reason to ship your apps as a .dmg. I’ve been suspicious of disk images for a few years now; and usability tests show that people get confused by them.

Distribute your application as a single .app in a .zip archive. What possible use are other files besides the application? If a “Readme” file should be read before using the application, then show it when the application is first launched.

Installers are opaque and un-Mac like. There’s always a risk that they’ll install something that breaks the computer. As a developer I am even more suspicious of installers on the Mac, because I know how broken Apple’s installer tools are.

Of course, as a developer, I know that applications do sometimes need to install components. And here the best solution is for the application to check it’s environment and ask to install missing components as needed (in essence be it’s own installer). It’s more robust, since it detects-and-corrects missing or damaged components. It always preserves the user-facing abstraction that the icon is the application.

Applications shouldn’t install hacks dangerous enough to require a bundled user-facing unisntaller. To make IMLocation work, I had to install a background process — but I made it intelligent enough that it would uninstall itself if the main application had been deleted. Yes, this is more work, but it’s worth it.


1Another idea is to make Safari and Firefox smart enough to download applications directly into the right /Applications/ folder, bypassing the usual downloads folder. This elegantly solves the instillation problem, although it creates some new problems.

2Although it would be a cool hack to write.

Big Freaking Systems

Filed under: Programming,Quotes,Research | , , , ,
― Vincent Gable on September 17, 2009

A programming language is a tool for handling design complexity. That’s what all of computer science is, really — languages, libraries, type systems, garbage collectors, everything you learn about programming. They’re ways to build more and more complex designs without losing your grip.

The way you manage complexity is to be able to ignore it. A good programming tool lets you forget about some part of the problem, so that you can focus on some other part. And it ensures that when you return to the parts you forgot, you haven’t accidentally broken them.

Andrew Potkin

Years ago, When I was taking to programmers about what college I wanted to attend, I had in interesting conversation about how Computer Science education is an utter failure at preparing students for real-world programming. Outside of Software Development, no technical field accepts (sometimes prefers) candidates with “N years of experience” in place of a degree. I’m not sure I know why CS education fails so badly and universally. But my current best guess is that it’s because school never exposes you to enough complexity. Projects have to end in a semester. You never have to deal with a multimillion-line program, written by hundreds of co-workers, dozens of which you need to collaborate with, at unexpected times, for surprising reasons.

September 15, 2009

More Dear Than Sleep

Filed under: Uncategorized | , ,
― Vincent Gable on September 15, 2009

… making (my new MacBook Pro) well worth the ~$2700 purchase price because I use my computer for more hours in a year than I sleep

Jason Kottke

My computer stays on 24/7. When I take it somewhere, it’s “asleep” but still on. Yes, I restart it occasionally; but by any human definition restarting isn’t turning off, anymore than someone blinking is taking a nap.

September 11, 2009

Never Start An Integer With 0

When programming, never start an integer with 0. Most programming languages treat a decimal number that starts with 0 as octal (base-8). So x = 013; does not set x to 13. Instead x is 11, because 013 is interpreted as 138 not 1310.

Languages with this quirk include: C, C++, Objective-C, Java, JavaScript, Perl, Python 3.0, and Ruby. If you add up the “market share” of these languages, it comes out to above 50%, which is why I say most languages.

“But I use {Smalltalk, Haskell, Lisp, etc.}”

I’m jealous that you get to use such a nice language. However, it’s bad programming hygiene to pick up habits that are dangerous in common languages.

Now, I assume you wouldn’t write 7 as 007, unless the leading zero(s) carried some extra meaning. There are cases where this clarity outweighs “cleanliness” (unless the code meant to be ported to a C-like language).

But you should at least be aware of this inter-lingual gotcha.

September 5, 2009

August 28, 2009

Fair Coin Tosses

Filed under: Security,Tips | , , ,
― Vincent Gable on August 28, 2009

Flipping a coin is, ever so slightly, unfair. As this article (via) points out, there is a bias for a coin to land on the same side it started on.

Fortunately, all the biases coins have are systemic biases — they effect all similar coins the same way.

So, with a fair thrower, it’s possible to flip twice, and have the bias of the two throws cancel each other out.

Procedure

  1. Put a coin heads-up, and flip it, as you normally would.
  2. Note the result, if certified this will be the decision.
  3. Flip the coin again, exactly as you did in step 1.
  4. If the coin lands on the opposite side as it did in step 2, the result from step 2 is certified. Otherwise, restart from step 1.

For maximum fairness and reproducibility, it’s best to let the coin land on the floor.

Why This Works

To simplify discussion, let’s call the sides of the coin unlikely (U) and likely (L) instead of heads & tails.

There are only 4 possible results to a pair of coin tosses: UU, UL, LU, LL. Obviously LL is most likely, and UU is least likely, so we rethrow if we get either (steps 3-4). That means the only “certified” results are UL or LU, and the odds of getting UL are the same as getting LU.

Dexterous Cheating

Unfortunately, this is not a self-enforcing protocol, so if the thrower is skillful enough, they can make the second throw go however they like, and keep re-throwing until they get the result they want.

Fortunately, most people aren’t able to manipulate a coin-toss. If you are worried that someone else is, then only let them flip once, and call the result in the air — that way they won’t know which side to pick.

If you can throw the result, and can’t find someone else to call the result — it serves you right for driving away all your friends by cheating at coin tosses, you tosser. But I’m still impressed.

August 27, 2009

Prometheus 1.0 Released!

Filed under: Announcement,iPhone | , ,
― Vincent Gable on August 27, 2009

My first iPhone app is in the iTunes App Store!

PrometheusLogoChrome.png

Prometheus

App_Store_Badge_EN.png

There are many apps for reading Wikipedia. Prometheus is different. It’s an editor for the Simple English Wikipedia

Simple English Wikipedia is like regular English Wikipedia, but it’s written with simple words and grammar, so kids and non-native speakers can easily grasp it.

Features

  • Shake for a random page
  • Or search and browse with purpose.
  • All articles are formatted for iPhone.
  • Tap the words you want to change to start editing.
  • Landscape keyboard support for easy typing.
  • Unfinished edits are automatically saved for later.

Simple Wikipedia makes a complex world comprehensible. Use it to teach what you know to someone who wants to know it.

Download from the iTunes App Store

August 19, 2009

iPhone Password Correction

Filed under: Accessibility,iPhone,Security,Usability | , , , ,
― Vincent Gable on August 19, 2009

Idea: your iPhone knows your passwords, so when you make a small typo, it corrects it for you.

There are obviously major security concerns here. But I believe they can be acceptably mitigated by the phone itself. Someone would have to physically use the iPhone to get password correction, and correctly could only happen on the first or second password attempt. Also, correction could be limited to the kinds of typos a person would make.

Passwords are broken by machines, not people. I believe password correction can help people, without substantially helping machines, and compromising security.

It’s hard to type precisely on an iPhone’s virtual keyboard. That prevents people from using secure passwords, and that hurts security. Because password correction helps people actually use strong passwords, it should be to be a net security benefit.

« Newer PostsOlder Posts »

Powered by WordPress