My Blog
HOWTO Use Custom DNS Redirects to Save Browser Keystrokes
Given the recent interest in DNS and its role in the public infrastructure of the Internet, sparked by the release of Google Public DNS, here’s a hack that can help you save keystrokes in the browser while accessing your favorite sites. Instead of typing in “youtube.com” or “twitter.com”, you can just type “y” or “t”. If you’re looking for a map of San Francisco, CA, you can type “map/sf” and jump to the right place in Google Maps.
A bright bold blinking marquee disclaimer before we start: this is advanced territory. If you don’t know what sudo is and why 127.0.0.1 is special, be careful following these instructions because you may unintentionally destroy your ability to do anything at all on the Internet — including looking up instructions for getting unstuck. Also, these instructions only apply to Mac OS X and Linux, or other UNIX variants.
Redirect custom DNS hostnames to frequently-accessed sites
The file /etc/hosts
on your machine is consulted by the DNS resolver before
making a request to a DNS server. The idea is to add new DNS entries to the
hosts file on your machine, pointing short domains such as g
and t
to
127.0.0.1. Now, whenever you type g or t into your
browser, the hostname will be matched from your /etc/hosts file, instead of
receiving an NXDOMAIN reply (i.e., this domain does not exist) from an
upstream DNS provider. Since this request is received by your own machine, you
can then handle it to do whatever you want, including, but not limited to,
redirecting the user to the intended destination.
This HOWTO assumes that Apache is installed and running on your system with PHP and mod_rewrite support.
Modify /etc/hosts
Open /etc/hosts
in your favorite text editor, and add one line for each
shortcut you’d like to set up. Leave everything else unchanged. (You will need
to sudo
edit this file.)
## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 127.0.0.1 c # for Calendar 127.0.0.1 f # for Facebook 127.0.0.1 g # for Google Search 127.0.0.1 m # for Mail 127.0.0.1 map # for Maps 127.0.0.1 t # for Twitter 127.0.0.1 w # for Wikipedia 127.0.0.1 y # for Yelp 127.0.0.1 yo # for YouTube 255.255.255.255 broadcasthost ::1 localhost fe80::1%lo0 localhost
You can test that this change worked, by typing in the address (e.g. https://g/ in your browser. Instead of seeing a page that says that your browser "can’t find the server 'g'", now you would see a page saying that your server isn't configured correctly, or welcome to Apache, or whatever you would see if you typed http://localhost/ instead. If that worked, proceed.
Configure Apache to handle requests for unknown domains/URIs
Edit the following lines in /etc/apache2/httpd.conf
. The following code shows an excerpt with lots of context around the line you need to edit. Locate the relevant section in your file.
#
# This should be changed to whatever you set DocumentRoot to.
#
Locate your Apache root directory. It's usually /Library/WebServer/Documents
on the Mac or /var/www
in Ubuntu. If you're unsure, check where it is by issuing the following command in a terminal: (assuming you're running Apache 2.x)
grep "DocumentRoot" /etc/apache2/httpd.conf
In that directory, save the following file. It should be named exactly .htaccess
. (That's htaccess with a period at the beginning, so it's a hidden file on UNIX.) Save it as /Library/WebServer/Documents/.htaccess
on Mac OS X or /var/www/.htaccess
on Ubuntu.
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) /index.php [L]
The actual redirection script
Here's the script that I use for redirection, but you can roll out your own, and do anything with each request you receive. (If you do something phenomenally awesome, I'd love to hear about it in your comments.) As you can see, it's customized to the sites I frequent, including location preferences (e.g. the Yelp shortcut takes me to Yelp San Francisco directly. The search box is preconfigured for SF.)
Save this as /Library/WebServer/Documents/index.php
(on Mac OS X) or as /var/www/index.php
on Ubuntu.
<?php
$uri = preg_replace('/^\//', '', $_SERVER['']);
switch($_SERVER['']) {
case '':
('');
break;
case '':
('');
break;
case '':
('' . $uri);
break;
case '':
('');
break;
case '':
('' . $uri);
break;
case '':
('');
break;
case '':
if ('' === $uri) {
('');
} else {
('' . $uri);
}
break;
case '':
if ('' === $uri) {
('');
} else {
('' . $uri);
}
break;
case '':
if ('' === $uri) {
('');
} else {
('' . $uri);
}
break;
}
{
header('' . $url);
}
?>
That's it, now type your shortcuts into your browser instead of the longer URLs, and there you are. If you run into trouble, leave a comment and I'll address it.
The only downside of this approach
Redirecting involves an additional HTTP request to your machine, which introduces additional latency. The request, however, is from your machine to your machine itself, so there's no network involved. Personally, I feel that the keystrokes saved by the technique would have taken longer to type than the shortcuts I set via this method. But you don't lose anything if you set this up and don't use it — just continue to type entire URLs and you will never pay a latency penalty.
Read MoreMarathon Fundraising: A Noble Goal or Exploiting your Social Network?
On-the-fly CSS Compression in PHP
Web site optimization experts suggest that webmasters try to minimize the number and size of HTTP requests necessary to serve web pages. Web designers often use multiple CSS files because they are easier to manage, but this requires as many HTTP requests as there are CSS files.
This free script serves all your CSS files as a single HTTP resource, minified (by removing comments and extraneous whitespace), and gzip-compressed. It also requests browsers to cache the CSS content for at least a day before trying to fetch a new version.
The best part is that this does not pre-process the files, so it does not add any steps to your deployment process. It's licensed free for commercial and non-commercial use, with attribution requested.
Read MoreThe query: Protocol
Update: I implemented this idea at https://queryprotocol.appspot.com. Comments, questions, and suggestions are welcome!
When trying to explain a concept to others over email, I often find myself linking to a search engine's result pages for a specific query, instead of a single destination URL. These are non-navigational queries, and there is no single result that I expect to be the most important one. Instead, my intention is to provide the reader a variety of links on the topic such that s/he may draw her own conclusions, or solve their own problem -- all they need is a nudge towards the right query term to use. If, over time, better search results are available for the same query, then future readers get the benefit of automatically updated results.
E.g. Q: Where can I find the latest numbers related to the spread of the Swine Flu?
A: Try [H1N1 update].
To do this today, I simply link to my favorite search engine, Google. But that does not seem fair to fans of other search engines: Bing, Yahoo!, Altavista, and others. I would prefer to use a notation that allows the reader to use their choice of search engine to obtain the results. Just as we specify our default browser and default email client, we should be able to pick our default search engine.
We have already solved the first two problems (picking default browsers and email clients) using protocol handlers in the operating system. When I pass around a link to a web page, starting with https://
, I do not specify the browser it should open in. Your operating system determines that it's a link to a hyper-text transfer protocol (HTTP) document, and invokes your default browser. Similarly, for emails, the mailto:
protocol provides for an application-agnostic way to invoke the user's default email client to send an email.
It is easy to see how a query:
protocol could be implemented similarly. To point you to the search results for a particular term, I would send you the following link: (don't click on it, it won't work -- at least as of this writing.)
The URL that the above links to is query:h1n1+update
. Note there's no HTTP protocol marker specified. If the OS wanted, it could provide local results as well. This means that the protocol extends seamlessly to Desktop Search as well.
Syntactically, this validates as a URI. Just as the mailto:
protocol handler defines standard parameter names, subject
, cc
, and bcc
, similar parameters can be standardized for the query:
protocol. These may include corpus restricts (corpus={web, images, desktop, ...}
), pagination controls (start=0, num=10
), or domain restricts (site=manas.tungare.name
).
Implementation is simple: all operating systems and major browsers support external custom protocol handlers. They can be configured as follows:
Protocol Prefix:
query
Application Name:/Path/to/Application
The application does not need to be very complicated. It's a mere stub, which, depending upon the user's preferred search engine, converts a URI of the form query:h1n1+update
to https://google.com/search?q=h1n1+update
or https://bing.com/search?q=h1n1+update
and opens that link in the user's default browser.
Eventually, if browsers understand the query:
protocol, there is no need for the stub application, and users may be able to share and exchange queries and yet seek results using their favorite search engines.
(The opinions expressed in this blog post are solely my own, and may not reflect the opinions of my employer, Google.)
Read MoreGrad School 101
This is a collection of tips compiled for a seminar series at Virginia Tech for Computer Science Grad Students in Fall 2008, compiled by Manas Tungare, with contributions from (in alphabetical order) Manuel Pérez-Quiñones, Rhonda Phillips, Pardha Pyla, Naren Ramakrishnan, Bill Schilit, and Andrea Wiggins.
</td> |
</td> </tr> </table> 1. IntroductionThis document is extremely terse, so you don't end up spending too much time reading it. 2. Getting Started2.1. ClassesIn your first few semesters of grad school, you will be required to take classes. They provide an opportunity to learn about new areas, and gain some depth in your area of focus. But grad school is not about getting an A in every class. Don't ignore research in favor of getting good grades. Be clear about the requirements of your program: you don't want to discover that you missed taking a required class and have to take it towards the end of your Ph.D. Quote from a professor (used with permission):
2.2. Choosing an Advisor
|