Very cool new feature in ScreenSleeves

I have a Mac which is pretty much dedicated to playing my music; I regularly use iTunes (actually now more often Swinsian), Spotify and occasionally Radium for a particular internet radio station I like.

However, that mac doesn't always have a screen attached (I often use screen sharing to control the music). In any case, it's not the screen I like to have running the Screensleeves screensaver.

This problem has been on my mind for a long time. What's required is an elegant way of sharing what's playing on another computer. Without any messy setting up or messing around with passwords every time a computer is restarted or just decides it wants to be awkward.

And here it is. It's called Screensleeves Broadcaster. It's included in the Screensleeves Pro dmg, and you just need to pop it in the Applications folder of the computer that plays your music, start it (you may like to add it to your login items so it's just running whenever your computer is on).

Then install version 5 of the Screensleeves screensaver (obviously on the computer that you want to be displaying the saver). Go into its options and switch on "Listen for the Screensleeves Broadcaster" (under the Pro options). And that's it.

Version 5 of Screensleeves has various fixes / improvements, support for the Broadcaster, and it also restores support for 10.6 (Snow Leopard) which has been broken in recent versions.

Update: v5.0.1 Pro is now released, and the Broadcaster is officially released too.

A 500 server error in Scrutiny / Integrity for a page which is apparently fine

We recently looked at a support call where a large number of 500 errors were being reported - that's lots of red in Integrity or Scrutiny - for a site that appeared fine in the browser.

It caused some head-scratching here and lots of experimentation to find the difference between the request the browser was sending and the one Integrity was sending (cookies? javascript? request header fields?)

It was while investigating the request being sent by the browser, we noticed that although the page appeared as expected in the browser, the server was in fact returning a 500 code there too: (this is from Safari's web console)

It's a little odd that the requested page follows hot on the heels of this 500 response code. I don't know the reason for all of this, but if my user finds out and passes it on, I'll update this post.

The moral of the story is... don't take it for granted that if a page appears as expected in the browser, that nothing's wrong. (NB Google will also receive a 500 code when requesting this page.) Another good reason for using a scanning tool.

testing linked files - css, javascript, favicons

This feature has been a very long time coming. Website link tester Integrity reaches back to 2007, Integrity Plus and Scrutiny build on it, using the same engine.

But none of these crawling apps have ever found and checked linked external files such as style sheets, favicons and javascript. (This isn't entirely true - Scrutiny's 'page analysis' feature which tests the responsiveness of all elements of a page does include these linked files).

So this is a well-overdue feature and now it's built into our v6 engine and can be rolled out into Integrity, Integrity Plus, Scrutiny and other apps which use the same engine.

As you can see in the top screenshot, the new checkbox sits nicely beside the 'broken images' switch (which has existed for a very long time). The option can be set 'per-site' (except for Integrity, which doesn't handle multiple sites / settings)

With that option checked, linked files should be listed with your link results (obviously there's no link text, that's given as '[linked file]').

This feature is in beta.

[update: the beta version of all three apps containing this new feature is available for download on the app's home page]