Midnight Oil

Have you ever done a search on Google, only to find that some of the results point to the search page of another site? Irritating, right? Still, don’t you wish you could do it, too? Because surely, users would want to see your site’s search pages, right? Turns out, it’s not really that hard to do.

Argh! A SERP in my SERP!

For the most part, in order for Google to index your results, you need to have it linked from somewhere. For content pages, that makes sense. However, for dynamic search results, it’s doubtful that you have links going there. So, we need to find another way to get our results into the index.

Our secret inroad will be your site’s Google Sitemap. This index of content on your site helps Google find content that might otherwise be hidden or unlinked.

Assuming that your search is GET based (instead of POST), which it really should be, it’s now only a matter of adding search URLs to your sitemap. For example, you could add the following:

http://my.site.com/search/term1

http://my.site.com/search/term2

...

http://my.site.com/search/termN

Google will extract these URLs and crawl them just like any other page.

For bonus points, you can get your users to do the hard work of generating the terms to index. Just track the terms that they are searching on in your site, then stick these in your sitemap. If there are too many, then just use the top 1,000 or 10,000 terms.

Before you know it, you’ll have thousands of search pages in Google’s index, irritating (ahem…”informing”) your fellow Internet denizens.

Note: It’s a solid theory, but I haven’t personally tried this yet, so maybe Google is smart enough to discard these results. Let me know if this works for you.

I attended MerbDay in Atlanta this weekend, and while enlightening, it was ultimately a blah experience. In all honesty, I feel like I paid $60 to attend a Ruby meetup and get a breakfast and lunch.

The highlight to me was a quick introduction to HAML / SASS. While not strictly Merb related, both look very cool. Still, when I subtract out the cool factor, I’m not sure there’s a big incentive to use them over straight up HTML and CSS. Nonethelesss, very interesting.

So, all in all, I’m glad I learned a little about Merb, but I don’t feel like I’ve gotten any more from this than I could by perusing a HOWTO and following along at home for an hour or so. I guess that’s why this was $60, instead of being a $$$ multi-day training course.

@merbday twitpay -$60 for making me pay for a ruby meetup

Just a little joke. One of the main presenters of MerbDay helped create twitpay. Seriously, I’m glad I came.

Open mouth, insert foot

I’ve been called out in the comments for judging a little too early, and it turns out they’re right. The day picked up near the end, culminating with a great keynote by Yehuda Katz. Plus, $60 for a day full of good info is still pretty cheap, even it’s presented like an extended Ruby meetup. Throw in breakfast, lunch, and free beers afterward (paid for by Rails Machine) and it turns out to be a pretty good day. So, I end up the one with egg on my face for being snarky and prematurely bitching.

Constructive Criticism

In order to be a little less whiny and lessen my troll karma, I’ll offer the following constructive criticism:

I would say to have fewer presentations and perhaps some breakout sessions with small groups writing an app. Make it a hackfest rather than a list of presentations. Teams of 3 and a script to follow, with gurus prowling the room giving help when asked. Maybe that would suck, but I feel like I’d learn more.

Also, I really don’t think the “write code while you’re following along” approach really works. It’s just too hard to stay with the presenter, and it’s too easy to run into small problems (don’t have this-or-that gem installed, small typo, etc.). Plus, if you try to do a pull and catch up with the real repo, you’ll probably encounter conflicts and that will suck.

So, hopefully this explains my complaints a little better. I’ll try to be more constructive and less snarky in the future.

If you’re using the Facebooker SSH tunnels along with Phusion Passenger, you may run into an issue where you have multiple Rails apps running on your machine at different subdomains. Unfortunately, when facebook makes a request to your tunnel, it’s passed through on port 80 to your local machine and Apache chooses the first defined virtual host to serve the request, which may or may not be the one you want.

An easy solution is to use a ServerAlias directive in your vhost file that matches up with your tunnel domain.


<VirtualHost *:80>
ServerName my.local.rails.app.localhost
ServerAlias my.tunnel.domain
DocumentRoot /path/to/rails/app/public
</VirtualHost>


This works because the tunnel will pass the request through to your machine without changing any of the request headers. So, they come through with the Host header set to the tunnel domain, and Apache will match it to your server alias.