Mozilla Nederland LogoDe Nederlandse

Mozilla Releases Thunderbird 38.4.0 to Patch High and Critical Security Issues - Softpedia News

Nieuws verzameld via Google - do, 26/11/2015 - 03:25

Softpedia News

Mozilla Releases Thunderbird 38.4.0 to Patch High and Critical Security Issues
Softpedia News
Mozilla announced the release of a new maintenance version of the popular, open source, and cross-platform Mozilla Thunderbird 38 email and news client for all supported operating systems, including GNU/Linux, Mac OS X, and Windows. According to the ...

Categorieën: Mozilla-nl planet

Nick Cameron: Macro hygiene in all its guises and variations

Mozilla planet - do, 26/11/2015 - 01:59

Note, I'm not sure of the terminology for some of this stuff, so I might be making horrible mistakes, apologies.

Usually, when we talk about macro hygiene we mean the ability to not confuse identifiers with the same name but from different contexts. This is a big and interesting topic in it's own right and I'll discuss it in some depth later. Today I want to talk about other kinds of macro hygiene.

There is hygiene when naming items (I've heard this called "path hygiene", but I'm not sure if that is a standard term). For example,

mod a { fn f() {} pub macro foo() { f(); } } a::foo!();

The macro use will expand to f(), but there is no f in scope. Currently this will be a name resolution error. Ideally, we would remember the scope where the call to f came from and look up f in that scope.

I believe that switching our hygiene algorithm to scope sets and using the scope sets for name resolution solves this issue.

Privacy hygiene

In the above example, f is private to a, so even if we can name it from the expansion of foo, we still can't access it due to its visibility. Again, scope sets comes to the rescue. The intuition is that we check privacy from the scope used to find f, not from its lexical position. There are a few more details than that, but nothing that will make sense before explaining the scope sets algorithm in detail.

Unsafety hygiene

The goal here is that when checking for unsafety, whether or not we are allowed to execute unsafe code depends on the context where the code is written, not where it is expanded. For example,

unsafe fn foo(x: i32) {} macro m1($x: expr) { foo($x) } macro m2($x: expr) { $x } macro m3($x: expr) { unsafe { foo($x) } } macro m4($x: expr) { unsafe { $x } } fn main() { foo(42); // bad unsafe { foo(42); // ok } m1(42); // bad m2(foo(42)); // bad m3(42); // ok m4(foo(42)); // bad unsafe { m1(42); // bad m2(foo(42)); // ok m3(42); // ok m4(foo(42)); // ok } }

We could in theory use the same hygiene information as for the previous kinds. But when checking unsafety we are checking expressions, not identifiers, and we only record hygiene info for identifiers.

One solution would be to track hygiene for all tokens, not just identifiers. That might not be too much effort since groups of tokens passed together would have the same hygiene info. We would only be duplicating indices into a table, not more data than that. We would also have to track or be able to calculate the safety-status of scopes.

Alternatively, we could introduce a new kind of block into the token tree system - a block which can't be written by the user, only created by expansion or procedural macros. It would affect precedence but not scoping. Such a block is also the solution to having interpolated AST in the token stream - we just have tokens wrapped in the scope-less block. Such a block could be annotated with its safety-status. We would need to track unsafety during parsing/expansion to make this work. We have something similar to this in the HIR where we can push/pop unsafe blocks. I believe we want an absolute setting here rather than push/pop though, and we also don't want to introduce new scoping.

We could follow the current stability solution and annotate spans, but this is a bit of an abuse of spans, IMO.

I'm not super-happy with any of these solutions.

Stability hygiene

Finally, stability. We would like for macros in libraries with access to unstable code to be able to access unstable code when expanded. This is currently supported in Rust by having a bool on spans. We can probably continue to use this system or adapt either of the solutions proposed for unsafety hygiene.

It would be nice for macros to be marked as stable and unstable, I believe this is orthogonal to hygiene though.

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: Add-ons Update – Week of 2015/11/25

Mozilla planet - wo, 25/11/2015 - 23:46

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

The Review Queues

In the past 3 weeks, 758 add-ons were reviewed:

  • 602 (79%) were reviewed in less than 5 days.
  • 32 (4%) were reviewed between 5 and 10 days.
  • 124 (16%) were reviewed after more than 10 days.

There are 281 listed add-ons awaiting review, and 189 unlisted add-ons awaiting review. I should note that this is an unusually large number of unlisted add-ons, which is due to a mass uploading by a developer with 100+ add-ons.

Review times for most add-ons have improved recently  due to more volunteer activity. Add-ons that are admin-flagged or very complex are now getting much needed attention, thanks to a new contractor reviewer. There’s still a fairly large review backlog to go through.

If you’re an add-on developer and would like to see add-ons reviewed faster, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 43 Compatibility

This compatibility blog post is now public. The bulk compatibility validation should be run soon.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition to make sure that they continue to work correctly. End users can install the Add-on Compatibility Reporter to identify and report any add-ons that aren’t working anymore.

Changes in let and const in Firefox 44

Firefox 44 includes some breaking changes that you should all be aware of. Please read the post carefully and test your add-ons on Nightly or the newest Developer Edition.

Extension Signing

The wiki page on Extension Signing has information about the timeline, as well as responses to some frequently asked questions. The current plan is to turn on enforcement by default in Firefox 43.


Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. In a nutshell, Firefox will run on multiple processes now, running content code in a different process than browser code.

This is the time to test your add-ons and make sure they continue working in Firefox. We’re holding regular office hours to help you work on your add-ons, so please drop in on Tuesdays and chat with us!

Web Extensions

If you read the post on the future of add-on development, you should know there are big changes coming. We’re investing heavily on the new WebExtensions API, so we strongly recommend that you start looking into it for your add-ons. You can track progress of its development in

Categorieën: Mozilla-nl planet

Finanzbericht 2014: Mozilla mit gesteigertem Umsatz und mit Gewinn -

Nieuws verzameld via Google - wo, 25/11/2015 - 23:13

Finanzbericht 2014: Mozilla mit gesteigertem Umsatz und mit Gewinn
Jedes Jahr im November veröffentlicht Mozilla den Finanzbericht des Vorjahres. Dieser belegt für das Jahr 2014 eine Umsatzsteigerung von 314 Millionen auf knapp 330 Millionen Dollar. Ein Großteil des Geldes kommt dabei noch von Google. Im November ...

en meer »Google Nieuws
Categorieën: Mozilla-nl planet

Air Mozilla: Quality Team (QA) Public Meeting, 25 Nov 2015

Mozilla planet - wo, 25/11/2015 - 22:30

Quality Team (QA) Public Meeting This is the meeting where all the Mozilla quality teams meet, swap ideas, exchange notes on what is upcoming, and strategize around community building and...

Categorieën: Mozilla-nl planet

Air Mozilla: Bugzilla Development Meeting, 25 Nov 2015

Mozilla planet - wo, 25/11/2015 - 22:00

Bugzilla Development Meeting Help define, plan, design, and implement Bugzilla's future!

Categorieën: Mozilla-nl planet

Chris H-C: How Mozilla Pays Me

Mozilla planet - wo, 25/11/2015 - 20:08

When I told people I was leaving BlackBerry and going to work for Mozilla, the first question was often “Who?”

(“The Firefox people, ${familyMember}” “Oh, well why didn’t you say so”)

More often the first question (and almost always the second question for ${familyMember}) was “How do they make their money?”

When I was working for BlackBerry, it seemed fairly obvious: BlackBerry made its money selling BlackBerry devices. (Though obvious, this was actually incorrect, as the firm made its money more through services and servers than devices. But that’s another story.)

With Mozilla, there’s no clear thing that people’s minds can latch onto. There’s no doodad being sold for dollarbucks, there’s no subscriber fee, there’s no “professional edition” upsell…

Well, today the Mozilla Foundation released its State of Mozilla report including financials for calendar 2014. This ought to clear things up, right? Well…

The most relevant part of this would be page 6 of the audited financial statement which shows that, roughly speaking, Mozilla makes its money thusly (top three listed):

  • $323M – Royalties
  • $4.2M – Contributions (from fundraising efforts)
  • $1M – Interest and Dividends (from investments)

Where this gets cloudy is that “Royalties” line. The Mozilla Foundation is only allowed to accrue certain kinds of income since it is a non-profit.

Which is why I’m not employed by the Foundation but by Mozilla Corporation, the wholly-owned subsidiary of the Mozilla Foundation. MoCo is a taxable entity responsible for software development and stuff. As such, it can earn and spend like any other privately-held concern. It sends dollars back up the chain via that “Royalties” line because it needs to pay to license wordmarks, trademarks, and other intellectual property from the Foundation. It isn’t the only contributor to that line, I think, as I expect sales of plushie Firefoxen and tickets to MozFest factor in somehow.

So, in conclusion, rest assured, ${conceredPerson}: Mozilla Foundation has plenty of money coming in to pay my…

Well, yes, I did just say I was employed by Mozilla Corporation. So?

What do you mean where does the Corporation get its money?

Fine, fine, I was just going to gloss over this part and sway you with those big numbers and how MoCo and MoFo sound pretty similar… but I guess you’re too cunning for that.

Mozilla Corporation is not a publicly-traded corporation, so there are no public documents I can point you to for answers to that question. However, there was a semi-public statement back in 2006 that confirmed that the Corporation was earning within an order of magnitude of $76M in search-related partnership revenue.

It’s been nine years since then. The Internet has changed a lot since the year Google bought YouTube and MySpace was the primary social network of note. And our way of experiencing it has changed from sitting at a desk to having it in our pockets. Firefox has been downloaded over 100 million times on Android and topped some of the iTunes App Store charts after being released twelve days ago for iOS. If this sort of partnership is still active, and is somewhat proportional to Firefox’s reach, then it might just be a different number than “within an order of magnitude of $76M.”

So, ${concernedPerson}, I’m afraid there just isn’t any more information I can give you. Mozilla does its business, and seems to be doing it well. As such, it collects revenue which it has to filter through various taxes and regulation authorities at various levels which are completely opaque even when they’re transparent. From that, I collect a paycheque.

At the very least, take heart from the Contributions line. That money comes from people who like that Mozilla does good things for the Internet. So as long as we’re doing good things (and we have no plans to stop), there is a deep and growing level of support that should keep me from asking for money.

Though, now that you mention it


Categorieën: Mozilla-nl planet

Mozilla affirme qu'il ne dépend plus financièrement de Google - Presse-citron (Blog)

Nieuws verzameld via Google - wo, 25/11/2015 - 19:45

Presse-citron (Blog)

Mozilla affirme qu'il ne dépend plus financièrement de Google
Presse-citron (Blog)
Le trafic que Mozilla renvoie sur Google Search (en tant que moteur de recherche par défaut) lui rapportait des centaines de millions de dollars chaque année. Par exemple, d'après le site Cnet, Mozilla aurait gagné 330 millions de dollars en 2014 et la ...

Categorieën: Mozilla-nl planet

Mozilla krijgt geen geld voor instellen Google als zoekmachine in Europese Firef - Tweakers

Nieuws verzameld via Google - wo, 25/11/2015 - 19:34

Mozilla krijgt geen geld voor instellen Google als zoekmachine in Europese Firef
Hoewel Google voor Europese gebruikers van Firefox nog steeds de zoekmachine is na installatie, krijgt Mozilla geen geld meer als onderdeel van een commerciële overeenkomst. Dat stelt de maker van de browser. Mozilla claimt zonder Google te kunnen ...

en meer »
Categorieën: Mozilla-nl planet

Air Mozilla: The Joy of Coding - Episode 36

Mozilla planet - wo, 25/11/2015 - 19:00

The Joy of Coding - Episode 36 mconley livehacks on real Firefox bugs while thinking aloud.

Categorieën: Mozilla-nl planet

Firefox maker Mozilla: We don't need Google's money anymore - CNET

Nieuws verzameld via Google - wo, 25/11/2015 - 17:28


Firefox maker Mozilla: We don't need Google's money anymore
For years, Google in effect sponsored Mozilla by paying for searches launched through the Firefox browser. In 2014, that deal accounted for most of the nonprofit organization's $330 million in revenue, according to financial results just now being ...

en meer »
Categorieën: Mozilla-nl planet

Mozilla will den Firefox schlanker machen -

Nieuws verzameld via Google - wo, 25/11/2015 - 17:22

Mozilla will den Firefox schlanker machen
Diese erlauben einen tiefgreifenden Eingriff in den Look des Browser, benutzen aber das von Mozilla entwickelte XUL, dessen man sich langfristig ebenfalls entledigen will. Als Alternative gibt es schon länger die Möglichkeit schlanke Themes zu ...
Mozilla will Firefox-Funktionen streichenHeise Newsticker
Mozilla will Firefox
Browser: Mozilla will Firefox
FOCUS Online -WinFuture
alle 18 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla launches new JavaScript-based Add-ons Validator for developers - BetaNews

Nieuws verzameld via Google - wo, 25/11/2015 - 15:45


Mozilla launches new JavaScript-based Add-ons Validator for developers
Like apps hitting a store, browser add-ons have to go through validation to ensure that they work properly and are secure. This is the case with Firefox, and developers will be only too aware that the validation tool provided by Mozilla is unreliable ...

Categorieën: Mozilla-nl planet

Jan de Mooij: Making `this` a real binding in SpiderMonkey

Mozilla planet - wo, 25/11/2015 - 14:38

Last week I landed bug 1132183, a pretty large patch rewriting the implementation of this in SpiderMonkey.

How this Works In JS

In JS, when a function is called, an implicit this argument is passed to it. In strict mode, this inside the function just returns that value:

function f() { "use strict"; return this; }; // 123

In non-strict functions, this always returns an object. If the this-argument is a primitive value, it's boxed (converted to an object):

function f() { return this; }; // returns an object: new Number(123)

Arrow functions don't have their own this. They inherit the this value from their enclosing scope:

function f() { "use strict"; () => this; // `this` is 123 };

And, of course, this can be used inside eval:

function f() { "use strict"; eval("this"); // 123 };

Finally, this can also be used in top-level code. In that case it's usually the global object (lots of hand waving here).

How this Was Implemented

Until last week, here's how this worked in SpiderMonkey:

  • Every stack frame had a this-argument,
  • Each this expression in JS code resulted in a single bytecode op (JSOP_THIS),
  • This bytecode op boxed the frame's this-argument if needed and then returned the result.

Special case: to support the lexical this behavior of arrow functions, we emitted JSOP_THIS when we defined (cloned) the arrow function and then copied the result to a slot on the function. Inside the arrow function, JSOP_THIS would then load the value from that slot.

There was some more complexity around eval: eval-frames also had their own this-slot, so whenever we did a direct eval we'd ensure the outer frame had a boxed (if needed) this-value and then we'd copy it to the eval frame.

The Problem

The most serious problem was that it's fundamentally incompatible with ES6 derived class constructors, as they initialize their 'this' value dynamically when they call super(). Nested arrow functions (and eval) then have to 'see' the initialized this value, but that was impossible to support because arrow functions and eval frames used their own (copied) this value, instead of the updated one.

Here's a worst-case example:

class Derived extends Base { constructor() { var arrow = () => this; // Runtime error: `this` is not initialized inside `arrow`. arrow(); // Call Base constructor, initialize our `this` value. eval("super()"); // The arrow function now returns the initialized `this`. arrow(); } }

We currently (temporarily!) throw an exception when arrow functions or eval are used in derived class constructors in Firefox Nightly.

Boxing this lazily also added extra complexity and overhead. I already mentioned how we had to compute this whenever we used eval.

The Solution

To fix these issues, I made this a real binding:

  • Non-arrow functions that use this or eval define a special .this variable,
  • In the function prologue, we get the this-argument, box it if needed (with a new op, JSOP_FUNCTIONTHIS) and store it in .this,
  • Then we simply use that variable each time this is used.

Arrow functions and eval frames no longer have their own this-slot, they just reference the .this variable of the outer function. For instance, consider the function below:

function f() { return () =>; }

We generate bytecode similar to the following pseudo-JS:

function f() { var .this = BoxThisIfNeeded(this); return () => (.this).foo(); }

I decided to call this variable .this, because it nicely matches the other magic 'dot-variable' we already had, .generator. Note that these are not valid variable names so JS code can't access them. I only had to make sure with-statements don't intercept the .this lookup when this is used inside a with-statement...

Doing it this way has a number of benefits: we only have to check for primitive this values at the start of the function, instead of each time this is accessed (although in most cases our optimizing JIT could/can eliminate these checks, when it knows the this-argument must be an object). Furthermore, we no longer have to do anything special for arrow functions or eval; they simply access a 'variable' in the enclosing scope and the engine already knows how to do that.

In the global scope (and in eval or arrow functions in the global scope), we don't use a binding for this (I tried this initially but it turned out to be pretty complicated). There we emit JSOP_GLOBALTHIS for each this-expression, then that op gets the this value from a reserved slot on the lexical scope. This global this value never changes, so the JITs can get it from the global lexical scope at compile time and bake it in as a constant :) (Well.. in most cases. The embedding can run scripts with a non-syntactic scope chain, in that case we have to do a scope walk to find the nearest lexical scope. This should be uncommon and can be optimized/cached if needed.)

The Debugger

The main nuisance was fixing the debugger: because we only give (non-arrow) functions that use this or eval their own this-binding, what do we do when the debugger wants to know the this-value of a frame without a this-binding?

Fortunately, the debugger (DebugScopeProxy, actually) already knew how to solve a similar problem that came up with arguments (functions that don't use arguments don't get an arguments-object, but the debugger can request one anyway), so I was able to cargo-cult and do something similar for this.

Other Changes

Some other changes I made in this area:

  • In bug 1125423 I got rid of the innerObject/outerObject/thisValue Class hooks (also known as the holy grail). Some scope objects had a (potentially effectful) thisValue hook to override their this behavior, this made it hard to see what was going on. Getting rid of that made it much easier to understand and rewrite the code.
  • I posted patches in bug 1227263 to remove the this slot from generator objects, eval frames and global frames.
  • IonMonkey was unable to compile top-level scripts that used this. As I mentioned above, compiling the new JSOP_GLOBALTHIS op is pretty simple in most cases; I wrote a small patch to fix this (bug 922406).

We changed the implementation of this in Firefox 45. The difference is (hopefully!) not observable, so these changes should not break anything or affect code directly. They do, however, pave the way for more performance work and fully compliant ES6 Classes! :)

Categorieën: Mozilla-nl planet

Software-update: Pale Moon 25.8.0 - Tweakers

Nieuws verzameld via Google - wo, 25/11/2015 - 13:57


Software-update: Pale Moon 25.8.0
Pale Moon logo (75 pix) Versie 25.8 van Pale Moon is verleden week uitgekomen. Deze webbrowser maakt gebruik van de broncode van Mozilla Firefox, maar is geoptimaliseerd voor moderne hardware. De Windows-versie van Mozilla Firefox wordt ...

Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla contributor creates diabetes project for the masses -

Nieuws verzameld via Google - wo, 25/11/2015 - 13:01

Mozilla contributor creates diabetes project for the masses
So I started getting involved in Mozilla around 2009, helping out on IRC and then eventually getting involved with the Mozilla WebFWD program, becoming a team member, then the Mozilla Reps Program, Mozilla DevRel Program, and then for just over two ...
Debian-Based Webconverger 33.1 Kiosk Linux OS Is Out with Mozilla Firefox 42.0Softpedia News (blog)

alle 3 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla contributor creates diabetes project for the masses -

Nieuws verzameld via Google - wo, 25/11/2015 - 13:01

Mozilla contributor creates diabetes project for the masses
So I started getting involved in Mozilla around 2009, helping out on IRC and then eventually getting involved with the Mozilla WebFWD program, becoming a team member, then the Mozilla Reps Program, Mozilla DevRel Program, and then for just over two ...
Debian-Based Webconverger 33.1 Kiosk Linux OS Is Out with Mozilla Firefox 42.0Softpedia News (blog)

alle 2 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla Firefox 64-Bit to Come with Microsoft Silverlight Support - Softpedia News

Nieuws verzameld via Google - wo, 25/11/2015 - 11:47

Softpedia News

Mozilla Firefox 64-Bit to Come with Microsoft Silverlight Support
Softpedia News
The 64-bit version of Firefox is still on the table after so many years of development, and Mozilla is now working on the features that will be included in it, with new evidence now showing that support for Silverlight is very likely to be offered ...
Firefox 64-bit to support Microsoft Silverlight after allGhacks Technology News

alle 3 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla Addons Blog: A New Firefox Add-ons Validator

Mozilla planet - wo, 25/11/2015 - 11:30

The state of add-ons has changed a lot over the past five years, with Jetpack add-ons rising in popularity and Web Extensions on the horizon. Our validation process hasn’t changed as much as the ecosystem it validates, so today Mozilla is announcing we’re building a new Add-ons Validator, written in JS and available for testing today! We started this project only a few months ago and it’s still not production-ready, but we’d love your feedback on it.

Why the Add-ons Validator is Important

Add-ons are a huge part of why people use Firefox. There are currently over 22,000 available, and with work underway to allow Web Extensions in Firefox, it will become easier than ever to develop and update them.

All add-ons listed on (AMO) are required to pass a review by Mozilla’s add-on review team, and the first step in this process is automated validation using the Add-ons Validator.

The validator alerts reviewers to deprecated API usage, errors, and bad practices. Since add-ons can contain a lot of code, the alerts can help developers pinpoint the bits of code that might make your browser buggy or slow, among other problems. It also helps detect insecure add-on code. It helps keep your browsing fast and safe.

Our current validator is a bit old, and because it’s written in Python with JavaScript dependencies, our old validator is difficult for add-on developers to install themselves. This means add-on developers often don’t know about validation errors until they submit their add-on for review.

This wastes time, introducing a feedback cycle that could have been avoided if the add-on developer could have just run addons-validator myAddon.xpi before they uploaded their add-on. If developers could easily check their add-ons for errors locally, getting their add-ons in front of millions of users is that much faster.

And now they can!

The new Add-ons Validator, in JS

I’m not a fan of massive rewrites, but in this case it really helps. Add-on developers are JavaScript coders and nearly everyone involved in web development these days uses Node.js. That’s why we’ve written the new validator in JavaScript and published it on npm, which you can install right now.

We also took this opportunity to review all the rules the old add-on validator defined, and removed a lot of outdated ones. Some of these hadn’t been seen on AMO for years. This allowed us to cut down on code footprint and make a faster, leaner, and easier-to-work-with validator for the future.

Speaking of which…

What’s next?

The new validator is not production-quality code yet and there are rules that we haven’t implemented yet, but we’re looking to finish it by the first half of next year.

We’re still porting over relevant rules from the old validator. Our three objectives are:

  1. Porting old rules (discarding outdated ones where necessary)
  2. Adding support for Web Extensions
  3. Getting the new validator running in production

We’re looking for help with those first two objectives, so if you’d like to help us make our slightly ambitious full-project-rewrite-deadline, you can…

Get Involved!

If you’re an add-on developer, JavaScript programmer, or both: we’d love your help! Our code and issue tracker are on GitHub at We keep a healthy backlog of issues available, so you can help us add rules, review code, or test things out there. We also have a good first bug label if you’re new to add-ons but want to contribute!

If you’d like to try the next-generation add-ons validator, you can install it with npm: npm install addons-validator. Run your add-ons against it and let us know what you think. We’d love your feedback as GitHub issues, or emails on the add-on developer mailing list.

And if you’re an add-on developer who wishes the validator did something it currently doesn’t, please let us know!

We’re really excited about the future of add-ons at Mozilla; we hope this new validator will help people write better add-ons. It should make writing add-ons faster, help reviewers get through add-on approvals faster, and ultimately result in more awesome add-ons available for all Firefox users.

Happy hacking!

Categorieën: Mozilla-nl planet

Matjaž Horvat: Meet Jarek, splendid Pontoon contributor

Mozilla planet - wo, 25/11/2015 - 10:43

Some three months ago, a new guy named jotes showed up in #pontoon IRC channel. It quickly became obvious he’s running a local instance of Pontoon and is ready to start contributing code. Fast forward to the present, he is one of the core Pontoon contributors. In this short period of time, he implemented several important features, all in his free time:

Top contributors. He started by optimizing the Top contributors page. More specifically, he reduced the number of DB queries by some 99%. Next, he added filtering by time period and later on also by locale and project.

User permissions. Pontoon used to rely on the Mozillians API for giving permissions to localizers. It turned out we need a more detailed approach with team managers manually granting permission to their localizers. Guess who took care of it!

Translation memory. Currently, Jarek is working on translation memory optimizations. Given his track record, our expectations are pretty high. :-)

I have this strange ability to close my eyes when somebody tries to take a photo of me, so on most of them I look like a statue of melancholy. :D

What brought you to Mozilla?
A friend recommended me a documentary called Code Rush. Maybe it will sound stupid, but I was fascinated by the idea of a garage full of fellow hackers with power to change the world. During one of the sleepless nights I visited and after a few patches I knew Mozilla is my place. A place where I can learn something new with help of many amazing people.

Jarek Śmiejczak, thank you for being splendid! And as you said, huge thanks to Linda – love of your life – for her patience and for being an active supporter of the things you do.

To learn more about Jarek, follow his blog at Joyful hackin’.
To start hackin’ on Pontoon, get involved now.

Categorieën: Mozilla-nl planet