This week is a good week: We've got lots of reasons to celebrate, that couldn't be more different in nature. Which ones, you ask?
Let's start with the oldest one: On November 10, Sesame Street turns 40. The show is still going strong, and I have fond memories of it when I was a child. My favorite characters were always Samson, as well as Ernie and Bert. Only much later I found out to my astonishment that Samson, the big, brown bear, is only present in the German version of the show, and not in its American counterpart. (In turn, Big Bird is missing from the German Sesamstraße). Happy Birthday, Sesame Street!
Number two on the list of this weeks "birthdays" is the reunited Federal Republic of Germany. While reunification wasn't completed until late 1990, the 9th of November, 1989, marks perhaps the most important step in the process. After several weeks of civil protests, the East German government announced that all GDR citizens could visit West Germany and West Berlin. In a slip of tongue, the announcing politician declared the unprecedented travel permit to be valid "immediately", resulting in an exodus of East Germans to the West.
Witnesses would later describe how the customs officials tried to check passports at first, and after awhile just opened the borders to let people pass, realizing it was futile to try any further checks. Due to this historic significance, the 9th of November was considered for the national holiday of Germany, but it was dropped in favor of the 3rd of October due to its unfortunate coincidence with at least two dark spots in German history. Happy birthday, reunited Germany!
Last, but certainly not least, Mozilla Firefox turns 5 on the 9th of November as well. Firefox 1.0 was released in 2004, and since then, the Web has been changing faster than ever. It has developed into an exciting platform for innovation and collaboration. That the web browser space is now a competitive environment with a number of excellent players in the market, is something Firefox had an essential influence on and it is something the Mozilla community can be proud of. Make sure to watch the video "The Story of Firefox" on the Five Years of Firefox website. Happy birthday, Firefox!
Photograph of West Germans welcoming East Germans, CC by-sa licensed by Bundesarchiv on Wikipedia.
Over time, unfortunately, some files start to contain a significant amount of mixed-up indentation (both from badly set-up IDEs and third-party contributions that came with tab indentation but went un-noticed). That's both tedious and error-prone to fix by hand.
A similar problem poses trailing whitespace. While it's just annoying in general, especially in HTML template files, it also increases page size unnecessarily by leading to more bytes transmitted on the wire, with no benefit to neither the users nor the developers.
Luckily, there are two quick fixes for these problems in both the editor vim and my IDE of choice, Komodo:
To remove tabs and replace them with spaces...
- in Komodo, select a code block, then click Code -> Untabify Region.
- in vim, type
:%s/\t/ /g(those are four spaces) -- or, as oremj points out in the comments, you could just to
And to wipe out trailing whitespace...
- in Komodo, in Preferences -> Editor / Save Options, activate the option "Clean trailing whitespace and EOL markers". Then open your document of choice and just save it again. However, when writing patches, you might want to refrain from keeping this option on at all times: It might result in confusion if a lot of lines are touched that do not have anything to do with the current patch. I wish there was a one-time way to run this, instead of a config option.
- in vim, type
:%s/\s+$//gwhich the regex-savvy among you have quickly decyphered as: "in the entire document, replace all one or more whitespace characters that are followed by a line ending with the empty string".
For work, I have a virtual machine serving one little purpose: To run Microsoft Internet Explorer 6, for the rare instances when I have to test a website with it. To make that a little more convenient and a little less painful, I just created a "desktop shortcut" for it, and look what it showed up as:
Haha, "Shortcut to Internet" -- this is classic.
It's been awhile since I last had to announce planned maintenance here, so here we go:
My current domain service provider closes down its consumer services at the end of the year, prompting me to transfer all the domains that I own (including fredericiana.com) to a different service provider. I have chosen domainfactory, a well-established player in the market that I read good reviews about.
Please bear with me while the transfer is in progress and the name servers are being switched over. It should soon be smooth sailing again. But, if problems persist, as always, just shoot me an email.
Update: I am glad to report my domains have all been transferred properly and everything should be back to normal now.
Just a reminder, because I always forget it: When you use git-svn on an svn repository and your code base contains empty directories (say, for temporary files, or log files), they will be ignored by git unless they contain at least one file.
Paradox? Maybe. There's a good reason however: git ignores empty directories because it tracks (file) content, not a bunch of directories some of which happen to contain a file (the concept of tracking files might be the only thing git has remotely in common with
good ol' CVS -- though git also does not deeply care about file names, only content).
The "common" way to handle this is by adding a
.gitignore file to the repository. This won't harm svn-only clients, but it'll make git-svn clients pick up the (almost) empty directory properly.
This is what you need to do.
mkdir empty_dir echo '*' > empty_dir/.gitignore echo '!.gitignore' >> empty_dir/.gitignore git add empty_dir git commit -m 'adding empty directory' empty_dir
.gitignore file tells git what file names not to track inside the directory in question. The asterisk means, ignore all files, but the second line makes sure the
.gitignore file itself is recognized and added to the repository.
As always, what I am writing here is my own opinion and not a statement on behalf of Mozilla Corporation.
When I was just visiting Wikipedia, I was greeted with this temporary error note (which, luckily, does not happen too often in spite of Wikipedia's huge popularity):
And, even if this marks me as a Web 2.0 geek, I must admit: All I was thinking was -- where's the pet?
The first company to put a recognizable, even likable, "pet" onto their error pages was likely Twitter. And due to the horribly frequent outages associated with Twitter's "growing pain", we got to see the
little fellow quite often. In the mean time, he seems to have swam away, at least I haven't seen him in awhile. Yet, he's not forgotten: the fail whale even has his own fanclub.
Another place where I saw a "fail pet" was yelp, whose error page was sporting a picture of an actual dog, apparently the company puppy "Darwin" (sorry for the tiny screenshot):
Now where's yours, Wikipedia?
Of course, considering I so provocatively ask this question, you might respond: Well, where's yours, Mozilla?
Here at Mozilla, we are not particularly proud of software failures, because unlike your regular web 2.0 start-up (think Twitter) where every service failure means more customers than anticipated, failures in Mozilla-land usually mean a crashed browser, (possibly) lost data and certainly frowning users*). So when the Crash Reporter icon was redesigned, we could have gone ahead and hired Foxkeh as our "crash mascot", but that would do the poor little fox wrong -- and at any rate, we prefer associating mascots with good stuff here at Mozilla. So at the time, user experience engineer Alex Faaborg made sure we don't create something too memorable, for example nothing like a second "Blue Screen of Death". Of course, had Microsoft known at the time how appeasing error messages can become with a little help from the animal kingdom, they'd have hired the entire cast of Looney Tunes to show up in their dreaded error messages.
But this might well be one of the few things we have in common with Microsoft: No fail-pets for us, any time soon.
*) On a side note, although it won't make a user fell better whose browser just crashed: When Firefox crashes it is most often due to binary, third-party plug-ins like Flash, Acrobat etc., and not due to a bug in Mozilla software -- as evidenced by the publicly available "top crashes" list and the bugs associated with it.
Here's an excerpt from the Caribbean:
The map is a pleasure to look at even on the screen (I love the colors!), and I might even buy one in print and hang it on the wall.
photo credit: flodIn a very well written article that was published in Sunday's New York Times, Miguel Helft explains the post-"browser wars" web, and how Mozilla's mission fits into this increasingly complex setup.
As indicated by the title -- "For Mozilla and Google, Group Hugs are Getting Tricky", the author puts some emphasis onto the Google/Mozilla relationship, which among the community tends to be a big point of interest. Quote:
"In many ways, Google and Mozilla are fighting the same battle, albeit not with the same objectives. They both contend that the Web should be open and based on common standards — Mozilla because it is its mission, Google because it is good for its business."
Highly recommended reading, even for non-geeks, who are interested in Mozilla and the Web as a whole.