Safari normally uses the Web Kit framework found inside Mac OS X to render web pages and execute javascript. This means that if you preserve an old version of Safari to run it on a newer version of Mac OS, it will use the newer Web Kit found in the system and you will get the same results as with the newer version. Thus, you would normally need a separate installation of Mac OS X for each version of Safari you want to test a website into.

If you're going to write an insanely fast, headless browser, how can you not call it Zombie? Zombie it is.

It indexes all the elements and their classes, and then--class by class--it removes one, and times how long it takes to scroll the page. Classes that save a considerable amount of time when removed indicate problem areas.

This is a super simple service for generating different HTTP codes.

It's useful for testing how your own scripts deal with varying responses.

Just add the status code you want to the URL, like this: httpstat.us/200

I've worked on several large Rails apps and seen at least a dozen javascript systems. In this post I'll describe a few techniques that I've seen that consistently make javascript easier to test and maintain. To those of you who write javascript more than I do, these might be old news, but it's taken me 4 years to learn them!

100+ tools including SEO, validation, etc.