October 2008 Archives

I'm unhappy with the state of my pants.

Now, before you get too far into the "um... lose some weight then" comments (thanks for that, though :-) ), let me explain. I'm unhappy that I need to carry around so many keys. It's gotten fairly ridiculous; I won't post a picture of my keyring here, because people could copy my keys, but I need four keys for my apartment building, a key to CS grad student stuff, a car key, a couple of keys to other people's things, a USB key that holds encryption keys, a one-time-password token (for VeriSign VIP), and a card wallet that holds two other pseudo-electronic keys: my Hopkins ID, and my Peabody Conservatory ID. All keys. The total weight is something like three pounds-- a lot in a pants pocket.

This is insane. First off, of course, Hopkins owns Peabody, so there's no earthly reason that we should use different ID cards-- but every division of Hopkins does, so this isn't a new problem. Even setting that aside, though, why should I need to carry tokens in addition to one magnetic-readable card to access Hopkins resources, like the CS department?

Well, as usual, there's a political problem here too: Hopkins believes that its security is so important that nearly no one should have access to the card verification network. Hence, to tie into it, Hopkins charges departments $5000 to install a card reader. (Which costs $5. Seriously.) Therefore, departments (which aren't made of money, really) either have to roll their own card reader system (as my department did for the undergraduate lab), or issue keys to a whole lot of students (as they did for the graduate and Ph.D labs).

In addition to these, I have OTP and encryption tokens, which aren't necessary. Why not?

Well, here's the deal. I carry around a very powerful, very compact device that has a full processor and OS in it. It's called an iPhone. The iPhone has bluetooth and WiFi connectivity to broadcast its presence to everyone else. Why can't this do everything I need? Why can't it let me into doors, serve as an OTP token, hold my encryption keys (heck-- it could perform the encryptions locally, on demand from my computer), and all the rest?

There are too many crappy bits of metal I have to keep track of, for no reason other than politics (JHU Security, mostly, though GPG having no iPhone implementation, when it runs on every other system up to and including a toaster oven, is also most likely a political mess-- and with real encryption locally, it could serve as a smart card, and thus be able to be used as a physical security token). And now with Android being in a real device, one can even have a more "open" smart platform. So what gives?

For now, however, I'll just resign myself to breaking my wrist off to open my mailbox. What a mess.

Two things I learned today:

• A pipe wrench is directional (one way it grips, one way it doesn't)
• It is actually possible to strain your right wrist and bruise all your left fingers simultaneously

I've never been what one might call "handy," in a go-sweat-and-grunt-and-build-something sort of way. I'm fairly good at building interesting things electronically, of widely ranging complexity. Actually fixing big items requiring brute strength, however, seems to be beyond me.

I should note that this is not due to lack of trying on my father's part. He tried to get all three of us to do everything with him, as kids: fix cars (we actually own some cars where one can fix it oneself without an EE degree), repair plumbing, build various things. We actually did all of it, but for me at least, the lessons learned there didn't really seem to rub off much; while I was shown how to do things, and I assisted in their completion ("OK, now you do it!" "OK!"), all these years later it doesn't seem to have given me an ability to, you know, do stuff.

I suppose, then, that it's a good thing that I'm building Project Voom for my own sake, and not, say, to impress a lady. She would otherwise, no doubt, be rolling on the ground laughing after today.

That said, Voom is actually going well, in the sense that I now have nearly all the parts necessary, I know how I wish to complete the wiring, and I have a full design for (and soon, will have completed) the frame.

Motors used for building Segway-like devices are usually taken from wheelchairs-- and indeed, if you look on eBay for wheelchair motors, most of the listings will reference battlebots or robotics in the hope of attracting these types of buyers. I was lucky enough, a few weeks ago, to run across a listing on eBay for an actual powered wheelchair in full working condition, and with a new set of batteries (so they could actually hold a charge), for about half what one would expect to pay for one working wheelchair motor-- so I snapped it up. This has advanced my project from the "let's build a prototype first" phase to the "let's just go ahead and build the thing" phase-- perhaps to its detriment, but oh well.

I enjoy the challenge, certainly; I haven't done robotics since high school-- 9 years ago now-- and so it's fun to go back to it. The actual programming is pretty straightforward-- measure angle, calculate a new speed, set the new speed, rinse, repeat-- but the construction of this robot is more in-depth than my old ones were, which is interesting.

When I get a frame that looks somewhat segway-ish, I'll post a picture, but for now, imagining a bunch of pipes on my floor, and purple knuckles, will get you nicely to the current status of Project Voom. Ah well.

[EDIT: two typos.]

I got the opportunity to attend BarCampDC yesterday, an unconference filled with lots of fun people from the (still relatively small) DC startup community. It was a great opportunity to meet people from the area; while my internships in the Bay have (this summer especially) provided ways for me to meet the tech community there, Hopkins hasn't made it a priority to get events like this here (though I've tried to convince them a few times). My beneficent overlords also provided some of the funding for this BarCamp, which was cool (BarCamps are funded by lots of smaller donations, rather than a few big ones, to prevent any one company from dominating discourse; at this BarCamp, the max donation was $250, and they had more than 36 sponsoring companies). It was my first time at a BarCamp, and I had a blast.

One of the more interesting talks I attended was by Samantha Warren, essentially "a guide for engineers on how to talk to design people." Originally billed as "Design 101 for Non-Designers," it was nonetheless a useful introduction into their dark arts-- and while I already had an appreciation for designers (since I'm frighteningly bad with even a pen, let alone Photoshop and free time), it was still a good explanation of what designers are actually looking for, and how to evaluate design's usefulness to help your brand. (There were, however, dissenters; another graphic designer in the room said that "graphic designers live in their own world," and that he didn't want engineers butting in; the "guru on a mountaintop" approach, I suppose.) The session also convinced me that not only does Mnikr need a logo (in that big space in the upper-left) once it gets a bit farther, but it wouldn't hurt to have some sort of coherent branding across all my various USSJoin-fed projects... I wonder if someone in the DMC might be willing to take pity on a poor graduate student?

There were also great sessions on MySQL tuning for web apps (useful for everything I do), HacDC (a group of people playing around with tech in the DC area), and very excitingly, Apps for Democracy-- a project to take all of Washington, D.C.'s data, now publicly available, and create useful applications based on it. I hope their project does well; if I had more free time, I might even join it.

One of the interesting experiences I had at the camp was the ability to watch what everyone at the camp was thinking in real-time, through examining their Twitter feeds; while a lot of people make fun of twitter as "too short to be useful," it was actually a great tool to see how all five simultaneous sessions were going at any one time, as well as to communicate between attendees (many of whom didn't know each other beforehand; instead, everyone simply included the hash code "#barcampdc" in their Tweets, and people could monitor occurrences of that to see what everyone was twittering about). I haven't used Twitter at a live event before, so that was a first for me as well.

So a great conference overall, and great people throughout. I even found out about another unconference occurring soon, and closer to home: SocialDevCampEast happens in just two weeks at the University of Baltimore, and since both my job and my thesis revolve around the social web, I hope to attend that as well.

Last post, I discussed the set of projects I had to accomplish this semester/year. Since that time, in between my mother coming to visit, various installments of homework, and needless drama with JHUMagic, I've managed to get some major work done on one of them: Mnikr.

As I mentioned, Mnikr (pronounced "Moniker," which, as it turns out, some people don't know how to pronounce either; it's mawn-ih-ker, like "Fawn Is Curled") is the overarching name for the work I'm doing for my Master's thesis this year. It is also, however, a set of useful tools I hope to build to solve a variety of issues that have been annoying me. The first component of Mnikr that I've built is Mnikr Cards, at Cards.Mnikr.com.

Mnikr Cards is a pretty simple, and yet (I hope) elegant, solution to a problem of the modern era. When I want to give someone contact information, I don't really have a great way to make that happen. If I'm carrying them (and I try to), I have a set of Moo MiniCards that I can give out; they've got my stylized picture on the front, and a bit of contact information on the back (just a name, email address, website, and GPG key). This is fine, and I like having them-- but that's all they do. Also, a surprising number of people are put off in some way by their small form factor; while I think it's unique and different, people seem to want to make sure that their stacks of cards can all align neatly, and my cards prevent that.

So style is one problem, and obviously, I could solve that by just printing the same information on a full-sized business card. That would not, however, solve the next problem: a printed card does only one thing. Once I've sent them to the printing presses, that's it; they're finalized, and no matter how much I want them to transform to a particular need-- say, if I have someone to whom I want to give a different email address, or who I'd like to send straight to a resume, blog entry, or LOLcat-- they won't change.

The third problem, although not one often thought about either by me or my disreputable Web 2.x friends, is simply elegance; my MiniCards, while "cute," aren't really elegant. They aren't appropriate, say, for an extravagant soiree. (Do I ever go to these? No. But it's the principle of the thing.) They're too business-y for many things, I can't use them to convey other sorts of messages, they're too wordy (even with their stated minimalism), etc.

To solve this last problem, we can turn to a previous age; social cards used to be the accepted norm for gentlemen (and ladies) to carry for precisely this reason. A whole system of mannerisms and codes grew around them; that link is to a good article on all of it. This doesn't solve the problem of static content, however; even though they're now the right size, and more elegant, they're still printed on bits of dead tree.

Mnikr Cards, then, steps in to provide the full solution. It's a web service that generates unique URLs for users; each can be individually customized to provide a unique message to whoever accesses that particular URL. Each URL can be tracked by its user (to see if it's been accessed), reassigned, or destroyed at any time, and the URLs are random, to prevent people from finding them merely through snooping (as is possible, say, with TinyURL). The coup de gras, however, is that it's tied to the Moo API, allowing users to send a batch of cards (up to 50) to Moo to be printed. The style is very understated by default-- just a name and URL, as you can see here-- but people can add additional things to the flip side of the card. (Eventually, I'll add in more customization options to the application; at the moment, however, nothing stops someone from using it for URLs and making their own tokens.) The URLs themselves can contain a note of any length, a URL, or both, allowing for a wide range of possibilities for their use. There's also no indication on the URLs of the username (or even actual name) of the person responsible-- so they can be used in many situations in which disclosure of a variety of contact information is undesirable. (Do you really want to give your work email address to any person you meet?)

The whole thing, of course, is also OpenID-enabled, so it can just fit neatly into your corner of the social web; no need for yet another username and password for a site you might not use every day.

Hopefully some people will find it useful, or at least interesting; I've already started to use these cards for a few things, which I find quite enjoyable. For my part, it's now time for me to move onto the first "thesis-y" stage of Mnikr; hopefully I'll post something fun about that soon, and post something else entirely sooner.