Tim Bray wishes for individual page feeds.

Page Feeds

In his blog entry, Wikipedia, Tim Bray confesses that he has taken an interest in editing a few Wikipidea entries, but that its just impossible for him to keep it up.

He says:

I don’t have time to go check back every day or even every week, and that’s what a conscientious article minder ought to do. I totally need, for each article, a feed I can subscribe to that will summarize changes.

I have no control over Wikipedia, but I would like to point out that Ruse wiki does indeed suppply individual page RSS feeds. So, if you are interested in monitoring a particular page, you can put that page’s RSS feed into your feed reader and be notified of every single change.

For example, if you wish to monitor the home page of the Ruby garden, you would use the URL: http://wiki.rubygarden.org/Ruby/feeds/rss/HomePage.

If you use feed autodiscovery, each page should present three different feeds, one to the page (as noted above), one for changes to the wiki, and a feed to capture changes to all the wikis supported by that instance of Ruse. The ability to stay on top of changes to a wiki is an important tool in the fight agaist wiki spam.

One interesting side effect of individual page feeds is the use of message pages. On RubyGarden, I created a page named JimWeirich/Messages and subscribed to that page’s feed. Now, if you want to drop me a message on the wiki itself, just edit that page and I will be notified of the change.

The new Wiki is up for 26 hours and we got our first spam attempt.

Ruse is Now Running RubyGarden

Chad and I quietly moved Ruse into production to support the RubyGarden wiki Wednesday morning. Spam immediately stopped with the new wiki software, mainly because the spam bots don’t know how to update Ruse pages (yet).

I figured that we would get a grace period before the spam starts. Well, here we are … about 26 hours after deployment. Here’s a look at the logs:

Notice the two red postings. They were made by an anonymous user and triggered the spam filters, so they went directly into the tarpit. Non-spamming users won’t ever see that spam.

So, it looks like it is working. It will be interesting to see just how effective Ruse turns out to be.

Oh, by the way. I just checked the logs and we have served over 11,000 wiki pages so far in the day and a half that we have been running.

Today’s topic is Spam … and what we are doing about it.

Spam by the Numbers

Anyone who visits the RubyGarden wiki regularly has probably run into wiki spam. You know what I mean, defaced pages with hundreds of links to questionable web sites. All done with the goal of increasing Google page rank.

Just to give you an idea of the magnitude of this problem, make a guess on how many time during the past 7 days someone tried to deface the RubyGarden wiki with spam.

Got a number? Its probably too low.

According to the logs, we had 18,139 attacks against our wiki. In just seven days! Over the past few weeks we have been averaging between 17,000 and 20,000 attacks in a 7 day period.

That’s a lot of spam.

Fortunately most of the attacks went directly into the wiki tarpit where only other spammers saw the results. Only about 250 attacks made it to the real wiki where they needed to be cleaned by hand.

(For those who aren’t familiar with a wiki tarpit, it is a shawdow wiki behind the real wiki where spammers are directed. The spammers spend all their time updating a virtual wiki that no one, except other spammers, will ever see. The goal is to have the spammers waste their time instead of ours.)

Now the tarpit isn’t perfect. Sometimes legitimate users get sent to the tarpit instead of the real wiki. If you ever went to RubyGarden and saw spam on almost every page, you were probably in the tarpit.

But, cleaning up 250 spams instead of 18000? That is a pretty good success story.

But We Need Something Better

As good as the tarpit approach is, we still need something better. The UseMod wiki software we are using makes it painful to clean up spam. The average page needs about four clicks to despam, with a lot of hard to automate decision making in the process. See this demo for a look at what I do to clean up a UseMod wiki page. Go ahead, click now. I’ll wait for you.

That’s a lot of work. Despamming several hundred posts can take hours.

Ruse

Ruse is new wiki with built-in anti-spam features. It supports UseMod style markup, so all of the RubyGarden pages can be easily migrated into it. It has an integrated tarpit that makes despamming a page a single button press. In fact, Ruse can move all of an author’s pending posts into the tarpit with a single click. Ruse can mark edits as spam based on either content (e.g. linking to a known spam site) or IP address (coming from a known spammer).

Best of all, Ruse makes it easy to distribute the job of detecting and marking spam across the regular contributers to the wiki.

Watch this demo to see Ruse in action.

The Beta

Chad and I have setup a mirror of the RubyGarden wiki at http://rubygarden.org:3000/Ruby. This is a trial run of the software before we commit to using it. Feel free to check it out, kick the tires and beat on it a bit. Shoot, if you have a secret desire to be a spam writter, go for it, just to see what happens.

You can post anonymously, or sign up for a guest account. After a certain number of spam-free postings, guest accounts are upgraded to full member accounts.

Oh, the account “spammer” with password “spammer” is already setup if you to see how the wiki reacts to spammers.

But remember, this is a beta trial and content of the wiki will be reset before it goes “live” for real.

Documentation is a bit skimpy right now, but we are working on that too.

Enjoy.

The OneStepBack site will be up and down today, 25/Apr/2006

I am upgrading software and doing a bit of apache reconfiguration today, so the site will be up and down today … no need to panic.

Geoffrey Grosenbach recently invited me to talk on the Ruby on Rails podcast.

Ruby on Rails Podcast

Geoffrey Grosenbach recently interviewed me for the Ruby On Rails podcast. He introduces me as the “Santa Claus” of the Ruby world (listen to find out why). Perhaps I need to let my beard grow and were a bright red outfit to the next RubyConf.

It was a fun interview, I hope you enjoy it. You can find it at http://paranode.com/~topfunky/audio/2006/Jim-Weirich.mp3.

I am heading to Chicago for the Chicago Area Ruby Group meeting next Monday.

I’m Speaking at Chirb

I will be speaking at the next Chicago Area Ruby Group (Chirb) next Monday evening, March 6th. It looks like the meeting is starting at 6:30. You can get directions and all the details here. The topic will be “Demystifying Continuations” (a reprise of the RubyConf talk Chad and I gave last year). Bring a laptop if you have one, the evening will involve some Ruby coding.

I look forward to seeing some Chicago Rubyists.

A Movie of last Tuesday’s Intro to Rails talk is now available.

An Quick Introduction to Rails

Last Tuesday evening I gave a “Quick Introduction to Rails” talk at the local XP users group. The talk was a departure from my normal presentation style and was inspired (in part) by Dick Hardt’s Identity 2.0 talk I saw at OSCON last year. Bill Barnett has made a movie of the talk available for download, so those of you who missed it can still see it.

Next Presentation

I will be giving shortened version of the talk again on the 21st of January at the Dayton-Cincinnati Code Camp sponsored by the Dayton and Cincinnati .NET users group. I will also be giving the popular 10 Things Every Java Programmer Should Know About Ruby talk at the same conference. Hope to see you there.

Presentation Links

I probably won’t post the “Intro to Rails” slides. (Update: See below). I don’t think the slides stand alone very well. But several people have asked about links to the stories I mentioned. Here is a partial list:

• David Geary
  • BIO (http://nofluffjuststuff.com/speaker_view.jsp?speakerId=4)
  • The Koolaid Posting (http://rubyurl.com/I9t)
  • Retraction (http://rubyurl.com/HeG)
  • Demo (http://jroller.com/page/dgeary/20050821)
  • The Rails Cafe (http://jroller.com/page/dgeary/20050714)

• Justin Gehtland
  • BIO (http://www.nofluffjuststuff.com/speaker_view.jsp?speakerId=5)
  • Java 2 Ruby Project (http://www.relevancellc.com/blogs/?p=29)
  • Feedback on J2R (http://www.relevancellc.com/blogs/?p=30)
  • Performance Numbers (http://www.relevancellc.com/blogs/?p=31)

• Stuart Halloway
  • BIO (http://nofluffjuststuff.com/speaker_view.jsp?speakerId=6)
  • Estimating Rails Jobs (http://www.relevancellc.com/blogs/?p=92)
  • Feedback on Estimating (http://www.relevancellc.com/blogs/?p=93)

• C.A.R. Hoare
  • The 1980 ACM Turing Award Lecture The Emperor’s Old Clothes (PDF) (http://www.braithwaite-lee.com/opinions/p75-hoare.pdf)

• David Heinemeier Hansson
  • BIO—Source of the XML Situps quote (http://conferences.oreillynet.com/cs/eurooscon/view/e_spkr/2130)
  • Ruby on Rails (http://www.rubyonrails.org/)
  • List of Real World usages of Rails (from which I pulled a small fraction for the talk (http://wiki.rubyonrails.com/rails/pages/RealWorldUsage)

There’s some other great articles on Stuart’s and Justin’s Relevance blog site. Also, the Hoare paper is a classic and well worth the read (even though I understand he retracted much of what he said about Ada later).

Presentation Styles

The software I used for the slides runs entirely on Firefox, and a reference can be found here: http://cardboard.nu/blog/2005_12_15/a_cute_mozilla_xul_app.html.

Here are some references on the influences on that particular presentation style:

• Dick Hardt’s Identity 2.0 Presentation at OSCON 2005 (http://www.identity20.com/media/OSCON2005/)
• The Takahashi Method (http://rubyurl.com/r81)
• The Lessig Method (http://rubyurl.com/4YH)

It is interesting to note that TAKAHASHI Masayoshi, the inventor of the Takahashi method, is involved with Ruby in Japan.

Update (Monday: 9/Jan/06)

Several people have asked for the slides and pointed out that if I published them, you could watch them in conjunction with with the video. Ok, good point.

The online version of the presentation is available here.

If you wish to download the presentation for local viewing, or for your own use or modification (under the terms of the Creative Commons Attribution/Non-Commercial License), then here is a tarfile. If you download the tarfile, make sure you specify the data file properly in the URL. See the live link above for an example.

Have fun.

It always bothers me to see mock objects creating and returning other mock objects.

David Chelimsky on Dependencies

David Chelimsky of Object Mentor notes that dependency injection eases the pain of dependencies so much that we sometimes don’t bother to root out the bad dependencies. Read the article and pay close attention to the dependencies in the original and final versions (I drew a couple UML diagrams to keep it clear in my head).

Plus its got a great Princess Bride reference!

Inevitably, every Ruby nuby asks the question “What are symbols?”, and the standard answer is “A Symbol is an immutable string”. I have some issues with that answer.

Every Nuby’s Question

Whenever someone asks “what are symbols” in the ruby-talk mailing list, the explaination almost always begins with “Symbols just immutable strings”, and then goes on to explain what symbols are good for and how they are used. Comparing them to something familiar (like a String) is a good pedagogical technique, but I’m left feeling that the answer leads the nuby down the wrong path to understanding.

Symbols aren’t Strings

First of all, symbols really aren’t immutable strings. Not even close. In fact, they aren’t Strings of any kind. This simple fact is easily demonstrated by the following:

  $ irb --simple-prompt
  >> sym = :symbol
  => :symbol
  >> sym.size
  NoMethodError: undefined method `size' for :symbol:Symbol
          from (irb):2
  >> sym[0,2]
  NoMethodError: undefined method `[]' for :symbol:Symbol
          from (irb):3

You can’t ask for the size of a symbol. You can’t ask for a substring of the symbol. You can’t do anything that you can do with strings on Symbols except (1) convert it to an integer (using to_i) and (2) convert it to a symbol (using to_sym). If a symbol is not a duck-type for a String, it hardly seems reasonable to call Symbols any kind of String, even immutable ones.

So if they aren’t Strings, what are they?

A Symbol is a simply an object that can be can be uniquely identified by its name. Every time you say :xyz in your code, you will be refering to an object (a symbol) that has the name “xyz”. There is only one Symbol with the name “xyz”, so all references to :xyz will refer to the same symbol¹.

So you see, there is a tight relationship between Strings and Symbols. Every symbol has a string name (available via to_s). And every String can be asked for its corresponding symbol (via to_sym). Strings and Symbols are closely related, but they are not the same thing.

So, fundamentally, Symbols are just objects with names.

And when should we use Symbols?

Invariably, when presented with the “Symbols are immutable Strings” meme, the nuby will ask “So when do I use Strings and when do I use Symbols”? By pointing out that Symbols are not Strings at all, makes it clear. Use Strings whenever you need … umm … string-like behavior.

As we pointed earlier, Symbols are not even duck-typed strings. So using a symbol where you really want string-like behavior is a mistake. Rather, take a clue from the description of a symbol: an object with a name. It turns out that symbols are great for naming things. Use them whenever you need to name something in your code. For example:

1. Naming keyword options in a method argument list
2. Naming enumerated values (e.g. like enums in C).
3. Naming options in an option hash table.

I’m sure other uses will come to your mind.

Some Closing Thoughts

Here’s how I like to express the difference between Strings and Symbols. Strings are about a sequence of characters. Symbols are about naming and identifying things.

There you have it.

I’m watching. Perhaps the next time this question comes up on ruby-talk, someone will say “A Symbol is an object with a name”. That would make my day.

¹ For anyone familiar with Lisp, the simularities between Symbols and Atoms are obvious.

The last several clients I have worked for loved to publish huge coding standards documents. A recent one was only 20 pages long (and that was one of the shorter ones).

While browsing the new Rails 1.0 web site1, I stumbled upon the Rails coding standard. Here it is in full (link):

• Two spaces, no tabs
• MyClass.my_method(my_arg)—not my_method( my_arg ) or my_method my_arg
• Follow the conventions you see used in the source already

¹ You did know that Rails 1.0 was released today, right?