Mozilla Nederland LogoDe Nederlandse

Firefox-Chef verlässt Mozilla -

Nieuws verzameld via Google - fr, 20/02/2015 - 10:23

Heise Newsticker

Firefox-Chef verlässt Mozilla
Bei der Mozilla Foundation neigt sich eine Ära dem Ende zu. Jonathan Nightingale, der acht Jahre lang die Entwicklung des Browsers Firefox geleitet hatte, wird seinen Hut nehmen. Aus privaten Gründen – Erschöpfung und dem Wunsch nach mehr Zeit für ...
Mozilla: Firefox-Chef Johnathan Nightingale gehtHeise Newsticker
Mozilla: Firefox- und Cloud-Sparte werden
Firefox-Chefentwickler verlässt MozillaPC-Welt
WinFuture -IT Reseller
alle 11 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Soledad Penades: webpack vs browserify

Mozilla planet - fr, 20/02/2015 - 10:10

I saw a project yesterday that was built using webpack, and I started to wonder what makes webpack better than Browserify? The website didn’t really explain to me, so I asked in Twitter because I was sure there would be a bunch of webpack experts ready to tell me—and I wasn’t wrong! ;-)


Webpack comes with “batteries included” and preconfigured, so you get more “out of the box”, it’s easier to get started, and the default outputs are really decent. Whereas with browserify you need to choose the modules you want to use, and essentially assemble the whole thing together: it’s slower to learn, but way more configurable.

Some of the most insightful replies:

@supersole it has way more out of the box, gives better control over optimizing how modules are bundled together.

— James “Jimmy” Long (@jlongster) February 19, 2015

@supersole webpack is more opinionated, has more features in core (bullet point engineering). great if you dont like using npm search

— =^._.^= (@maxogden) February 19, 2015

@supersole It's much faster. Generates slightly smaller output by default. Custom loaders are easier to write.

— Kornel 「コルネル」 (@pornelski) February 20, 2015

Show me the data!

It really irks me when I get vague answers like “performance was better” but no numbers are provided. So I’m glad that the very awesome Kate Hudson indeed did some research for Mozilla’s Webmaker App, and so she could provide us with some numbers:

Webpack’s output can be from 8% to 16% leaner than Browserify’s (using uglify, which is pretty much the standard combination).

Of course this comes at a cost; Kate told me that generating the bundle takes longer with webpack, as it has to do more work than uglify does to get rid of dead code, etc. Also combining React with es6to5 and gulp and browserify didn’t really work well for them whereas webpack could take it easily.

I insist: this was a very specific use case. Your case might be totally different; don’t take this as a dogma.


I’m really used to Browserify even though I haven’t used probably 80% of its features. Maybe I’m missing out! But I don’t really need to change my tooling yet, I think.

On the other hand there are also some interesting features in Webpack like its ability to consume both AMD and UMD modules, and seems like it can also package static text easily whereas Browserify transforms are still a bit esoteric to me (yeeeah, I need to do my homework).

I always feel a bit unsure about introducing new tools, until there’s a certain mass of users (and they iron out the most terrible bugs too), but I will be keeping webpack on my radar.

Thanks to everyone that sent info! :-)

flattr this!

Categorieën: Mozilla-nl planet

Air Mozilla: Bay Area Rust Meetup February 2015

Mozilla planet - fr, 20/02/2015 - 05:00

Bay Area Rust Meetup February 2015 This meetup will be focused on the blocking IO system part of the standard library, and asynchronous IO systems being built upon mio.

Categorieën: Mozilla-nl planet

Manish Goregaokar: Superfish, and why you should be worried

Mozilla planet - fr, 20/02/2015 - 04:06
I'll be updating this post as I get more information .

For non-techies, skip to the last paragraph of the post for instructions on how to get rid of this adware.

Today a rather severe vulnerability on certain Lenovo laptops was discovered.

Software (well, adware) called "Superfish" came preinstalled on some of their machines (it seems like it's the Yoga series).

The software ostensibly scans images of products on the web to provide the user with alternative (perhaps cheaper) offers. Sounds like a mix of annoying and slightly useful, right?

Except to achieve this, they do something extremely unsafe. They install a new root CA certificate into the Windows certificate store. The software works via a local proxy server which does a man in the middle attack on your web requests. Of course, most websites of importance these days use HTTPS, so to be able to successfully decrypt and inject content on these, the proxy needs to have the ability to issue arbitrary certificates. It's a single certificate as far as we can tell (you can find it here in plaintext form)

It also leaves the certificate in the system even if the user does not accept the terms of use.

This means that a nontrivial portion of the population has a untrusted certificate on their machines.

It's actually worse than that, because to execute the MITM attack, the proxy server should have the private key for that certificate.

So a nontrivial portion of the population has the private key to said untrusted certificate. Anyone owning one of these laptops who has some reverse engineering skills has the ability to intercept, modify, and duplicate the connections of anyone else owning one of these laptops. Bank logins, email, credit card numbers, everything. One usually needs physical proximity or control of a network to do this right, but it's quite feasible that this key could be sold to someone who has this level of access (e.g. a secretly evil ISP). Update: The key is now publicly known

This is really bad.

Installing random crapware on laptops is pretty much the norm now; and that's not the issue. Installing crapware which causes a huge security vulnerability? No thanks. What's especially annoying is their attitude towards it; they haven't even acknowledged the security hole they've caused.

The EFF has a rather nice article on this here.

As far as we can tell, Firefox isn't affected by this since it maintains its own root CA store, however we are still trying to verify this, and will see if we can block it in case Firefox is affected, for example, if Superfish installs the cert in Firefox as well. If you have an affected system and can provide information about this, feel free to comment on that bug or tweet at @ManishEarth.

The application seems to detect Firefox and install some add ons as well as the certificate. We're looking into this, further insights would be valuable.

Superfish does NOT infect Firefox.

Chrome uses the OS's root CA store, so it is affected. So is IE.

 It turns out that internally they're using something called Komodia to generate the MITM; and Komodia uses a similar (broken) framework everywhere -- the private key is bundled with it; and the password is "komodia".

If you have friends at Microsoft who can look into this, please see if a hotfix can be pushed, blacklisting the certificate. Whilst it is possible for an "arms race" to happen between Superfish and Windows, it's unlikely since there's more scrutiny now and it would just end up creating more trouble for Superfish. The main concern right now is that rogue root CA cert is installed on many laptops, and the privkey is out there too. 

If you own a Lenovo laptop that came preinstalled with Windows (especially one of these models), please check in your task manager for an app called "VisualDiscovery" or "Superfish". Here's a small guide on how to do this. It's slightly outdated, but the section on uninstalling the program itself should work. Then, follow the steps here to remove all certificates with the name "Superfish" from the root store. Then go and change all your passwords;  and check your bank history amongst other things (/email/paypal/etc)  for any suspicious transactions. Chances are that you haven't been targeted, but it's good to be sure.

Categorieën: Mozilla-nl planet

The Rust Programming Language Blog: Announcing Rust 1.0.0.alpha.2

Mozilla planet - fr, 20/02/2015 - 01:00

Today, we are happy to announce the release of Rust 1.0.0.alpha.2! Rust is a systems programming language pursuing the trifecta: safe, fast, and concurrent.

In accordance with our status report last week, this is a second alpha release, rather than a first beta release. The beta release will be six weeks from today, with the final coming six weeks after that.

We’ve managed to land almost all of the features previously expected for this cycle. The big headline here is that all major API revisions are finished: path and IO reform have landed. At this point, all modules shipping for 1.0 are in what we expect to be their final form, modulo minor tweaks during the alpha2 cycle. See the previous post for more details.

This coming release cycle is crucial to Rust, as this will be the last cycle that we recommend nightly builds for most users. Part of the way through the cycle, around March 9th, we expect to have all major functionality we expect in 1.0 marked as stable; we will fill in stability gaps between then and beta on March 31st. The beta release will fully introduce the “stable channel”, which will not allow use of unstable features but will guarantee backwards-compatibility (after 1.0). Unstable features will only be available in nightly.

For more detail, please see the Release notes.

Thank you to all 204 contributors for this release:

  • Aaron Turon <>
  • Adam Roben <>
  • Adolfo Ochagavía <>
  • Ahmed Charles <>
  • Aidan Hobson Sayers <>
  • Akos Kiss <>
  • Alexander Bliskovsky <>
  • Alexander Korolkov <>
  • Alexander Light <>
  • Alex Crichton <>
  • Alexis <>
  • Alfie John <>
  • Alfie John <>
  • Andrea Canciani <>
  • Andrew Barchuk <>
  • Andrew Paseltiner <>
  • Ariel Ben-Yehuda <>
  • Ariel Ben-Yehuda <>
  • Armin Preiml <>
  • Artem <>
  • Barosl Lee <>
  • Benjamin Peterson <>
  • Ben S <>
  • Björn Steinbrink <>
  • blackbeam <>
  • Brian Anderson <>
  • Brian Leibig <>
  • caipre <>
  • Cam Jackson <>
  • Carl Lerche <>
  • Carol Nichols <>
  • Carter Hinsley <>
  • CarVac <>
  • Caspar Krieger <>
  • Chase Southwood <>
  • Chris Morgan <>
  • Chris Thorn <>
  • Chris Wong <>
  • Clifford Caoile <>
  • Corey Farwell <>
  • Corey Richardson <>
  • Daniel Griffen <>
  • Daniel Grunwald <>
  • Daniel Raloff <>
  • Daniil Smirnov <>
  • Dan Yang <>
  • David Creswick <>
  • Diggory Blake <>
  • Dominik Inführ <>
  • Duane Edwards <>
  • Duncan Regan <>
  • Dzmitry Malyshau <>
  • Earl St Sauver <>
  • Eduard Burtescu <>
  • Edward Wang <>
  • Elantsev Serj <>
  • emanueLczirai <>
  • Erick Rivas <>
  • Erick Tryzelaar <>
  • Eunji Jeong <>
  • Felix S. Klock II <>
  • Fenhl <>
  • Filip Szczepański <>
  • Flavio Percoco <>
  • Florian Hahn <>
  • Garrett Heel <>
  • Geoffrey Thomas <>
  • Greg Chapple <>
  • Guillaume Gomez <>
  • Guillaume Pinot <>
  • Henrik Schopmans <>
  • Hugo van der Wijst <>
  • Huon Wilson <>
  • Ignacio Corderi <>
  • Ingo Blechschmidt <>
  • Jake Goulding <>
  • James Miller <>
  • Jared Roesch <>
  • Jason Fager <>
  • jatinn <>
  • Jay True <>
  • Jeff Belgum <>
  • John Hodge <>
  • John Kåre Alsaker <>
  • Jonathan Reem <>
  • JONNALAGADDA Srinivas <>
  • Jorge Aparicio <>
  • Jorge Israel Peña <>
  • Jormundir <>
  • Joseph Crail <>
  • JP Sugarbroad <>
  • Julian Orth <>
  • Junseok Lee <>
  • Kang Seonghoon <>
  • Keegan McAllister <>
  • Keegan McAllister <>
  • Ken Tossell <>
  • KernelJ <>
  • Kevin Ballard <>
  • Kevin Butler <>
  • Kevin Yap <>
  • Kim Røen <>
  • klutzy <>
  • Kostas Karachalios <>
  • kud1ing <>
  • Lai Jiangshan <>
  • Lauri Lehmijoki <>
  • Leo Testard <>
  • Liigo Zhuang <>
  • Logan Chien <>
  • Loïc Damien <>
  • Luca Bruno <>
  • Luke Francl <>
  • Luke Steensen <>
  • madmalik <>
  • Manish Goregaokar <>
  • Markus Siemens <>
  • Marvin Löbel <>
  • Matt Roche <>
  • Mátyás Mustoha <>
  • mdinger <>
  • Michael Budde <>
  • Michael Neumann <>
  • Michael Pankov <>
  • Michael Sproul <>
  • Michael Woerister <michaelwoerister@posteo>
  • Mike English <>
  • Mikhail Zabaluev <>
  • Ms2ger <>
  • NAKASHIMA, Makoto <>
  • nathan dotz <>
  • Nathaniel Theis <>
  • Nathan Stoddard <>
  • Nelson Chen <>
  • Nick Cameron <>
  • Nick Howell <>
  • Nick Sarten <>
  • Niko Matsakis <>
  • NODA, Kai <>
  • Oliver 'ker' Schneider <>
  • Oliver Schneider <>
  • Orpheus Lummis <>
  • P1start <>
  • Pascal Hertleif <>
  • Paul Collier <>
  • Paul Crowley <>
  • Peter Atashian <>
  • Peter Schuller <>
  • Pierre Baillet <>
  • Piotr Czarnecki <>
  • posixphreak <>
  • Potpourri <>
  • Pyfisch <>
  • Raul Gutierrez S <>
  • Renato Alves <>
  • Renato Zannon <>
  • Richo Healey <>
  • Robin Stocker <>
  • Rohit Joshi <>
  • Ryan Levick <>
  • Sean Collins <>
  • Sean Gillespie <>
  • Sean Patrick Santos <>
  • Sean T Allen <>
  • Sebastian Gesemann <>
  • Sebastian Rasmussen <>
  • Sébastien Marie <>
  • Seo Sanghyeon <>
  • Seth Faxon <>
  • Simonas Kazlauskas <>
  • Stepan Koltsov <>
  • Steve Klabnik <>
  • Steven Allen <>
  • Steven Crockett <>
  • Steven Fackler <>
  • Strahinja Val Markovic <>
  • Thiago Carvalho <>
  • Tim Brooks <>
  • Tim Cuthbertson <>
  • Tim Dumol <>
  • Tim Parenti <>
  • Tobias Bucher <>
  • Toby Scrace <>
  • Tom Chittenden <>
  • Tom Jakubowski <>
  • Toni Cárdenas <>
  • Travis Watkins <>
  • Tristan Storch <>
  • Tshepang Lekhonkhobe <>
  • Tyler Thrailkill <>
  • Ulrik Sverdrup <root@localhost>
  • Vadim Chugunov <>
  • Vadim Petrochenkov <>
  • Valerii Hiora <>
  • Victory <>
  • visualfc <>
  • Vojtech Kral <>
  • Volker Mische <>
  • Wangshan Lu <>
  • we <>
  • Willson Mock <>
  • Will <>
  • wonyong kim <>
  • York Xiang <>
Categorieën: Mozilla-nl planet

James Long: Radical Statements about the Mobile Web

Mozilla planet - fr, 20/02/2015 - 01:00

I drafted a long post about the mobile web, but then Flipboard released their new mobile site with a detailed explanation of why they used canvas instead of the DOM to layout content. Subsequent blog posts ensued in response.

Since the topic of 60 FPS mobile apps has already been discussed greatly, my original post isn't relevant anymore (and I don't have time to polish it up). However, I would still like to point out some important issues.

A quick note (I added this after publishing): I have to give huge props to the recently formed Houdini project which is involving all parties of the web to figure out how to make css/layout/rendering extensible. They are talking about all of these problems in depth (see the wiki) and smarter people than me might be able to really solve this.

This was triggered by playing with React Native, but it stems from years of trying to make the web work well on mobile. These statements are intentionally bold to stir discussion. Some of my assertions may be wrong, but I believe there's at least some truth in most of them.

I'm going to try a new point-based format. The interesting thing about it that is it helps make my argument very clear, since all the colorful articulation (which I don't have time to do) is removed. The downside is that it's quite dense, and might be easy to misinterpret. Here we go:

  1. I work for Mozilla, and I want the web to win. However, this is a thought experiment and I'm going to try to take the role of an unbiased observer. Some of the statements are undoubtedly controversial. None of them reflect my employer — these are just my own thoughts.
  2. The web isn't close to competing with higher-end native apps. You may think the UX is getting close, but there's always more jank. Let's not even talk technical; even if it is getting close, when companies want to develop a beautiful, ground-breaking app, they choose native. I've talked to enough developers to see that we aren't close to changing this yet.
  3. Users don't care about the web. You may argue that the web brings all sorts of benefits over native apps, that they have URLs, are accessible, and you can zoom them. Sadly, most users don't care. By now it should be clear that too many users would choose a native app over a web app.
  4. We need to accept this. The longer we downplay the importance of performance of native app animations, the longer we fail. Animations that smoothly respond to gestures are not progressive enhancement on mobile, they are how users interact. Maybe not on very low-end devices, but I think it's wrong to bet the web on the low-end.
  5. The DOM is slow. I don't think you can argue against that. The only question is if it will get faster, which is what everyone seems to assume. "At some point, the DOM will be fast enough and the mobile web will start winning," they say. It's based on nothing. There's no indication the DOM will ever be fast enough, and if it does happen it's lightyears away on mobile. I've seen no technical description of a truly plausible way to make it significantly faster. This is like trying to optimize your rendering loop to render a model with a million polygons, when what you really need to do is reduce the number of polygons in your model.
  6. The DOM makes JavaScript slow. There are land mines in browser JavaScript that kill performance: DOM APIs. All of them are synchronous. If you touch the DOM, the entire JS engine may block for a while. If there's any indication that we are not working on the right solution here, it's that there's no work to make DOM APIs asynchronous, which if the first thing I'd do if we really want to try to make the DOM work. (edit: this statement was too bold. Recently those involved with standards have been looking at other solutions which may actually work out much better.) We need to guarantee that the JS event loop will run at 60 FPS which is impossible right now.
  7. The main thread should only do layout/rendering. Ideally even layout would be on a separate thread. But we need to guarantee that content will be painted at 60 FPS as well, and we can't do anything like image decoding, or especially run JavaScript, on the main thread. The DOM makes it really hard to do this, but asynchronous APIs are a step in the right direction.
  8. JavaScript-based animations are important, which is why all of this matters. You might wonder why off-thread CSS animations aren't working, and it's because there are tons of animations that you can't do with them. It's really hard to do gesture-based (or physics-based) animations with CSS. And besides, when animations are off-thread it introduces delays when trying to interrupt or cancel it.
  9. Maybe we need native support for ScrollViews? Instead of JavaScript-based animations, maybe we need better native support for common gesture-based interactions, like a scroll view that only renders fixed-height items within the view. Or moving an element around based on the finger. This would diminish the need to have custom JS-based solutions, but if you talk to any iOS/Android shop, you'll see how much customization goes into a high-end mobile app. They can "drop-down" into native code and write custom animations, but we can't drop-down like that.
  10. Servo is on the right track. This is the only project that's tackling this correctly. They are writing a parallel browser, where scripting, layout, and everything else run on separate threads. This will expose all the terrible parts of the current web, showing the points at which we stall the JavaScript event loop, or block rendering. This is perfectly summed up by their intention to make asynchronous versions of all the DOM APIs. Finally!
  11. Maybe the DOM is not the answer. The web is not the DOM. If the DOM doesn't work out, we should look for other solutions. At this point, any advanced app has to work against the DOM (see the whole React movement, which Ember is now copying, and others). The industry is crying out for something faster and more controllable than the DOM. Don't be religious about this.
  12. Lower-level APIs are going to be exposed. Work has already started on controlling the layout and measurement systems of browsers, see here. This might finally allow us to start experimenting with custom DOM-like solutions. I believe this is the direction we should be going. The Box Tree API is especially of interest.
  13. Accessibility is important. Once we start circumventing the DOM, we need to think about how to make our content accessible. Nothing shows that this is impossible, and it's obviously important for the web, so don't freak out. This might be way simpler than you think.

Prediction #1: In the next few years, we see a significant amount of effort to run web apps in web workers. Asynchronous APIs are created to interact with anything that runs on the main thread, like layout, storage, etc. is doing a lot of interesting research in this vein.

Prediction #2: React Native becomes so popular that a significant portion of web developers use it to write web/native apps. Attempts to mitigate the DOM by running apps in web workers fails to provide the experience of React Native because the DOM is still the bottleneck. By 2018, we see a big push for a collection of lower-level asynchronous APIs to do layout, rendering, and construct accessibility databases instead of using the DOM. Accessibility APIs allow the developer to apply roles to various parts of the layout.

Prediction #3: By 2020, A special mode for shared memory multi-threading becomes available in asm.js, with a fallback to a single-threaded cooperative mode if asm.js isn't specially recognized. This is far-fetched (and not based on any current work), but games are already pushing hard for this. We grant access to the lower-level rendering & layout APIs to a special asm.js subthread, giving developers the ability to construct advanced rendering engines with a dedicated rendering thread. Apps are written in JavaScript inside a web worker, and communicating with the asm.js code is made fast enough.

Categorieën: Mozilla-nl planet

Air Mozilla: Community Education Call - February 19th

Mozilla planet - to, 19/02/2015 - 20:00

Community Education Call - February 19th The Community Education Working Group exists to merge ideas, opportunities, efforts and impact across the entire project through Education & Training.

Categorieën: Mozilla-nl planet

Air Mozilla: Community Building Forum

Mozilla planet - to, 19/02/2015 - 20:00

Community Building Forum The Grow Mozilla Community Building Forum

Categorieën: Mozilla-nl planet

Will Kahn-Greene: Me: 2014 retrospective

Mozilla planet - to, 19/02/2015 - 17:20

This is belated because I've been busy.

2014 was crazy. It had a lot of epically lousy parts, but also had some good parts. Like 2013, I don't know what I did with my 2014 goals.

2013 involved a lot of projects. 2014 involved fewer.

  • dennis: Lots of development on Dennis. It's really come along as a tool, though I wish I had more users since that would help flesh out issues.
  • denise: A web front-end for dennis. I did some work on it, but it needs some more to remove some of the sharp edges.
  • ernest: Everyone has a Bugizlla front-end--this is mine. I work on this with Mike, Ricky and Rehan. We made some solid improvements in 2014. Having said that, it's still pretty hacked-together and it's not generally useful to anyone else.
  • denton: A bunch of us keep a log of what we've worked on day-to-day in Standup. Denton pulls the weekly data and throws it into an email. It doesn't sound like much, but it runs on a RHEL 5 system with an aged Python 2.6 and it's a pain in the ass to use. Given that, Denton has virtually no dependencies and sports its own (mildly terrible) template parser. It continues to be a mildly fun hobby project to tinker with periodically.
  • elasticutils: I did a ton of work on ElasticUtils so that people could use it and get over the Elasticsearch 0.90 -> 1.x hump. After talking with Honza, Jannis, Erik and Rob at PyCon US 2014, we decided it wasn't worth keeping ElasticUtils going. Honza built elasticsearch-dsl does some of the things ElasticUtils does, but better. Several Django-focused shim libraries that sit on elasticsearch-dsl have appeared since then. In January 2015, I deprecated the project and no longer work on it.
  • richard, steve and pyvideo: I did a bunch of work on these three right after PyCon US 2014 and then I totally burned out. Sheila took over admin of pyvideo. I tried to reduce my role to fixing architectural problems with richard and steve. I haven't spent much time on either, though. I'd like to spend more time on them, but now I'm having difficulties finding free time to spend. These projects are currently struggling.

I also spent time on a bunch of other projects:

  • peep: I helped a bunch on peep adding support for github tarball urls which we use a lot for Input and SUMO. I'm now a maintainer and help out with project maintenance.
  • django-ratelimit: James did an overhaul that I reviewed and helped with.
  • Sandstone: Schalk built this project as a Bootstrap version of Mozilla Sandstone look and feel. I was thinking I'd use it, but it seriously lacked documentation so I helped work on that for a while.
  • elasticsearch-dsl-py: I spent a portion of PyCon US 2014 sprints talking with Honza, Rob and Jannis about what I liked about ElasticUtils and we worked out parts of the elasticsearch-dsl-py API. Since then, I very occasionally comment on issues. I'd like to spend more time on this project, but Input and SUMO are still stuck on Elasticsearch 0.90, so I don't have anywhere to use it, yet.

At work, I spend most of my time on fjord which powers Mozilla Input.

2014 was interesting:

  • The sec-champs group fizzled out. I continue to help manage Django security updates across the various Mozilla web-sites. (Security)
  • I continue to work on l10n issues by improving the Dennis PO/POT linter. I also wrote Denise which anyone (particularly translators) can use without having to install Dennis. (L10N)
  • I got around to writing a site-health dashboard for Input. This makes it much easier to spot issues after deployments and code changes. (IT)
  • I wrote a smoketests test suite using Selenium for Input. This reduced goofs with feedback that we had periodically. (QA)
  • We set up Fjord to work with Vagrant. The vagrant provisioning script is a bash shell script and isn't idempotent which is a bit of a drag occasionally. However, this system has made it a lot easier for new people to contribute to Fjord/Input development. L. Guruprasad helped a ton here. (Community building)
  • I overhauled the feedback forms on Input making them more responsive, accessible and generally better. (UX/UI)
  • I wrote a translation system for Input which does automated machine and human translation. It's currently using Gengo, but the system is modular so we could write modules for other translation companies. This translates incoming feedback in non-English languages allowing our analysis tools to operate on everything in English. (Software engineering)
  • I started a Dashboards for Everyone project which coupled an API for querying feedback on Input with some examples using d3 for converting that code into dashboards. I thought this project would do a lot to alleviate peoples' needs for data, but as far as I can tell, it never caught on. (Software engineering)
  • Early in 2014, I started working on a data retention policy for Input data. Over the course of 2014, this policy gelled and was implemented. (Privacy)
  • In 2014, I committed to writing up project plans for the bigger Input projects and maintaining them in public. The thinking was that this lets other people follow along and correct missteps. Also we have a record of why we did certain things the way we did them. In reality, I don't think anyone really cared and/or looks at them. Still, it occasionally helps me, so that's probably good enough. (Project management)

Challenges for the year:

  • I think I'm easier to work with than I was in previous years. I spent some time fixing how I did things. Over the course of 2014, the indications that I was hard to work with have mostly disappeared. It's entirely possible that's because I switched projects and work with different people now. As a side note, User Advocacy group at Mozilla is amazing to work with.
  • I'm still working on too many things. I continued working on fixing this. I retired ElasticUtils which was taking a lot of time. I retired from working on playdoh, funfactory and friends. Still, there are projects I want to work on that I haven't/can't, so that bums me out.
  • Two roommates is still crazy. It'll be like that for a while, I think.
  • Wearing lots of hats on the Fjord/Input project really took a toll: project manager, architect, lead/solo developer, QA, deployer, ... I do it all. I learned I can do this, but that it's exhausting and I spent most of 2014 feeling overwhelmed and like I can't move fast enough. I really appreciate Ricky, Rehan and Mike helping with reviews and technical questions I have, else I would be sunk.

In 2015, I want to:

  • Spend time working on pyvideo, richard, dennis and ernest and get them to better places.
  • Overhaul my blog. Douglas is great, but the blog theme has issues and has since I last overhauled it in like the mid-2000s.
  • Find more time to tinker. I had like zero tinker time in 2014--it was just too crazy. No tinker means I'm falling behind (or at least feeling like I'm falling behind).
  • Blog more. I did a few impressive things. I wish I had blogged about them so that there's a record of me doing those things and also so that others could learn from my experiences. It's hard to find the time, though.

That's 2014 in a nutshell!

Categorieën: Mozilla-nl planet

Air Mozilla: Reps weekly

Mozilla planet - to, 19/02/2015 - 17:00

Reps weekly Weekly Mozilla Reps call

Categorieën: Mozilla-nl planet

Mozilla: Firefox-Chef Johnathan Nightingale geht - Heise Newsticker

Nieuws verzameld via Google - to, 19/02/2015 - 16:13

Heise Newsticker

Mozilla: Firefox-Chef Johnathan Nightingale geht
Heise Newsticker
März die Mozilla-Stiftung. Nightingale war bisher für die Entwicklung des Firefox-Browsers verantwortlich. Er sei sehr stolz auf das, "was wir alle erreicht haben", schreibt der "Vollzeit-Mozillian" Nightingale in seinem Blog. Seinen Abgang solle man ...
Mozilla: Firefox- und Cloud-Sparte werden
Firefox-Chefentwickler verlässt MozillaPC-Welt
Firefox-Chef verlässt
WinFuture -Pro-Linux
alle 10 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Firefox VP Departure Signals All's Not Well With Mozilla - Tech Times

Nieuws verzameld via Google - to, 19/02/2015 - 15:58

Tech Times

Firefox VP Departure Signals All's Not Well With Mozilla
Tech Times
Mozilla VP of Firefox Johnathan Nightingale is leaving his role as of March 31, citing he wants to spend more time with his family and get more involved in the Toronto technology sector. Mark Mayo will step into Nightingale's role. Mayo has led Mozilla ...
Mozilla's vice president of Firefox to leave the company next monthTechSpot
Departing Firefox chief takes shots at doomsayersComputerworld

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

Armen Zambrano: Pinning of mozharness completed

Mozilla planet - to, 19/02/2015 - 15:24
Yesterday we switched all jobs that use mozharness to use a specific changeset of mozharness instead of the production branch.

If you land mozharness code this affects you as you will have to:

  • land on the default branch
  • land a change on an integration branch to bump the revision of mozharness
    • only at that moment your code will be in use
In other words, buildduty is not anymore in charge to make your changes live.
Original post: Pinning mozharness from in-tree (aka mozharness.json)Bug: Bug 1110286Notice to newsgroups: dev.platform - dev.b2g

Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Categorieën: Mozilla-nl planet

Mozilla's vice president of Firefox to leave the company next month - TechSpot

Nieuws verzameld via Google - to, 19/02/2015 - 14:37


Mozilla's vice president of Firefox to leave the company next month
Johnathan Nightingale, Mozilla's vice president of Firefox, has announced that he will be leaving the company on March 31. He said that the move will not only help him spend more time with his family, but will also allow him to plant deeper roots in ...

Categorieën: Mozilla-nl planet

Both IE and Chrome Are to Support asm.js -

Nieuws verzameld via Google - to, 19/02/2015 - 12:33

Both IE and Chrome Are to Support asm.js
The modern.IE Platform Status indicates that now asm.js is in Development. According to Microsoft, the Chakra engine in Windows 10 will support asm.js, and Microsoft has been collaborating with Mozilla to implement it faster. Chrome is going to support ...

en meer »
Categorieën: Mozilla-nl planet

​Microsoft joins with Mozilla in bid for fast Web apps - CNET

Nieuws verzameld via Google - to, 19/02/2015 - 11:39


​Microsoft joins with Mozilla in bid for fast Web apps
That suited Mozilla just fine, since its mission was to promote the Web as an open foundation for computing. In recent years, to try to attract even more software to the Web, Mozilla created software called asm.js that's designed to accelerate certain ...
Microsoft's JavaScript Engine Will Soon Support Mozilla's Asm.jsTechCrunch
Microsoft enlists Mozilla to speed up JavaScript in Windows 10InfoWorld
Windows 10 to support asm.js in IE Chakra JS engineZDNet
alle 7 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Tess John: February 7:Sharing experience as an OPW intern at Mozilla Quality Assurance

Mozilla planet - to, 19/02/2015 - 11:30

Featured image

February 7 ,2015 has been a really special day in event life.I had shared my experience as an OPW intern at Mozilla Web Maker Party organised at Rajagiry School of Engineering and Technology,Kochi. Thank you Rebecca Billings for connecting me with the mozilla reps in my region and thanking Vigneshwar Dhinakaran  who trusted me to take the session.

It was my first ever conference in which I handled a session, and it was next to awesome.The maker party gave me an opportunity to network with other mozilla people at my region. Further in this post I shall my experience of the event.

I reached the venue at 9.00 a.m.and met Vigneshar Dhinakaran.Vigneshwar is the Mozilla rep and main organiser of the event.He proved to be friendly host and smart organizer. RSETians where waiting with enthusiasm to for the event.A few hours later I met another team of Mozilla reps who co-organised with Vigneshawar including Nidhya,Praveen,Abid.Praveen was GSOC intern in one of the previous round. Praveen blog is quite informative. Click here to read his blog

Featured image

The session started with transforming ideas into prototype,followed by an introduction to web technologies and mozilla web maker,after that Praveen and myself shared our experience as an intern at Mozilla and SMC(Swantantra Malayalam Computing).We spoke about opportunities like Google Summer Code OPW and Rails Girls  summer code.

We both explained our respective projects Oneanddone. It was interesting to know about his project  developing and adding support for Indic language layouts for Firefox OS.

Featured image

I spoke about the upcoming opw round, and gave some tips to get started.We  talked about  irc,encouraged them to subscribe to mailing list,use irc and learn github. We were able to help them in finding  resources for learning like openhatch,trygit etc.

We found that students really doesn’t get  a chance to contribute in open source projects. There is a popular misconception that open source projects has place only for highly skilled developers.We presented open source as a platform for developing skills.I gave  a brief description about how they can be a part of documentation,quality and testing etc.

To conclude open source is an important part of technical education.But students are not aware of  how they can contribute in open source. Providing them proper mentorship could help them bringing to forefront. Opportunities like OPW and GSOC could be a good dive into open source.To achieve this the mozilla reps has decided to organise a boot camp in the upcoming week.Stay tuned

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Winter of Security - Audit Go Project

Mozilla planet - to, 19/02/2015 - 05:04

Mozilla Winter of Security - Audit Go Project MWoS Audit Go presentation

Categorieën: Mozilla-nl planet

Mike Conley: The Joy of Coding (Episode 2)

Thunderbird - to, 19/02/2015 - 04:54

The second episode is up! We seem to have solved the resolution problem this time around – big thanks to Richard Milewski for his work there. This time, however, my microphone levels were just a bit low for the first half-hour. That’s my bad – I’ll make sure my gain is at the right level next time before I air.

Here are the notes for the bug I was working on.

And let me know if there’s anything else I can do to make these episodes more useful or interesting.

Categorieën: Mozilla-nl planet

Mike Conley: The Joy of Coding (Episode 2)

Mozilla planet - to, 19/02/2015 - 04:54

The second episode is up! We seem to have solved the resolution problem this time around – big thanks to Richard Milewski for his work there. This time, however, my microphone levels were just a bit low for the first half-hour. That’s my bad – I’ll make sure my gain is at the right level next time before I air.

Here are the notes for the bug I was working on.

And let me know if there’s anything else I can do to make these episodes more useful or interesting.

Categorieën: Mozilla-nl planet