Anjana Sofia Vakil

Notes from KatsConf2

2017-02-19T00:00:00+00:00

Hello from Dublin! Yesterday I had the privilege of attending KatsConf2, a functional programming conference put on by the fun-loving, welcoming, and crazy-well-organized @FunctionalKats. It was a whirlwind of really exciting talks from some of the best speakers around. Here’s a glimpse into what I learned.

There’s no such thing as an objectively perfect programming language: all languages make tradeoffs. But it is possible to find/design a language that’s more perfect for you and your project’s needs.
Automation, automation, automation:
- Generative programming lets you write high-level code that generates low-level code
- Program derivation and synthesis let you write specifications/tests and leave it to the computer to figure out the code
- (Boring!) code rewriting tasks can be automated too
Relational programming, Total programming and Type-Driven Development are (cool/mindblowing) things.
You can do web programming with FP - and interestingly, even in a total language like Idris.

I took a bunch of notes during the talks, in case you’re hungering for more details. But @jessitron took amazing graphical notes that I’ve linked to in the talks below, so just go read those!

And for the complete experience, check out this storify Vicky Twomey-Lee, who led a great ally skills workshop the evening before the conference, made of the #KatsConf2 tweets:

Hopefully this gives you an idea of what was said and which brain-exploding things you should go look up now! Personally it opened up a bunch of cans of worms for me - definitely a lot of the material went over my head, but I have a ton of stuff to go find out more (i.e. the first thing) about.

Disclaimer: The (unedited!!!) notes below represent my initial impressions of the content of these talks, jotted down as I listened. They may or may not be totally accurate, or precisely/adequately represent what the speakers said or think, and the code examples are almost certainly mistake-ridden. Read at your own risk!

The origin story of FunctionalKats

FunctionalKatas => FunctionalKats => (as of today) FunctionalKubs

Meetups in Dublin & other locations
Katas for solving programming problems in different functional languages
Talks about FP and related topics
Welcome to all, including beginners

The Perfect Language

Bodil Stokke @bodil

Bodil's opinions on the Perfect Language. #katsConf2
Rather noninflammatory, it must be early in the morning https://t.co/KsqGAKubpd
— Jessica Kerr (@jessitron) February 18, 2017

What would the perfect programming language look like?

“MS Excel!” “Nobody wants to say ‘JavaScript’ as a joke?” “Lisp!” “I know there are Clojurians in the audience, they’re suspiciously silent…”

There’s no such thing as the perfect language; Languages are about compromise.

What the perfect language actually is is a personal thing.

I get paid to make whatever products I feel like to make life better for programmers. So I thought: I should design the perfect language.

What do I want in a language?

It should be hard to make mistakes

On that note let’s talk about JavaScript. It was designed to be easy to get into, and not to place too many restrictions on what you can do. But this means it’s easy to make mistakes & get unexpected results (cf. crazy stuff that happens when you add different things in JS). By restricting the types of inputs/outputs (see TypeScript), we can throw errors for incorrect input types - error messages may look like the compiler yelling at you, but really they’re saving you a bunch of work later on by telling you up front.

Let’s look at PureScript

Category theory! Semiring: something like addition/multiplication that has commutativity (a+b == b+a). Semigroup: …?

There should be no ambiguity

1 + 2 * 3

vs.

(+ 1 (* 2 3))

Pony: 1 + (2 * 3) – have to use parentheses to make precedence explicit

It shouldn’t make you think

Joe made a language at Ericsson in the late 80’s called “Erlang”. This is a gif of Joe from the Erlang movie. He’s my favorite movie star.

Immutability: In Erlang, values and variable bindings never change. At all.

This takes away some cognitive overhead (because we don’t have to think about what value a variable has at the moment)

Erlang tends to essentially fold over state: the old state is an input to the function and the new state is an output.

The “abstraction ceiling”

This term has to do with being able to express abstractions in your language.

Those of you who don’t know C: you don’t know what you’re missing, and I urge you not to find out. If garbage collection is a thing you don’t have to worry about in your language, that’s fantastic.

Elm doesn’t really let you abstract over the fact that e.g. map over array, list, set is somehow the same type of operation. So you have to provide 3 different variants of a function that can be mapped over any of the 3 types of collections. This is a bit awkward, but Elm programmers tend not to mind, because there’s a tradeoff: the fact that you can’t do this makes the type system simple so that Elm programmers get succinct, helpful error messages from the compiler.

I was learning Rust recently and I wanted to be able to express this abstraction. If you have a Collection trait, you can express that you take in a Collection and return a Collection. But you can’t specify that the output Collection has to be the same type as the incoming one. Rust doesn’t have this ability to deal with this, but they’re trying to add it.

We can do this in Haskell, because we have functors. And that’s the last time I’m going to use a term from category theory, I promise.

On the other hand, in a language like Lisp you can use its metaprogramming capabilities to raise the abstraction ceiling in other ways.

Efficiency

I have a colleague and when I suggested using OCaml as an implementation language for our utopian language, she rejected it because it was 50% slower than C.

In slower languages like Python or Ruby you tend to have performance-critical code written in the lower-level language of C.

But my feeling is that in theory, we should be able to take a language like Haskell and build a smarter compiler that can be more efficient.

But the problem is that we’re designing languages that are built on the lambda calculus and so on, but the machines they’re implemented on are not built on that idea, but rather on the Von Neumann architecture. The computer has to do a lot of contortions to take the beautiful lambda calculus idea and convert it into something that can run on an architecture designed from very different principles. This obviously complicates writing a performant and high-level language.

Rust wanted to provide a language as high-level as possible, but with zero-cost abstractions. So instead of garbage collection, Rust has a type-system-assisted kind of clean up. This is easier to deal with than the C version.

If you want persistent data structures a la Erlang or Clojure, they can be pretty efficient, but simple mutation is always going to be more efficient. We couldn’t do PDSs natively.

Suppose you have a langauge that’s low-level enough to have zero-cost abstractions, but you can plug in something like garbage collection, currying, perhaps extend the type system, so that you can write high-level programs using that functionality, but it’s not actually part of the library. I have no idea how to do this but it would be really cool.

Summing up

You need to think about:

Ergonomics
Abstraction
Efficiency
Tooling (often forgotten at first, but very important!)
Community (Code sharing, Documentation, Education, Marketing)

Your language has to be open source. You can make a proprietary language, and you can make it succeed if you throw enough money at it, but even the successful historical examples of that were eventually open-sourced, which enabled their continued use. I could give a whole other talk about open source.

Functional programming & static typing for server-side web

Oskar Wickström @owickstrom

FP has been influencing JavaScript a lot in the last few years. You have ES6 functional features, libraries like Underscore, Rambda, etc, products like React with FP/FRP at their core, JS as a compile target for functional languages

But the focus is still client-side JS.

Single page applications: using the browser to write apps more like you wrote desktop apps before. Not the same model as perhaps the web browser was intended for at the beginning.

Lots of frameworks to choose from: Angular, Ember, Meteor, React&al. Without JS on the client, you get nothing.

There’s been talk recently of “isomorphic” applications: one framework which runs exactly the same way on the esrver and the client. The term is sort of stolen & not used in the same way as in category theory.

Static typing would be really useful for Middleware, which is a common abstraction but every easy to mess up if dynamically typed. In Clojure if you mess up the middleware you get the Stack Trace of Doom.

Let’s use extensible records in PureScript - shout out to Edwin’s talk related to this. That inspired me to implement this in PureScript, which started this project called Hyper which is what I’m working on right now in my free time.

Goals:

Safe HTTP middleware architecture
Make effects of middleware explicit
No magic

How?

Track middleware effects in type system
leverage extensible records in PureScript
Provide a common API for middleware
Write middleware that can work on multiple backends

Design

Conn: sort of like in Elixer, instead of passing a request and returning a response, pass them all together as a single unit
Middleware: a function that takes a connection c and returns another connection type c’ inside another type m
Indexed monads: similar to a state monad, but with two additional parameters: the type of the state before this action, and the type after. We can use this to prohibit effectful operations which aren’t correct.
Response state transitions: Hyper uses phantom types to track the state of response, guaranteeing correctness in response side effects

Functional Program Derivation

@Felienne

(Amazing, hand-drawn, animal-filled) Slides

#KatsConf2 notes from @Felienne TL;DR Math is good practice at being precise. This helps with programming. https://t.co/4QB9xFcLay
— Jessica Kerr (@jessitron) February 18, 2017

Program derivation:

Problem => Specification => Derivation => Program

Someone said this is like “refactoring in reverse”

Generalization: introduce parameters instead of constant values

Induction: prove something for a base case and a first step, and you’ve proven it for all numbers

Induction hypothesis: if you are at step n, you must have been at step n-1 before that.

With these elements, we have a program! We just make an if/else: e.g. for sum(n), if n == 0: return 0; else return sum(n-1) + n

It all comes down to writing the right specification: which is where we need to step away from the keyboard and think.

Induction is the basis of recursion.

We can use induction to create a specification for sorting lists from which we can derive the QuickSort algorithm.

But we get 2 sorting algorithms for the price of 1: if we place a restriction that we can only do one recursive call, we can tweak the specification to derive InsertionSort, thus proving that Insertion Sort is a special case of Quick Sort.

I stole this from a PhD dissertation (“Functional Program Derivation” by ). This is all based on program derivation work by Djikstra.

Takeaways:

Programming == Math. Practicing some basic math is going to help you write code, even if you won’t be doing these kind of exercises on yo ur day-to-day
Calculations provide insight
Delay choices where possible. Say “let’s assume a solution to this part of the problem” and then go back and solve it later.

I’m writing a whole book on this, if you’re interested in giving feedback on chapter drafts let me know! mail at felienne dot com

Q&A:

is there a link between the specification and the complexity of the program? Yes, the specification has implications for implementation. The choices you make within the specification (e.g. caching values, splitting computation) affect the efficency of the program.
What about proof assistants? Those are nice if you’re writing a dissertation or whatnot, but if you’re at the stage where you’re practicing this, the exercise is being precise, so I recommend doing this on paper. The second your fingers touch the keyboard, you can outsource your preciseness to the computer.
Once you’ve got your specification, how do you ensure that your program meets it? One of the things you could do is write the spec in something like fscheck, or you could convert the specification into tests. Testing and specification are really enriching each other. Writing tests as a way to test your specification is also a good way to go. You should also have some cases for which you know, or have an intuition of, the behavior. But none of this is supposed to go in a machine, it’s supposed to be on paper.

The cake and eating it: or writing expressive high-level programs that generate fast low-level code at runtime

Nada Amin @nadamin

Distinguish stages of computation

Program generator: basic types (Int, String, T) are executed at code generation time
Rep(Int), Rep(String), Rep(T) are left as variables in the generated code and executed at program run time(?)

Shonan Challenge for Generative Programming - part of the gen. pro. for HPC literature: you want to generate code that is specialized to a particular matrix

Demo of generating code to solve this challenge

Generative Programming Patterns

Deep linguistic reuse
Turning interpreters into compilers
- You can think of the process of staging as something which generates code, think of an interpreter as taking code and additional input and creates a result.
- Putting them together we get something that takes code and symbolic input, and in the interpret stage generates code which takes actual input, which in the execution stage produces a result
- This idea dates back to 1971, Futamura’s Partial Evaluation
Generating efficient low-level code
- e.g. for specialized parsers
- We can take an efficient HTTP parser from 2000+ lines to 200, with parser combinators
- But while this is great for performance, it leaves big security holes
- So we can use independent tools to verify the generated code after the fact

Sometimes generating code is not the right solution to your problem

More info on the particular framework I’m using: Generative Programming for ‘Abstraction without Regret’

Rug: an External DSL for Coding Code Transformations (with Scala Parser-Combinators)

Jessica Kerr @jessitron, Atomist

The last talk was about abstraction without (performance) regret. This talk is about abstraction without the regret of making your code harder to read.

Elm is a particularly good language to modify automatically, because it’s got some boilerplate, but I love that boilerplate! No polymorphism, no type classes - I know exactly what that code is going to do! Reading it is great, but writing it can be a bit of a headache.

As a programmer I want to spend my time thinking about what the users need and what my program is supposed to do. I don’t want to spend my time going “Oh no, i forgot to put that thing there”.

Here’s a simple Elm program that prints “Hello world”. The goal is to write a program that modifies this existing Elm code and changes the greeting that we print.

We’re going to do this with Scala. The goal is to generate readable code that I can later go ahead and change. It’s more like a templating engine, but instead of starting with a templating file it starts from a cromulent Scala program.

Our goal is to parse an Elm file into a parse tree, which give us the meaningful bits of that file.

The “parser” in parser combinators is actually a combination of lexer and parser.

Reuse is dangerous, dependencies are dangerous, because they create coupling. (Controlled, automated) Cut & Paste is a safer solution.

at which point @jessitron does some crazy fast live coding to write an Elm parser in Scala

Rug is the super-cool open-source project I get to work on as my day job now! It’s a framework for creating code rewriters

Repo for this talk

In conclusion: any time my job feels easy, I think “OMG I’m doing it wrong”. But I don’t want to introduce abstraction into my code, because someone else is going to have difficulty reading that. I want to be able to abstract without sacrificing code readability. I can make my job faster and harder by automating it.

Relational Programming

Will Byrd

Your days are numbered, human programmers. #KatsConf2 @webyrd https://t.co/NK8tRg3sei
— Jessica Kerr (@jessitron) February 18, 2017

There are many programming paradigms that don’t get enough attention. The one I want to talk about today is Relational Programming. It’s somewhat representative of Logic Programming, like Prolog. I want to show you what can happen when you commit fully to the paradigm, and see where that leads us.

Functional Programming is a special case of Relational Programming, as we’re going to see in a minute.

What is functional programming about? There’s a hint in the name. It’s about functions, the idea that representing computation in the form of mathematical functions could be useful. Because you can compose functions, you don have to reason about mutable state, etc. - there are advantages to modeling computation as math. functions.

In relational programming, instead of representing computation as functions we represent it as relations. You can think of a relation in may ways. If you’re familiar with relational databases, or you can think in terms of tuples where we want to reason over sets or collections of tuples, or we can think of it in terms of algebra - like high school algebra - where we have variables representing unknown quantities and we have to figure out their values. We’ll see that we can get FP as a special case - there’s a different set of tradeoffs - but we’ll see that when you commit fully to this paradigm you can get some very surprising behavior.

Let’s start in our functional world, we’re going to write a little program in Scheme or Racket, a little program to manipulate lists. We’ll just do something simple like append or concatenate. Let’s define append in Scheme:

(define append
  (lambda (l s)
    (if (null? l)
        s
        (cons (car l) (append (cdr l) s))))

We’re going to use a relational programming language called Mini Kanren which is basically an extension that has been applied to lots of languages which allows us to put in variables representing values and ask Kanren to fill in those values.

So I’m going to define appendo. (By convention we define our names ending in -o, it’s kind of a long story, happy to explain offline.)

Writes a bunch of Kanren that we don’t really understand

Now I can do:

> (run 1 (q) (appendo '(a b c) '(d e) q))
((a b c d e))

So far, not very interesting, if this is all it does then it’s no better than append. But where it gets interesting is that I can run it backwards to find an input:

> (run 1 (X) (appendo '(a, b, c) X (a b c d e)))
((d e))

Or I can ask it to find N possible inputs:

> (run 2 (X Y) (appendo X Y (a b c d e)))
((a b c d) (e))
((a b c d e) ())

Or all possible inputs:

> (run* (X Y) (appendo X Y (a b c d e)))
((a b c d) (e))
((a b c d e) ())
...

What happens if I do this?

> (run* (X Y Z) (appendo X Y Z))

It will run forever. This is sort of like a database query, except where the tables are infinite.

One program we could write is an interpreter, an evaluator. We’re going to take an eval that’s written in MiniKanren, which is called evalo and takes two arguments: the expression to be evaluated, and the value of that expression.

> (run 1 (a) (evalo '(lambda (x) x) q))
((closure x x ()))

> (run 1 (a) (evalo '(list 'a) q))
((a))

Professor wrote a Valentine's day post "99 ways to say 'I love you' in Racket", to teach people Racket by showing 99 different racket expressions that evaluate to the list `(I love you)`

> (run 99 (q) (evalo q '(I love you)))
...99 ways...

What about quines: a quine is a program that evaluates to itself. How could we find or generate a quine?

> (run 1 (q) (evalo q q))

And twines: two different programs p and q where p evaluates to q and q evaluates to p.

> (run 1 (p q) (=/= p q) (evalo p q) (evalo q p))
...two expressions that basically quote/unquote themselves...

What would happen if we run Scheme’s append in our evaluator?

> (run 1 (q)
    (evalo
      `(letrec ((append
                  (lambda (l s)
                    (if (null? l)
                        s
                        (cons (car l)
                              (append (cdr l)
                                      s)))))))
          (append '(a b c) '(d e))
      q))
((a b c d e))

But we can put the variable also inside the definition of append:

> (run 1 (q)
    (evalo
      `(letrec ((append
                  (lambda (l s)
                    (if (null? l)
                        q
                        (cons (car l)
                              (append (cdr l)
                                      s)))))))
          (append '(a b c) '(d e))
      '(a b c d e)))
(s)

Now we’re starting to synthesize programs, based on specifications. When I gave this talk at PolyConf a couple of years ago Jessitron trolled me about how long it took to run this, since then we’ve gotten quite a bit faster.

This is a tool called Barliman that I (and Greg Rosenblatt) have been working on, and it’s basically a frontend, a dumb GUI to the interpreter we were just playing with. It’s just a prototype. We can see a partially specified definition - a Scheme function that’s partially defined, with metavariables that are fill-in-the-blanks for some Scheme expressions that we don’t know what they are yet. Barliman’s going to guess what the definition is going to be.

(define ,A
    (lambda ,B
      ,C))

Now we give Barliman a bunch of examples. Like (append '() '()) gives '(). It guesses what the missing expressions were based on those examples. The more test cases we give it, the better approximation of the program it guesses. With 3 examples, we can get it to correctly guess the definition of append.

Yes, you are going to lose your jobs. Well, some people are going to lose their jobs. This is actually something that concerns me, because this tool is going to get a lot better.

If you want to see the full dog & pony show, watch the ClojureConj talk I gave with Greg.

Writing the tests is indeed the harder part. But if you’re already doing TDD or property-based testing, you’re already writing the tests, why don’t you just let the computer figure out the code for you based on those tests?

Some people say this is too hard, the search space is too big. But that’s what they said about Go, and it turns out that if you use the right techniques plus a lot of computational power, Go isn’t as hard as we thought. I think in about 10-15 years program synthesis won’t be as hard as we think now. We’ll have much more powerful IDEs, much more powerful synthesis tools. It could even tell you as you’re writing your code whether it’s inconsistent with your tests.

What this will do for jobs, I don’t know. I don’t know, maybe it won’t pan out, but I can no longer tell you that this definitely won’t work. I think we’re at the point now where a lot of the academic researchers are looking at a bunch of different parts of synthesis, and no one’s really combining them, but when they do, there will be huge breakthroughs. I don’t know what it’s going to do, but it’s going to do something.

Working hard to keep things lazy

Raichoo @raichoo

The how, why, and trade offs of non-strictness in Haskell @raichoo #KatsConf2 https://t.co/TWkJjW3gL7
— Jessica Kerr (@jessitron) February 18, 2017

Without laziness, we waste a lot of space, because when we have recursion we have to keep allocating memory for each evaluated thing. Laziness allows us to get around that.

What is laziness, from a theoretical standpoint?

The first thing we want to talk about is different ways to evaluate expressions.

> f x y = x + y
> f (1 + 1) (2 + 2)  

How do we evaluate this?

=> (1 + 1) + (2 + 2)
=> 2 + 4
=> 6  

This evaluation was normal form

Church-Rosser Theorem: the order of evaluation doesn’t matter, ultimately a lambda expression will evaluate to the same thing.

But! We have things like non-termination, and termination can only be determined after the fact.

Here’s a way we can think of types: Let’s think of a Boolean as something which has three possible values: True, False, and “bottom”, which represents not-yet-determined, a computation that hasn’t ended yet. True and False are more defined than bottom (e.g. _|_ <= True). Partial ordering.

Monotone functions: if we have a function that takes a Bool and returns a Bool, and x and y are bools where x <= y, then f x <= f y. We can now show that f _|_ = True and f x = False doesn’t work out, because it would have the consequence that True => False, which doesn’t work - that’s a good thing because if it did, we would have solve the halting problem. What’s nice here is that if we write a function and evaluate it in normal order, in the lazy way, then this naturally works out.

Laziness is basically non-strictness (this normal order thing I’ve been talking about the whole time), and sharing.

Laziness lets us reuse code and use combinators. This is something I miss from Haskell when I use any other language.

Honorable mention: Purely Functional Data Structures by Chris Okasaki. When you have Persistent Data Structures, you need laziness to have this whole amortization argument going on. This book introduces its own dialect of ML (lazy ML).

How do we do laziness in Haskell (in GHC)? At an intermediate stage of compilation called STG, Haskell takes unoptimized code and optimizes it to make it lazy. (???)

Total Functional Programming

Edwin Brady @edwinbrady

Type driven development of interactive, total programs @edwinbrady #KatsConf2 https://t.co/KpzHhzXxMX
— Jessica Kerr (@jessitron) February 18, 2017

Idris is a pure functional language with dependent types. It’s a “total” language, which means you have program totality: a program either terminates, or gives you new results.

Goals are:

Encourage type-driven development
Reduce the cost of writing correct software - giving you more tools to know upfront the program will do the correct thing.

People on the internet say, you can’t do X, you can’t do Y in a total language. I’m going to do X and Y in a total language.

Types become plans for a program. Define the type up front, and use it to guide writing the program.

You define the program interactively. The compiler should be less like a teacher, and more like a lab assistant. You say “let’s work on this” and it says “yes! let me help you”.

As you go, you need to refine the type and the program as necessary.

Test-driven development has “red, green, refactor”. We have “type, define, refine”.

If you care about types, you should also care about totality. You don’t have a type that completely describes your program unless your program is total.

Given f : T: if program f is total, we know that it will always give a result of type T. If it’s partial, we only know that if it gives a result, it will be type T, but it might crash, run forever, etc. and not give a result.

The difference between total and partial functions in this world: if it’s total, we can think of it as a Theorem.

Idris can tell us whether or not it thinks a program is total (though we can’t be sure, because we haven’t solved the halting problem “yet”, as a student once wrote in an assignment). If I write a program that type checks but Idris thinks it’s possibly not total, then I’ve probably done the wrong thing. So in my Idris code I can tell it that some function I’m defining should be total.

I can also tell Idris that if I can prove something that’s impossible, then I can basically deduce anything, e.g. an alt-fact about arithmetic. We have the absurd keyword.

We have Streams, where a Stream is sort of like a list without nil, so potentially infinite. As far as the runtime is concerned, this means this is lazy. Even though we have strictness.

Idris uses IO like Haskell to write interactive programs. IO is a description of actions that we expect the program to make(?). If you want to write interactive programs that loop, this stops it being total. But we can solve this by describing looping programs as a stream of IO actions. We know that the potentially-infinite loops are only going to get evaluated when we have a bit more information about what the program is going to do.

Turns out, you can use this to write servers, which run forever and accept responses, which are total. (So the people on the internet are wrong).

Check out David Turner’s paper “Elementary Strong Functional Programming”, where he argues that totality is more important than Turing-completeness, so if you have to give up one you should give up the latter.

Book coming out: Type-Driven Development with Idris

Notes from FOSDEM 2017

2017-02-13T00:00:00+00:00

Riding the tram you hear the word “Linux” pronounced in four different languages. Stepping out into the grey drizzle, you instantly smell fresh waffles and GitHub-sponsored coffee, and everywhere you look you see a FSF t-shirt. That’s right kids, it’s FOSDEM time again! The beer may not be free, but the software sure is.

Last year I got my first taste of this most epic of FLOSS conferences, back when I was an unemployed ex-grad-student with not even 5 pull requests to my name. This year, as a bona fide open source contributor, Mozillian, and full-time professional software engineer, I came back for more. Here are some things I learned:

Open source in general - and, anecdotally, FOSDEM in particular - has a diversity problem. (Yes, we already knew this, but it still needs mentioning.)
…But not for long, if organizations like Mozilla and projects like IncLudo have anything to say about it.
Games are a powerful tool to introduce programming, promote diversity, and build 21st-century literacy skills.
Speech applications built on open technologies are not just a pipe dream!
How browsers render the web is super interesting and something I want to get a clue about.
FoxPuppet is making automating & testing Firefox even easier than with our beloved Marionette!
The Mozilla Tech Speakers are straight killin’ it.

— "How do you say “@mozTechSpeakers rocked @FOSDEM today!” in fox?
— … 😉#mozdem pic.twitter.com/KStl9R8QLM
— Flaki (@slsoftworks) February 4, 2017

Open data for bike sharing programs in >400 cities around the world! 💚🚲💚 https://t.co/liu6MOI8Nc @ctbikes #FOSDEM pic.twitter.com/QHJyx3QzAm
— Anjana Vakil (@AnjanaVakil) February 5, 2017

Wrapped up the day with some VR painting in the browser (!!!) at the @mozilla stand - see you next year #FOSDEM ✌️ pic.twitter.com/d23v7sRY9a
— Anjana Vakil (@AnjanaVakil) February 5, 2017

See the notes below for more!

Disclaimer: The (unedited!!!) notes below represent my impressions of the content of these talks, jotted down as I listened. They may or may not be totally accurate, or precisely/adequately represent what the speakers said or think. If you want to get it from the horse’s mouth, follow the links to the FOSDEM schedule entry to find the video, slides, and/or other resources!

Mozilla Dev Room, Saturday

Firefox Nightly

Pascal Chevrel

Nightly users are crucial for early detection of regressions and bugs introduced by new features (especially important with the advent of Quantum)
Nightly users aren’t as diverse as stable users:
- 86% Windows, 6% Linux, 5% Mac
- Around 70% come from just 15 countries (USA, Germany, Russia at top)
- Over 80% are using en-US locale
Generally, Nightly users are tech-savvy (though not necessarily devs) - this means the bugs they report are generally higher-quality, more helpful
Nightly Reboot Status: Project started in 2016 to encourage Nightly use and bring better integration with release process
- Download pages: now you can download Nightly! :D
- Nightly-specific default bookmarks
- Locale-specific about:home page with e.g. info about local events, links to translated articles
- Nightly IRC channel
- Nightly blog (e.g. mconley’s “These weeks in Firefox”)
- @FirefoxNightly on Twitter
Help out!
- Use Nightly as your main browser
- Translate information & help bug reporters that aren’t comfortable with English
- Help triage bugs - too many for Mozilla staff to handle
Q&A
- A lot of former Nightly users have moved over to Aurora - this means they find the bugs later, and Aurora isn’t more stable/as stable as people expect

Firefox DevTools

Alex “Laka” Lakatos (@lakatos88)

Opening DevTools:
- Right click > Inspect Element
- Tools menu
Element inspector:
- Search box: can search for CSS selectors
CSS rules:
- use filter box to find e.g. every ‘color’ selector
- Colors
  - Shift-Click on colored circle to switch between hex/RGB/named representation
  - Click on it to get color picker
Debugger
- Click line to set breakpoint
- Can view all variables at the point where execution is paused
Network
- Shows every request you make
- Shows two sizes: Size during transport and size on disk - helps you minimize transfer time
DevTools in Nightly
- New features rolled out constantly
- Disable HTTP Cache when DevTools is open - super useful while you’re developing and the cache drives you insane!
- If you’re nostalgic, can use the Firebug theme
Moving DevTools to add-on instead of built in to Firefox - Will help ship faster

WebExtensions

Daniele Scasciafratte

Firefox is famous for extensions - it’s the most customizable browser out there
Extensions sometimes become features of Ffx itself
WebExtensions is “One API to Rule Them All”
- Standard HTML/CSS/JS (not XUL)
- compatibility with Chrome
- Content scripts allow extensions to run in pages
- Background scripts allow them to maintain long-term state from the moment they’re installed to the moment they’re removed
- Fully customizable “browser actions” (buttons on top right) with their own menus etc.

The Firefox Puppet Show

Dave Hunt (& Henrik the Foxy Puppet)

Selenium
- Tool for browser automation
- Never maintained by Mozilla
- Works for multiple browsers, including Firefox
- Limited to the content space; has no control over browser chrome
FirefoxDriver
- Deprecated due to add-on signing from Ffx 48
Marionette (Woo!!!)
- Introduced 2012, originally for FirefoxOS
- Directly integrated into Gecko
- Controls chrome and content (whereas Selenium is content-based)
GeckoDriver
- Proxy for W3C WebDriver & Gecko
- WebDriver spec should be a recommendation by end of Q1 2017
- Idea: any browser implementing the spec can be automated
- Has been adopted by all major browser vendors
- Thanks to WebDriver, Selenium (or any automation client) doesn’t have to worry about how to automate all the browsers: just has to implement the spec, and can then control any compliant browser
- GeckoDriver not feature complete yet, partly bc the spec is still in late stages of development
FoxPuppet
- Python package w/ simple API for finding & interacting with the Firefox UI
- Allows you to interact with Firefox in Selenium, builds on top of Selenium
- Ultimately going to be used to test Ffx itself
- Marionette can do more than what just Selenium offers (chrome); FoxPuppet takes it the next step by making it much simpler to write automation code using Selenium+Marionette
- At the moment supports window management, interaction with popups, soon interaction with tabs…

Excited about FoxPuppet @ #mozdem! It's even easier to automate & test @Firefox now: https://t.co/apmdCW3ZMC @davehunt82 @whimboo pic.twitter.com/RRnJoE49sO
— Anjana Vakil (@AnjanaVakil) February 4, 2017

Q&A:
- Can it run headlessly?
  - No, because there’s no true headless mode for Firefox, though you can make it effectively headless via e.g. running in Docker
- Can it work with WebGL?
  - The problem is similar to with canvas - if we just have one element, we can’t look inside of it unless there’s some workaround to expose additional information about the the state of the app specifically for testing
- Excecuting async JS?
  - Selenium has functionality to handle this, and since FoxPuppet builds on Selenium, the base Selenium functionality is still available

WebRender

Nicolas Silva

Servo
- Mostly research, for trying out new ideas more quickly than we could in Ffx (without worrying about putting it in front of users)
How do rendering engines work? (Using Gecko as a reference)
- layout: DOM Tree layout is computed and transformed into a Frame Tree (has other names in e.g. WebKit)
- invalidation: From the Frame Tree we get a display list - pretty flat structure of things we need to render
- painting: We then render the display list into a Layer Tree
  - like layers in Photoshop
  - Intermediate surfaces containing rendered elements
- compositing: mirror the layer tree on the compositor process, for scrolling etc. at a high frame rate
WebRender
- attempts to move away from this type of architecture and do something different
- designed to work around the GPU, like a game rendering engine
- drops the distinction between painting/compositing, and just render everything to the window directly
- take the page content & turn it into a series of primitives we can send to the GPU (??)
- written in Rust
- using OpenGL for now, though in the future other backends would be possible
- doesn’t understand arbitrary shapes, but rather only a simple set of shapes that are common on the web (e.g. rectangles, rounded rects)
Working fast on a GPU
- GPUs are very stateful things, so switching state/state changes have a big impact
- Batching is the key
- Transferring data to/from the CPU is expensive
- Memory bandwidth is really costly, especially on mobile devices - so try to avoid touching too many pixels/touching the same pixels too many times (aka “overdraw”)
  - Rendering back-to-front, you have to draw e.g. the whole background even if most of it is covered by other things
  - Rendering front-to-back means you can avoid drawing any parts of layers other than those that will ultimately be seen

How Rust is being developed

@jgbarah Jesus M. Gonzalez-Barahona, Bitergia

Analytics dashboard with contribution data: https://rust-analytics.mozilla.community

Code Invaders: Learning to code with IoT games and HTML/CSS/JS

István “Flaki” Szmozsánszky @slsoftworks

Happy Code Friends
- Tech needs more diversity, we need more people to learn to code
- But we need to spark people’s interest - games!
Arduboy
- Kickstarter project funded about 1-2 years ago
- Basically puts a micro Arduino, screen, buttons in a nice little (cheap) package
- But unfortunately you had to write programs for it in C through the Arduino IDE - not very beginner friendly
Code Invaders
- Teaching people the basics of programming (functions, variables, …) while building their own game
- Code is written in JS and compiled to C by pushing a button in the IDE
- Makes Arduboy programming accessible for beginners

@slsoftworks invaded spaces at #mozdem, showing us how beginners can learn to code #arduboy games in JS! pic.twitter.com/WKNrGUpAvv
— Anjana Vakil (@AnjanaVakil) February 4, 2017

Diversity in Open Source

Kristi Pogri @KristiPogri

Hard truths about (lack of) diversity in FOSS as @mozTechSpeakers own @KristiProgri opens eyes at #mozdem pic.twitter.com/VzAZEofTQT
— Anjana Vakil (@AnjanaVakil) February 4, 2017

Horrendenously low %s of open-source developers are women
Open source isn’t really open unless it’s open to everyone
Organizations/initiatives like WoMoz and Outreachy are actively trying to change this

Diversity user research

Gloria Dwomoh

Listening is a skill, one which we don’t study enough in comparison with e.g. reading, writing, speaking
Hearing vs. Listening:
- Hearing is perceiving sounds
- Listening is concentrating on them
Body language is important for listening - showing that you’re bored makes the speaker cut themselves off
Active listening
- Reflection: when someone tells you something, you try to reflect back what they’re saying - to show that you understood, e.g. “so you mean that….”
- Funneling: you try to ask for more general or more specific information
- Empathy: important for building trust with the speaker
  - Sympathy is “oh, that must have been hard, I’m sorry”
  - Empathy is also “I understand what you mean, because I had a similar experience when ….” - show that you deeply understand the speaker’s experience

Active listening: reflect, summarize, clarify, show empathy. @mozTechSpeakers own Gloria Dwomoh reminds us we should all get better at this pic.twitter.com/UzemrL5YZ1
— Anjana Vakil (@AnjanaVakil) February 4, 2017

Don’t break the internet! Mozilla Copyright Campaign in Europe

Raegan MacDonald

We need to bring copyright into the 21st century
- Bring in flexibility
- Encourage creativity & expression online
Copyright reform is happening, but unfortunately it’s not the kind of reform we need
- Doesn’t focus on the interests of users on the internet
- Instead of protecting & encouraging innovation & creativity online, may in some cases undermine that
Mozilla wants to ensure that the internet remains a “global public resource open & accessible to all”
- not trying to get rid of copyright
- but rather encourage copyright laws that support all actors in the web ecosystem
Issues in the current copyright directive
- Upload filters:
  - platforms that are holding large amounts of copyrighted content would need agrements with rights holders
  - ensuring that they uphold those agreements would require them to implement upload filters that may end up restricting users’ ability to post their own content
- Neighboring rights - aka “snippet tax” or “google tax”
  - proposal to extend copyright to press publishers
  - press publications would get to charge aggregators for e.g. posting a snippet of their article, the headline, and a hyperlink
  - already been attempted in Germany and Spain, where it had negative effects on startup aggregators and entrenched the power of established aggregators (Google)
- Text & Data Mining (TDM)
  - there would be restrictions on ingesting copyrighted data for the purposes of data mining
  - there would only be exceptions for research institutions
The fight right now is unfortunately quite binary: The big Silicon Valley companies/aggregators (Google etc.) vs. the Publishing/Music/Film industry
- We need it to involve the full spectrum of stakeholders on the web, especially users, independent content creators
Get involved!
- changecopyright.org
- raegan@mozilla.com
- Series of events across Europe
Q&A:
- Since filtering requires monitoring, and monitoring is unconstitutional in the EU, are there plans to fight this if it passes?
  - Yes, there is absolutely a contradiction there, and we plan to fight it. We want to bring the proposal in line with existing law and channel activism against these filters.
- Previous events/campaigns were focused on Freedom of Panorama (copyright exception that allows you to take photographs of e.g. buildings, art and post them online). Will new events be focused on the 4 areas you discussed?
  - Yes, this is sort of our 2nd wave of activism on this issue, and we’ll be organizing and encouraging more advocacy around these issues.
- Do you coordinate with the media?
  - Yes. There are a number of organizations working on a modern version of copyright that looks forward, not backwards. The C4C (copyright for creativity) brings together a lot of players (e.g libraries, digital rights NGOs), and that serves as a sort of umbrella. A lot of folks have similar issues and we work together as much as possible to amplify & support certain voices.
- What is the purpose of another wave? Are we starting over?
  - EU policy making is a very slow game. This reform has been under discussion for over 5 years, and the process of it going through negotiations to reach a final EU parliament agreement will be at least a year. If we want to have an impact & mobilize different voices, it has to be a sustained, long-term effort, which was not the case in the 1st wave because we didn’t have the proposal yet. Now that we have it, we have more focus on what to encourage people to speak out about, which is potentially game-changing.
- It seems that the education exception excludes all informal sources of education
  - This exception applies to cases where licensed materials can’t be acquired. But that’s not really the problem; the problem is the cost. There’s now a campaign copyrightforeducation.org. It’s something we’re following closely, and we’re mostly relying on our partners who are experts in this area.
- When will this be decided by parliament?
  - There will be votes on committee opinions next month, but the main opinion will be deliberated in March, and they want it to be voted by end of summer 2017. So the next 6 months could be game-changing, it’s an important time to contact your representatives.
- Would the TDM exception implicate privacy concerns?
  - This doesn’t deal with privacy-protected content, but rather would allow people that have lawfully acquired works/texts to create e.g. a visualization. It doesn’t get into privacy issues about mining people’s metadata and all that - it’s a separate issue from privacy and wouldn’t override it.

Other rooms, Saturday-Sunday

WebRTC and speech recognition with Adhearsion

Luca Pradovera @lucaprado - MojoLingo

Spoken dialog system built entirely on open tools
PocketSphinx for recognition (understands stock grammar of ~100 words)
Rasa NLU for interpretation
Flite for TTS (voice a bit robotic but gets the job done)
FreeSwitch - switching platform with good WebRTC support. Asterisk is an alternative
Adhearsion is the main control layer
- Ruby framework for voice apps
- handles things like picking up the call, transferring, answering, recording, etc.
- Connects to FreeSwitch or Asterisk
- Uses actor model - treats each call as an actor, handles it in isolation (so if one call fails, the whole system doesn’t fail)
- Case studies
  - RingRx HIPAA-compliant phone system
  - LiveConnect for broadcasting surgical procedures

Can open source open minds? IncLudo games for workplace diversity

Jesse Himmelstein

"Diversity is an institutional advantage." WORD. @himmelattack & @IncludoProject are trying to ++ workplace diversity with games 🤘 #FOSDEM pic.twitter.com/ynqIgnxoKq
— Anjana Vakil (@AnjanaVakil) February 5, 2017

Diversity is an institutional advantage
But it’s difficult to implement - “we are feeling beings who think, not thinking beings who feel”
- some research suggests that our ability to reason may exist to convince others of our ideas, rather than to make decisions
IncLudo project created a variety of games to improve workplace diversity in India
- some teach about biases
- some (esp. board games) encourage conversation & exchange of experiences/stories among players
Process
- Game jams are a good way to try out new ideas
- Paper prototypes are great for experimenting, though clients don’t always accept them so easily
- Having a diverse team helps
Q&A
- You mentioned a game where you have to hide your bias from others
  - You pretend you’re management at a company, and you have to hire someone for a position. Everyone has a secret bias card (“don’t want to hire [women, muslims, …]”). Your goal is to fight for the candidate you (don’t) want, but without being so obvious about it as to reveal your secret bias to the other managers. There were some really funny conversations coming out of it.
- How do you measure the impact?
  - That’s really hard. There’s a few different things: you can try to measure what people learned from the game, which is difficult in itself. The other attempt is to see what the organizations actually do in real live - that’s what (our partner) ZMQ is going to do: see if the orgs actually change their practices.
- How do your games relate to competitive vs. collaborative games
  - I wouldn’t agree that competition is bad by itself - it motivates us and as long as we understand that we’re competing in the game and not once it’s over. Our games are competitive, with the exception of Pirat Partage which wasn’t competitive but then the players started asking us for a scoring system so that they could see who’s winnign
- Aren’t competition and diversity contradictory?
  - If you’re trying to bring diversity into an existing social structure made of companies that are competing, it makes sense to sell it to them that way.

Hellink, an educational game about open data

Thomas Planques

Game for 1st year uni students that aims to
- teach information literacy: critical thinking about info sources
- raise awareness about open data
The game talks about process of creation of scientific knowledge
- Who pays for scientific knowledge?
  - Unis pay Scientists’ salaries
  - Unis must also pay publishers, the publishers don’t pay the scientists
  - Unis also pay to buy the journal, to buy back the knowledge
  - So we say in scientific knowledge domain, people (taxpayers) pay 3 times
- What keeps this system going?
  - each scientist has an H index based on their publications that’s important for their career
  - the publishers own the journals, i.e. the means for scientists to advance their careers
  - monopoly by big scientific publishers make knowledge less accessible
- One big solution would be the open data movement
  - publishing not in private journals, but open source archives
  - but scientists often think this will strip them of their work
    - but it’s the other way around
- This is the subject of our game: we believe in the goal of open knowledge
  - the goal is to raise awareness about this problem
  - and also that checking the sources of your info is very important
- We chose to use the same humorous tone as Ace Attorney (manga-like Japanese game where you play a lawyer, trial is like Dragonball-Z)
  - you’re sent to investigate a massive plot linked to who owns info & data in the uni/scientific publishing world
  - you have one person who tells you a false assertion backed by false info sources
  - like in Papers Please, you need to point out what is false in the info source & link it with a publishing rule that the source is supposed to respect
- What we learned
  - procedural rhetoric: the game itself must convey the message
    - a lot of educational games involve a little playing and a lot of reading
    - the goal here is that you actually learn by playing
  - making a game about notions like this that have gray areas is a lot harder than making games about hard science/math/programming etc. & needs more time invested
  - what should ed games aim to do?
    - games in general are not very good at conveying a very complex message/complex domain of learning
    - what they’re good at is piquing interest and raising awareness
    - ed games shouldn’t aim to teach everything to the player, but rather to give them the interest to go look into the topic themselves
  - we tried to make our game one that’s actually fun in itself
    - the game is for 1st year uni students, who by that point are used to playing a lot of “serious games” that are not up to the standard of entertainment games
    - ours aims not just to be a “serious game” for education, but one that’s actually fun to play in and of itself
- The game will be released (for free) in April 2017

Tablexia: app for children with dyslexia

Andrea Sichova, cz.nic

Cognitive training for children with dyslexia
- focused on older children, 11-15 years
- teachers told us: we can give a lot of lessons, but with older children the problem is motivation
- so we developed a game to address that
- available on Android/iOS
- available in schools & counseling facilities, but we also encourage students to use it indepedently
- Available in Czech, Slovak, and German language
What’s dyslexia?
- specific learning disability
- problems with reading/writing caused by cognitive functions (attention, working memory)
- dyslexic people have different learning strategies to cope
App development
- focused on mobile (Android)
- testing: tried to put it in front of students as much as possible, ask questionnaires etc
- difficulty: needs to be at the right level so that they’re neither bored nor frustrated
- tasks:
  - attention/working memory: need to read instructions and remember how they relate to previous ones
  - spacial reasoning: map tiles
  - phonological recognition/analysis: see a word, hear different options, choose the right one
  - visual memory: have to click on the right things at the right time
  - visual recognition: recognizing “alien” writing symbols, some of which are similar to others
  - phonological memory: remember the content/order of sounds you heard
- also includes “badges” for completing exercises, statistics view of progress, and “encyclopedia” with info about dyslexia (which also has voice recordings of all texts)
Does it work?
- studying it is difficult: we need a lot of children diagnosed with dyslexia, and let them play the game for some time
- children are not going to school regularly - problems with attendance
Language
- We focused on Czech
- Dyslexia is closely related to the language
  - aspects that dyslexic children struggle with are different from e.g. Czech to German

Marionette, Act II: Harnessing automation to test the browser

2016-08-22T00:00:00+00:00

Welcome back to my post series on the Marionette project! In Act I, we looked into Marionette’s automation framework for Gecko, the engine behind the Firefox browser. Here in Act II, we’ll take a look at a complementary side of the Marionette project: the testing framework that helps us run tests using our Marionette-animated browser, aka the Marionette test harness. If – like me at the start of my Outreachy internship – you’re clueless about test harnesses, or the Marionette harness in particular, and want to fix that, you’re in the right place!

Wait, what’s Marionette again?

Quick recap from Act I:

Marionette refers to a suite of tools for automated testing of Mozilla browsers.

In that post, we saw how the Marionette automation framework lets us control the Gecko browser engine (our “puppet”), thanks to a server component built into Gecko (the puppet’s “strings”) and a client component (a “handle” for the puppeteer) that gives us a simple Python API to talk to the server and thus control the browser. But why do we need to automate the browser in the first place? What good does it do us?

Well, one thing it’s great for is testing. Indulge me in a brief return to my puppet metaphor from last time, won’t you? If the automation side of Marionette gives us strings and a handle that turn the browser into our puppet, the testing side of Marionette gives that puppet a reason for being, by letting it perform: it sets up a stage for the puppet to dance on, tell it to carry out a given performance, write a review of that performance, and tear down the stage again.

OK, OK, metaphor-indulgence over; let’s get real.

Wait, why do we need automated browser testing again?

As Firefox¹ contributors, we don’t want to have to manually open up Firefox, click around, and check that everything works every time we change a line of code. We’re developers, we’re lazy!

Clueless via POPSUGAR

But we can’t not do it, because then we might not realize that we’ve broken the entire internet (or, you know, introduced a bug that makes Firefox crash, which is just as bad).

So instead of testing manually, we do the same thing we always do: make the computer do it for us!

The type of program that can magically do this stuff for us is called a test harness. And there’s even a special version specific to testing Gecko-based browsers, called – can you guess? – the Marionette test harness, also known as the Marionette test runner.

(Lazy) Firefox contributors, rejoice!

Clueless via tenor

So, what exactly is this magical “test harness” thing? And what do we need to know about the Marionette-specific one?

What’s a test harness?

First of all, let’s not get hung up on the name “test harness” – the names people use to refer to these things can be a bit ambiguous and confusing, as we saw with other parts of the Marionette suite in Act I. So let’s set aside the name of the thing for now, and focus on what the thing does.

Assuming we have a framework like the Marionette client/server that lets us automatically control the browser, the other thing we need for automatically testing the browser is something that lets us:

Properly set up & launch the browser, and any other related components we might need
Define tests we want to perform and their expected results
Discover tests defined in a file or directory
Run those tests, using the automation framework to do the stuff we want to do in the browser
Keep track of what we actually saw, and how it compares to what we expected to see
Report the results in human- and/or machine-readable logs
Clean up all of that stuff we set up in the beginning

Take out the browser-specific parts, and you’ve got the basic outline of what a test harness for any kind of software should do.

Ever write tests using Python’s unittest, JavaScript’s mocha, Java’s JUnit, or a similar tool? If you’re like me, you might have been perfectly happy writing unit tests with one of these, thinking not:

Yeah, I know unittest! It’s a test harness.

but rather:

Yeah, I know unittest! It’s, you know, a, like, thing for writing tests that lets you make assertions and write setup/teardown methods and stuff and, like, print out stuff about the test results, or whatever.

Turns out, they’re the same thing; one is just shorter (and less, like, full of “like”s, and stuff).

Clueless via POPSUGAR

So that’s the general idea of a test harness. But we’re not concerned with just any test harness; we want to know more about the Marionette test harness.

What’s special about the Marionette test harness?

Um, like, duh, it’s made for tests using Marionette!

What I mean is that unlike an all-purpose test harness, the Marionette harness already knows that you’re a Mozillian specifically interested in is running Gecko-based browser tests using Marionette. So instead of making you write code in for setup/teardown/logging/etc. that talks to Marionette and uses other features of the Mozilla ecosystem, it does that legwork for you.

You still have control, though; it makes it easy for you to make decisions about certain Mozilla-/Gecko-specific properties that could affect your tests, like:

Need to use a specific Firefox binary? Or a particular Firefox instance running on a device somewhere?
Got a special profile or set of preferences you want the browser to run with?
Want Electrolysis enabled, or not?

As well as some more general decisions, like:

Need to run an individual test module? A directory full of tests? Tests listed in a manifest file?
Want the tests run multiple times? Or in chunks?
How and where should the results be logged?
Care to drop into a debugger if something goes wrong?

But how does it do all this? What does it look like on the inside? Let’s dive into the code to find out.

How does the Marionette harness work?

Inside Marionette, in the file harness/marionette/runtests.py, we find the MarionetteHarness class. MarionetteHarness itself is quite simple: it takes in a set of arguments that specify the desired preferences with respect to the type of decisions we just mentioned, uses an argument parser to parse and process those arguments, and then passes them along to a test runner, which runs the tests accordingly.

So actually, it’s the “test runner” that does the brunt of the work of a test harness here. Perhaps for that reason, the names “Marionette Test Harness” and “Marionette Test Runner” sometimes seem to be used interchangeably, which I for one found quite confusing at first.

Anyway, the test runner that MarionetteHarness makes use of is the MarionetteTestRunner class defined in runtests.py, but that’s really just a little wrapper around BaseMarionetteTestRunner from harness/marionette/runner/base.py, which is where the magic happens – and also where I’ve spent most of my time for my Outreachy internship, but more on that later. For now let’s check out the runner!

How does Marionette’s test runner work?

The beating heart of the Marionette test runner is the method run_tests. By combining some methods that take care of general test-harness functionality and some methods that let us set up and keep tabs on a Marionette client-server session, run_tests gives us the Marionette-centric test harness we never knew we always wanted. Thanks, run_tests!

To get an idea of how the test runner works, let’s take a walk through the run_tests method and see what it does.²

First of all, it simply initializes some things, e.g. timers and counters for passed/failed tests. So far, so boring.

Next, we get to the part that puts the “Marionette” in “Marionette test runner”. The run_tests method starts up Marionette, by creating a Marionette object – passing in the appropriate arguments based on the runner’s settings – which gives us the client-server session we need to automate the browser in the tests we’re about to run (we know how that all works from Act I).

Adding the tests we want to the runner’s to-run list (self.tests) is the next step. This means finding the appropriate tests from test modules, a directory containing test modules, or a manifest file listing tests and the conditions under which they should be run.

Given those tests, after gathering and logging some info about the settings we’re using, we’re ready to run! (Perhaps multiple times, if repeated runs were requested.)

To actually run the tests, the runner calls run_test_sets, which runs the tests we added earlier, possibly dividing them into several sets (or chunks) that will be run separately (thus enabling parallelization). This in turn calls run_test_set, which basically just calls run_test, which is the final turtle.³

Glancing at run_test, we can see how the Marionette harness is based on Python’s unittest, which is why the tests we run with this harness basically look like unittest tests (we’ll say a bit more about that below). Using unittest to discover our test cases in the modules we provided, run_test runs each test using a MarionetteTextTestRunner and gets back a MarionetteTestResult. These are basically Marionette-specific versions of classes from moztest, which helps us store the test results in a format that’s compatible with other Mozilla automation tools, like Treeherder. Once we’ve got the test result, run_test simply adds it to the runner’s tally of test successes/failures.

So, that’s how run_tests (and its helper functions) execute the tests. Once all the tests have been run, our main run_tests method basically just logs some info about how things went, and which tests passed. After that, the runner cleans up by shutting down Marionette and the browser, even if something went wrong during the running or logging, or if the user interrupted the tests.

So there we have it: our very own Marionette-centric test-runner! It runs our tests with Marionette and Firefox set up however we want, and also gives us control over more general things like logging and test chunking. In the next section, we’ll take a look at how we can interact with and customize the runner, and tell it how we want our tests run.

What do the tests look like?

As for the tests themselves, since the Marionette harness is an extension of Python’s unittest, tests are mostly written as a custom flavor of unittest test cases. Tests extend MarionetteTestCase, which is an extension of unittest.TestCase. So if you need to write a new test using Marionette, it’s as simple as writing a new test module named test_super_awesome_things.py which extends that class with whatever test_* methods you want – just like with vanilla unittest.

Let’s take a look at a simple example, test_checkbox.py:

from marionette import MarionetteTestCase
from marionette_driver.by import By

class TestCheckbox(MarionetteTestCase):
    def test_selected(self):
        test_html = self.marionette.absolute_url("test.html")
        self.marionette.navigate(test_html)
        box = self.marionette.find_element(By.NAME, "myCheckBox")
        self.assertFalse(box.is_selected())
        box.click()
        self.assertTrue(box.is_selected())

This and the other Marionette unit tests can be found in the directory testing/marionette/harness/marionette/tests/unit/, so have a peek there for some more examples.

Once we’ve got our super awesome new test, we can run it (with whatever super awesome settings we want) using the harness’s command-line interface. Let’s take a look at how that interface works.

What is the interface to the harness like?

Let’s peek at the constructor method for the BaseMarionetteTestRunner class:

class BaseMarionetteTestRunner(object):
    # ...
    def __init__(self, address=None,
        app=None, app_args=None, binary=None, profile=None,
        logger=None, logdir=None,
        repeat=0, testvars=None,
        symbols_path=None, timeout=None,
        shuffle=False, shuffle_seed=random.randint(0, sys.maxint), this_chunk=1, total_chunks=1, sources=None,
        server_root=None, gecko_log=None, result_callbacks=None,
        prefs=None, test_tags=None,
        socket_timeout=BaseMarionetteArguments.socket_timeout_default,
        startup_timeout=None, addons=None, workspace=None,
        verbose=0, e10s=True, emulator=False, **kwargs):

Our first thought might be, “Wow, that’s a lot of arguments”. Indeed! This is how the runner knows how you want the tests to be run. For example, binary is the path to the specific Firefox application binary you want to use, and e10s conveys whether or not you want to run Firefox with multiple processes.

Where do all these arguments come from? They’re passed to the runner by MarionetteHarness, which gets them from the argument parser we mentioned earlier, MarionetteArguments.

Analogous to MarionetteTestRunner/BaseMarionetteTestRunner, MarionetteArgument is just a small wrapper around BaseMarionetteArguments from runner/base.py, which in turn is just an extension of Python’s argparse.ArgumentParser. BaseMarionetteArguments defines which arguments can be passed in to the harness’s command-line interface to configure its settings. It also verifies that whatever arguments the user passed in make sense and don’t contract each other.

To actually use the harness, we can simply call the runtests.py script with: python runtests.py [whole bunch of awesome arguments]. Alternatively, we can use the Mach command marionette-test (which just calls runtests.py), as described here.

To see all of the available command-line options (there are a lot!), you can run python runtests.py --help or ./mach marionette-test --help, which just spits out the arguments and their descriptions as defined in BaseMarionetteArguments.

So, with the simple command mach marionette-test [super fancy arguments] test_super_fancy_things.py, you can get the harness to run your Marionette tests with whatever fancy options you desire to fit your specific fancy scenario.

Iggy Azalea's "Fancy" via tenor

But what if you’re extra fancy, and have testing needs that exceed the limits of what’s possible with the (copious) command-line options you can pass to the Marionette runner? Worry not! You can customize the runner even further by extending the base classes and making your own super-fancy harness. In the next section, we’ll see how and why you might do that.

How is the Marionette test harness used at Mozilla?

Other than enabling people to write and run their own tests using the Marionette client, what is the Marionette harness for? How does Mozilla use it internally?

Well, first and foremost, the harness is used to run the Marionette Python unit tests we described earlier, which check that Marionette is functioning as expected (e.g. if Marionette tells the browser to check that box, then by golly that box better get checked!). Those are the tests that will get run if you just run mach marionette-test without specifying any test(s) in particular.

But that’s not all! I mentioned above that there might be special cases where the runner’s functionality needs to be extended, and indeed Mozilla has already encountered this scenario a couple of times.

One example is the Firefox UI tests, and in particular the UI update tests. These test the functionality of e.g. clicking the “Update Firefox” button in the UI, which means they need to do things like compare the old version of the application to the updated one to make sure that the update worked. Since this involves binary-managing superpowers that the base Marionette harness doesn’t have, the UI tests have their own runner, FirefoxUITestRunner, which extends BaseMarionetteTestRunner with those superpowers.

Another test suite that makes use of a superpowered harness is the External Media Tests, which tests video playback in Firefox and need some extra resources – namely a list of video URLs to make available to the tests. Since there’s no easy way to make such resources available to tests using the base Marionette harness, the external media tests have their own test harness which uses the custom MediaTestRunner and MediaTestArguments (extensions of BaseMarionetteTestRunner and BaseMarionetteArguments, respectively), to allow the user to e.g. specify the video resources to use via the command line.

So the Marionette harness is used in at least three test suites at Mozilla, and more surely can and will be added as the need arises! Since the harness is designed with automation in mind, suites like marionette-test and the Firefox UI tests can be (and are!) run automatically to make sure that developers aren’t breaking Firefox or Marionette as they make changes to the Mozilla codebase. This all makes the Marionette harness a rather indispensable development tool.

Which brings us to a final thought…

How do we know that the harness itself is running tests properly?

The Marionette harness, like any test harness, is just another piece of software. It was written by humans, which means that bugs and breakage are always a possibility. Since breakage or bugs in the test harness could prevent us from running tests properly, and we need those tests to work on Firefox and other Mozilla tools, we need to make sure that they get caught!

Do you see where I’m going with this? We need to… wait for it…

Test the thing that runs the tests

Yup, that’s right: Meta-testing. Test-ception. Tests all the way down.

Clueless via POPSUGAR

And that’s what I’ve been doing this summer for my Outreachy project: working on the tests for the Marionette test harness, otherwise known as the Marionette harness (unit) tests. I wrote a bit about what I’ve been up to in my previous post, but in my next and final Outreachy post, I’ll explain in more detail what the harness tests do, how we run them in automation, and what improvements I’ve made to them during my time as a Mozilla contributor.

Stay tuned!

Clueless via POPSUGAR

Notes

1 Or Fennec, or B2G, or [insert Gecko-based project here]… ↩

2 If you scroll through it and think, “Wow, that’s long and ugly”, well, you should’ve seen it before I refactored it!

Clueless via POPSUGAR

↩

3 If you think distinguishing run_tests, run_test_sets, run_test_set, and run_test is confusing, I wholeheartedly agree with you! But best get used to it; working on the Marionette test harness involves developing an eagle-eye for plurals in method names (we’ve also got _add_tests and add_test). ↩

Outreachy halftime(ish) update

2016-08-02T00:00:00+00:00

It feels like yesterday that I started my Outreachy internship, but it was actually over 2 months ago! For the last couple of weeks I’ve been on Outreachy hiatus because of EuroPython, moving from Saarbrücken to Berlin, and my mentor being on vacation. Now I’m back, with 6 weeks left in my internship! So it seems like a good moment to check in and reflect on how things have been going so far, and what’s in store for the rest of my time as an Outreachyee.

What have I been up to?

Learning how to do the work

In the rather involved application process for Outreachy, I already had to spend quite a bit of time figuring out the process for making even the tiniest contribution to the Mozilla codebase. But obviously one can’t learn everything there is to know about a project within a couple of weeks, so a good chunk of my Outreachy time so far was spent on getting better acquainted with:

The tools

I’ve already written about my learning experiences with Mercurial, but there were a lot of other components of the Mozilla development process that I had to learn about (and am still learning about), such as Bugzilla, MozReview, Treeherder, Try, Mach… Then, since the project I’m working focuses on testing, I had to grok things like Pytest and Mock. Since most everything I’m doing is in Python, I’ve also been picking up useful Python tidbits here and there.
The project

My internship project, “Test-driven refactoring of Marionette’s Python test runner”, relates to a component of the Marionette project, which encompasses a lot of moving parts. Even figuring out what Marionette is, what components it comprises, how these interrelate, and which of them I need to know about, was a non-trivial task. That’s why I’m writing a couple of posts about the project itself - one down, one to go - to crystallize what I’ve learned and hopefully make it a little easier for other people to get through the what-even-is-it steps that I’ve been going through. This post is a sort of “intermission”, so stay tuned for my upcoming post on the Marionette test runner and harness!

Doing the work

Of course, there’s a reason I’ve been trying to wrap my head around all the stuff I just mentioned: so that I can actually do this project! So what is the actual work I’ve been doing, i.e. my overall contribution to Mozilla as an Outreachy intern?

Well, to quote the project description:

we’re testing the thing that runs Firefox tests

The “thing” is the Marionette test runner, a tool written in Python that allows us to run tests that make use of Marionette to automate the browser. It’s responsible for things like discovering which tests we need to run, setting up all the necessary prerequisites, running the tests one by one, and logging all of the results.

Since the test runner is essentially a program like any other, it can be broken just like any other! And since it’s used in automation to run the tests that let Firefox developers know if some new change they’ve introduced breaks something, if the test runner itself breaks, that could cause a lot of problems. So what do we do? We test it!

That’s where I come in. My mentor, Maja, had started writing some unit tests for the test runner before the internship began. My job is basically to add more tests. This involves:

Reading the code to identify things that could break and cause problems, and thus should be tested
Writing new unit tests using Pytest
Refactoring the code to make it easier to test, more readable, easier to extend/change, or otherwise better

Aside from the testing side of things, another aspect of the project (which I particularly enjoy) involves improving how the runner relates to the rest of the world. For example, improving the command line interface to the runner, or making sure the unit tests for the runner are producing logs that play nicely with the rest of the Mozilla ecosystem.

Writing stuff down

As you can see, I’ve also been spending a fair bit of time writing blog p o s t s about what I’ve been learning and encountering over the course of my internship. Hopefully these have been or will be useful to others who might also be wrapping their heads around these things for the first time. But regardless, writing them has certainly been useful for me!

What’s been fun?

Learning all the things

While working with a new system or technology can often be frustrating, especially when you’re used to something similar-but-not-quite-the-same (ahem, git and hg), I’ve found that the frustration does subside (or at least lessen) eventually, and in its place you find not only the newfound ease of working with the new thing, but also the gratification that comes with the realization: “Hey! I learned the thing!” This makes the overall experience of grappling with the learning curve fun, in my experience.

Working remotely

This internship has been my first experience with a lifestyle that always attracted me: working remotely. I love the freedom of being able to work from home if I have things to take care of around the house, or at a cafe if I just really need to sip on a Chocolate Chai Soy Latte right now, or from the public library if I want some peace & quiet. I also loved being able to escape Germany for 2 weeks to visit my boyfriend’s family in Italy, or to work a day out of the Berlin office if I’m there for a long weekend looking at apartments. Now that I’ve moved to Berlin, I love the option of working out of the office here if I want to, or working from home or a cafe if I have things I need to take care of on the other side of the city. And because the team I’m working on is also completely distributed, there’s a great infrastructure already in place (IRC, video conferences, collaborative documents) to enable us to work in completely different countries/time zones and still feel connected.

Helping others get started contributing!

A couple of weeks ago I got to mentor my first bug on Bugzilla, and help someone else get started contributing to the thing that I had gotten started contributing to a few months ago for my Outreachy internship. Although it was a pretty simple & trivial thing, it felt great to help someone else get involved, and to realize I knew the answers to a couple of their questions, meaning that I’m actually already involved! That’s the kind of thing that really makes me want to continue working with FOSS projects after my internship ends, and makes me so appreciative of initiatives like Outreachy that help bring newcomers like me into this community.

What’s been hard?

Impostor Syndrome

The flip side of the learning-stuff fun is that, especially at the beginning, ye olde Impostor Syndrome gets to run amok. When I started my internship, I had the feeling that I had Absolutely No Idea what I was doing – over the past couple of months it has gotten gradually better, but I still have the feeling that I have a Shaky and Vague Idea of what I’m doing. From my communications with other current/former Outreachy interns, this seems to be par for the course, and I suppose it’s par for the course for anyone joining a new project or team for the first time. But even if it’s normal, it’s still there, and it’s still hard.

Working remotely

As I mentioned, overall I’ve been really enjoying the remote-work lifestyle, but it does have its drawbacks. When working from home, I find it incredibly difficult to separate my working time from my not-working time, which is most often manifested in my complete inability to stop working at the end of the day. Because I don’t have to physically walk away from my computer, at the end of the day I think “Oh, I’ll just do that one last thing,” and the next thing I know the Last Thing has led to 10 other Last Things and now it’s 11:00pm and I’ve been working for 13 hours straight. Not healthy, not fun. Also, while the flexibility and freedom of not having a fixed place of work is great, moving around (e.g. from Germany to Italy to other side of Germany) can also be chaotic and stressful, and can make working (productively) more difficult – especially if you’re not sure where your next internet is going to come from. So the remote work thing is really a double-edged sword, and doing in a way that preserves both flexibility and stability is clearly a balancing act that takes some practice. I’m working on it.

Measuring productivity

Speaking of working productively, how do you know when you’re doing it? Is spending a whole day reading about mock objects, or writing a blog post, or banging your head against a build failure, or [insert activity that is not writing 1000 lines of code] productive? The nature of the Outreachy system is that every project is different, and the target outcomes (or lack thereof) are determined by the project mentor, and whether or not your work is satisfactory is entirely a matter of their judgment. Luckily, my mentor is extremely fair, open, clear, and realistic about her goals for the project. She’s also been very reassuring when I’ve expressed uncertainty about productivity, and forthcoming about her satisfaction with my progress. But I feel like this is just my good luck having a mentor who a) is awesome and b) was an Outreachy intern herself once, and can thus empathize. I do wonder how my experience would be different, especially from the standpoint of knowing whether I’m measuring up to expectations, if I were on a different project with a different mentor. Which brings me to…

What’s been helpful?

Having a fantastic mentor

As I’ve just said, I feel really lucky to be working with my mentor, Maja. She’s been an incredible support throughout the internship, and has just made it a great experience. I’m really thankful for her for being so detailed & thorough in her initial conception of the project and instructions to me, and for being so consistently responsive and helpful with any of my questions or concerns. I can’t imagine a better mentor.

Being part of a team

“It takes a village,” or whatever they say, and my village is the Automation crew (who hang out in #automation on IRC) within the slightly-larger village of the Engineering Productivity team (A-Team) (#ateam). Just like my mentor, the rest of the crew and the team have also been really friendly and helpful to me so far. If Maja’s not there, if I’m working on some adjacent component, or if I have some general question, they’ve been there for me. And while having a fantastic mentor is fantastic, having a fantastic mentor within a fantastic team is double-fantastic, because it helps with the hard things like learning new tools or working remotely (especially when your mentor is in a different time zone, but other team members are in yours). So I’m also really grateful to the whole team for taking me in and treating me as one of their own.

Attending the All Hands

Apparently, at some point in the last couple of years, someone at Mozilla decided to start including Outreachy interns in the semi-annual All Hands meetings. Whoever made that decision: please accept my heartfelt thanks. Being included in the London All Hands made a real difference - not only because I understood a lot about various components of the Mozilla infrastructure that had previously been confusing or unclear to me, but also because the chance to meet and socialize with team members and other Outreachy interns face-to-face was a huge help in dealing with e.g. Impostor Syndrome and the challenges of working on a distributed team. I’m so glad I was able to join that meeting, because it really helped me feel more bonded to both Mozilla as a whole and to my specific team/project, and I hope for the sake of both Mozilla and Outreachy that Outreachyees continue to be invited to such gatherings.

Intern solidarity

Early on in the internship, one of the other Mozilla Outreachy interns started a channel just for us on Mozilla’s IRC. Having a “safe space” to check in with the other interns, ask “dumb” questions, express insecurities/frustrations, and just generally support each other is immensely helpful. On top of that, several of us got to hang out in person at the London All Hands meeting, which was fantastic. Having contact with a group of other people going through more or less the same exciting/bewildering/overwelming/interesting experience you are is invaluable, especially if you suffer from Impostor Syndrome as so many of us do. So I’m so grateful to the other interns for their support and solidarity.

What’s up next?

In the remaining weeks of my internship, I’m going to be continuing the work I mentioned, but instead of from a library in a small German town or a random internet connection in a small Italian town, I’ll be working mainly out of the Berlin office, and hopefully getting to know more Mozillians here. I’ll also be participating in the TechSpeakers program, a training program from the Mozilla Reps to improve your public speaking skills so that you can go forth and spread the word about Mozilla’s awesome technologies. Finally, in the last week or two, I’ll be figuring out how to pass the baton, i.e. tie up loose ends, document what I’ve done and where I’m leaving off, and make it possible for someone else – whether existing team or community members, or perhaps the next intern – to continue making the Marionette test runner and its unit tests Super Awesome. And blogging all the while, of course. :) Looking forward to it!

Marionette, Act I: We’ve got Firefox on a string

2016-07-08T00:00:00+00:00

As you may already know, I’m spending my summer interning with Mozilla’s Enginering Productivity team through the Outreachy program. Specifically, the project I’m working on is called Test-driven Refactoring of Marionette’s Python Test Runner. But what exactly does that mean? What is Marionette, and what does it have to do with testing?

In this two-part series, I’d like to share a bit of what I’ve learned about the Marionette project, and how its various components help us test Firefox by allowing us to automatically control the browser from within. Today, in Act I, I’ll give an overview of how the Marionette server and client make the browser our puppet. Later on, in Act II, I’ll describe how the Marionette test harness and runner make automated testing a breeze, and let you in on the work I’m doing on the Marionette test runner for my internship.

And since we’re talking about puppets, you can bet there’s going to be a hell of a lot of Being John Malkovich references. Consider yourself warned!

How do you test a browser?

On the one hand, you probably want to make sure that the browser’s interface, or chrome, is working as expected; that users can, say, open and close tabs and windows, type into the search bar, change preferences and so on. But you probably also want to test how the browser displays the actual web pages, or content, that you’re trying to, well, browse; that users can do things like click on links, interact with forms, or play video clips from their favorite movies.

Because let's be honest, that's like 96% of the point of the internet right there, no?

These two parts, chrome and content, are the main things the browser has to get right. So how do you test them?

Well, you could launch the browser application, type “Being John Malkovich” into the search bar and hit enter, check that a page of search results appears, click on a YouTube link and check that it takes you to a new page and starts playing a video, type “I ❤️ Charlie Kaufman and Spike Jonze” into the comment box and press enter, check that it submits the text…

And when you’re done, you could write up a report about what you tested, what worked and what didn’t, and what philosophical discoveries about the nature of identity and autonomy you made along the way.

Am I the puppet? AM I?
Being John Malkovich via COADA on Tumblr

Now, while this would be fun, if you have to do it a million times it would be less fun, and your boss might think that it is not fun at all that it takes you an entire developer-hour to test one simple interaction and report back.

Wouldn’t it be better if we could magically automate the whole thing? Maybe something like:

import magical_automated_browser as client

client.navigate("https://www.youtube.com")
client.find_element(By.ID, "search-bar").send_keys("Being John Malkovich")
client.find_element(By.ID, "search-button").click()
# etc., etc.

SPOILER ALERT: We can, thanks to the Marionette project!

What is Marionette?

Marionette refers to a suite of tools for automated testing of Mozilla browsers. One important part of the project is an automation framework for Gecko, the engine that powers Firefox. The automation side of Marionette consists of the Marionette server and client, which work together to make the browser your puppet: they give you a nice, simple little wooden handle with which you can pull a bunch of strings, which are tied to the browser internals, to make the browser and the content it’s displaying do whatever you want. The client.do_stuff code above isn’t even an oversimplification; that’s exactly how easy it becomes to control the browser using Marionette’s client and server. Pretty great right?

But Marionette doesn’t stop there! In addition to the client & server giving you this easy-peasy apparatus for automatic control of the browser, another facet of the Marionette project - the test harness and runner - provides a full-on framework for automatically running and reporting tests that utilize the automation framework. This makes it easy to set up your puppet and the stage you want it to perform on, pull the strings to make the browser dance, check whether the choreography looked right, and log a review of the performance. I can see the headline now:

Screenwriter Charlie Kaufman enthralls again with a brooding script for automated browser testing

You: GROAN. That's a terrible joke.
Me: Sorry, it won't be the last. Hang in there, reader.
Being John Malkovich via the dissected frog (adapted with GIFMaker.me)

As I see it, the overall aim of the Marionette project is to make automated browser testing easy. This breaks down into two main tasks: automation and testing. Here in Act I, we’ll investigate how the Marionette server and client let us automate the browser. In the next post, Act II, we’ll take a closer look at how the Marionette test harness and runner make use of that automation to test the browser.

How do Marionette’s server and client automate the browser?

A real marionette is composed of three parts:

a puppet
strings
a handle

This is a great analogy for Marionette’s approach to automating the browser (I guess that’s why they named it that).

The puppet we want to move is the Firefox browser, or to be precise, the Gecko browser engine underlying it. We want to make all of its parts – windows, tabs, pages, page elements, scripts, and so forth – dance about as we please.

The handle we use to control it is the Marionette client, a Python library that gives us an API for accessing and manipulating the browser’s components and mimicking user interactions.

The strings, which connect handle to puppet and thus make the whole contraption work, are the Marionette server. The server comprises a set of components built in to Gecko (the bottom ends of the strings), and listens for commands coming in from the client (the top ends of the strings).

Photo adapted from "Marionettes from Being John Malkovich" by Alex Headrick, via Flickr

The puppet: the Gecko browser engine

So far, I’ve been talking about “the browser” as the thing we want to automate, and the browser I have in mind is (desktop) Firefox, which Marionette indeed lets us automate. But in fact, Marionette’s even more powerful than that; we can also use it to automate other products, like Firefox for Android (codenamed “Fennec”, so cute!) or FirefoxOS/Boot to Gecko (B2G). That’s because the puppet Marionette lets us control is actually not the Firefox desktop browser itself, but rather the Gecko browser engine on top of which Firefox (like Fennec, and B2G) is built. All of the above, and any other Gecko-based products, can in principle be automated with Marionette.¹^,²

Just choose your puppet!
Adapted from "Marionettes from Being John Malkovich" by Alex Headrick via Flickr, with logos from @FennecNightly, Firefox branding, and B2G OS.

So what exactly is this Gecko thing we’re playing with? Well, I’ve already revealed that it’s a browser engine - but if you’re like me at the beginning of this internship, you’re wondering what a “browser engine” even is/does. MDN explains:

Gecko’s function is to read web content, such as HTML, CSS, XUL, JavaScript, and render it on the user’s screen or print it. In XUL-based applications Gecko is used to render the application’s user interface as well.

In other words, a browser engine like Gecko takes all that ugly raw HTML/CSS/JS code and turns it into a pretty picture on your screen (or, you know, not so pretty - but a picture, nonetheless), which explains why browser engines are also called “layout engines” or “rendering engines”.

And see that bit about “XUL”? Well, XUL (XML User interface Language) is a markup language Mozilla came up with that lets you write application interfaces almost as if they were web pages. This lets Mozilla use Gecko not only to render the websites that Firefox lets you navigate to, but also to render the interface of Firefox itself: the search bar, tabs, forward and back buttons, etc. So it’s safe to say that Gecko is the heart of Firefox. And other applications, like the aforementioned Fennec and FirefoxOS, as well as the Thunderbird email client.

But wait a minute; why do we have to go all the way down to Gecko to control the browser? It’s pretty easy to write add-ons to control Firefox’s chrome or content, so why can’t we just do that? Well, first of all, security issues abound in add-on territory, which is why add-ons typically run with limited privileges and/or require approval; so an add-on-based automation system would likely give under- or over-powered control over the browser. But in fact, the real reason Marionette isn’t an add-on is more historical. As browser automation expert and Mozillian David Burns explained at SeleniumConf 2013, Marionette was originally developed to test FirefoxOS, which had the goal of using Gecko to run the entire operating system of a smartphone (hence FirefoxOS being codenamed Boot to Gecko). FirefoxOS didn’t allow add-ons, so the Marionette team had to get creative and build an automation solution right into Gecko itself. This gave them the opportunity to make Marionette an implementation of the WebDriver specification, a W3C standard for a browser automation interface. The decision to build Marionette as part of Gecko rather than an add-on thus had at least two advantages: Marionette had native access to Gecko and didn’t have to deal with add-on security issues,³ and by making Marionette WebDriver-compliant, Mozilla helped advanced the standardization of browser automation.

So that’s why it’s Gecko, not Firefox, that Marionette ties strings to. In the next section, we’ll see what those knots look like.

The strings: the Marionette server

As mentioned in the previous section, Marionette is built into Gecko itself. Specifically, the part of Marionette that’s built into Gecko, which gives us native access to the browser’s chrome and content, is called the Marionette server. The server acts as the strings of the contraption: the “top end” listens for commands from the handle (i.e. the Marionette client, which we’ll get to in the next section), and the “bottom end” actually manipulates the Gecko puppet as instructed by our commands.

The code that makes up these strings is written in JavaScript and lives within the Firefox codebase at mozilla-central/testing/marionette. Let’s take a little tour, shall we?

The strings are embedded into Gecko via a component called MarionetteComponent, which, when enabled,⁴ starts up a MarionetteServer, which is the object that most directly represents the strings themselves. MarionetteComponent is defined in components/marionettecomponent.js (which, incidentally, includes the funniest line in the entire Marionette codebase), while MarionetteServer is defined in the file server.js. As you can see in server.js, MarionetteServer is responsible for tying the whole contraption together: it sets up a socket on a given port where it can listen for commands, and uses the dispatcher defined in dispatcher.js to receive incoming commands and send data about command outcomes back to the client. Together, the server and dispatcher provide a point of connection to the “bottom end” of the strings: GeckoDriver, or the part of Marionette that actually talks to the browser’s chrome and content.

GeckoDriver, so named because it’s the part of the whole Marionette apparatus that can most accurately be said to be the part automatically driving Gecko, is defined in a file that is unsurprisingly named driver.js. The driver unites a bunch of other specialized modules which control various aspects of the automation, pulling them together and calling on them as needed according to the commands received by the server. Some examples of the “specialized modules” I’m talking about are:

element.js, which maps out and gives us access to all the elements on the page
interaction.js and action.js, which help us mimic mouse, keyboard, and touchscreen interactions
evaluate.js, which lets us execute JavaScript code

With the help of such modules, the driver allows us to grab on to whatever part of the browser’s chrome or content interests us and interact with it as we see fit.

The Marionette server thus lets us communicate automatically with the browser, acting as the strings that get tugged on by the handle and in turn pull on the various limbs of our Gecko puppet. The final part of the puzzle, and subject of the next section, is the handle we can use to tell Marionette what it is we want to do.

The handle: the Marionette client

For us puppeteers, the most relevant part of the whole marionette apparatus is the one we actually have contact with: the handle. In Marionette, that handle is called the Marionette client. The client gives us a convenient API for communicating with Gecko via the Marionette server and driver described in the previous section.

Written in user-friendly Python,⁵ the client is defined in the confusingly-named client/marionette_driver directory inside of mozilla-central/testing/marionette. The client and its API are described quite clearly in the refreshingly excellent documentation, which includes a quick tutorial that walks you through the basic functionality.

To start pulling Marionette’s strings, all we need to do is instantiate a Marionette object (a client), tell it to open up a “session” with the server, i.e. a unique connection that allows messages to be sent back and forth between the two, and give it some commands to send to the server, which (as we saw above) executes them in Gecko. And of course, this assumes that the instance of Firefox (or our Gecko-based product of choice) has Marionette enabled,⁴ i.e. that there’s a Marionette server ready and waiting for our commands; if the server’s disabled, the strings we’re pulling won’t actually be connected to anything.

The commands we give can either make changes to the browser’s state (e.g. navigate to a new page, click on an element, resize the window, etc.), or return information about that state (e.g. get the URL of the current page, get the value of a property of a certain element, etc.). When giving commands, we have to be mindful of which context we’re in, i.e. whether we’re trying to do something with the browser’s chrome or its content. Some commands are specific to one context or the other (e.g. navigating to a given URL is a content operation), while others work in both contexts (e.g. clicking on an element can pertain to either of the two). Luckily, the client API gives us an easy one-liner to switch from one context to another.

Let’s take a look at a little example (see the docs for more):

# Import browser automation magic
from marionette import Marionette
from marionette_driver.by import By

# Instantiate the Marionette (client) class
client = Marionette(host='localhost', port=2828)

# Start a session to talk to the server
# (otherwise, nothing will work because the strings aren't connected)
client.start_session()

# Give a command and check that it worked
client.navigate("https://www.mozilla.org")
assert "building a better Internet" in client.title

# Switch to the chrome context for a minute (content is default)
with client.using_context(client.CONTEXT_CHROME):
   urlbar = client.find_element(By.ID, "urlbar")
   urlbar.send_keys("about:robots")
   # try this one out yourself!

# Close the window, which ends the session
client.close()

It’s as simple as that! We’ve got an easy-to-use, high-level API that gives us full control over the browser, in terms of both chrome and content. Given this simple handle provided by the client, we don’t really need to worry about the mechanics of the server strings or the Gecko puppet itself; instead, we can concern ourselves with the dance steps we want the browser to perform.

Arabesque? Pirouette? Pas de bourrée? You name it!
Being John Malkovich via ScreenplayHowTo

The browser is our plaything! Now what?

So now we’ve seen how the Marionette client and server give us the apparatus to control the browser like a puppet. The client gives us a simple handle we can manipulate, the server ties strings to that handle that transmit our wishes directly to the Gecko browser engine, which dances about as we please.

But what about checking that it’s got the choreography right? Well, as mentioned above, the client API not only lets us make changes to the browser’s chrome and content, but also gives us information about their current state. And since it’s just regular old Python code, we can use simple assert statements to perform quick checks, as in the example in the last section. But if we want to test the browser and user interactions with it more thoroughly, we could probably use a more developed and full-featured testing framework.

ANOTHER SPOILER ALERT (well OK I actually already spoiled this one): the Marionette project gives us a tool for that too!

In Act II of this article, we’ll explore the Marionette test harness and runner, which wrap the server-client automation apparatus described here in Act I in a testing framework that makes it easy to set the stage, perform a dance, and write a review of the performance. See you back here after the intermission!

Sources

The brains of Mozillians David Burns, Maja Frydrychowicz, Henrik Skupin, and Andreas Tolfsen. Many thanks to them for their feedback on this article.
From FirefoxDriver to Marionette, Mozilla pulls the strings - Jonathan Griffin & David Burns, SeleniumConf 2013
Automating your browser-based testing using WebDriver - Simon Stewart, Google Tech Talks 2012
The Marionette codebase and documentation - Mozilla

Notes

1 Emphasis on the “in principle” part, because getting Marionette to play nicely with all of these products may not be trivial. For example, my internship mentor Maja has been hard at work recently on the Marionette runner and client to make them Fennec-friendly. ↩

2 If you’re interested in automating a browser that doesn’t run on Gecko, don’t fret! Marionette is Gecko-specific, but it’s an implementation of the engine-agnostic WebDriver standard, a W3C specification for a browser automation protocol. Given a WebDriver implementation for the engine in question, any browser can in principle be automated in the same way that Marionette automates Gecko browsers. ↩

3 In fact, Marionette’s built-in design makes it able to circumvent the add-on signing requirement mentioned earlier; this would be dangerous if exposed to end users (see 4), but comes in handy when Mozilla developers need to inject unsigned add-ons into development versions of Gecko browsers in automation. ↩

4 At this point (or some much-earlier point) you might be wondering:

Wait a minute - if the Marionette server is built into Gecko itself, and gives us full automatic control of the browser, isn’t that a security risk?

Indeed it is. That’s why, although Marionette is indeed built into Gecko and is thus, in a sense, laying dormant in every instance of a Gecko-based application like Firefox, it’s disabled by default so it can’t be used to control the browser. To run Firefox (or your puppet of choice) with Marionette enabled, you have to be running a Marionette-friendly build (i.e. a version for developers and not standard users) and specifically indicate that you want Marionette turned on when you launch the application. ↩

5 Prefer to talk to the Marionette server from another language? No problem! All you need to do is implement a client in your language of choice, which is pretty simple since the WebDriver specification that Marionette implements uses bog-standard JSON over HTTP for client-server communications. If you want to use JavaScript, your job is even easier: you can take advantage of a JS Marionette client developed for the B2G project. ↩

Mozilla London All Hands 2016

2016-06-20T00:00:00+00:00

Last week, all of Mozilla met in London for a whirlwind tour from TARDIS to TaskCluster, from BBC1 to e10s, from Regent Park to the release train, from Paddington to Positron. As an Outreachy intern, I felt incredibly lucky to be part of this event, which gave me a chance to get to know Mozilla, my team, and the other interns much better. It was a jam-packed work week of talks, meetings, team events, pubs, and parties, and it would be impossible to blog about all of the fun, fascinating, and foxy things I learned and did. But I can at least give you some of the highlights! Or, should I say, Who-lights? (Be warned, that is not the last pun you will encounter here today.)

Foxy, the TARDIS, and espionage in the park? All in a day's work at #MozLondon! pic.twitter.com/QPWdPRnJHY
— Anjana Vakil (@AnjanaVakil) June 14, 2016

Role models

While watching the plenary session that kicked off the week, it felt great to realize that of the 4 executives emerging from the TARDIS in the corner to take the stage (3 Mozillians and 1 guest star), a full 50% were women. As I had shared with my mentor (also a woman) before arriving in London, one of my goals for the week was to get inspired by finding some new role moz-els (ha!): Mozillians who I could aspire to be like one day, especially those of the female variety.

Why a female role model, specifically? What does gender have to do with it?

Well, to be a good role model for you, a person needs to not only have a life/career/lego-dragon you aspire to have one day, but also be someone who you can already identify with, and see yourself in, today. A role model serves as a bridge between the two. As I am a woman, and that is a fundamental part of my experience, a role model who shares that experience is that much easier for me to relate to. I wouldn’t turn down a half-Irish-half-Indian American living in Germany, either.

At any rate, in London I found no shortage of talented, experienced, and - perhaps most importantly - valued women at Mozilla. I don’t want to single anyone out here, but I can tell you that I met women at all levels of the organization, from intern to executive, who have done and are doing really exciting things to advance both the technology and culture of Mozilla and the web. Knowing that those people exist, and that what they do is possible, might be the most valuable thing I took home with me from London.

Aw, what about the Whomsycorn?

No offense, Whomyscorn, you’re cool too.

The Whomsycorn, making its #mozlondon debut.

(c/o @shorlander and @FirefoxUX) pic.twitter.com/xEFGcnNZNp
— madhava (@madhava) June 14, 2016

Electrolysis (e10s)

Electrolysis, or “e10s” for those who prefer integers to morphemes, is a massive and long-running initiative to separate the work Firefox does into multiple processes.

At the moment, the Firefox desktop program that the average user downloads and uses to explore the web runs in a single process. That means that one process has to do all the work of loading & displaying web pages (the browser “content”), as well as the work of displaying the user interface and its various tabs, search bars, sidebars, etc. (the browser “chrome”). So if something goes wrong with, say, the execution of a poorly-written script on a particular page, instead of only that page refusing to load, or its tab perhaps crashing, the entire browser itself may hang or crash.

That’s not cool. Especially if you often have lots of tabs open. Not that I ever do.

Of course not. Anyway, even less cool is the possibility that some jerk (not that there are any of those on the internet, though, right?) could make a page with a script that hijacks the entire browser process, and does super uncool stuff.

It would be much cooler if, instead of a single massive process, Firefox could use separate processes for content and chrome. Then, if a page crashes, at least the UI still works. And if we assign the content process(es) reduced permissions, we can keep possibly-jerkish content in a nice, safe sandbox so that it can’t do uncool things with our browser or computer.

Better performance, more security? Super cool.

Indeed. Separation is cool. Electrolysis is separation. Ergo, Electrolysis is cool.

It’s not perfect yet - for example, compatibility with right-to-left languages, accessibility (or “a11y”, if “e10s” needs a buddy), and add-ons is still an issue - but it’s getting there, and it’s rolling out real soon! Given that the project has been underway since 2008, that’s pretty exciting.

Rust, Servo, & Oxidation

I first heard about the increasingly popular language Rust when I was at the Recurse Center last fall, and all I knew about it was that it was being used at Mozilla to develop a new browser engine called Servo.

More recently, I heard talks from Mozillians like E. Dunham that revealed a bit more about why people are so excited about Rust: it’s a new language for low-level programming, and compared with the current mainstay C, it guarantees memory safety. As in, “No more segfaults, no more NULLs, no more dangling pointers’ dirty looks”. It’s also been designed with concurrency and thread safety in mind, so that programs can take better advantage of e.g. multi-core processors. (Do not ask me to get into details on this; the lowest level I have programmed at is probably sitting in a beanbag chair. But I believe them when they say that Rust does those things, and that those things are good.)

Finally, it has the advantage of having a tight-knit, active, and dedicated community “populated entirely by human beings”, which is due in no small part to the folks at Mozilla and beyond who’ve been working to keep the community that way.

OK OK OK, so Rust is a super cool new language. What can you do with it?

Well, lots of stuff. For example, you could write a totally new browser engine, and call it Servo.

Wait, what’s a browser engine?

A browser engine (aka layout or rendering engine) is basically the part of a browser that allows it to show you the web pages you navigate to. That is, it takes the raw HTML and CSS content of the page, figures out what it means, and turns it into a pretty picture for you to look at.

Uh, I’m pretty sure I can see web pages in Firefox right now. Doesn’t it already have an engine?

Indeed it does. It’s called Gecko, and it’s written in C++. It lets Firefox make the web beautiful every day.

So why Servo, then? Is it going to replace Gecko?

No. Servo is an experimental engine developed by Mozilla Research; it’s just intended to serve(-o!) as a playground for new ideas that could improve a browser’s performance and security.

The beauty of having a research project like Servo and a real-world project like Gecko under the same roof at Mozilla is that when the Servo team’s research unveils some new and clever way of doing something faster or more awesomely than Gecko does, everybody wins! That’s thanks to the Oxidation project, which aims to integrate clever Rust components cooked up in the Servo lab into Gecko. Apparently, Firefox 45 already got (somewhat unexpectedly) an MP4 metadata parser in Rust, which has been running just fine so far. It’s just the tip of the iceberg, but the potential for cool ideas from Servo to make their way into Gecko via Oxidation is pretty exciting.

The Janitor

Another really exciting thing I heard about during the week is The Janitor, a tool that lets you contribute to FOSS projects like Firefox straight from your browser.

For me, one of the biggest hurdles to contributing to a new open-source project is getting the development environment all set up.

Ugh I hate that. I just want to change one line of code, do I really need to spend two days grappling with installation and configuration?!?

Exactly. But the Janitor to the rescue!

Cowboy Bebop via GIPHY

Powered by the very cool Cloud9 IDE, the Janitor gives you one-click access to a ready-to-go, cloud-based development environment for a given project. At the moment there are a handful of project supported (including Firefox, Servo, and Google Chrome), and new ones can be added by simply writing a Dockerfile. I’m not sure that an easier point of entry for new FOSS contributors is physically possible. The ease of start-up is perfect for short-term contribution efforts like hackathons or workshops, and thanks to the collaborative features of Cloud9 it’s also perfect for remote pairing.

Awesome, I’m sold. How do I use it?

Unfortunately, the Janitor is still in alpha and invite-only, but you can go to janitor.technology and sign up to get on the waitlist. I’m still waiting to get my invite, but if it’s half as fantastic as it seems, it will be a huge step forward in making it easier for new contributors to get involved with FOSS projects. If it starts supporting offline work (apparently the Cloud9 editor is somewhat functional offline already, once you’ve loaded the page initially, but the terminal and VNC always needs a connection to function), I think it’ll be unstoppable.

L20n

The last cool thing I heard about (literally, it was the last session on Friday) at this work week was L20n.

Wait, I thought “localization” was abbreviated “L10n”?

Yeah, um, that’s the whole pun. Way to be sharp, exhausted-from-a-week-of-talks-Anjana.

See, L20n is a next-generation framework for web and browser localization (l10n) and internationalization (i18n). It’s apparently a long-running project too, born out of the frustrations of the l10n status quo.

According to the L20n team, at the moment the localization system for Firefox is spread over multiple files with multiple syntaxes, which is no fun for localizers, and multiple APIs, which is no fun for developers. What we end up with is program logic intermingling with l10n/i18n decisions (say, determining the correct format for a date) such that developers, who probably aren’t also localizers, end up making decisions about language that should really be in the hands of the localizers. And if a localizer makes a syntax error when editing a certain localization file, the entire browser refuses to run. Not cool.

Pop quiz: what’s cool?

Um…

C’mon, we just went over this. Go on and scroll up.

Electrolyis?

Yeah, that’s cool, but thinking more generally…

Separation?

That’s right! Separation is super cool! And that’s what L20n does: separate l10n code from program source code. This way, developers aren’t pretending to be localizers, and localizers aren’t crashing browsers. Instead, developers are merely getting localized strings by calling a single L20n API, and localizers are providing localized strings in a single file format & syntax.

Wait but, isn’t unifying everything into a single API/file format the opposite of separation? Does that mean it’s not cool?

Shhh. Meaningful separation of concerns is cool. Arbitrary separation of a single concern (l10n) is not cool. L20n knows the difference.

OK, fine. But first “e10s” and “a11y”, now “l10n”/”l20n” and “i18n”… why does everything need a numbreviation?

You’ve got me there.

I want to mock with you

2016-06-16T00:00:00+00:00

This post brought to you from Mozilla’s London All Hands meeting - cheers!

When writing Python unit tests, sometimes you want to just test one specific aspect of a piece of code that does multiple things.

For example, maybe you’re wondering:

Does object X get created here?
Does method X get called here?
Assuming method X returns Y, does the right thing happen after that?

Finding the answers to such questions is super simple if you use mock: a library which “allows you to replace parts of your system under test with mock objects and make assertions about how they have been used.” Since Python 3.3 it’s available simply as unittest.mock, but if you’re using an earlier Python you can get it from PyPI with pip install mock.

So, what are mocks? How do you use them?

Well, in short I could tell you that a Mock is a sort of magical object that’s intended to be a doppelgänger for some object in your code that you want to test. Mocks have special attributes and methods you can use to find out how your test is using the object you’re mocking. For example, you can use Mock.called and .call_count to find out if and how many times a method has been called. You can also manipulate Mocks to simulate functionality that you’re not directly testing, but is necessary for the code you’re testing. For example, you can set Mock.return_value to pretend that an function gave you some particular output, and make sure that the right thing happens in your program.

But honestly, I don’t think I could give a better or more succinct overview of mocks than the Quick Guide, so for a real intro you should go read that. While you’re doing that, I’m going to watch this fantastic Michael Jackson video:

Oh you’re back? Hi! So, now that you have a basic idea of what makes Mocks super cool, let me share with you some of the tips/tips/trials/tribulations I discovered when starting to use them.

Patches and namespaces

tl;dr: Learn where to patch if you don’t want to be sad!

When you import a helper module into a module you’re testing, the tested module gets its own namespace for the helper module. So if you want to mock a class from the helper module, you need to mock it within the tested module’s namespace.

For example, let’s say I have a Super Useful helper module, which defines a class HelperClass that is So Very Helpful:

# helper.py

class HelperClass():
    def __init__(self):
        self.name = "helper"
    def help(self):
        helpful = True
        return helpful

And in the module I want to test, tested, I instantiate the Incredibly Helpful HelperClass, which I imported from helper.py:

# tested.py

from helper import HelperClass

def fn():
    h = HelperClass() # using tested.HelperClass
    return h.help()

Now, let’s say that it is Incredibly Important that I make sure that a HelperClass object is actually getting created in tested, i.e. that HelperClass() is being called. I can write a test module that patches HelperClass, and check the resulting Mock object’s called property. But I have to be careful that I patch the right HelperClass! Consider test_tested.py:

# test_tested.py

import tested

from mock import patch

# This is not what you want:
@patch('helper.HelperClass')
def test_helper_wrong(mock_HelperClass):
    tested.fn()
    assert mock_HelperClass.called # Fails! I mocked the wrong class, am sad :(

# This is what you want:
@patch('tested.HelperClass')
def test_helper_right(mock_HelperClass):
    tested.fn()
    assert mock_HelperClass.called # Passes! I am not sad :)

OK great! If I patch tested.HelperClass, I get what I want.

But what if the module I want to test uses import helper and helper.HelperClass(), instead of from helper import HelperClass and HelperClass()? As in tested2.py:

# tested2.py

import helper

def fn():
    h = helper.HelperClass()
    return h.help()

In this case, in my test for tested2 I need to patch the class with patch('helper.HelperClass') instead of patch('tested.HelperClass'). Consider test_tested2.py:

# test_tested2.py

import tested2
from mock import patch

# This time, this IS what I want:
@patch('helper.HelperClass')
def test_helper_2_right(mock_HelperClass):
    tested2.fn()
    assert mock_HelperClass.called # Passes! I am not sad :)

# And this is NOT what I want!
# Mock will complain: "module 'tested2' does not have the attribute 'HelperClass'"
@patch('tested2.HelperClass')
def test_helper_2_right(mock_HelperClass):
    tested2.fn()
    assert mock_HelperClass.called

Wonderful!

In short: be careful of which namespace you’re patching in. If you patch whatever object you’re testing in the wrong namespace, the object that’s created will be the real object, not the mocked version. And that will make you confused and sad.

I was confused and sad when I was trying to mock the TestManifest.active_tests() function to test BaseMarionetteTestRunner.add_test, and I was trying to mock it in the place it was defined, i.e. patch('manifestparser.manifestparser.TestManifest.active_tests').

Instead, I had to patch TestManifest within the runner.base module, i.e. the place where it was actually being called by the add_test function, i.e. patch('marionette.runner.base.TestManifest.active_tests').

So don’t be confused or sad, mock the thing where it is used, not where it was defined!

Pretending to read files with `mock_open`

One thing I find particularly annoying is writing tests for modules that have to interact with files. Well, I guess I could, like, write code in my tests that creates dummy files and then deletes them, or (even worse) just put some dummy files next to my test module for it to use. But wouldn’t it be better if I could just skip all that and pretend the files exist, and have whatever content I need them to have?

It sure would! And that’s exactly the type of thing mock is really helpful with. In fact, there’s even a helper called mock_open that makes it super simple to pretend to read a file. All you have to do is patch the builtin open function, and pass in mock_open(read_data="my data") to the patch to make the open in the code you’re testing only pretend to open a file with that content, instead of actually doing it.

To see it in action, you can take a look at a (not necessarily great) little test I wrote that pretends to open a file and read some data from it:

def test_nonJSON_file_throws_error(runner):
    with patch('os.path.exists') as exists:
        exists.return_value = True
        with patch('__builtin__.open', mock_open(read_data='[not {valid JSON]')):
            with pytest.raises(Exception) as json_exc:
                runner._load_testvars() # This is the code I want to test, specifically to be sure it throws an exception
    assert 'not properly formatted' in json_exc.value.message

Gotchya: Mocking and debugging at the same time

See that patch('os.path.exists') in the test I just mentioned? Yeah, that’s probably not a great idea. At least, I found it problematic.

I was having some difficulty with a similar test, in which I was also patching os.path.exists to fake a file (though that wasn’t the part I was having problems with), so I decided to set a breakpoint with pytest.set_trace() to drop into the Python debugger and try to understand the problem. The debugger I use is pdb++, which just adds some helpful little features to the default pdb, like colors and sticky mode.

So there I am, merrily debugging away at my (Pdb++) prompt. But as soon as I entered the patch('os.path.exists') context, I started getting weird behavior in the debugger console: complaints about some ~/.fancycompleterrc.py file and certain commands not working properly.

It turns out that at least one module pdb++ was using (e.g. fancycompleter) was getting confused about file(s) it needs to function, because of checks for os.path.exists that were now all messed up thanks to my ill-advised patch. This had me scratching my head for longer than I’d like to admit.

What I still don’t understand (explanations welcome!) is why I still got this weird behavior when I tried to change the test to patch 'mymodule.os.path.exists' (where mymodule.py contains import os) instead of just 'os.path.exists'. Based on what we saw about namespaces, I figured this would restrict the mock to only mymodule, so that pdb++ and related modules would be safe - but it didn’t seem to have any effect whatsoever. But I’ll have to save that mystery for another day (and another post).

Still, lesson learned: if you’re patching a commonly used function, like, say, os.path.exists, don’t forget that once you’re inside that mocked context, you no longer have access to the real function at all! So keep an eye out, and mock responsibly!

Mock the night away

Those are just a few of the things I’ve learned in my first few weeks of mocking. If you need some bedtime reading, check out these resources that I found helpful:

An intro to mocking in Python on Toptal
Mozilla dev Armen Z.G.’s blog post on better Python tests

I’m sure mock has all kinds of secrets, magic, and superpowers I’ve yet to discover, but that gives me something to look forward to! If you have mock-foo tips to share, just give me a shout on Twitter!

Warming up to Mercurial

2016-06-03T00:00:00+00:00

When it comes to version control, I’m a Git girl. I had to use Subversion a little bit for a project in grad school (not distributed == not so fun). But I had never touched Mercurial until I decided to contribute to Mozilla’s Marionette, a testing tool for Firefox, for my Outreachy application. Mercurial is the main version control system for Firefox and Marionette development,¹ so this gave me a great opportunity to start learning my way around the hg. Turns out it’s really close to Git, though there are some subtle differences that can be a little tricky. This post documents the basics and the trip-ups I discovered. Although there’s plenty of other info out there, I hope some of this might be helpful for others (especially other Gitters) using Mercurial or contributing to Mozilla code for the first time. Ready to heat things up? Let’s do this!

Getting my bearings on Planet Mercury

OK, so I’ve been working through the Firefox Onramp to install Mercurial (via the bootstrap script) and clone the mozilla-central repository, i.e. the source code for Firefox. This is just like Git; all I have to do is:

$ hg clone <repo>

(Incidentally, I like to pronounce the hg command “hug”, e.g. “hug clone”. Warm fuzzies!)

Cool, I’ve set foot on a new planet! …But where am I? What’s going on?

Just like in Git, I can find out about the repo’s history with hg log. Adding some flags make this even more readable: I like to --limit the number of changesets (change-whats? more on that later) displayed to a small number, and show the --graph to see how changes are related. For example:

$ hg log --graph --limit 5

or, for short:

$ hg log -Gl5

This outputs something like:

@    changeset:   300339:e27fe24a746f
|\   tag:         tip
| ~  fxtree:      central
|    parent:      300125:718e392bad42
|    parent:      300338:8b89d98ce322
|    user:        Carsten "Tomcat" Book <cbook@mozilla.com>
|    date:        Fri Jun 03 12:00:06 2016 +0200
|    summary:     merge mozilla-inbound to mozilla-central a=merge
|
o  changeset:   300338:8b89d98ce322
|  user:        Jean-Yves Avenard <jyavenard@mozilla.com>
|  date:        Thu Jun 02 21:08:05 2016 +1000
|  summary:     Bug 1277508: P2. Add HasPendingDrain convenience method. r=kamidphish
|
o  changeset:   300337:9cef6a01859a
|  user:        Jean-Yves Avenard <jyavenard@mozilla.com>
|  date:        Thu Jun 02 20:54:33 2016 +1000
|  summary:     Bug 1277508: P1. Don't attempt to demux new samples while we're currently draining. r=kamidphish
|
o  changeset:   300336:f75d7afd686e
|  user:        Jean-Yves Avenard <jyavenard@mozilla.com>
|  date:        Fri Jun 03 11:46:36 2016 +1000
|  summary:     Bug 1277729: Ignore readyState value when reporting the buffered range. r=jwwang
|
o  changeset:   300335:71a44348d3b7
|  user:        Jean-Yves Avenard <jyavenard@mozilla.com>
~  date:        Thu Jun 02 17:14:03 2016 +1000
   summary:     Bug 1276184: [MSE] P3. Be consistent with types when accessing track buffer. r=kamidphish

Great! Now what does that all mean?

Some (confusing) terminology

Changesets/revisions and their identifiers

According to the official definition, a changeset is “an atomic collection of changes to files in a repository.” As far as I can tell, this is basically what I would call a commit in Gitese. For now, that’s how I’m going to think of a changeset, though I’m sure there’s some subtle difference that’s going to come back to bite me later. Looking forward to it!

Changesets are also called revisions (because two names are better than one?), and each one has (confusingly) two identifying numbers: a local revision number (a small integer), and a global changeset ID (a 40-digit hexadecimal, more like Git’s commit IDs). These are what you see in the output of hg log above in the format:

changeset: <revision-number>:<changeset-ID>

For example,

changeset:   300339:e27fe24a746f

is the changeset with revision number 300339 (its number in my copy of the repo) and changeset ID e27fe24a746f (its number everywhere).

Why the confusing double-numbering? Well, apparently because revision numbers are “shorter to type” when you want to refer to a certain changeset locally on the command line; but since revision numbers only apply to your local copy of the repo and will “very likely” be different in another contributor’s local copy, you should only use changeset IDs when discussing changes with others. But on the command line I usually just copy-paste the hash I want, so length doesn’t really matter, so… I’m just going to ignore revision numbers and always use changeset IDs, OK Mercurial? Cool.

Branches, bookmarks, heads, and the tip

I know Git! I know what a “branch” is! - Anjana, learning Mercurial

Yeeeah, about that… Unfortunately, this term in Gitese is a false friend of its Mercurialian equivalent.

In the land of Gitania, when it’s time to start work on a new bug/feature, I make a new branch, giving it a feature-specific name; do a bunch of work on that branch, merging in master as needed; then merge the branch back into master whenever the feature is complete. I can make as many branches as I want, whenever I want, and give them whatever names I want.

This is because in Git, a “branch” is basically just a pointer (a reference or “ref”) to a certain commit, so I can add/delete/change that pointer whenever and however I want without altering the commit(s) at all. But on Mercury, a branch is simply a “diverged” series of changesets; it comes to exist simply by virtue of a given changeset having multiple children, and it doesn’t need to have a name. In the output of hg log --graph, you can see the branches on the left hand side: continuation of a branch looks like |, merging |\, and branching |/. Here are some examples of what that looks like.

Confusingly, Mercuial also has named branches, which are intended to be longer-lived than branches in Git, and actually become part of a commit’s information; when you make a commit on a certain named branch, that branch is part of that commit forever. This post has a pretty good explanation of this.

Luckily, Mercurial does have an equivalent to Git’s branches: they’re called bookmarks. Like Git branches, Mercurial bookmarks are just handy references to certain commits. I can create a new one thus:

$ hg bookmark my-awesome-bookmark

When I make it, it will point to the changeset I’m currently on, and if I commit more work, it will move forward to point to my most recent changeset. Once I’ve created a bookmark, I can use its name pretty much anywhere I can use a changeset ID, to refer to the changeset the bookmark is pointing to: e.g. to point to the bookmark I can do hg up my-awesome-bookmark. I can see all my bookmarks and the changesets they’re pointing to with the command:

$ hg bookmarks

which outputs something like:

   loadvars                  298655:fe18ebae0d9c
   resetstats                300075:81795401c97b
 * my-awesome-bookmark       300339:e27fe24a746f

When I’m on a bookmark, it’s “active”; the currently active bookmark is indicated with a *.

OK, maybe I was wrong about branches, but at least I know what the “HEAD” is! - Anjana, a bit later

Yeah, nope. I think of the “HEAD” in Git as the branch (or commit, if I’m in “detached HEAD” state) I’m currently on, i.e. a pointer to (the pointer to) the commit that would end up the parent of whatever I commit next. In Mercurial, this doesn’t seem to have a special name like “HEAD”, but it’s indicated in the output of hg log --graph by the symbol @. However, Mercurial documentation does talk about heads, which are just the most recent changesets on all branches (regardless of whether those branches have names or bookmarks pointing to them or not).² You can see all those with the command hg heads.

The head which is the most recent changeset, period, gets a special name: the tip. This is another slight difference from Git, where we can talk about “the tip of a branch”, and therefore have several tips. In Mercurial, there is only one. It’s labeled in the output of hg log with tag: tip.

Recap: Mercurial glossary

Term	Meaning
branch	a “diverged” series of changesets; doesn’t need to have a name
bookmark	a named reference to a given commit; can be used much like a Git branch
heads	the last changesets on each diverged branch, i.e. changesets which have no children
tip	the most recent changeset in the entire history (regardless of branch structure)

All the world’s a stage (but Mercury’s not the world)

Just like with Git, I can use hg status to see the changes I’m about to commit before committing with hg commit. However, what’s missing is the part where it tells me which changes are staged, i.e. “to be committed”. Turns out the concept of “staging” is unique to Git; Mercurial doesn’t have it. That means that when you type hg commit, any changes to any tracked files in the repo will be committed; you don’t have to manually stage them like you do with git add <file> (hg add <file> is only used to tell Mercurial to track a new file that it’s not tracking yet).

However, just like you can use git add --patch to stage individual changes to a certain file a la carte, you can use the now-standard record extension to commit only certain files or parts of files at a time with hg commit --interactive. I haven’t yet had occasion to use this myself, but I’m looking forward to it!

Turning back time

I can mess with my Mercurial history in almost exactly the same way as I would in Git, although whereas this functionality is built in to Git, in Mercurial it’s accomplished by means of extensions. I can use the rebase extension to rebase a series of changesets (say, the parents of the active bookmark location) onto a given changeset (say, the latest change I pulled from central) with hg rebase, and I can use the hg histedit command provided by the histedit extension to reorder, edit, and squash (or “fold”, to use the Mercurialian term) changesets like I would with git rebase --interactive.

My Mozilla workflow

In my recent work refactoring and adding unit tests for Marionette’s Python test runner, I use a workflow that goes something like this.

I’m gonna start work on a new bug/feature, so first I want to make a new bookmark for work that will branch off of central:

$ hg up central
$ hg bookmark my-feature

Now I go ahead and do some work, and when I’m ready to commit it I simply do:

$ hg commit

which opens my default editor so that I can write a super great commit message. It’s going to be informative and formatted properly for MozReview/Bugzilla, so it might look something like this:

Bug 1275269 - Add tests for _add_tests; r?maja_zf

Add tests for BaseMarionetteTestRunner._add_tests:
Test that _add_tests populates self.tests with correct tests;
Test that invalid test names cause _add_tests to
throw Exception and report invalid names as expected.

After working for a while, it’s possible that some new changes have come in on central (this happens about daily), so I may need to rebase my work on top of them. I can do that with:

$ hg pull central

followed by:

$ hg rebase -d central

which rebases the commits in the branch that my bookmark points to onto the most recent changeset in central. Note that this assumes that the bookmark I want to rebase is currently active (I can check if it is with hg bookmarks).

Then maybe I commit some more work, so that now I have a series of commits on my bookmark. But perhaps I want to reorder them, squash some together, or edit commit messages; no problemo, I just do a quick:

$ hg histedit

which opens a history listing all the changesets on my bookmark. I can edit that file to pick, fold (squash), or edit changesets in pretty much the same way I would using git rebase --interactive.

When I’m satisfied with the history, I push my changes to review:

$ hg push review

My special Mozillian configuration of Mercurial, which a wizard helped me set up during installation, magically prepares everything for MozReview and then asks me if I want to

publish these review requests now (Yn)?

To which I of course say Y (or, you know, realize I made a horrible mistake, say n, go back and re-do everything, and then push to review again).

Then I just wait for review feedback from my mentor, and perhaps make some changes and amend my commits based on that feedback, and push those to review again.

Ultimately, once the review has passed, my changes get merged into mozilla-inbound, then eventually mozilla-central (more on what that all means in a future post), and I become an official contributor. Yay! :)

So is this goodbye Git?

Nah, I’ll still be using Git as my go-to version control system for my own projects, and another Mozilla project I’m contributing to, Perfherder, has its code on Github, so Git is the default for that.

But learning to use Mercurial, like learning any new tool, has been educational! Although my progress was (and still is) a bit slow as I get used to the differences in features/workflow (which, I should reiterate, are quite minor when coming from Git), I’ve learned a bit more about version control systems in general, and some of the design decisions that have gone into these two. Plus, I’ve been able to contribute to a great open-source project! I’d call that a win. Thanks Mercurial, you deserve a hg. :)

Outreachy: What? How? Why?

2016-05-23T00:00:00+00:00

Today was my first day as an Outreachy intern with Mozilla! What does that even mean? Why is it super exciting? How did I swing such a sweet gig? How will I be spending my summer non-vacation? Read on to find out!

What is Outreachy?

Outreachy is a fantastic initiative to get more women and members of other underrepresented groups involved in Free & Open Source Software. Through Outreachy, organizations that create open-source software (e.g. Mozilla, GNOME, Wikimedia, to name a few) take on interns to work full-time on a specific project for 3 months. There are two internship rounds each year, May-August and December-March. Interns are paid for their time, and receive guidance/supervision from an assigned mentor, usually a full-time employee of the organization who leads the given project.

Oh yeah, and the whole thing is done remotely! For a lot of people (myself included) who don’t/can’t/won’t live in a major tech hub, the opportunity to work remotely removes one of the biggest barriers to jumping in to the professional tech community. But as FOSS developers tend to be pretty distributed anyway (I think my project’s team, for example, is on about 3 continents), it’s relatively easy for the intern to integrate with the team. It seems that most communication takes place over IRC and, to a lesser extent, videoconferencing.

What does an Outreachy intern do?

Anything and everything! Each project and organization is different. But in general, interns spend their time…

Coding (or not)

A lot of projects involve writing code, though what that actually entails (language, framework, writing vs. refactoring, etc.) varies from organization to organization and project to project. However, there are also projects that don’t involve code at all, and instead have the intern working on equally important things like design, documentation, or community management.

As for me specifically, I’ll be working on the project Test-driven Refactoring of Marionette’s Python Test Runner. You can click through to the project description for more details, but basically I’ll be spending most of the summer writing Python code (yay!) to test and refactor a component of Marionette, a tool that lets developers run automated Firefox tests. This means I’ll be learning a lot about testing in general, Python testing libraries, the huge ecosystem of internal Mozilla tools, and maybe a bit about browser automation. That’s a lot! Luckily, I have my mentor Maja (who happens to also be an alum of both Outreachy and RC!) to help me out along the way, as well as the other members of the Engineering Productivity team, all of whom have been really friendly & helpful so far.

Traveling

Interns receive a $500 stipend for travel related to Outreachy, which is fantastic. I intend, as I’m guessing most do, to use this to attend conference(s) related to open source. If I were doing a winter round I would totally use it to attend FOSDEM, but there are also a ton of conferences in the summer! Actually, you don’t even need to do the traveling during the actual 3 months of the internship; they give you a year-long window so that if there’s an annual conference you really want to attend but it’s not during your internship, you’re still golden.

At Mozilla in particular, interns are also invited to a week-long all-hands meet up! This is beyond awesome, because it gives us a chance to meet our mentors and other team members in person. (Actually, I doubly lucked out because I got to meet my mentor at RC during “Never Graduate Week” a couple of weeks ago!)

Blogging

One of the requirements of the internship is to blog regularly about how the internship and project are coming along. This is my first post! Though we’re required to write a post every 2 weeks, I’m aiming to write one per week, on both technical and non-technical aspects of the internship. Stay tuned!

How do you get in?

I’m sure every Outreachy participant has a different journey, but here’s a rough outline of mine.

Step 1: Realize it is a thing

Let’s not forget that the first step to applying for any program/job/whatever is realizing that it exists! Like most people, I think, I had never heard of Outreachy, and was totally unaware that a remote, paid internship working on FOSS was a thing that existed in the universe. But then, in the fall of 2015, I made one of my all-time best moves ever by attending the Recurse Center (RC), where I soon learned about Outreachy from various Recursers who had been involved with the program. I discovered it about 2 weeks before applications closed for the December-March 2015-16 round, which was pretty last-minute; but a couple of other Recursers were applying and encouraged me to do the same, so I decided to go for it!

Step 2: Frantically apply at last minute

Applying to Outreachy is a relatively involved process. A couple months before each round begins, the list of participating organizations/projects is released. Prospective applicants are supposed to find a project that interests them, get in touch with the project mentor, and make an initial contribution to that project (e.g. fix a small bug).

But each of those tasks is pretty intimidating!

First of all, the list of participating organizations is long and varied, and some organizations (like Mozilla) have tons of different projects available. So even reading through the project descriptions and choosing one that sounds interesting (most of them do, at least to me!) is no small task.

Then, there’s the matter of mustering up the courage to join the organization/project’s IRC channel, find the project mentor, and talk to them about the application. I didn’t even really know what IRC was, and had never used it before, so I found this pretty scary. Luckily, I was RC, and one of my batchmates sat me down and walked me through IRC basics.

However, the hardest and most important part is actually making a contribution to the project at hand. Depending on the project, this can be long & complicated, quick & easy, or anything in between. The level of guidance/instruction also varies widely from project to project: some are laid out clearly in small, hand-holdy steps, others are more along the lines of “find something to do and then do it”. Furthermore, prerequisites for making the contribution can be anything from “if you know how to edit text and send an email, you’re fine” to “make a GitHub account” to “learn a new programming language and install 8 million new tools on your system just to set up the development environment”. All in all, this means that making that initial contribution can often be a deceptively large amount of work.

Because of all these factors, for my application to the December-March round I decided to target the Mozilla project “Contribute to the HTML standard”. In addition to the fact that I thought it would be awesome to contribute to such a fundamental part of the web, I chose it because the contribution itself was really simple: just choose a GitHub issue with a beginner-friendly label, ask some questions via GitHub comments, edit the source markup file as needed, and make a pull request. I was already familiar with GitHub so it was pretty smooth sailing.

Once you’ve made your contribution, it’s time to write the actual Outreachy application. This is just a plain text file you fill out with lots of information about your experience with FOSS, your contribution to the project, etc. In case it’s useful to anyone, here’s my application for the December-March 2015-16 round. But before you use that as an example, make sure you read what happened next…

Step 3: Don’t get in

Unfortunately, I didn’t get in to the December-March round (although I was stoked to see some of my fellow Recursers get accepted!). Honestly, I wasn’t too surprised, since my contributions and application had been so hectic and last-minute. But even though it wasn’t successful, the application process was educational in and of itself: I learned how to use IRC, got 3 of my first 5 GitHub pull requests merged, and became a contributor to the HTML standard! Not bad for a failure!

Step 4: Decide to go for it again (at last minute, again)

Fast forward six months: after finishing my batch at RC, I had been looking & interview-prepping, but still hadn’t gotten a job. When the applications for the May-August round opened up, I took a glance at the projects and found some cool ones, but decided that I wouldn’t apply this round because a) I needed a Real Job, not an internship, and b) the last round’s application process was a pretty big time investment which hadn’t paid off (although it actually had, as I just mentioned!).

But as the weeks went by, and the application deadline drew closer, I kept thinking about it. I was no closer to finding a Real Job, and upheaval in my personal life made my whereabouts over the summer an uncertainty (I seem never to know what continent I live on), so a paid, remote internship was becoming more and more attractive. When I broached my hesitation over whether or not to apply to other Recursers, they unanimously encouraged me (again) to go for it (again). Then, I found out that one of the project mentors, Maja, was a Recurser, and since her project was one of the ones I had shortlisted, I decided to apply for it.

Of course, by this point it was once again two weeks until the deadline, so panic once again set in!

Step 5: Learn from past mistakes

This time, the process as a whole was easier, because I had already done it once. IRC was less scary, I already felt comfortable asking the project mentor questions, and having already been rejected in the previous round made it somehow lower-stakes emotionally (“What the hell, at least I’ll get a PR or two out of it!”). During my first application I had spent a considerable amount of time reading about all the different projects and fretting about which one to do, flipping back and forth mentally until the last minute. This time, I avoided that mistake and was laser-focused on a single project: Test-driven Refactoring of Marionette’s Python Test Runner.

From a technical standpoint, however, contributing to the Marionette project was more complicated than the HTML standard had been. Luckily, Maja had written detailed instructions for prospective applicants explaining how to set up the development environment etc., but there were still a lot of steps to work through. Then, because there were so many folks applying to the project, there was actually a shortage of “good-first-bugs” for Marionette! So I ended up making my first contributions to a different but related project, Perfherder, which meant setting up a different dev environment and working with a different mentor (who was equally friendly). By the time I was done with the Perfherder stuff (which turned out to be a fun little rabbit hole!), Maja had found me something Marionette-specific to do, so I ended up working on both projects as part of my application process.

When it came time to write the actual application, I also had the luxury of being able to use my failed December-March application as both a starting point and an example of what not to do. Some of the more generic parts (my background, etc.) were reusable, which saved time. But when it came to the parts about my contribution to the project and my proposed internship timeline, I knew I had to do a much better job than before. So I opted for over-communciation, and basically wrote down everything I could think of about what I had already done and what I would need to do to complete the goals stated in the project description (which Maja had thankfully written quite clearly).

In the end, my May-August application was twice as long as my previous one had been. Much of that difference was the proposed timeline, which went from being one short paragraph to about 3 pages. Perhaps I was a bit more verbose than necessary, but I decided to err on the side of too many details, since I had done the opposite in my previous application.

Step 6: Get a bit lucky

Spoiler alert: this time I was accepted!

Although I knew I had made a much stronger application than in the previous round, I was still shocked to find out that I was chosen from what seemed to be a large, competitive applicant pool. I can’t be sure, but I think what made the difference the second time around must have been a) more substantial contributions to two different projects, b) better, more frequent communication with the project mentor and other team members, and c) a much more thorough and better thought-out application text.

But let’s not forget d) luck. I was lucky to have encouragement and support from the RC community throughout both my applications, lucky to have the time to work diligently on my application because I had no other full-time obligations, lucky to find a mentor who I had something in common with and therefore felt comfortable talking to and asking questions of, and lucky to ultimately be chosen from among what I’m sure were many strong applications. So while I certainly did work hard to get this internship, I have to acknowledge that I wouldn’t have gotten in without all of that luck.

Why am I doing this?

Last week I had the chance to attend OSCON 2016, where Mozilla’s E. Dunham gave a talk on How to learn Rust. A lot of the information applied to learning any language/new thing, though, including this great recommendation: When embarking on a new skill quest, record your motivation somewhere (I’m going to use this blog, but I suppose Twitter or a vision board or whatever would work too) before you begin.

The idea is that once you’re in the process of learning the new thing, you will probably have at least one moment where you’re stuck, frustrated, and asking yourself what the hell you were thinking when you began this crazy project. Writing it down beforehand is just doing your future self a favor, by saving up some motivation for a rainy day.

So, future self, let it be known that I’m doing Outreachy to…

Write code for an actual real-world project (as opposed to academic/toy projects that no one will ever use)
Get to know a great organization that I’ve respected and admired for years
Try out working remotely, to see if it suits me
Learn more about Python, testing, and automation
Gain confidence and feel more like a “real developer”
Launch my career in the software industry

I’m sure these goals will evolve as the internship goes along, but for now they’re the main things driving me. Now it’s just a matter of sitting back, relaxing, and working super hard all summer to achieve them! :D

Got any more questions?

Are you curious about Outreachy? Thinking of applying? Confused about the application process? Feel free to reach out to me! Go on, don’t be shy, just use one of those cute little contact buttons and drop me a line. :)

Notes from JSUnconf 2016

2016-04-24T00:00:00+00:00

This conference was awesome: not too big, not too cramped of a schedule (long breaks between talk sessions), free drinks, snacks & meals (with vegan options!), unisex bathrooms (toiletries & tampons provided!), a code of conduct, and - most importantly, to me - a great diversity program that gave me and 16 others support to attend! The unconference format was really interesting, and worked better than I expected. It also enabled something I wasn’t planning on: I gave my first talk at a tech conference!

What’s an unconference?

There’s no pre-planned schedule; instead, at the beginning of each day, anyone who’s interested in giving a talk makes a short pitch of their topic, and for the next hour or so the rest of the attendees vote on which talks they want to attend. The highest-voted talks are selected, and begin shortly after that. It sounds like it would be chaos, but it works!

I gave my first tech talk! On 3 hours’ notice!

On day 2 of the conference, in a completely unexpected turn of events, I proposed, planned, and delivered a 30-minute talk within a period of about 3 hours. Am I crazy? Perhaps. But the good kind of crazy!

See, there had been some interest in functional programming in JS (as part of the unconference format, people can submit topics they’d like to hear a talk on as well), and some talks on specific topics related to functional languages/libraries, but no one had proposed a high-level general introduction about it. So, at literally the last minute of the talk-proposal session, I spontaneously got up and pitched “Learning Functional Programming with JS” (that’s how I learned FP, after all!).

Turns out people were indeed interested: my proposal actually got more votes than any other that day. Which meant that I would present in the main room, the only one out of the three tracks that was being recorded. So all I had to do was, you know, plan a talk and make slides from scratch and then speak for 30 minutes in front of a camera, all in the space of about 3 hours.

Yay! No, wait… panic!

Luckily my years of teaching experience and a few presentations at academic conferences came to the rescue. I had to skip a couple of the sessions before mine (luckily some talks were recorded), and get a little instant feedback from a few folks at the conference that I had gotten to know, but ultimately I was able to throw together a talk outline and some slides.

When it came to actually delivering the talk, it was actually less scary than I thought. I even had enough time to do an ad-hoc digression (on the chalkboard!!!) into persistent data structures, which are the topic of my first scheduled tech talk at !!Con 2016.

So, how did it go? I’ll let Twitter tell you:

And now: Learning functional programming with JS and @AnjanaVakil #jsunconf 💡 pic.twitter.com/2CzOJ5JID0
— Nina (@sssggr) April 24, 2016

Is it a bird? 🐦 No! Plane? ✈ Nope, it's a Mapreduce Sandwich! 🍔@AnjanaVakil's 💯 intro to functional prog. #jsunconf pic.twitter.com/uqUniJ4zpg
— Flaki (@slsoftworks) April 24, 2016

Back 2 School with @AnjanaVakil and Functional Programming in JS ! @jsunconf Awesome talk ! #jsunconf pic.twitter.com/xa4oHYlE68
— claudiahdz ᕕ( ᐛ )ᕗ (@koste4) April 24, 2016

One of the best talks of #jsunconf by @AnjanaVakil & a good reason why DiversitySupport improves the DevCommunity 👍 pic.twitter.com/I1YgHc5Vs9
— Robert Willemelis (@robertSPD) April 24, 2016

Aw geez y’all, I’m blushing! :D

The whole thing was a great experience, and definitely gave me a huge confidence boost for speaking at more conferences in the future (look out, !!Con and EuroPython!). I would recommend it to anyone! Come to think of it, why aren’t you giving talks yet?

Some things I learned at JSUnconf

The unconference format is pretty sweet!
Giving a tech talk is not as scary as all that!
HTTP/2 is a thing
Service Workers are a thing
There is a library for building neural nets in JS: Synaptic
I want to learn Elm
Flora Power Mate is so much better than Club Mate (i.e. it actually tastes like mate)!

Talk notes

These are the unedited notes I jotted down during the talks. Mistakes, omissions, and misunderstandings are totally possible! Don’t take my word for anything; when in doubt check out the slides!

HTTP/2

Speaker: Ole Michaelis (@CodeStars, nesQuick on Github), from Jimdo

HTTP/1.1 has been in use since 1997
But it has some problems:
- Lots of requests required to load a single page; “request bonanza”
- Have to load the page itself, assets, ad stuff, tracking stuff….
- Requests have to be done one-at-a-time, creating a “‘waterfall’ of blocked requests”
- This causes latency (e.g. ~10 second load time for a web page like The Verge)
- Especially problematic for mobile
You can get around it with weird hacks/workarounds, but these could violate best practices
Google made a thing called SPDY (“speedy”), which was sort of a predecessor to…
HTTP/2 is the real solution
- Binary, not text
- Single TCP connection, but multiple streams with requests running in parallel
- Headers are compressed
Each browser can determine how to figure out/build the tree of dependencies
- Firefox has the most efficient implementation at the moment
- It sets up the dependency tree of requests before actually making any requests (?)
Sidenote: Huffman encoding
- Take a string to compress
- Count the frequencies of each character
- Make a binary tree such that the leaf nodes are the characters arranged left-to-right from most frequent to least, and the leaves are connected through binary nodes from right to left, where each branch is labeled 0 on the left and 1 on the right
- Use the path from the root of the tree to the character’s leaf node as the compression table
- So the most frequent character will be 00, the least frequent will be e.g. 1111
- This means more frequent characters have shorter compressions, so the overall compression will be as small as possible
HTTP/2 is already in use (22% of sites(???)) - you should start using it now!
- Customers using HTTP/1.1 will experience an increase in load times, but those using updated browsers will see a decrease

Natural user interfaces using JS

Speaker: @princi_ya, from Zalando

Gesture-based interfaces, e.g. Intel RealSense 3D, Leap Motion
Some terminology:
- Augmented Reality, also called Mediated Reality(?): real environment augmented with virtual components
- Virtual Reality: totally simulated environment
- Perceptual Computing: automatically perceiving what’s happening in the environment
Using JS/the browser to communicate with RealSense/Leap Motion SDK via WebSocket server and getUserMedia to access the user’s webcam
JS-Object Detect - open-source library for object detection from webcam
Unfortunately not very accurate - demo didn’t work

Elm: Web development with delight

Speaker: Bastian Krol (@bastiankrol), from codecentric

Slides

Why Elm?
- Clean syntax - inspired by Haskell(?) and OCaml
- No runtime exceptions (!!!) - if code compiles, it will run
- Interoperates smoothly with vanilla JS, you can use JS libraries
- Reduces bug hunting
- Everything is stateless & immutable
  - application is composed out of stateless functions
  - removes a whole category of bugs in JS

Hello world:

import Html
main = Html.text "Hello Hamburg!"

Convention: every Elm app has a “main” module, and that module has a “main” function

Optional type annotations (best practice to add type annotations to all your top-level functions):

  import Html exposing (Html)

  greet : Int -> String -> Html
  greet number string =
    Html.text str

  main : Html
  main =
    greet "Hello Hamburg"

Elm supports partial function application
- when it takes in the Int in the greet function above, it essentially returns an anonymous function that takes a String and returns an Html
- so there’s no real difference between greet : Int -> String -> Html and greet : Int -> (String -> Html)
Signals
- use Signal.map to do something with the input from the signal (e.g. map Mouse.x to Html)
- can filter signals do drop certain events if you’re not interested
- you can also
- Further reading:
  - Elm guide to reactivity
  - Elm architecture tutorial
Architecture
- Features:
  - Unidirectional data flow
  - Single source of truth
  - Everything immutable & stateless
  - …these are similar to Redux and other popular libraries (who may have copied these features from Elm)
- Uniform structure for apps
- Main concepts:
  - Model: custom type that you declare (could be a simple int or a huge data structure)
  - Update: function that takes an action and the current model, and produces a new model (Action -> Model -> Model)
  - View: function that turns a model into an Html structure (essentially how you render the model)
Compiler
- Catches edge cases etc., e.g. empty lists
- So if your code compiles it will run - no runtime errors!

Shipping an app to production using WebMIDI and WebAudio: Lessons learned

Speaker: Jan Krutisch

Web Audio API
- allows you to generate, play back, modify, filter, etc. digital sounds/music of any sort in a flexible way
- can build synthesizers with it, use audio in your games, etc. etc.
Web MIDI API
- MIDI: Musical Instrument Digital Interface
Weird bit operations in JS

Some experiences building an Android app with React Native & Redux

Speaker: Alex Bepple (@alexbepple), from it-agile

Introducing a new term: Owdaf - One-way reactive data flow (aka unidirectional data flow)
What’s cool about Owdaf?
- All UI is a functional representation of the state of the (web/mobile/whatever) app
- The user always sees the same thing if the state is the same
- Changing what the user sees requires dispatching an action - but the presentational components don’t need to know anything about that
- You change something in one place, and everything in UI gets updated automatically
React Native
- Bridge between JS and the UI
- You have native components for the given mobile platform, but they’re controlled from a JS thread
- Great ecosystem of components
- Some gotchyas: require is different than in node, problems centering a grid, …
Redux:
- brings Owdaf to React Native (?)
- can persist state using redux-storage library
- can use libraries like redux-act to create actions and reducers
- encapsulation is a problem (?)
- there’s supposed to be time-traveling, but it didn’t work last he checked
React Native & Redux together:
- Biggest gotchya: how to represent navigation in your global state?
- for regular React there is react-router-redux
- no such thing for React Native (because the concept of a URL doesn’t really exist in a native app)

Anjana Sofia Vakil

Notes from KatsConf2

The origin story of FunctionalKats

The Perfect Language

It should be hard to make mistakes

There should be no ambiguity

It shouldn’t make you think

The “abstraction ceiling”

Efficiency

Summing up

Functional programming & static typing for server-side web

Functional Program Derivation

The cake and eating it: or writing expressive high-level programs that generate fast low-level code at runtime

Rug: an External DSL for Coding Code Transformations (with Scala Parser-Combinators)

Relational Programming

Working hard to keep things lazy

Total Functional Programming

Notes from FOSDEM 2017

Mozilla Dev Room, Saturday

Other rooms, Saturday-Sunday

Marionette, Act II: Harnessing automation to test the browser

Wait, what’s Marionette again?

Wait, why do we need automated browser testing again?

What’s a test harness?

What’s special about the Marionette test harness?

How does the Marionette harness work?

How does Marionette’s test runner work?

What do the tests look like?

What is the interface to the harness like?

How is the Marionette test harness used at Mozilla?

How do we know that the harness itself is running tests properly?

Notes

Outreachy halftime(ish) update

What have I been up to?

Learning how to do the work

Doing the work

Writing stuff down

What’s been fun?

Learning all the things

Working remotely

Helping others get started contributing!

What’s been hard?

Impostor Syndrome

Working remotely

Measuring productivity

What’s been helpful?

Having a fantastic mentor

Being part of a team

Attending the All Hands

Intern solidarity

What’s up next?

Marionette, Act I: We’ve got Firefox on a string

How do you test a browser?

What is Marionette?

How do Marionette’s server and client automate the browser?

The puppet: the Gecko browser engine

The strings: the Marionette server

The handle: the Marionette client

The browser is our plaything! Now what?

Sources

Notes

Mozilla London All Hands 2016

Role models

Electrolysis (e10s)

Rust, Servo, & Oxidation

The Janitor

L20n

I want to mock with you

Patches and namespaces

Pretending to read files with mock_open

Gotchya: Mocking and debugging at the same time

Mock the night away

Warming up to Mercurial

Getting my bearings on Planet Mercury

Some (confusing) terminology

Changesets/revisions and their identifiers

Branches, bookmarks, heads, and the tip

Recap: Mercurial glossary

All the world’s a stage (but Mercury’s not the world)

Turning back time

Pretending to read files with `mock_open`