How NOT to recruit software engineers

After going through Stanford's recruiting process for a summer internship for the first time (and having been contacted sporadically by headhunters for quite some time), I've been genuinely disappointed in a select few of my interactions with recruiters. A certain subset of recruiters commit some boneheaded errors that one might think would be precluded by an iota of common sense. These missteps waste my time and give the recruiters' respective companies a bad reputation with the students. Additionally, I have no reason to think my experience is unique amongst my fellow engineering student peers. Since my blog is actively read by thousands of recruiters worldwide (well, maybe not, but I'll pretend like it is anyway) I have resolved to better their recruiting process by providing them a few helpful tips on what NOT to do when trying to gather talent:

Schedule appointments unilaterally
Remember, the applicant's life already revolves around your company, so have no qualms about telling him when an interview will be. Never take his schedule or conflicts into account. Never ask if he can make an appointment, simply assume he can.

Don't keep appointments
If you schedule an appointment with a recruit, make sure you do not show up. Optionally, show up at a different time and/or place. The same goes for phone calls: try calling at a different time than which you promised.

Don't follow up after interviews
Feel free to cut off contact with the recruit at any time, for any reason or without reason. Resist closure for the applicant. Never tell him if or why he was or was not accepted for the position.

Strive for an inconsistent message
Make sure the recruit has multiple contacts at the company, and make sure each of them is sending him a different message. Give him the impression that working for your company will entail functioning within a hopelessly mismanaged bureaucracy.

Be annoying
Clog the recruit's inbox with as much irrelevant information as possible. Send multiple copies of the same email. Send the same message over several different mediums (phone, email, pager, carrier pigeon, etc.). Ensure that mandatory forms are filled out multiple times. Redouble your efforts after the recruit says he is not available or not interested.

Treat the applicant like a number, not a person
Make sure the recruit knows that he is just another anonymous cog in the corporate machine. Send out obviously templatized emails that start with things such as "Dear $applicantName." Never make exceptions for an individual's extenuating circumstances.

Never apologize
No matter how badly you screw up, never acknowledge that you did anything wrong. Refuse to apologise. Stand your ground, especially in the case of overwhelming evidence to the contrary.

On a related note, if you are a recruiter/interviewer and wondering what you should be doing, please read the authoritative documents on recruiting and interviewing from the Joel on Software blog.

Dispelling Google Latitude Privacy Hysteria

Google recently came out with a new service called Latitude which allows people to share their locations with each other via a Google Maps interface. [1] Almost immediately, talk about privacy concerns dominated the dialogue concerning Latitude. These fears, upon closer scrutiny, are largely baseless. Latitude does not present a significant danger to users' privacy; any suggestion otherwise is mere technophobia and headline-grabbing Google-bashing.

The most important point in this entire conversation is that your cell phone is already a tracking device in and of itself. Carrying around a cell phone surreptitiously exposes more personal information than Latitude could ever dream of doing. The GPS, wireless Internet, and cell phone signals that emanate from your phone can be used to locate you any time your phone is on. The cell phone companies, obviously, know your location because they need it to deliver you service; the government can get it via Triggerfish or by just asking the phone companies. But a phone can be used as more than just a locator -- it can also be used as an eavesdropper. Consider the well-known NSA surveillance program that slurps up cell phone conversations, or the ability of the government to listen to whatever noise a cell phone picks up even when it is powered off. If you are seriously worried about your privacy, you won't even be carrying around a phone in the first place.

Google Latitude can not honestly be called a privacy threat because it is opt-in at every level and gives one the opportunity to leave or disable the service at any time. For another person to have access to your location, you must 1) explicitly enable Latitude 2) request the other person to receive your location via Latitude or accept a similar request from him 3) not turn the service off. Disabling the service can come in the form of either opting out of Latitude entirely or hiding your location temporarily. You can even enable a 'city-level-only' location option, which only shares your location to the town level of granularity, or set a manuallocation that doesn't move. (Your mobile location can be exactly determined only if you install Latitude on your mobile phone as opposed to using the stationary option.) Again, no one besides the group of people you explicitly agree to share your location with can see your location.

The example scenarios that have been raised by Privacy International with regard to Latitude's purported privacy degradation that have captured headlines are pretty far-fetched. All of the scenarios involve a malicious user creating a Google account, enabling Latitude on a phone and giving the phone to someone else with the intention of tracking them (without, of course, informing them that Latitude is enabled on the phone). Any reasonably competent person would quickly discover that Latitude was enabled on the phone, if he had not inspected the phone in the first place when he initially received it. There are many other major invasions of privacy taking place elsewhere, and Privacy International would do well to raise a stink about those issues rather than chase windmills at the Googleplex.

There is a legitimate privacy concern that Google will store the history of a user's location, which could be used to construct a profile of where a user was at certain points in time. However, Google states in the Latitude FAQ that this is not the case: "Google Latitude only reports your last updated location and does not keep a history of previously reported locations." As long as Google keeps its word in this regard, and I believe that to be a reasonably safe assumption, there is no privacy danger here.

It is unfortunate that so much ado has been made about a service that is essentially a useful visualization of your friend group. [2] Google Latitude is a service that you should have no qualms about using, provided that carrying around a cell phone does not make you queasy.

============================
Footnotes:
[1] As several other commentators on Slashdot pointed out, Google is not the first company to offer this kind of service (Brightkite, Loopt, and Mologogo to name just a few).

[2] One could imagine other use cases: giving truckers cell phones to track their shipments, planning visits to friends based on their proximity to a certain destination, serendipitousmeetup opportunities with nearby friends, etc.

iPhone App Pyramid Scheme Plan

Where is the next fertile soil for a pyramid scheme? Why, the iPhone Application store, of course! Following these few easy directions, you can scam millions of yuppies for fun and profit.

How: First, create an iPhone Application with some kind of cheesy social-networking appeal (e.g. 'How many friends do you REALLY have?'). It doesn't really matter what the functionality of the app is as long as each install of the app is assigned a unique identifier. The buyer will enter the id of the person who referred them to the app. In this way, an n-ary tree can be constructed (with you at the root) of subsequent referrals and installs of the app. Motivate the spread of the app by promising some amount of money to a user every time someone else buys the app and enters the his or her 'promo code.' Price the app such that you net the difference of the cost of the app and the amount you are paying out on each install.

Why it will work: People who purchase iPhones have a proven record of buying a lot of iPhone applications with their disposable income. It is perfectly reasonable to believe that many of them would not mind spending a few bucks more to purchase another novelty application (indeed, some have proven that they will spend a great deal for a novelty application / status symbol). Second, sites like Facebook have proven users' insatialbe thirst for social applications that connect them to their friends/coworkers/strangers/etc. Many of these applications exploit some kind of emotional dynamic (for instance, who are your 'Top Friends'?) to appeal to users. The sucess of these applications leaves no doubt that other appeals of the same kind would find an audience. Third, the iPhone App store provides a quick and easy means of distribution and, presumably, payment. Finally, every pyramid scheme exploits people's motivation for profit, a powerful motive indeed.

Variables: The setting of a reasonable price and payout is critical. Ask too much and nobody will buy the app; ask too little and you won't make much money. Promise too much as a payout and you won't make much money, promise too little and the app will not virally spread. Another important decision is the appeal of the application -- how are you going to convince uses to buy the application in the first place? What is the most compelling social/emotional/psychological/whatever message that you can send to them that makes them want to buy? Going hand in hand with that, what does the application actually do? Does it simply redirect to a web page showing some statistics of who has recruited the most people to the scheme, or does it have something more sophisticated?

Unknowns: Apps need to be approved by Apple and can be yanked by Apple at any time, with or without explanation. The app needs to be written in such a way that it does not appear to be something that Apple would find questionable. The legality of these practices is another issue. Depending on what the function of the application is, you might be able to make a case that you are actually delivering a product to the user. Another unknown is the most effective way to move many small payments of money between people, and what kind of cost is incurred for those services.

Funny UNIX tricks from Slashdot

There was a recent story on slashdot about useless (or useful) things one can do in UNIX. Being a command line junkie, I read through virtually every comment (all 2300+ of them) to learn some new tricks. Here are some of the better ones:

Bash History

• history -c # clear history (good for preserving privacy/passwords, or check out the more precise -d option)
  
• In vi command mode, type /query and hit Enter to search history, n to keep searching backwards, N to search forwards

vimdiff

• vimdiff original_file patched_file
  
• unified format: open original file, then :vertical diffpatch path/to/diff

Encryption

• openssl aes-256-cbc -a -e -salt -in INPUT_FILENAME -out OUTPUT_FILENAME # encrypt
• openssl aes-256-cbc -a -d -salt -in INPUT_FILENAME -out OUTPUT_FILENAME # decrypt
• echo Oe lbh pna vzcyrzrag UK tbireazrag fgnaqneq rapelcgvba jvgu ge | tr a-z n-za-m # Rot 13 encrypt/decrypt
  

Others:

• sleep 8h; cat /dev/urandom > /dev/dsp # alarm clock
  
• eject -T # close cd tray if open, open if closed (useful to find out which physical machine you are logged into)
• sl # punish users who accidentally type 'sl' instead of 'ls'
  
• eposd && say 'hello' # make the computer talk
  
• :(){ :|:& };: # forkbomb (space required between { and :) (protect against this with ulimit -u)
  
• for I in $(seq 1 100) ; do echo $I; sleep .25; done | dialog --gauge "PIZZA" 6 50 100 # Pizza timer via dialog

New MTV Video Site's Censorship -- Bleeping out Names of File-Sharing Software

MTV has just launched a new online video site. While I won't go through the trouble of mocking the site (or the TV network) for its irrelevance (please visit this slashdot thread for plenty of that), it is worth noting that it does have one feature that other video sites do not: in-video censorship! As this observant slashdot commenter says:

I was perusing this yesterday, and came across the Weird Al video "Don't Download This Song". One line in the original song goes:
o/~ Like Morpheus or Grokster or Limewire or KaZaA o/~

But the version on the new MTV site goes:
o/~ Like *beep* or *beep* or *beep* or *beep* o/~

Does anyone know if it was aired on MTV/VH1 this way, or is this unique to the web version?

MTV: http://www.mtvmusic.com/video/?id=108884 [mtvmusic.com]
Youtube: http://www.youtube.com/watch?v=Yz-grdpKVqg [youtube.com]

Update
More coverage: Slashdot Techdirt

Interesting New Perspective on DRM

While browsing a Slashdot thread about a purported "open-source DRM" product I came across an interesting comment by a guy named Sancho. While I had always viewed DRM as a uniquely new development, he ties it to practices that have been occurring in the recording industry for some time:

I tend to think of it as ensuring repeated sales of their art throughout their lifetimes.

For a while there, ensuring this was as easy as making sure that your music was released on the format du jour. Records, 8-tracks, cassettes, CDs.... With the advent of digital music sans a physical medium, this trend of rebuying all of your albums is at risk. Suddenly, you're faced with customers never having to rebuy the White album, and you see your sustained profits going down the tubes.

DRM solves that. Now, rather than coming out with a new format every few years, you just have to come up with a new DRM scheme and turn off the old servers. Because the devices playing the music are somewhat general purpose, it's easy to move quickly--you don't have to worry about market penetration for the players, because it's just a free software update away.

One small point: in the old days, format upgrades, say from tape to CD, often brought with them added benefits (better sound quality, more convenient access to songs, larger storage space, etc.) so there were actually justifiable reasons to upgrade. Now, switching from one DRM-encumbered format to the next offers no such incentives for the consumer.

wmctrl and friends

wmctrl seems like an awesome utility. I first read about it in Kyle Rankin's Linux Journal column here. The wmctrl project page also has links to a bunch of other desktop-automation and related utilities. This is all going in the "to learn when I have some spare time" file along with screen.

Critique of Zittrain's "The Future of the Internet and How to Stop It"

One book that the technorati have been talking about recently (ok, not so recently... it took me a while to write this article) is Jonathan Zittrain's The Future of the Internet and How to Stop It. For a book written by a co-founder of the Berkman Center and someone who is a remarkably good speaker, I found the work to be disappointing. The book's argument is not convincing and the writing seems to lack discipline, often wandering from one loosely related subject to another.

Zittrain's main point is that the security failings of generative technologies will push consumers to buy more restrictive, and supposedly safer, devices. This claim has a number of problems with it. The first is that tethered devices are not safer or more secure than generative ones -- in fact, normally the opposite is true. Compare the number of vulnerabilities in the Windows operating systems vs the number in Linux or BSD operating systems. Or bugs in Internet Explorer vs bugs in Firefox. This claim is even more dubious the more control the manufacturer has over the device: Richard Stallman points out in his response to Zittran that the iPhone's remote kill-switch makes the iPhone "designed for remote attack by Apple."

The second problem with Zittrain's principal claim is that a consumer has no incentive to prefer a non-generative device. Since non-generative devices are less secure than generative ones, any purported advantage that the non-generative device manufacturer could claim is lost. There is empirical evidence to support the belief that consumers prefer generative devices --Stallman cites the number of jailbroken iPhones as an example. Roger Grimes adds in his response: "It’s hard to say that closed systems are taking a more prominent role when open examples abound. Even the 'closed' systems he mentions are becoming more open thanks to competition and customer demand."

Even if, for the sake of argument, locked-down devices were somehow more secure than generative devices, consumers wouldn't necessarily migrate to non-generative appliances because users rarely make purchasing decisions based on security. Most computers are purchased because the user is comfortable with the platform or because he thinks that the computer is pretty or because that particular computer is necessary to run some type of software. Rarely will a run-of-the-mill consumer take into account a record of operating system vulnerabilities or the pros and cons of different systems architectures when deciding between OSX and Windows.

There are other shortcomings of the book besides the weakness of the main argument. For one, Zittrain mistakes generativity as being a zero-sum game: something is either generative or it isn't. There is a continuum of generativity: for instance, Linux is more generative than Windows XP, but Windows XP is more generative than Windows Vista. It is a fallacy to simply assume that all products fall into one non-generative bucket or the other generative one.

For a book whose title suggests solutions to the problems with the Internet, Zittran's ideas underdeliver. Virtual machines, extra-legal incentives, data portability and network neutrality are all things that are familiar, and have been, to policymakers and programmers for a while. In a book such as this which only worries about theoretical overtures and not about the detailed technical implementation, more out-of-the-box, grander thinking and proposals would have been welcome.

The book has a couple of chapters that feel decidedly out of place. The final chapter regarding privacy and the chapter exploring Wikipedia both don't seem to fit in to the framework of the book. That being said, both are certainly worthy of scholarship on their own merits. I particularly found the chapter on privacy engaging, if not particularly relevant to the rest of the book.

Zittrain's book is still worth a read: it addresses areas of concern in today's Internet and references much interesting material. The end result, however, is unconvincing and disappointing -- keep a few grains of salt handy when reading.

=========================================
REFERENCES / FURTHER READING

Jonathan Zittrain
http://bostonreview.net/BR33.2/zittrain.php
"Protecting the Internet Without Wrecking It"

Richard Stallman
http://bostonreview.net/BR33.2/stallman.php
"The root of this problem is software controlled by its developer"

Bruce M Owen
http://bostonreview.net/BR33.2/owen.php
"As long as flexibility has value to users, suppliers will have incentives to offer it"

Roger A Grimes
http://bostonreview.net/BR33.2/grimes.php
"Fixing Web insecurity requires more than a caring community"

Hal Varian
http://bostonreview.net/BR33.2/varian.php
"Ultimately, the best protection is an informed buyer who demands openness"

Susan Crawford
http://bostonreview.net/BR33.2/crawford.php
"In the eyes of many exiting institutions, security isn't a problem -- it's an opportunity"

David D. Clark
http://bostonreview.net/BR33.2/clark.php
"We need to develop a socially embedded online experience"

Jonathan Zittrain
http://bostonreview.net/BR33.2/zittrainresponse.php
"The best solutions don't assume a zero-sum tradeoff between security and generativity"

Coverage on BoingBoing

Ars Technica review and interview

Watch High Quality YouTube Videos by Default

Explained here. Man, I missed the boat on this one... it's been out for half a year!

Cool Gmail Feature -- Periods do not Matter

It's true: john.doe@gmail.com is the same email address as johndoe@gmail.com as far as Gmail is concerned. And to think that everyone makes such a big fuss about making sure you have that period in the right place when they give out their emails...

This feature is documented in Gmail help here. Gmail even idiot-proofs this feature by having a link to the docs when you receive an email at a different address from the one you registered (see photo).

Some have used this feature to their advantage to reduce spam or create multiple accounts on a web service that all send mail to the same Gmail address.

Thoughts on Facebook and Privacy (or Lack Thereof)

After watching a DEFCON 16 presentation about the vulnerabilities in social networks, I reflected further upon Facebook and the privacy it offers you and me, which is close to nil. Your guarantees to privacy on Facebook depend on a multitude of assumptions, all of which are quite poor. [B]

First, you are trusting that the Facebook developers have implemented the privacy controls correctly such that there is no inadvertent information leakage on the site as a result of bugs. I write code for a living, and let me tell you, bug-free code does not exist. Facebook, like other applications, has had its share of bugs to scramble to fix in the past (including at least one truly amateur mistake) and the future will be (and the present is) no different.

Second, you are assuming that you can configure the myriad privacy options correctly such that every piece of information on your site is accessible to only those that you want it to be. Are you really sure that marking one person as only being allowed to see your limited profile and specifying that picture as globally viewable, for example, will turn out the restrictions you desire for the correct people? How can you tell which preferences override which? It would certainly be tedious to register other accounts (or use friends') and test various combinations of privacy features against their profiles and I am not aware of anyone that does this.

Third, anyone that can see your information is capable of leaking it to the public. [A] With the addition of every friend you are increasing the chance that your pictures, contact info, videos, etc. will be posted and shared outside of the Facebook walled garden. It is simply not possible that each of your 500 friends is not susceptible to give away information that you thought was just between you and them, especially when they have some kind of (monetary or otherwise) incentive to do so. The scenarios of a rival political party digging up dirt on a candidate and gossip magazines researching what someone did last night both come to mind.

Fourth, all of your information can be accessed by any Facebook engineer or executive who choses to do so. The engineers likely need access to real-world pages to debug their code, and the managers can order information from a compliant underling (if Facebook doesn't have internal tools set up already for them to access this information). And let's not forget everyone else that works there (sales, PR, HR, etc.) who can request your personal information as a favor from an engineer friend.

Fifth, just as with any other website, information on Facebook can be subpoenaed in a trial. Facebook, needing to comply with the law, will gladly turn over your personal information to any judge who so wishes.

Sixth, let's not forget the countless ways Facebook could involuntarily compromise your information. A malicious hacker could slurp down personal data off the site. A Facebook employee could negligently leave an unencrypted disk drive with your information on it in a public place. Etc.

The only conclusion is this sound advice: don't put anything on Facebook that you don't want to be exposed to the world. Because chances are, sooner or later, it will be.

Footnotes:

[A] This is, of course, assuming that your group of Facebook friends can not be considered 'the public.' With the amount of friends some have, and especially one's willingness to accept any request that comes their way and fire out friend requests at random, this distinction begins to blur.

[B] I was going to add this post to my Facebook Sucks article but it became too long and I thought it deserved a post of its own.

Updates:

Here is a post for those that want a HOWTO for micromanaging their privacy settings on Facebook. (Even Schneier likes it).

Here is a Slashdot story about a court demanding Facebook information pursuant to a case

DEFCON 16

DEFCON 16 was awesome, as expected. Some highlights:

• The first presentation I went to was called "Hacking in the Name of Science." Here a bunch of University of Washington grad students and a professor discussed the sweet research they are doing, almost all of which has been in the news (Implicating 'downloading' printers to the RIAA monitors, RFID ghost proxies, TCP information leakage, voting machine vulnerabilities, TrueCrypt vulnerabilities, implantable medical device hacking, ISP injected ads, etc.). They discussed the difference between just hacking and what you need to do in an academic setting to study what anyone else would call hacking. They encouraged attending academic security conferences, such as ACM CCS, NDSS, IEEE Security + Privacy, HotSec and Woot
  
• A talk entitled "Satan is on my Friends List" detailed the security vulnerabilities in OpenSocial-enabled websites. These guys demonstrated some hilarious things, including using a CSRF DOS attack: using an img tag placed in an html-enabled form that displays on a page, you can automatically logout anyone that sees that img by pointing the img's src attribute to the logout page. The speakers talked about how the socnet widget applications space is essentially a security free-for-all: apps hacking personal information, apps hacking other apps, etc. An opt-in security model for javascript safety in apps exacerbates the problem. An amusing conclusion to the talk was the speakers' impersonation of another security researcher on social networks which fooled his colleagues and family alike.
• Locksport enthusiast Eric Schmedl gave a talk that had some amusing anecdotes about cloak-and-dagger spying. Mary Lou McFate (NRA infiltrator of anti-gun groups), reconstructing passwords from audio of keystrokes, and multiple phone bugging technologies were discussed.
• Fyodor gave a talk on nmap, the tool he created and how he used it to scan a large subset of the Internet. He also presented some new features of the tool, including traceroute, ping, and netcat-like functionality... what can't it do?
• I briefly stopped in on a talk called "Taking Back Your Cellphone" which plugged the site HowardForums as an excellent resource for phone modification.
• The activity that I took part in for a fair share of my time there was the Lockpicking Village. I bought a set of lockpicks, and tried my skills on a variety of locks lying about the room. I also listened to talks on how to crack certain types of locks, including masterlocks (use coke can shiv, patterns for figuring out combo).
• Probably the most interesting thing that happened at DEFCON nobody got to see: a judge ordered a group of MIT students not to talk about hacking the Boston Subway system. This was rather pointless because 1) the presentation was distributed on CD before the gag was ordered 2) the ban was lifted after the conference 3) MIT's student newspaper put the presentation up on its site
• Other cool things: the badge, the mystery box
• Didn't see these presentations, but I looked at them on the CD:
• "The Death of Cash" features a preview of a world without cash. People are turning to credit because it is more convenient, banks love it because of better profit margins, government loves it because it makes you easier to track. (Note: Illegal to transfer $10,000 in/out of the country without declaring it). This is getting worse with stupid legislation (Patriot Act). Also, national security risk: electronic outages now mean that people can't get access to cash (even more troublesome as electric grid becomes less reliable). Strong crypto might be the basis of a future E-payment system. Advice: keep some cash on hand for emergencies, use non-cash as little as possible. thowlett@netsecuritysvcs.com says the presentation can be downloaded at www.netsecuritysvcs.com/presentations/defcon16/ but I don't see it there...
• An introduction to ham radio called "Ham for Hackers"
• A presentation on Javascript obfuscation that goes over the following methods: ASCII/Unicode escapes, XOR (ASCII/encoding), string splitting, simple encryption, non-obvious variable and function names, member enumeration, whitespace encoding/decoding
• Another presentation on SCADA systems that made me have nightmares
• A HOWTO on SSL cookie hijacking by Tor developer Mike Perry: insert an img tag with src mail.yahoo.com into an unencrypted connection and read their cookie, then save that cookie to cookies.txt and read their email (over SSL, if you want!)
• OCR tools: tesseract, jocr, ocrad
• A presentation similar to "Satan is on my Friends List" for Google Gadgets

Update:
Good photos of the event can be found here

Proposal: Free Parking through Self-Booting

San Francisco is a tough city to park in, so I've been scheming up some ways in which to get free parking... here's one thing I've come up with, but haven't had the guts to try yet.

1. Buy four boots (or more formally, wheel immobilizers).
2. Park in a tow-away parking zone.
3. Affix one boot to each wheel of your car.
4. Laugh at the people figuring out how to tow your car away seeing that they can not drag your car along on its back wheels nor wheel the car up onto a platform.
5. Return to your car at your leisure, detach boots, drive away.

Some things to consider:

• Boots are somewhat expensive, so the whole cost-efficiency of this scheme needs to be taken into consideration (price of tickets, if you plan to pay them, price of parking, risk of having car destroyed by angry tow truckers).
  
• I'm not sure what kinds of contracts tow truckers have with the city, private establishments, etc. If they are not liable for any harm that comes to your car, this probably isn't such a good idea, as the towers have no incentive to not damage your car trying to toe it away.
• Not paying tickets can bite you in the ass if the ticket-giver somehow manages to figure out your Vehicle Identification Number, usually found etched in various places in the car. Unpaid tickets can come up when you try and re-register your vehicle.
  
• Boots can be pried off... I'm sure this isn't the only way

UPDATE: Nothing to do with booting, but here's another way to get free parking in San Francisco, courtesy of Black Hat

HOWTO vertical display (X, Nvidia)

Here is how to get your monitor looking something like this (not my monitor, btw):




























Put this line as an option in the "Device" section of /etc/X11/xorg.conf: Option "Rotate" "CCW" Then, restart X with Ctrl+Alt+Backspace. Afterwards, start up sudo nvidia-settings and shuffle the screens around in X Server Display Configuration so that they are properly aligned. Be sure to press the Save to X Configuration File button.

Found via this forum thread and a tip from Arash.

Update:
Following is an xorg.conf file to get 2 Dell 2407 monitors in a T formation (with one on the left vertical and one on the right horizontal aka Rajiv-style). This setup has a few problems, though...
1) The screens are flush at the top, which makes a window across both monitors look disjointed... not a huge problem, and could probably be solved by tweaking the config
2) Can't seem to get compiz-fusion to work
3) Using Xinerama instead of Twinview is waaaaay slower, especially when an object is on both screens
4) Just feels too unnatural... I'm going back to both screens horizontal
It's also a bit hard finding helpful forum posts on these things anyways because everyone seems to misuse the terminlogy (Xinerama, Twinview, etc.) and problems are very individual (Depending on video drivers, screens, etc.). Anyways, here's the xorg.conf:

Section "ServerLayout"
   Identifier     "Default Layout"
   Screen      0  "Screen0" RightOf "Screen1"
   Screen      1  "Screen1" 0 0
EndSection

Section "Module"
   Load           "glx"
EndSection

Section "ServerFlags"
   Option         "Xinerama" "1"
EndSection

Section "InputDevice"
   Identifier     "Generic Keyboard"
   Driver         "kbd"
   Option         "XkbRules" "xorg"
   Option         "XkbModel" "pc105"
   Option         "XkbLayout" "us"
EndSection

Section "InputDevice"
   Identifier     "Configured Mouse"
   Driver         "mouse"
   Option         "CorePointer"
EndSection

Section "Monitor"
   Identifier     "Configured Monitor"
EndSection

Section "Monitor"
   Identifier     "Monitor0"
   VendorName     "Unknown"
   ModelName      "DELL 2407WFP"
   HorizSync       30.0 - 83.0
   VertRefresh     56.0 - 76.0
EndSection

Section "Monitor"
   Identifier     "Monitor1"
   VendorName     "Unknown"
   ModelName      "DELL 2407WFP"
   HorizSync       30.0 - 83.0
   VertRefresh     56.0 - 76.0
EndSection

Section "Device"
   Identifier     "Videocard0"
   Driver         "nvidia"
   VendorName     "NVIDIA Corporation"
   BoardName      "GeForce 7900 GS"
   Option         "Rotate" "CCW"
   Option         "NoLogo" "True"
   BusID          "PCI:1:0:0"
   Screen          0
EndSection

Section "Device"
   Identifier     "Videocard1"
   Driver         "nvidia"
   VendorName     "NVIDIA Corporation"
   BoardName      "GeForce 7900 GS"
   BusID          "PCI:1:0:0"
   Screen          1
EndSection

Section "Screen"
   Identifier     "Screen0"
   Device         "Videocard1"
   Monitor        "Monitor0"
   DefaultDepth    24
   Option         "TwinView" "0"
   Option         "metamodes" "DFP-0: nvidia-auto-select +0+0"
EndSection

Section "Screen"
   Identifier     "Screen1"
   Device         "Videocard0"
   Monitor        "Monitor1"
   DefaultDepth    24
   Option         "TwinView" "0"
   Option         "metamodes" "DFP-1: nvidia-auto-select +0+0"
EndSection

Keep SSH connections from timing out, client-side

Put these lines in ~/.ssh/config

ServerAliveInterval 300
TCPKeepAlive yes

txt2regex

txt2regex is an awesome tool that allows you to specify a regular expression in an interactive curses-based interface that is then printed out in a variety of formats, including English, vim, perl, etc. Perfect for when you know exactly what you want to match, but are not particularly knowledgeable about the idiosyncrasies of the current regex engine you're using.

Stop Spamming me with Corporate Birthday Cards

It is the time of year when my birthday is fast approaching and that means that I am receiving a few birthday cards, sometimes from parties from which I would not expect one. Some of these parties are not people, but corporations who happen to have my birth date on file for one reason or another.

In any other context, snail mail sent from a corporation to one's home mailbox for marketing purposes would be called junk mail or spam. Sunglasses Hut, et al. try and disguise the purpose of the letter (making you want to buy more of their products) by making the implication that they're corresponding out of consideration for you by politely remembering the celebration of your birth. Now, some may think that this is a genuine gesture of kindness, but I disagree. The entire point of a card is to remind someone that you are thinking about him or her and his/her particular situation. I find nothing personal or redeeming about being the recipient of a letter sent by a cron job at HQ once a year which was ordered by a marketing director that neither knows me nor has any reason to care about my circumstance save trying to extract more of my hard-earned cash out of my pocket.

In fairness I must note that, unlike most every other sender of birthday spam, Sunglasses Hut at least sent me a twenty-dollar gift certificate to their store. Considering that I don't need another pair of sunglasses and would hesitate to buy from SH again given this annoying practice, I find it small recompense for wasting my time and mailbox space with their spam.

I guess this can just be chalked up to another consequence of an age when more private parties are holding our personal data and are ever eager to exploit it for their own ends. It seems as there is no disincentive for corporations to send all the spam they want, I'll be receiving quite a few more cards from well-wishing chief marketing officers in the future.

bigshotcmo@sunglasseshut27:~$ crontab -l
# m h  dom mon dow   command
  0 0  1   *   *     ./send_birthday_cards_for_month

...

db.execute("SELECT * FROM customer WHERE MONTH(birthday) = MONTH(NOW())).each do |customer|
    Notifier.send_individual_card(customer)
end

...

Dear $customer.first_name,

Happy birthday!  You are super special to us!  Spend more money at our store!  
Thanks for providing us with your birthday!  Thanks to our expert DBAs and 
comprehensive database backup policy, we're able to retrieve your personal 
information on demand and sure to never expunge your data from our records.  
Have a nice day!

Love,

Moneybags
CMO

HOWTO Swap caps lock and escape keys in Linux

Caps lock takes up way too much space on a keyboard for how little (never) one presses it. Esc is a very useful key that gets pressed a lot (especially for vi users) but is rather far away and takes more effort to press in the corner of the keyboard. Here is how to switch the functionality of the two keys (solution adapted from the xmodmap manpage) in Linux.

Create a file called .Xmodmap in your home directory. Put the following text in the file:

!
! Swap Caps_Lock and Escape
!
remove Lock = Caps_Lock
remove Control = Escape
keysym Escape = Caps_Lock
keysym Caps_Lock = Escape
add Lock = Caps_Lock
add Control = Escape

Next time you log in, these settings should stick. If you want to switch the keys manually instead of on startup, run xmodmap .Xmodmap to do so. Loading the file again after you have loaded it once will switch the keys back to their original functionalities.

Btw, an informative discussion of all of this X customization stuff is found in chapter 6 of Unix Power Tools.

Google Experimental Search

Today I stumbled across Google's experimental page which has some add-ons to search that can be enabled. "Keyboard shortcuts" kicks ass: it's basically a vi-like interface to search. j to go down, k to go up, / to search, etc. It's really quite slick.

Although Google says that you can only add one of these experimental features at a time, "Keyword suggestions" is an option that can be enabled via the Customize Google Firefox extension. "Keyword suggestions" is a great feature as well.

The "Alternate views" options , on the other hand, are a heaping waste of time. Even the search results for the example queries listed on the page are unintuitive and uninformative.

Google also offers keyboard shortcuts for a lot of other products (Gmail, Calendar, Docs, Reader, Maps, Video), detailed here.

UPDATE: I actually disabled the experimental features. The vi emulation was not helpful enough... I could scan the page visually faster than my fingers could keep up. Furthermore, I missed the utility of Firefox's "/" to search the text on the page fast on a Google search result page.

Searching SVN trees with Ack (for Ruby on Ubuntu)

Searching through a subversion tree with grep is a pain in the ass. It wastes time searching through files I don't want to look into and its syntax is inconvenient for the task. Fortunately, there is a tool called ack which is suited specifically for matching text in VCS trees (including svn trees). Here's how to set it up on Ubuntu Gutsy (apparently you won't need to do all this in the next Ubuntu release; there's a package for Hardy).

First, you're going to need some relevant libraries. sudo apt-get install perl-doc to start. Next, download the File-Next archive from CPAN. Extract the archive and cd into the directory, then use the series of commands perl Makefile.PL && make && make test && sudo make install to install it.

Now for ack itself. svn checkout http://ack.googlecode.com/svn/trunk/ ack-read-only to checkout the source tree from Google Code and cd into the directory. Now if you want to edit some of the types that are built into the program, here's where to do it. For example, I want to also search for haml files with the --ruby flag. I grep -R rhtml * to see that four files (actually, less, but let's go ahead and edit all of them anyways...) require modification. The ruby line in Ack.pm, for instance, now reads ruby => [qw( rb rhtml rjs rxml erb haml )]. (Types can also be set on the command line using the --type-add and --type-set flags). Once you're finished tweaking types, use the same perl Makefile.PL && make && make test && sudo make install command to install ack.

For extra credit, you can also add flags to a ~/.ackrc file that get executed upon each invocation of ack. Personally, I add the --ruby flag because it seems to be that .rb, .haml and .rhtml files are all that I'm searching for these days.

And voila! Now a simple ack -f gives me a listing of all the ruby files in my svn tree (and no vi swp files, svn files, log files, etc.). ack "regex" returns a grep-like search of the relevant parts of the subversion tree with the parts of the line that matched the regex highlighted. SWEET! Get more information on the command line with ack --help for more help, ack --help type for a listing of matching types.

Do you know how hard this would have been with find/grep/xargs? Well, tough. grep -RE "regex" * | grep -v svn | grep -v log | ...etc... searches all files in the tree and might exclude matching lines if the contain one of the strings being filtered out by the later grep instances. That syntax can be improved to a alternating regular expression with grep -RE "regex" * | grep -v -E \(log\|svn\) but it still has the same problems. grep also has an --exclude flag which can exclude certain filenames that match a glob from being searched (although the manpage would seem to imply otherwise), but it doesn't have regex capabilities. So maybe we can use find and xargs? Nope, a svn tree output will kill xargs, which will compain that the "argument line is too long" if too much gets sent to it: grep -E "regex" `find . -regex '.*\.\(rhtml\|rb\|haml\)' | xargs -0` Perhaps find's --exec flag could be of use? Well, only if you want to kill your computer with the overhead of creating a new grep process and forking and context switching a couple times (etc.) upon each file match... find . -regex "regex" -exec grep -E "regex" '{}' \; will really do your cpu in. Then there's the cumbersome grep -E "regex" $(find . -regex "regex" | grep -vE \(log\|svn\)) ... well, let's just say I'm glad I found ack at this point.

UPDATE:
Put --type-add=ruby=.haml in your .ackrc to add haml as a type dynamically.