The Capstone Hackweekend

This past weekend Mike Conley and I visited the Capstone team to work one-on-one with the students, teach topics, and share the history of Mozilla.

The current capstone project is a continuation from last semesters project. The students are working on converting Firefox’s localization implementation from DTD/properties files to Fluent. Fluent brings with it many new capabilities, such as platform-dependent strings, custom formatters, asynchronous applying of translation, and more.

Last semester’s capstone group migrating parts of Firefox and wrote migration scripts. They also attempted to migrate startup strings and profile the performance implications.

This semester the students are continuing to migrate more parts of Firefox, while also working on our Fluent tools and researching using a faster parser.

Topics for the weekend

We met the students bright and early Saturday morning at 9am. The first topics that we covered were the page lifecycle as it applies to Fluent translation and comparisons to how DTD and .properties files have their strings applied. We also covered Fluent best practices (limiting formatValues where possible, for example).

Through a long day of hacking and learning about how code is written, tested, and shipped at Mozilla, the students wrote patches for the following bugs:

• Migrate about:rights to Fluent
• Convert resetProfile.dtd to Fluent
• Convert unknownContentType.dtd to Fluent
• Migrate pageInfo.dtd to Fluent
• Convert migration.dtd to Fluent
• Migrate about:tabcrashed to Fluent
• Capstone: convert about:privatebrowsing using gandalf’s conversion script

On Saturday night, we hosted our first-ever “Mozilla movie-night” on campus, showing the 2000 documentary “Code Rush.” The documentary covers the open-sourcing of Netscape and the birth of Mozilla. It was pretty impressive to see over 20 college students show up to the Engineering Building at 8:30pm on a Saturday night. Mike and I also did a Q&A with the students before and after the movie about working in open source software, applying for jobs, and more.

Sunday morning we were back in the computer lab at 9am again for a half-day of hacking. We spent the first hour of the day teaching how to know if a test failure on tryserver is an intermittent failure related to the current patch or a pre-existing and known issue. This is very useful as the students have been pushing their patches to tryserver more often this semester than in previous groups.

This was our sixth time that we’ve hosted a hack weekend with the Capstone team (different team each semester). We schedule these to occur within the first few weeks of the start of the semester to help bootstrap the students on their project. It’s been a very valuable use of all of our time, as it helps the students get some face-time with their mentors, and the mentors get a better grasp of some of the challenges that the students are facing.

More eslint coverage for Firefox developers

Since my last post on the eslint work that is happening in mozilla-central, we have increased coverage as well as enabling more rules.

The publication of that post spawned a few conversations, among them Florian Quèze has added a bunch of new Mozilla-specific rules to our eslint configuration and evilpies has started looking at what it would take to run eslint on the JS engine code.

The following rules have been added:

• newURI originally had three arguments, of which the last two were sparsely used and often had null passed in. Florian converted newURI to make the last two arguments optional, and wrote a script to remove the unneeded null usages. This now has an eslint rule to enforce it.
• removeObserver had many usages that passed an unused third argument of false. This was most likely done as people were writing code that used addObserver(..., ..., false), and thought that they needed to pass false when calling removeObserver. After that, it most likely got copy-pasted around the codebase. This also now has an eslint rule enforcing people don’t do this again.
• addEventListener has a {once: true} argument that can be used to automatically remove the event listener after it is called the first time. This rule can be applied to any code that was indiscriminately calling removeEventListener. This work should land very soon, as it just got r+ today. This work is being tracked in bug 1331599.
• no-undef work continues to make progress as Mark Banner is now focusing on /services subdirectory. We also have a few more globals defined in our configuration and have more testing globals that are imported automatically through a new rule.
• quotes is now enabled, requiring double-quotes for strings except in cases where double-quotes are used within the string or if the string is a template literal.

While working on no-undef, Mark noticed that the /services directory wasn’t being scanned by eslint even though it wasn’t listed in the .eslintignore file. The directory was missing an .eslintrc.js file. We now have one added in the directory, though there remain 59 warnings which should be fixed (these are listed as warnings temporarily and will be converted to errors once fixed).

Also of note is that we now have automated tests for the custom rules that we have implemented. You can view these tests in the /tools/lint/eslint/eslint-plugin-mozilla/tests directory.

If you’ve got ideas for new rules that we can add to help clean up the codebase, please comment on this post or contact any of us on IRC on the #eslint channel of irc.mozilla.org.

Protecting your open source project from poisonous people

This previous Thursday I attended a talk by Brian “Fitz” Fitzpatrick of Google on “How to Protect Your Open Source Project from Poisonous People”. Brian started Google’s Chicago Engineering office in 2005 working as an engineer on Google Code. He now leads several of Google’s Chicago engineering efforts, including Google Code, the Data Liberation Front, and the Google Affiliate Network. He also serves as internal advisor for Google’s open source efforts.

Brian started off the talk by recommending “Producing Open Source Software“, a free book written by Karl Fogel. I’ve added the book to my future reading list, and will try to take it in once the semester ends.

A lot of students within Computer Science think that the hardest part about making software is inventing algorithms or finding ways to use obscure data structures for improved performance. As someone who has worked within industry now for a few years, I immediately knew where he was going with this. I agreed with Brian when he said that the actual hardest problem is working with other people.

Poisonous people on a project can make others leave and cause fighting over little things. To reduce this problem, you’ll want to build a strong community based on politeness, respect, trust, and humility. If a person joins on to the project and is causing a disruption of some sorts, it is best to identify behaviors and address them the best way you can. Notice there that addressing behaviors is the goal, not addressing people.

Addressing behaviors vs. addressing people comes up in a lot of conflict resolution scenarios, and often the importance of it is overlooked. Jay Smooth describes a very similar scenario very well.

Brian also recommended defining a mission for the project. As he said, if the mission isn’t already defined, someone else will define it for you.

Feel free to read the rest of my notes from the talk as I’ve typed them up on a Google Doc.

Contributing to Open Source Software

Last week I attended the Google I/O conference. I went to some great sessions and learned a ton about Chrome, App Engine, and Android.

One of my biggest takeaways wasn’t from the sessions that I attended. I happened to bump in to some other college-aged guys and after some talking learned that they were contributors and committers to the Chromium project (the open source version of Google Chrome).

Now last year (2009) at the beginning of the summer, I wanted to participate in Google Summer of Code, specifically in one of the Google Chrome projects. I followed the steps on their developer setup guide, and kicked off a build on my machine. Hours later I realized that my machine was no match for Chromium.

Too much had to be installed to build the project and the file size of the project was leaps and bounds more than my pesky laptop could handle. I ended up putting away Chromium and focusing on tackling some books I had been wanting to read.

This summer is a whole new ball game. I’ve upgraded my computer and the Chromium project has also shed a lot of dependencies since May 2009. I’m happy to say that I was able to install Visual Studio 2008 Premium, SP1, a few hotfixes, and was off to building. An hour of waiting and I had my own build of Chromium running.

Today I can now say that I am a contributor to Chromium. I am proud that my name now resides on the AUTHORS file of Chromium, and I want to take this opportunity to pass-on some motivation for contributing to open source software.

If you’ve got an open source program that you use daily and get a lot out of, return the favor to the authors and help them out. Most open source software is free, so they’re not making money off of you using the software. It’s just kind of the fair thing to do.

Not to mention that there are tons of benefits that you will gain by contributing to an open source project. Let’s run through a list:

1. Experience working with different code (paradigms, styles, patterns, algorithms)
2. Get to work with developers located all across the world
3. A great opportunity to learn more about a programming language
4. A feeling of ownership of the product that you enjoy
5. and so many more…

So take a second right now and think of the programs that you use and love. Are any of them open source? Do they have a list of bugs that could use some help? You could even take this opportunity to fix anything that you don’t like about the application and make a special build for yourself 🙂

YouTube Playlist Downloader source code will be released

As I continue to work on making more of my source code open, I will be making all of the source code for the YouTube Playlist Downloader open source. You can expect to see a post up here soon with a link to the source files, and I will also cover some of the technologies used in more depth.

In the meantime, here is a very general overview: YouTube Playlist Downloader (YPD) was a project that I took up to learn Windows Presentation Foundation (WPF). It uses WPF for the user interface and all the animations. Windows Presentation Foundation was released with Microsoft .NET 3.0, which is why there is a requirement for this version of the framework. To get the list of videos in a playlist from YouTube, an external RSS web services is used. The files are then downloaded, and transcoded using FFmpeg.

That’s about the shortest technical overview I could give, and probably still left out too much. Look forward to some code walkthroughs in the next week or so. I haven’t made up my mind yet if it will be available as a .zip file or something where you can browse the source code online ala Google Code.