Jun 212012
 

Change is coming to the Mozilla Developer Network!

As you probably know, we’ve been using the MindTouch wiki software for several years now, and although it’s a nice package, it has not been a good fit for us. As I hope you also already know, we’ve been working for the last couple of years on a brand new replacement wiki, codenamed Kuma, to replace it.

The time for the switch to Kuma is nearly upon us! On or before July 15, we will throw the switch and have all users on the Kuma wiki platform.

Change can be a little scary, but this is a great thing for us. We will get stability, reliability, performance, and, over time, some kick-ass new features. As it stands, localizers should be pleased with a number of new tools they’ll get with Kuma.

The Kuma launch will happen on or before July 15. That’s not much time at all. We have some ongoing test projects for small groups, and we’ll be announcing tests for larger groups soon.

The important thing I want to get out there is that you’re going to see changes, and we don’t want you to be totally surprised! Future blog posts will share details about what to expect, but you can learn more from our basic Kuma documentation on MDN. It’s sketchy at the moment but I promise it will get better very soon!

Watch this space for further news and details. We’re all very excited about this project, and we think you’re going to love it.

 Posted by at 1:34 PM
Jun 202012
 

Fun, but see Phil Plait.

 Posted by at 10:41 AM
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:

{{gecko_callout_heading(“13.0”)}}

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 git@myserver.com:projectname.git
  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 dochub.io 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
Apr 302012
 

We had a fantastic documentation sprint this weekend! I won’t go over all the stuff we got accomplished, since that’s already covered elsewhere. Instead, I’d just like to thank the folks that came out for their time, and for all their hard work.

In addition to writing a lot of material, we got a lot cleaned up, and spent some great time talking, getting to know one another, and seeing the city of San Francisco and the surrounding area. Our ferry ride up to Sausalito for dinner, and the cab ride back to the city across the Golden Gate Bridge was, I know, a big hit with some of our first-time visitors to the Bay Area.

I personally enjoyed meeting everyone I didn’t already know, and seeing familiar faces once again. On top of that, it was nice to check out the San Francisco office, which I’d not yet seen. I understand now why it’s so popular. It’s one of the most impressive locations I’ve ever seen!

While most people share pictures of the view of the Bay or of the Bay Bridge, I want to share this one. I remember this sign from when I was a kid, but never from this close up!

The iconic Hills Bros. building sign!

It makes me very proud to work for an organization that will bring community members together like this to collaborate in real time, in person, now and then. It’s great for community bonding as well as for just getting things done. And I’m proud of our contributors that attended for giving up some of their personal time to spend time with us here in the City by the Bay. Thank you!

 Posted by at 1:17 PM
Apr 152012
 

As I’ve blogged about before, I’ve been working on sample code for the source-editor.jsm that was added to Firefox as part of the ongoing work on the developer tools. This sample code evolved over time into a full-fledged extension, and one I’m rather proud of. I just posted it to AMO today.

Edit Source adds options to the Web Developer menu and the context menu on text-based documents (including HTML, CSS, XML, and JavaScript), which lets you open a source editor window. You can then edit the document’s text, save it to your local disk, and most interestingly, re-render the original document (for HTML, anyway) to reflect the changes you’ve made.

This makes it a handy tool for experimenting with HTML, and a nice learning tool. In addition, if you open up an about:blank tab and edit its source, you can write HTML from scratch and see what it looks like rendered on screen. That’s also a pretty neat trick.

There are things that would be fun and useful to add to it, but I probably need to move on and get to writing again! So I’ve posted the code to Github. Feel free to take a look and tweak it! There’s an IDEAS.txt file in the repository you can look at for some thoughts for things that might be handy to add.

 Posted by at 4:46 PM