As I sit here blaming code to find the original source of a line of code I’m beginning to think that svn needs a new improved version of blame called spelunk it would work something like this:
$ svn help spelunk
spelunk (curse, showup, show): Output the content of specified files or URLs with the original revision and author information in-line ignoring white space changes and following movement of code between files.
Yes – I know I am dreaming 😉
A recent discussion around the way we write and share small helper scripts inside Automattic made me think a lot about why I do things the way I do and why I am against “authorship attribution” in shared code.
The views I have are strong and I think a good guiding principle for working collaboratively with your peers especially in Open Source projects:
I am very strongly against authorship attribution – it puts up a barrier to contribution by setting a subconscious ownership barrier around things.
I give you my code to do as you wish, I mold your code to do as I wish, I blame early and often when searching for bugs, and I expect you to have forgotten you wrote the tool I’m asking you about especially if you committed it yesterday!
What is your ethos and what do you think of mine?
This is the tale of a mystery and intrigue about the disappearance of the css from a blogs dashboard and how we hunted it down and fetched it back.
Thord Daniel Hedengren, one of the writers for Blog Herald, put out a plea for help on twitter and was pointed in my direction.
He was faced with a WordPress dashboard which looked like this and wasn’t much use:
This evening I hooked up with Thord and with the help of his server administrator we tracked down the issue and thought it a good idea to spread the message to help any one else out there who has a similar issue in the future.
I started off by looking at the headers returned by the php file which concatenates all the CSS files together and noticed something strange:
HTTP/1.1 200 OK Server: nginx/0.7.62 Date: Tue, 29 Sep 2009 19:34:47 GMT Content-Type: text/css;charset=“utf-8″ Connection: keep-alive X-Powered-By: PHP/5.3.0 Expires: Wed, 29 Sep 2010 19:34:47 GMT Cache-Control: public, max-age=31536000 Vary: Accept-Encoding
As you can see here the Content-Type header looks a little strange, it has a charset specified but the value being returned is not a valid charset and it looks like this is probably why Firefox is refusing to apply this css file to the page.
This was starting to look like a server configuration issue so we got in contact with the server admin and we tracked down the errant configuration to the php.ini file.
Within the php.ini file you can set a default charset to be used if one has not already been specified for the request this had erroneously been set in the file with some smart quotes rather than normal quotes and so php was outputting the smart quotes as well as the charset name into the HTTP header.
Now the headers look like this and Firefox is happy to display a fully styled WordPress dashboard:
HTTP/1.1 200 OK Server: nginx/0.7.62 Date: Tue, 29 Sep 2009 19:39:17 GMT Content-Type: text/css;charset=utf-8 Connection: keep-alive X-Powered-By: PHP/5.3.0 Expires: Wed, 29 Sep 2010 19:39:17 GMT Cache-Control: public, max-age=31536000 Vary: Accept-Encoding
In short, check the configuration you use for default_charset in your php.ini file and don’t use any quotes unless you need to the following works fine in my testing:
default_charset = utf-8
Jane asked –
“I’m nowhere near my iMac, and won’t be for weeks. I need to backup my iPhone onto my MacBook Pro or external hard drive today. How?!”
To which the answer is, suprisingly, use iTunes.
It turns out that once you have connected your iPhones to iTunes on another Mac you can just right click on the device and select backup like so:
Hopefully this will help other people in a similar situation in the future.