First MozLou gathering in Kentucky!

First Mozilla gathering in Louisville, Kentucky at Havana Rumba Cuban on May 02, 2012.

Today was the first lunch gathering of several Mozillians in Kentucky! I am really fortunate to be able to experience life in the South for the first time, and together with Curtis Koenig (on the left), met up with Stephen Horlander (on the right) at the Havana Rumba Cuban cafe in Louisville.

These few days have been great – after work was done during the day we headed to do stuff that one can barely think of in the urban areas, such as harvesting asparagus:

Harvesting asparagus on farmland!

It was great to see lots of farmland, horses, vast areas of greenery, and of course, bourbon, having hailed from urban areas all my life. First time to see asparagus growing in the soil (yeah, probably due to me only ever seeing them in grocery stores)…

The component to be attached to a John Deere combine harvester is huge..

… huge John Deere farming machines such as combine harvesters (things that I only got to read about, if I knew them at all) …

These are chicken and dumplings from Cracker Barrel.

… dumplings (noodles) from the South (the white sauce on the chicken and dumplings is very tasty) …

White Castle drive-in, they make sliders and are very popular locally.

… and of course sliders (they are greasy so they “slide”)!

Next up, hopefully I’ll get to head to Claudia Sanders Dinner House soon to visit the place where Colonel Harland Sanders (of Kentucky Fried Chicken fame) used to live in. And there’s the upcoming Kentucky Derby too!

(Pictures taken with a Nexus One)


What Mozilla is about..

Recently, I was in a group of friends where I was the new guy, and there were the usual questions about where you’re from, and what you do, etc. Having said that I worked in Mozilla, including Firefox, the folks perked up asking about update fatigue and comparisons with competing browsers.

However, once I mentioned that Mozilla always puts the needs and wants of the end-user first on its priority list and not to maximise profit for itself nor its shareholders, (or something along those lines because I was not speaking in English), the whole room simply went, “Whoa……” with a smile on most faces.

Couldn’t have wished for a better response.

Rust Made Easy – Part 1

Edited on 2013-04-03: This page is outdated.

Rust is a prospective language which just had its version 0.1 released, and coming from a background that does not hail from C or C++, learning it seemed quite daunting. Starting off writing Java in college and digesting Python in my free time helped, but just a little. Since I previously had some time on a plane and not really sleeping, I’ve been looking at ways to simplify learning Rust, and hopefully by guiding you, as a reader, along the way will help us share our experiences and enhance learning opportunities for all.

But seriously, what is Rust? You can find a short write-up here, along with things like not allowing null pointers (Yay! no more null crashes). Various other technical bits are way above me now. Nonetheless, follow the instructions to obtain your Rust compiler. In the following examples, save the code snippets in a file, renaming “test” to whatever you like as long as it still ends with .rs, compile it with the Rust compiler “rustc” and then execute the compiled file “./test”.

Alright, so let’s dive into Rust. To print a statement, let us understand that we first have to import a standard library or a module, known as std.

use std;

It’s like including iostream.h in C++.

Once we’ve done that, we can now print a statement:

use std;
fn main() {
    std::io::println("Hello World!");

to get:

Hello World!

(In Python, it is the equivalent of “print ‘Hello World!”)

In Rust, it is necessary to have a main function. The double colons “::” mean that it is calling println within module io within the std module. It’s similar to System.out.println in Java. Note that semicolons “;” at the end of the lines seem to be necessary most of the time — there are special circumstances where “;” is not needed at the end, but let’s leave that for later.

How about a number? I would like to create a local variable, which is a number, and print it. In this case, we use `let`:

use std;
fn main() {
    let x: int = 8;
    std::io::println("Our number is: " + int::str(x));

Two new things here. One is “let x: int = 8;”, which means create a local variable x of the type int, and set its value to 8. Again, there will be situations in the future where you leave out specifying the type, and in those cases the type will be inferred (the compiler will “guess” the type).

Second, note that we cast x to a string before printing it. In Rust, we cannot print a number without first changing its type to a string. This is done by calling str from the int module and passing in x, so we have “int::str(x)”.

You should get the output:

Our number is: 8

You may have noticed that Rust uses shortened keywords, such as “fn” for a function. It also uses “ret” for returning values. We will see more of this as we go along.

Next up, let’s construct a separate function instead of cramming everything up in main, and have it print our favourite number again:

use std;
fn fav_number(n: int) {
    std::io::println("Our number is: " + int::str(n));
fn main() {
    let x: int = 8;

You may notice that the fav_number function accepts an integer variable n, and this is reflected by “n: int”.

What if we want to pass in our favourite number as a command-line argument? This is done by:

use std;
fn fav_number(n: str) {
    std::io::println("Our number is: " + n);
fn main(args: [str]) {

Run this with “./test 8” and you should get the same output as above:

Our number is: 8

Remember to run it with a number as an argument – if you leave out the number, you will get an error:

rust: upcall fail ‘bounds check’,
rust: domain main @0x22a1a50 root task failed

Examine this example more closely and you will realize that there is no casting involved. This is because we are taking in the argument (number) as a string, and merely printing it out again.

Fuzzing at Mozilla brown bag on January 30, 1pm PT

Fuzzing [1], a form of randomized testing, it is an integral portion of the testing process at Mozilla. Crashes, hangs, assertions and various security problems, such as memory safety problems, are discovered through fuzzing [2].

Thousands of bugs in Mozilla applications have been found using fuzzers. In particular, 3 of the fuzzers have been responsible for more than a third of critical security bugs.

Drop by on Monday, January 30, at 1pm Pacific Time in 10 Forward, where we will host a brown bag session sharing a high-level overview on how fuzzing is used to discover these issues and how you can help us find more bugs.

The brown bag should be available on the public Air Mozilla ( ) and archived here.

See you there!

Gary Kwong
Mozilla Security Research and Testing


How one learns from his students in his very own class..

The third semester of teaching CS3108 (Mozilla) is coming to an end. For those of you new to the course, it is one that I guide students at my school, National University of Singapore, where I am currently finishing my third year of undergraduate studies. (Kudos to Professor Lee Wee Sun for supporting me over the many months, as well as others I haven’t mentioned)

Over the past semesters, I have welcomed student feedback on how I can make the course better and more exciting, at the same time remaining its flexibility in allowing students to fulfill their dreams at working on a large open source project.

Some of the feedback have been interesting. The first two batches came back with the opinions that each lesson have an overview of what the lesson should be about (I’m getting better at this, doesn’t seem to be a problem this semester), while there have consistently been queries asking about the CAP (GPA in other countries) required to take the course (which there isn’t).

As for the latter, my professors have been noting the trend that half the students in the first lesson of the course seem to disappear after hearing about the expectations. I am of the opinion that only the independent survive, because I am a student myself, I do not possess the opinion that the students be spoonfed material. I merely guide them along, in return for some wonderful projects that have happened over the past courses. To be honest, by the second half of the course, the students are usually much more well-versed than I am in their own area of interest.

Of course, I could always do better. This semester, there has been thought about how to obtain a student-project more easily, and this in fact has recently been mitigated with the introduction of the `student-project` keyword a while back. Interestingly, the students are also suggesting to give homework, not in the form of overly tough laboratory work, but rather short little quests. Such quests could involve writing a simple mozmill test to open a new tab, or even to use the DOM Inspector and find out the id of the Go button in Firefox, for example.

I thoroughly enjoy my classes at school. It is a great opportunity for the students to learn about the open source world, as well as a place where I can also learn from the students themselves, especially since some of their technical coding skills may be better than my very own. It brings forth the message of humility, where no one is above anyone else. I always encourage them to refer to the classes as “sharing sessions”, and to call me by name rather than “Professor”, “Lecturer”, or “Sir”, especially since I am none of the former.

I will continue to teach the course for another two semesters, till I graduate. Hopefully by then someone will take over, but till then I will continue to teach the class even though it does occasionally get tiring on top of my own university work. I thank my professors (Professor Dave Humphrey included), past and present students and members of the Mozilla community who patiently help out the students as they swim their way out of the deep end. The course has helped both the community (they get fixes) and the students (they get the experience – one past student did enough to get his name in official credits, another made use of the experience to set up his company, and a third finally may have found enough confidence to apply for a Google Summer of Code project).

CS3108 (Mozilla) will count as one of the biggest achievements that I am proud of, during my university days. I sincerely hope both the students and myself will benefit from this experience as we begin to look for jobs after graduation and step out into the real world.

NUS Student Projects – finalized for AY 09/10 Semester 2

This time, three students from National University of Singapore are taking on Mozilla projects across various disciplines, in no particular order:

Feel free to say hi to them if you spot them on IRC!