One problem I find myself having when writing tests is ensuring that no execution ever leaves my little test sandbox. For example, when writing tests for github-gem I keep looking through the code to find every place a function ends up `shelling out` and it's tiresome and error-prone. I finally decided I was going about this backwards. Testing is supposed to find problems for me, right? So why not raise an error whenever `` or Kernel#system() is called and let the tests tell me what else I need to mock?

Put the following code in your spec_helper.rb file and an exception will be raised whenever `` or Kernel#system() is called during a test:

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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

class Module
  def metaclass
    class << self;self;end
  end
end
 
module Spec::Example::ExampleGroupSubclassMethods
  def add_guard(klass, name, is_class = false)
    guarded = nil # define variable now for scoping
    target = (is_class ? klass.metaclass : klass)
    sep = (is_class ? "." : "#")
    target.class_eval do
      guarded = instance_method(name)
      define_method name do |*args|
        raise "Testing guards violated: Cannot call #{klass}#{sep}#{name}"
      end
    end
    @guards ||= []
    @guards << [klass, name, is_class, guarded]
  end
 
  def add_class_guard(klass, name)
    add_guard(klass, name, true)
  end
 
  def unguard(klass, name, is_class = false)
    row = @guards.find { |(k,n,i)| k == klass and n == name and i == is_class }
    raise "#{klass}#{is_class ? '.' : '#'}#{name} is not guarded" if row.nil?
    (is_class ? klass.metaclass : klass).class_eval do
      define_method name, row.last
    end
    @guards.delete row
  end
 
  def class_unguard(klass, name)
    unguard(klass, name, true)
  end
 
  def unguard_all
    @guards ||= []
    @guards.each do |klass, name, is_class, guarded|
      (is_class ? klass.metaclass : klass).class_eval do
        define_method name, guarded
      end
    end
    @guards.clear
  end
end
 
Spec::Runner.configure do |configuration|
  configuration.prepend_before(:all) do
    self.class.send :include, Spec::Example::ExampleGroupSubclassMethods
  end
 
  configuration.prepend_before(:each) do
    add_guard Kernel, :'`'
    add_guard Kernel, :system
    add_class_guard Process, :fork
    add_class_guard Open3, :popen3 if defined? Open3
  end
 
  configuration.append_after(:each) do
    unguard_all
  end
end

Note: if you want, you can write :` instead of :'`', but my syntax highlighter here doesn't like that.

Note that this requires version 0.2.5 of Safari Tidy, which was just released today.

• MacPorts
• TextMate Bundles

So if you’re using Safari 3.0, or if you’re Czech, go ahead and download SafariSource. If you’re using Safari 2.x, please let me know it still works as I can’t test that with 3.0 installed.

Download

We migrated off of Planet Argon and onto DreamHost, where we should have more control. We also upgraded to Trac 0.10.3 and turned off anonymous editing (users now have to register to file a ticket). This should (hopefully) prevent the issue that lead to Typosphere dying in the first place.

The issue, as near as I can tell, is Typosphere started getting spammed massively. At this time none of the developers (and that includes me) was really paying attention to Typo, as we were busy with other things. So for about a month Typosphere Trac got so full of spam that, well, it was more spam in one location than I’ve ever seen in the rest of my life. This managed to trip a bug in Trac that caused it to start sucking CPU and RAM, and so Planet Argon turned off Trac for our account.

Some time later, the other developers and I started trying to resurrect Typosphere. Unfortunately, at about this time the systems administrator for Planet Argon was preparing to leave the company, so any attempts at contacting him to resolve the issue went unanswered. I eventually called Planet Argon (which is how I learned that the systems administrator had, in fact, left that very day) and spoke to the new systems administrator. He agreed to try and fix Trac for us, but after hearing nothing for a few days, I decided it would be better to seek hosting elsewhere.

Luckily, I had access to a DreamHost account with plenty of spare bandwidth and disk space, so we decided to move there. For the most part the migration went smoothly, until I started up Trac and discovered exactly how much spam was in there.

This problem stumped me for about 2 weeks. I spent several hours trying to clean it by hand one day, and after those several hours I couldn’t tell the difference. So, yesterday, I finally sat down to try and solve the problem.

With the help of the fine folks on the #trac IRC channel, especially coderanger, I wrote a script which deleted every single ticket change after a certain timestamp (corresponding to the first spam comment). Unfortunately, there were probably a handful of legitimate changes lost, but there really was no other alternative. In any case, this script worked flawlessly, and Trac was de-spammed. To prevent this from happening in the future, I turned off anonymous editing and installed a plugin which allows users to register for an account. Hopefully the requirement of registration will block most spam.

There was one interesting aspect to this that puzzled me until yesterday. The vast majority of the spam I saw contained words that I had placed into the blacklist ages ago. I couldn’t figure out why the spam protection wasn’t working. And then yesterday I discovered the reason. The blacklist is kept on a page called BadContent. The first code block on that page consists of regular expressions, one per line, that each match a blacklisted expression. Unfortunately, I forgot to mark this page read-only. So what happened was one of the random spam attempts happened to target this page. The spammer replaced the content with his own code block containing a vast number of <a href> tags linking to spammy websites. This had the effect of replacing the entire blacklist with a bunch of regular expressions matching <a href> tags. This meant that all of the stuff that was previously blacklisted was no longer being blocked, opening the floodgates for all sorts of spam.

I think I’m going to convert Typo to use Haml for all its templates. I already did Azure’s layout file and it was pretty simple.

Method Swizzling is one common technique of people writing hacks, such as Safari Plugins. Unfortunately, it’s always suffered from a flaw, wherein swizzling inherited methods affects all classes which inherit that method (including the base class), rather than the intended subclass. This problem is discussed on the CocoaDev Method Swizzling page.

As part of writing YubNubSearch, I decided to solve this problem.

First I looked into dynamic subclass generation + posing. Unfortunately, this has a big problem. In this technique, calling the original implementation would naturally be done through a [super foo] call. Unfortunately, when the compiler sees super, it hardcodes a reference to the superclass at which to start the search. This means you cannot write this code in, say, a category on NSObject, then pull up the IMP into a dynamically-generated subclass and have it work. So that throws out that idea.

The other idea I had, which I eventually went with, was to copy inherited methods into the subclass that you wish to swizzle, before swizzling. It turned out to be fairly easy, and still has the same semantics as the old, flawed technique for calling the original implementation.

You can download my implementation here.