Amusing side effects of popular culture

As a result of Dark Knight, I'm now getting 40-50 hits a day to my personal site, featuring the joker cheesehead down on the left side there.

I was very confused as I watched the traffic spike, then I realized the movie came out.

Real-life Superpowers, part 1

Horses store up to 50% of their red blood cells and can release them during endurance running. Self-doping, with the larger hearts needed to deal with the thicker blood that results.

Ubiquitous call recording, finally.

https://www.speechtrack.com

I've been wanting a service like this for as long as I can remember. Now they just need to offer inbound phone numbers that auto-record, and maybe a transcription service or speech-to-text.

Git tricks I've been using a lot

• git add --patch

  Incredibly helpful for splitting up your patches into atomic commits.

  I use this like mad when I've made a few different types of changes between committing. (e.g. I find something that needs refactoring in the middle of adding a feature)

  For hairier tasks, don't forget it's older brother, git add --interactive, which launches a file manager shell with more options and better status info

• git stash apply

  Git stash is a wonderful thing, but people often don't realize that the stash is a stack, not just a single object.

  Using apply with an optional ref argument, you can pop things off the stack that date from before the most recent stash.

  I use this as a whole project undo/redo for things not worth creating a branch for

• git rebase --interactive

  Oh the power. If you pass the right revisions into git rebase --interactive, you can essentially go back and edit every single commit made in the repo.

  For extra fun, try nonlinear editing or cross-branch interactive rebasing.

  My primary use for this is to squash commits into useful units of functionality, particularly when updating a production branch or the equivalent.

  Caution: if you're publishing your changes to other people, using this can really piss them off. You can also drastically break your repo, so make sure you know what you're doing, or try it on a fresh clone

• git checkout -b branch_name remote/branch

  This is an interesting trick: you can create a local branch named something different than a remote branch, and set it to track the remote. Makes git pull work without having to specify a remote and branch to merge.

• git diff -Sstr

  This lets you pull out a change that relates to the string. If you want to see whole patches, play with --pickaxe-all, and for POSIX regex support use --pickaxe-regex.

  Useful if you ever want to see who's using that bad idiom that you want to crush out of existence, or if you need to go back and find a chunk of lost code.

Why you should always use SSH keys, not passwords

There are three main reasons for using SSH keys over passwords:

• Security

  Since SSH keys are stored on your computer and never go over the wire, they are inherently more secure than passwords. Even if you pick a terrible passphrase for your SSH keys (or none at all), an attacker still has to get ahold of that key (barring someone patching your random number generator to return one of 2^10 numbers...)

• Segmentation

  With passwords, if everyone needs access to an account on one of your servers, then everyone has to know the same password. If one of your coworkers goes insane, you have to change the password (and probably a lot more than one) whereas with SSH keys, you just remove their key from the authorized_keys file and they're gone, nobody else has to worry about it.

  Similarly, if people need access to some accounts and not others, you can segment access with keys much more easily than with passwords

• Speed

  Entering passwords gets old really quick. With the superb ssh-agent in use, you shouldn't ever have to do that, and as long as you remember to lock your computer when you leave it, you're as secure as if you were typing your password in every time

Recommendation Letter redux: how to write a letter of recommendation for a friend

Since I wrote this short joking post about faux pas in a friend's recommendation letter, I've been getting people asking me how to write a good recommendation letter.

For posterity and the Internet, here you go:

Content:

• Above all, be professional.

  Remember, your friend / colleague / student is submitting this for something that is very important to them. Probably the most important part is making sure that it reads like something you'd submit to a scholarly journal, not something you'd comment on their myspace page with.

• Be real.

  Talk about them as you know them: write about the qualities they've shown through the experiences you've had with them. Don't fluff, bullshit, or otherwise go further than your experiences can warrant.

• Advocate

  Remember, they're trying to get something from someone with this. That job, college admission, or grad school means a lot to your friend, and you have the ability to directly affect their chances. On the other hand, don't advocate so much that you're written off as a cheerleader.

• Be specific

  If prompts are provided, make sure you nail every one of them. If they aren't, think about what you'd want in someone working or studying with you, and nail those points. Particularly, make sure you talk about communication skills, work ethic, and creativity, since those are pretty universally applicable.

• Don't just talk about the good things

  Make sure you discuss ways in which they're not perfect. Talk about how they worked on their problems, how they changed for the better, and how they overcame obstacles.

• Get other eyes on it

  Before you send that make-or-break document off, have other people read it and give you feedback. A fresh set of eyes can catch possibly credibility-damaging errors before you have to apologize for them.

  In a pinch, drop me (Justin George) a note and I'll do a brain-dead check on it for you.

Style:

Stylistically, there are a couple things you want to make sure you do:

• Succinctness

  Write in short, complete paragraphs, and make sure each one has a topic. Limit yourself to a few sentences for each, and keep it punchy.

• Length

  Take the space you need, but don't be verbose. Imagine yourself in the shoes of the reviewer: you don't want to waste time, neither do they. I usually suggest that people aim for a page, two or three if you've known them for a long time or in multiple roles.

• Quality

  Sign it with real pen, on real paper, and mail it to them. People are silly creatures, and an authentic signature on good stationery will make it clear that you mean it.

  You do have good stationery, don't you? Everyone should have a few sheets of quality personal stationery for just such an occasion. Rag paper with a heavy feel shows you care enough to spend money on the people you're writing to, as well as the person you're writing for.

These are, generally, the same rules you should follow for all good writing. In fact, you'd do well to follow them for all official correspondence, including admissions letters and particularly thank-you letters.

If you're the one getting a recommendation, remember that it takes a lot of time and effort to write a really stellar one, so make sure you write them two letters: One to ask for a recommendation letter (Even if you're asking for a recommendation letter in person, it's a nice touch to follow up) and a second as a thank-you letter (both on real paper, following the rules above) and mean it. It will make you memorable in the future, and that can mean jobs, referrals, and other benefits, as well as a lasting friendship.

Bouncy visitors

Most simple websites and blogs have a really high bounce rate. Mine hovers around 95%.

So we lost 95% of the folks in the first three words of that sentence. Ouch.

Thus, you need to make the first words of the page good ones. One of the Portland bloggers I know just swapped out his Wordpress [Edit: Blogger! my bad.] default title text with a custom image and cut his bounce rate to one-tenth what it was.



So, that being said:

• If you have a site, think about the first thing people see.
• I'm going to go get myself a custom header

Migraine treatment tips

So I've learned (possibly more than I ever wanted to know) about migraines lately. Here's some tips if you're getting them:

1. Everyone is different, so this list isn't anywhere near definitive.
2. Nasal sprays don't work.
3. Neither do (normal) antidepressants. e.g. Prozac, Zoloft, Celexa, etc
4. Opiates (vicodin, percocet, oxycontin, etc) don't work. But they do make you not care which can be your last option at times.
5. Maxalt (rizatriptan) is pretty effective and works quickly. Maybe 3/4 of the time it can kill a migraine.
6. Supplements apparently can help prevent migraines. If you're getting more than eight a month, try petadolex / butterbur, riboflavin, coenzyme Q, or magnesium. Petadolex is sold in approximately the right doses (usually with riboflavin). Riboflavin you want 200mg/day twice a day. Ditto Coenzyme Q. Magnesium I'm not as clear what works.

Efficiency vs Efficacy

• Efficiency

  Efficiency is lack of waste. In some cases, it can mean "lack of waste of money" or "lack of waste of energy".

  Example: You're selling widgets, and you want to make the most money possible. This is an efficiency goal. Widget production cost = waste + materials + labor.

• Efficacy

  Efficacy is effectiveness. It can mean "level of coverage" or "level of positive outcome".

  Example: You're making a vaccine, and you want to make sure everyone gets it. Price is no longer particularly important, only the level of coverage. This is an efficacy goal. Number of people dead = ((people in population) / (people covered))^2 (since transmission is reduced, it's square-law-type)

For example, you want these to be efficient:

• Tax collection
• Luxury good distribution
• Financial services

You want these to be efficacious:

• Medical care
• Car safety
• Welfare services
• Fire and police services
• Education

Yahoo Pipes (Dataflow programming, but don't call it that!)

Pretty interesting stuff. If you've ever worked with LabView or VVVV (Windows-only, but a toolkit that deserves many posts of its own), you know how nifty dataflow programming can be.

I've just started playing around with Yahoo Pipes, late to the party again by about a year, and it's pretty interesting stuff.

As an example, I improved the Craigslist / Zillow mashup that was already on there to do multisegmented feeds (since craigslist limits you to 25 per feed) and to add query, min/max price, and county indicators, since I was interested in those as well.

Right now, it's pretty useful for comparing the real value of houses with the listings on Craigslist. If it's significantly different, be on the lookout for a bargain or a ripoff, or at least ask why it's different (remodels often mess up Zestimates).

Here's the link: Craigslist / Zillow mashup version 2 ( http://pipes.yahoo.com/jaggederest/clpricecheckv2 )

It's pretty typical of dataflow: It's easy to toss things together, but to really get into it you need to build new components, and apparently the only way to do that is via importing pipes, which is nice, but doesn't let me build 'if' statements as I'd like.

As a side note, dataflow is one of the other ways to achieve low-cost parallelism, and one that's often overlooked, I think. People concentrate on actor-model or locks far too often.

Tendency to Hoard stuff? A plan for piles.

I know I tend to pack-rat things. I often find it difficult to clear things up or clean an area out, even when I know most of the stuff in it is junk, or even just something I won't need right away.
Here's my method:

1. Clear it all out.

   It doesn't matter if it goes in a big pile in the middle of the room, just get it out of there. Put it someplace you can't stop until you're done.

2. Sort them out by quality or usefulness

   Ambiguous, yes, but it's really up to the person doing the sorting. Whatever criteria you use to decide whether to keep things when it's one-by-one, use it here, to group things into a set of piles.

   I usually use at least five. The goal is to have equal sized piles. (If you've heard of the bond market, they call this 'tranches', say AAA, AA, A, B, C, etc)

3. Put the first pile back

   Take the pile that is the top shelf stuff, and put it back where you started from. Make it nice, neat, and clean (good time to get dirt off, while it's empty).

4. Assess the situation

   Don't worry about all the other piles, just honestly assess the situation. Is the space clean? Is it clear? Does it have all the things you'd commonly use there?

   Sometimes with this part, it helps to get an outside opinion. Have someone you trust tell you whether it looks good, is cluttered, or is empty. If it's cluttered, split the pile.

5. If it needs more, go to step 3.

   Say you're organizing your drawing desk. Are all your favorite pastels still sitting behind you? Maybe you still need that ruler or the pens that haven't made it in yet. Time to go back, get another pile (the next-best one) and put it away as well.

6. Clean up the other piles

   Here's the fun part: By process of elimination, you've just decide what to store/give away/recycle without ever having to agonize over your favorite pincushion. You can trick yourself into realizing that you don't need so much stuff.

7. You're done.

   You've just reclaimed usable space, and, if you're like me, given away quite a bit to charity, which can take a nice bite out of your tax liabilities.

   Do this often enough, you'll realize how many of the things you thought were 'vital' to have out are really once-a-month or once-a-year items, too.

Git is amazing

So, today, I'm working on a project, I've got it all mocked out with some sample forms and some throwaway objects to play with.

I realize 'Hey, I need an authorization/authentication system', so I have a dilemma.

On the one hand, my code is throwaway that I plan to evolve to fit what I end up actually doing with it long term.

On the other hand, I really don't want to have to redo it later, since I'll probably want to come back here after I build out the auth/auth system.

Git to the rescue.

I've been doing all my development on the 'experimental' branch locally, as one ought to do.

git commit -m 'End of tinkering, time to get serious'

git checkout master #Back to the beginning,
#or you can use git checkout HEAD~x where x is how many commits you want to go back

#create the new branch and check it out
#equivalent of git branch restful_auth; git checkout restful_auth
git checkout -b restful_auth #which is a wonderful plugin, btw

# do your install here...

git commit -m 'All restful, now lets go back to the other'

git checkout experimental

git rebase restful_auth

# fix the conflicts, I had three

And you're done. You just saved yourself a couple hours of rewriting throw-away bits of your app. And of course, this is completely doable with pretty much any type of edit. You can go back into the past and effectively 'redo it right' without having to worry about the time it takes up front.

Ibuprofen, Naproxsyn/Naproxsen, and Aspirin: Don't overdo it.

My girlfriend just got out of the hospital after having a bleeding ulcer as a result of taking ibuprofen, among other stressors.

Just a heads up, any of you who read this, go easy on the ibuprofen, because the effects can be very bad if you are unlucky, and it is surprisingly common.

multiurl

like tinyurl but with multiple pages. Pop page with previews, ask users if they want to open all, one, some, or play slideshow-style in frame?

Perhaps a bookmarklet interface, along the standard HTML paste-in-urls.

Edit: Already exists, ManyURL, works nice from what I see. Could use a bit more, though! Too simple, not complicated enough.