Sitemaps, Webmaster Tools, Rails, and You
Sitemaps are an easy way for you to inform search engines what pages on your site are available for crawling. Web crawlers typically discover pages by following links from site to site. Sitemaps provide hints so they can do a better job.
The Sitemap protocol defines a simple XML schema for specifying what URLs are on your site, along with some useful optional information: the date of last modification, how frequently the page is likely to change, and the priority of a given URL relative to other URLs on your site. Here's an example:
/sitemap.xml — Sample sitemap
<?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <url> <loc>http://sickpea.com/</loc> <lastmod>2009-07-17T17:17:32-07:00</lastmod> <changefreq>daily</changefreq> <priority>0.8</priority> </url> </urlset>
How To Self-Sign a Java Applet
I don't do much Java stuff anymore, but I did come across the need to sign an SSH applet recently so that I could embed it into a web page.
Unsigned applets can only connect to the server they are served from. This is a bit limiting if you want a web-based SSH session. Self-signing an applet "solves" this problem, but remember that just because an applet is signed doesn't mean you should trust it!
Bootstrapping Development Databases
At Ooga Labs, we strive to spin up new
developers quickly. One problematic area in the past has been creating developer
sandbox databases. Models and migrations, despite our
best efforts, are fragile. As
models get refactored, methods are inevitably removed or renamed, and early
migrations dependent on the old model behaviors are left to rot
until that ill-advised db:migrate months later unleashes calamity
and ruin.
It's a Rails best practice to treat your db/schema.rb
definition as the authoritative source for your database schema. To a quote a
comment in that file:
If you need to create the application database on another system, you should be using db:schema:load, not running all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations you'll amass, the slower it'll run and the greater likelihood for issues).
Named Scopes and Default Scopes
Rails 2.1 introduced named scopes which basically allow you to give a set of finder
criteria a name. For instance, you may only want to find / operate on published
articles, where published_at is nil. Instead of
adding that condition to all your find calls, you can define that named scope
directly in your model:
app/models/articles.rb — Named scope
class Article < ActiveRecord::Base named_scope :published, :conditions => 'published_at IS NOT NULL' ... end Article.all # => SELECT * from `articles` Article.published # => SELECT * from `articles` WHERE (published_at IS NOT NULL)
Nice. There's a whole lot more you can do with named scopes if you're interested. Another cool feature introduced in Rails 2.3 is called default scoping. When I'm fetching articles for this site, I almost always want to get the most recently published entries first. Default scopes let you do just that:
Canonical URLs in Rails
Websites often have identical content accessible through multiple URLs. For example:
http://sickpea.com/2009/7/canonical-urls-in-rails http://sickpea.com/2009/7/canonical-urls-in-rails?trackingid=42 http://sickpea.com/2009/7/canonical-urls-in-rails?random=parameter&more=less
A human can quickly (and reasonably) assume that all of these URLs point to the same blog entry, perhaps with minor differences in the formatting or presentation order. Search engines cannot absolutely tell which version is the preferred one, so you either end up with a bunch of duplicate content, or your blog entry appears in search engine listings under an obscure URL.
Google introduced a canonical link standard in February 2009 that hints strongly to the search engine what the preferred URL is. Yahoo, Microsoft, and Ask also immediately supported it. Some people think this little line is a big deal:
Rails App Configuration in 10 Lines
There are many, many, many, many Rails app config implementations out there, but I still like to use this little code snippet. Not-Invented-Here Syndrome? Perhaps. Too clever? Probably.
config/initializers/app.rb
module App def self.[](*args) args.inject(CONFIG) { |hash, arg| hash[arg] } end def self.method_missing(method, *args) self[method, *args] end yaml = YAML.load(ERB.new(File.read(Rails.root.join('config', 'app.yml'))).result) CONFIG = HashWithIndifferentAccess.new(yaml[Rails.env]).freeze end
Just drop it into config/initializers/app.rb, and create a configuration
file in config/app.yml:
Haml & Sass TextMate Bundles
To install TextMate's Haml/Sass bundles using Subversion, simply:
mkdir -p /Library/Application\ Support/TextMate/Bundles cd /Library/Application\ Support/TextMate/Bundles svn co http://macromates.com/svn/Bundles/trunk/Bundles/Ruby\ Haml.tmbundle svn co http://macromates.com/svn/Bundles/trunk/Review/Bundles/Ruby\ Sass.tmbundle
This installs the bundles system-wide, under /Library, as
recommended
here.
Many bundles, including ruby-haml, are officially mirrored on
Github as well (but not
ruby-sass). To install using Git:
cd /Library/Application\ Support/TextMate/Bundles
git clone http://github.com/textmate/ruby-haml.tmbundle.git
Refactoring Capistrano Deployment
Capistrano.
Love it or hate it, many people use it. And once you get it configured, it works
fairly well. I just finished up a long overdue refactoring of an old
deploy.rb file, one we've been happily treating as a blackbox for years,
mostly due to its unnecessary complexity. I'll take the blame. The road to
maintenance hell is filled with good intentions.
First I threw away all the one-off tasks that we never used or never worked quite
right: watching God /
Nginx logs, reloading configs, starting, stopping,
restarting, and checking statuses. You get the idea. The important ones are handled by
deploy:restart and its brethren, the rest are easily accomplished with
cap invoke COMMAND="foobar".
Hello, world.
Lacking my own words of wisdom for this first post, I'll borrow some from Alan Perlis:
I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.
