After many years of calling 849 Fell Street home, my roommates Tom and Ted are moving out at the end of the month. Jeremy and I have been relying principally on Craigslist to find new roommates. Rather than direct incoming applications to either (or both) of our personal inboxes, we opted to create a new, special-use GMail account dedicated to our search (appropriately name 849fellstreet@gmail.com). That much isn't novel, but we've also developed a quick and easy system for categorizing and responding to applicants that I want to share.
As a CS problem, it would be natural to abstract the data into several tables: "roommates", "applicants", "ratings", "appointments", and "correspondences". In our case there are only two rows in the "roommates" table: Jeremy and me. Every reply to our Craigslist ad creates rows in "applicants" and "correspondences". Assuming Jeremy reads an application and likes it, it creates a row in the "ratings" table (e.g. roommate: 1, applicant: 37, rating: approve). One of us replies, creating a new row in "appointments" and another row in "correspondences". Phew. That's a lot of work, and coding that in Rails would take a non-zero amount of effort. That's why doing everything I just described in GMail is quite neat-o.
Because Craigslist correspondences happen over e-mail anyway, every GMail thread is a row in "applicants", plus >=1 row in "correspondences". Instead of tables for "ratings" and "appointments", labels can be used to track the status of applicants (e.g. JeremyLikes, JeremyPass, InterviewScheduled, RejectionSent).
Being a label-whore affords other useful tricks. Add the "Quick Links" Lab and save custom, frequently used queries. Here are some that are invaluable to us:
I hope this trick comes in handy the next time you need to categorize and search some data. One word of caution: as of this writing, there is a bug in GMail involving labels containing dashes (I switched to camelcase after many frustrating and fruitless attempts to fix my search queries). Good luck!
As a CS problem, it would be natural to abstract the data into several tables: "roommates", "applicants", "ratings", "appointments", and "correspondences". In our case there are only two rows in the "roommates" table: Jeremy and me. Every reply to our Craigslist ad creates rows in "applicants" and "correspondences". Assuming Jeremy reads an application and likes it, it creates a row in the "ratings" table (e.g. roommate: 1, applicant: 37, rating: approve). One of us replies, creating a new row in "appointments" and another row in "correspondences". Phew. That's a lot of work, and coding that in Rails would take a non-zero amount of effort. That's why doing everything I just described in GMail is quite neat-o.
Because Craigslist correspondences happen over e-mail anyway, every GMail thread is a row in "applicants", plus >=1 row in "correspondences". Instead of tables for "ratings" and "appointments", labels can be used to track the status of applicants (e.g. JeremyLikes, JeremyPass, InterviewScheduled, RejectionSent).Being a label-whore affords other useful tricks. Add the "Quick Links" Lab and save custom, frequently used queries. Here are some that are invaluable to us:
- Brian likes, Jeremy hasn't decided: label:brianlikes AND -{label:jeremylikes label:jeremypass}
- Jeremy likes, Brian hasn't decided: label:jeremylikes AND -{label:brianlikes label:brianpass}
- Needs "thanks but no thanks" note: label:brianpass AND label:jeremypass AND -{label:rejectionsent}
- Let's set up an interview: label:brianlikes label:jeremylikes -{label:interviewscheduled}
- Needs attention: label:requiresfollowup OR -{label:brianlikes label:brianpass label:jeremylikes label:jeremypass}
I hope this trick comes in handy the next time you need to categorize and search some data. One word of caution: as of this writing, there is a bug in GMail involving labels containing dashes (I switched to camelcase after many frustrating and fruitless attempts to fix my search queries). Good luck!
Leave a comment