According to the Wall Street Journal (registration required) today, MySpace is getting ready to release some interesting data to law-enforcement authorities. According to the Journal, “MySpace says it has identified and deleted the profiles of about 7,000 registered sex offenders”.

Wow. Seven thousand. Sex offenders. On MySpace. With your kid.

And that’s just the ones they know about. The article quoted Connecticut Attorney General Richard Blumenthal:

Mr. Blumenthal commended MySpace for its release but said the data are “limited in ultimate value because convicted-sex-offender profiles are probably just the most visible tip of the predator problem on MySpace.” He added that “the real problem now is the thousands of other predators that have never been convicted or are using aliases.” (emphasis mine)

What does this mean for you? It means that if you have kids, you had better make sure that you are aware of and involved with their online experience. It’s not just MySpace, either. Your kids might not be on MySpace, but even simple Google search can take you some places that will make your eyes burn.

It’s important to be involved with your children online. We’ve posted some great articles on Moral Metric about this. If you have kids, you need to read these articles:

• Moral Metric: Taming the Tech Tyrant: What You Need to Know About Teens & Technology
• MySpace: Total Abstinence Guarantees Zero Protection
• Articles tagged ‘MySpace’ on Moral Metric

Moral Metric is a really neat project I’ve been working on for a while now. We have a ton of awesome resources for parents, including articles, movie reviews, web safety products, and even video games. We also have a budding community of people who are concerned about their kids and want to make informed parenting decisions.

[UPDATE] This article accidentally got deleted, along with all the comments. Shame on my trigger-happy mouse finger, which clicked “OK” without reading the contents of the delete confirmation. So, thanks to Jeff Whitmire who found the text of the article in his RSS feed. Sorry to those who commented – there were some good thoughtful ones.

In my Rails projects, I sometimes have trouble remembering all my complex routes. Not only that, it’s a bummer to have to type out that long line every time I need to generate a URL.

So instead, I let the models tell me their URLs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class Article < ActiveRecord::Base
belongs_to :category

  include ActionController::UrlWriter
  default_url_options[:host] = "www.example.com"

  def url
    category_article_url(self.category, self)
  end

  def path
    category_article_path(self.category, self)
  end

end

Now I can say @article.url, which will generate

http://www.example.com/categories/123/articles/456-my-article

or @article.path, which will give me just the path:

/categories/123/articles/456-my-article

Fantastic conference. I wish I had more to say, but I’m still trying to untangle my brain and get back into the swing of work.

On a related note, I must be the world’s last Twitter adopter:

I was just going through my spam comments, and accidentally clicked “Delete this article” instead of “Delete these comments”. Dang. You’d think that Mephisto, which keeps such a careful log of the changes that you make to articles, would not just wholesale delete your article. Hmm… maybe it’s still there in the database somewhere.

So, if you’re looking for the article “Asking Objects for their URL”, it’s been accidentally zapped. Sorry.

I’m off to RailsConf!

This is a great little tip if you use Capistrano 2.0 to deploy to multiple servers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

task :production do
  role :web, "web.example.com"
  role :app, "app.example.com"
  role :db,  "db.example.com", :primary => true
  
  set :deploy_via, :remote_cache
  
  set :start_mongrel,   "/path/to/mongrel_cluster start"
  set :stop_mongrel,    "/path/to/mongrel_cluster stop"
  set :restart_mongrel, "/path/to/mongrel_cluster restart"
end

task :staging do
  role :web, "staging.example.com"
  role :app, "staging.example.com"
  role :db,  "staging.example.com", :primary => true
  
  set :deploy_via, :checkout
  set :mongrel_rails, "/path/to/mongrel_rails"

  set :start_mongrel, "#{mongrel_rails} start -d 
                       -p #{application_port} 
                       -e production 
                       -P #{current_path}/log/mongrel.pid 
                       -l #{current_path}/log/mongrel.log 
                       -c #{current_path}"
  set :stop_mongrel, "#{mongrel_rails} stop 
                       -P #{current_path}/log/mongrel.pid"
  set :restart_mongrel, "#{mongrel_rails} restart 
                       -P #{current_path}/log/mongrel.pid"
end

namespace :deploy do
  
  desc "Restart mongrel"
  task :restart, :roles => :app do
    sudo restart_mongrel
  end
  
  desc "Start mongrel"
  task :start, :roles => :app do
    sudo start_mongrel
  end
  
  desc "Stop mongrel"
  task :stop, :roles => :app do
    sudo stop_mongrel
  end
  
end

Capistrano 2.0 gives you powerful new options using namespaces and tasks. As you can see, we set up special tasks for staging production, and then set our variables for each environment there.

If you’re familiar with Capistrano deploy.rb file, then the role lines should be pretty self-explanitory. We just set up different roles for the staging environment and the staging environment.

Now, on my particular setup, I use mongrel_cluster in production, but plain old Mongrel in staging, just to keep things simple. In order to accommodate the two different commands, I just assign the command to appropriate variables inside the :staging and :production tasks, and then call the variables from sudo.

Now you can do things in your different environments by calling

1
2
3
4

cap production deploy          # Deploy to production
cap staging deploy             # Deploy to staging
cap production deploy:restart  # Restart mongrels on production
cap staging deploy:update_code # Update code

You’ll also notice that I used a different deploy_via in each environment. In production, I want to deploy_via :remote_cache because it is much quicker than a full svn export. But on my staging server, I want to be able to cheat and run svn update occasionally so that I don’t always have to do a full deploy.

Theoretically, you could have any number of different environments, and any combination of different variables for each environment. Really though, the simpler the better – with a staging server, the point is to get as close as possible to emulating the actual environment of the production server. For those little variations, this setup works great.

• Original tip by Ezra on Google Groups
• See Geoffrey’s Capistrano introduction at http://nubyonrails.com
• Capistrano 2.0