May 242012

Here’s a helpful, handy tip for you if you occasionally edit documentation on the Mozilla Developer Network site!

Don’t delete obsolete content. If it was ever accurate, it’s probably still accurate for users of older versions of Firefox or other browsers. Instead, mark the content as obsolete.

First, you can tag individual items in a list as obsolete by inserting {{obsolete_inline(version)}}. For example:

  • Some interesting fact or link
  • Something that’s no longer true but used to be {{obsolete_inline(“gecko14.0”)}}
  • Another interesting fact or link

This indicates that the second item became obsolete effective in Gecko 14.0. You can also use “js<version>”, “css<version>”, or “html<version>”, to use versions of those specifications.

Similarly, you can mark an entire article as having become obsolete with a given version by using {{obsolete_header(version)}}.

You can also insert notes that are relevant for specific versions of Gecko by using the template {{gecko_callout_heading(geckoversion)}} in concert with the callout box div style, as follows:

  1. Put a paragraph that contains only the gecko_callout_heading template, specifying your gecko version. For example, “{{gecko_callout_heading(“15.0″)}}”.
  2. The next paragraph (or paragraphs), should be the text to appear in the callout box. This can be any kind of text, and can include notes, code snippets, and so forth.
  3. Highlight all the note text, as well as the gecko_callout_heading template line, then click the <div> icon in the toolbar. It’s on the middle row.
  4. In the popup dialog that appears, choose the style “Callout box” and click “OK”.
  5. Revel in the glory of your new callout box.

For example, if you do this:


The foo() method became obsolete in Gecko 13.0. Instead, you should use the uberFoo() method, as follows:

var result = uberFoo(myUrl);
if (!result) {
alert("uberFoo failed! ZOMG!");

That will have a similar result.

The output will look like this:

This will not only let you call out plainly that something changed, but let you also show how to do things after the change was made. You should absolutely feel free to use any or all of these techniques at the same time!

The point of all this is that because we have to support developers that are still using older versions of our software, or of other browsers, we can’t simply delete content when it’s no longer useful. Instead, we have to mark it as obsolete and move on from there.

I hope this was helpful!

 Posted by at 9:50 AM
May 142012

I have a side project I’m working on in collaboration with a friend, for which we needed version control. So I set out this weekend to set up a git server on my personal server, which runs Mac OS X 10.6.8. Fortunately, git is already there, courtesy of the standard Apple developer tools, so that part was already in place.

After spending some time reading through Pro Git on the Safari bookstore, as well as surfing the web, I figured out how to do it and got it all set up and working. I figured that, having done so, I should share what I did. So here we go!

Creating the server

  1. Start up Workgroup Manager and create a new “git” user. Set the startup shell for this user to a custom shell and enter “/usr/bin/git-shell”. This will prevent the “git” user from logging into a bash shell.
  2. In the Server Admin utility, add the “git” user to the list of users that have SSH access to the server; this is done in the “Access” panel.
  3. Open a terminal on the server (or ssh to it) and su git to work as the “git” user.
  4. Create your repository or repositories (see “Adding repositories” below).
  5. Add files to the repository; see “Adding files” below.

Giving access to users

In order to let contributors access the server, we’ll use SSH keys. Gather SSH public keys from everyone that will be contributing to the project. Then follow these steps:

  1. su git
  2. cd
  3. mkdir .ssh
  4. chmod 700 .ssh
  5. Append all of the public keys for your users to the file “.ssh/authorized_keys”, one per line.

Adding repositories

Follow these steps for each repository you want to create on the server.

  1. mkdir projectname.git
  2. cd projectname.git
  3. git init –bare

Adding files

For each repository, add files to the repository by following these steps from the machine on which your files are currently located:

  1. cd projectname
  2. git init
  3. git add *
  4. git commit -m “Some initial commit text.
  5. git remote add origin
  6. git push -u origin master

At this point, any of your users whose keys you’ve authorized can access your git server and can both push and fetch files from it.

Wrapping up

I wrote this little guide up from jotted-down notes and memory, so if I’ve made any mistakes, be sure to let me know so I can fix it. I fully expect I will refer back to this in the future (which is part of why I wrote it all down here)! I hope this helps you out too.

 Posted by at 4:20 PM
May 082012

Through some dark IT voodoo, we won’t be losing access to MDN today after all! That’s the shorthand version of what’s going on.

More precisely, IT has shut down one of our three MDN hosts and created a VM based on it down at the new data center; MDN will be hosted entirely off that one VM until the physical hardware is in place, at which point we’ll switch back over to the three physical servers we usually run on. Because the VM will be using our real database server the whole time, we don’t even have to lock down to prevent editing! This is an unexpected but highly welcome development that deserves a huge round of applause for our IT department, because every time we’ve tried this in the past, some dark MindTouch secret has prevented it from working.

All that said, because MDN will be operating on a single VM instead of three physical servers, I expect performance will be significantly lower than usual. So be ready for that.

 Posted by at 7:55 AM
May 072012

Please don’t forget: MDN will be offline for about eight hours tomorrow (that is, Tuesday, May 8th). Our IT team is physically removing the servers from their current data center and driving them to our new data center to transplant them there.

For the duration of that move, I expect visitors to MDN will be directed to visit or other sites temporarily for their basic documentation needs.

It will be interesting how many panicky emails, bug reports, and angry tweets we get over this planned downtime.

 Posted by at 12:24 PM
May 012012

I was ecstatic to discover that Mozilla has opened a position for a Mac Platform Integration engineer. While Firefox works, and works pretty well, on the Mac, there are a lot of quirks and oddities that get me down.

In some cases, it’s a matter of the uncanny valley effect. A long time ago, Firefox felt like a Windows application on the Mac. The UI was distinctly different from every other Mac application, and it stood out like a sore thumb. But you knew what you were getting into. You started it up, and because it looked nothing like a Mac app, it was okay that it didn’t really act like one. You didn’t expect it to.

But then we put a fair amount of work into making it look a lot more like a Mac application. As a result, we now have a Firefox that looks much more like a Mac app… but doesn’t quite act like one. There are little, subtle things that just feel wrong. This gives you this uneasy feeling, very much like the uncanny valley effect, and it’s unsettling. This really needs to be addressed, because it’s a big turnoff to a lot of people (myself included).

There are big things, too, of course.

A few things, right off the top of my head, that bug me:

  • Pop-up menus don’t behave like real Mac pop-up menus. This is one of those uncanny valley problems; they used to act totally different, then we made them much closer, but there are still differences, and they’re annoying.
  • Our pop-up panels (like the one that appears when you go to edit a bookmark) look very out-of-place, and many of them are not resizeable even though they would be much more useful if they could be resized.
  • Text selection behavior is subtly different in ways I can’t put my finger on, but I know the issue is there.
  • Drop-down sheets — particularly the one for configuring the toolbar — are just not right.
  • If Firefox isn’t running, and you click a link in another app that causes Firefox to open to open that app, and Firefox has an update pending, the update installs, Firefox restarts, and you don’t get your link opened. This was fixed at one point, then rebroke (possibly around the time we switched from Carbon to Cocoa). This drives me nuts, especially since I run on Aurora and/or Nightly, so it happens to me all the time.
  • We could use more and better gesture support. At one point, we had swipe to top and bottom support, but that vanished at some point. With Lion making it clear that gestures are the wave of the future on Mac, we need to get on board.
  • With Mountain Lion on the way, we need to look at integrating with the new Notification Center as well as the operating system’s built-in sharing service. Being able to quickly tweet using that service would be a really nice touch.

That’s by no means everything, but just what I could think about in the five minutes or so it took me to compose this post.

So if you’re a Mac developer looking for work, consider Mozilla! You’ll be glad you did! It’s a kick-ass place to work, and a lot of fun. And you’ll be making a great browser greater on the best operating system around.

 Posted by at 8:05 AM