I'm sure this stuff might work great, and the Chingjing Veteran's Farm where it's sold is worth a trip if you're in the area in Taiwan, but I'm not sure the extremely straightforward packaging would work so well in the U.S. And yet, on the long list of bizarre stuff people willingly smear all over their faces in the name of beauty, sheep placenta isn't even the strangest.
Earlier this year, a friend of mine parked her car at a meter in downtown Chicago. Unfortunately, she didn't notice that the meter was in a no-parking-during-rush-hour zone, and while she was away from her car, morning rush hour came and went. When she returned a few minutes too late to feed the meter, she noticed a shiny new ticket attached to her window and, thinking it was for the expired meter, figured there was no longer much point in filling the meter and went back about her business. When she returned again, she found another ticket – this time actually for the expired meter.
Modern highwaymen give receipts.
Now here's the interesting part: both tickets were issued by the same officer, from the same ticket pad. Each ticket on a pad has (I assume) a monotonically decreasing ticket number printed on it. Each ticket is timestamped. The tickets were for $60 and $50, respectively – and the most common offenses and fine amounts are conveniently displayed on each ticket. Some fines are significantly more than $50-60, but I'd bet a lot more $50-60 tickets are given out than $200 ones. So let's call the average fine amount $55. We have here a perfect opportunity to use simple math combined with liberal assumptions to speculate wildly – one of my favorite hobbies!
For privacy reasons, I've masked out the license plate on each ticket, along with most of the digits of the ticket numbers (which could have been used to look up the license plate from the Chicago Department of Revenue's web site). But I've left in the digits of the ticket numbers that actually differ between the two tickets – the leading several digits were the same on each ticket. So – between 8:49 AM and 11:03 AM, this particular officer handed out 45 tickets, doing an average of about $55 worth of damage each.
Do the math: On a January morning earlier this year, a single meter maid was raking in over $1100 an hour for the City of Chicago. The city can and does legally mug its citizens to the tune of tens of thousands of dollars every hour of every day – and is still projected to have a budget deficit of (at the low end of the available estimates) over $200 million in 2010, even after budget cuts, furloughs, and selling out Chicago's parking meter rights for the next 75 years for over a billion dollars. You can draw a lot of different possible conclusions from these facts, none of them very flattering toward Mayor Daley or any of the other folks who run the City of Chicago – to put it mildly.
On a completely unrelated note, according to the 2010 City of Chicago Budget, Booters (the pleasant people who have decided to spend most of their days ruining the days of others, professionally) earn $29.60 per hour. If you assume each booter works a few hours less per year than the average for employed people in the United States – say about 1800 hours per year – that means that Chicago booters earn more than CPS teachers with a Masters degree. Differences in benefits and retirement packages almost surely put teachers ahead in compensation, overall, but the fact remains that in Chicago, being a high school drop-out and professional asshole pays nearly as well as going into debt to earn two college degrees and dedicating your life to doing right by children and ceaselessly working for social justice.
Why am I not surprised?
I was in the Barnes and Noble in downtown Naperville, IL over the weekend. I brought my laptop with me to get some work done in the café.
It sucked. Here's why:
Downtown Naperville Barnes & Noble to customers: F*#@ you.
I hope the downtown Naperville Barnes & Noble will get its act together some day – in the meantime, there are plenty of local alternatives with free wifi, rafts of available power outlets, and better music. And never forget that there are folks out there with real problems.
Pandora Radio is where I find most of my new music these days. When I hear a song I really like for the first time, I bookmark it, and usually end up going over my bookmarks sometime later and buying a lot of the tracks on Amazon. Unfortunately, the big music companies, for reasons unfathomable to sane and rational people, are still trying their hardest to prevent anyone from buying their music, and have mandated a 6-track "skip limit" for Pandora. Looking for new music, and already own (or dislike) the next few songs Pandora plays? Tough – after 6 skips (12 if you switch stations), you're stuck with whatever happens to be playing.
Well, I think that's pretty stupid. If you'd like to get your 6 skips back after you've used them up, here's one way to do so. Generic instructions for any browser first:
This takes advantage of the fact that Pandora allows anonymous listening for a period of time. It probably doesn't work with a registered account (because your skips can be tracked with more persistent server-side state). So you won't get to save stations, bookmark songs, etc. But if you really want to skip more than 6 times in a row, you can. As a special bonus for Safari users on OS X, here's a bash shell one-liner that'll accomplish steps 1 and 2 for you automatically (this deletes some files and is potentially dangerous if copy/pasted incorrectly – be careful):
export PATH=/usr/libexec:$PATH && export C=$HOME/Library/Cookies/Cookies.plist && PlistBuddy -c print $C |awk '/Domain =/{x++; print x-1,$0}'|grep ".pandora.com"|cut -d ' ' -f 1|sort -rn|xargs -I "{}" PlistBuddy -c "Delete :'{}'" $C && find ~/Library/Preferences/Macromedia/Flash\ Player/\#SharedObjects -name "pandora.com"|xargs -I "{}" rm -rf {}
For the curious, Safari stores its cookies in .plist format, which can be primitively read and manipulated by a command-line utility that comes with OS X called PlistBuddy. Due credit to this code snippet for hints on how to use it to delete cookies. Safari's cookies are stored in ~/Library/Cookies/Cookies.plist . Flash stores its cookies in ~/Library/Preferences/Macromedia Flash Player/#SharedObjects/ .
As far as I can tell, none of this violates Pandora's Terms of Use. The closest prohibition is one against "[circumventing] any technology used by Pandora or its licensors to protect content accessible via the Pandora Services or the Licensed Application", but I'd really like to see someone argue with a straight face that a user cleaning out his or her browser cookies counts as "circumventing technology". Then again, these are record companies we're talking about – if anyone would try it…
A colleague of mine recently asked if I knew of any applications that would allow him to save and backup voicemail off his iPhone. He had found The Missing Sync, but frankly $40 is a bit steep just to save voicemail; he didn't need to do anything else.
A quick search turned up an article describing how to save voicemail from a jailbroken iPhone, but nothing so simple for a non-jailbroken phone. The article did, however, drop a clue: voicemails are stored in AMR format.
iPhone backup files are conveniently all stored in a directory named for the phone's ID in "~/Library/Application Support/MobileSync/Backup/". The files all have a .mddata or .mdinfo extension. Could any of them contain an AMR file? According to the AMR format RFC, plain, single-channel AMR files should start with the ASCII string "#!AMR\n". A simple grep revealed that several files in fact contained the AMR header. As it turns out, Apple has politely stored each voicemail in its own, separate file – no file carving is necessary to extract the voicemail.
It's so simple to find the voicemail in an iPhone backup, it can be done with a bash shell one-liner (credit to Seren in the comments for finding a slightly more compatible "find" syntax):
pushd ~/Library/Application\ Support/MobileSync/Backup ; for I in `find . -name *.mddata -exec grep -la '#\!AMR' {} \;` ; do cp $I $OLDPWD/`basename -s mddata $I`amr ; done ; popd
That'll copy all the voicemail for the current user's iPhone(s) to the current directory, named with a .amr extension. (Both QuickTime and iTunes can play .amr files.) Note that this can take a minute or two – so be patient for at least a couple minutes if it looks like nothing is happening.
For those less familiar with bash, I'll break down the one-liner a bit:
pushd ~/Library/Application\ Support/MobileSync/Backup ; \<br />
for I in `find . -name *.mddata -exec grep -la '#\!AMR' {} \;` ; \<br />
do cp $I $OLDPWD/`basename -s mddata $I`amr ; \<br />
done ; \<br />
popd
1. pushd changes the current directory and stores the previous current directory in the $OLDPWD environment variable. The "Application Support" directory has an unfortunate space in it, which makes it a bit tougher to throw around pathnames using it without getting the escaping just right – I didn't want to bother with it.
2. The find command looks for only those files that end in .mddata to save a small amount of time (there are no voicemails in .mdinfo files) and then passes each to grep. grep is used to look for files with the AMR header; the -la options are used to quit looking through a file after the first match (again, this is for a small speed improvement – the AMR header ends with a newline and must be the first thing in an AMR file, which means grep is able to move on quicker on the few files that match) and to treat files as text.
3. Use basename to strip off the .mddata filename extension so we can make a copy of the .mddata file with a .amr extension.
4. End of loop.
5. popd restores the current directory to the original working directory.
There are tons of different ways of doing the same thing; I tried for a little while to find one that was functionally equivalent (using xargs rather than a for-loop and bash substring manipulation rather than basename, etc.) but would fit in a Twitter update, but alas, I'm not a bash expert, and failed. If you can come up with a shorter one-liner, feel free to leave it in the comments. It needs to be general (it can't assume a specific iPhone ID, for example), and needs to assume a very large number of files in the backup directory (such that "grep '#\!AMR' *" would likely fail due to "*" being too long; that happens to be the case for me). Other than that, have fun.
