mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Botond Ballo: C++ Concepts TS could be voted for publication on July 20

Mozilla planet - 1 uur 10 min geleden

In my report on the C++ standards meeting this May, I described the status of the Concepts TS as of the end of the meeting:

  • The committee’s Core Working Group (CWG) was working on addressing comments received from national standards bodies.
  • CWG planned to hold a post-meeting teleconference to complete the final wording including the resolutions of the comments.
  • The committee would then have the option of holding a committee-wide teleconference to vote the final wording for publication, or else delay this vote until the next face-to-face meeting in October.

I’m excited to report that the CWG telecon has taken place, final wording has been produced, and the committee-wide telecon to approve the final wording has been scheduled for July 20.

If this vote goes through, the final wording of the Concepts TS will be sent to ISO for publication, and the TS will be officially published within a few months!


Categorieën: Mozilla-nl planet

Mozilla delays Firefox 39 update over stability issue - Product Reviews

Nieuws verzameld via Google - 5 uur 42 min geleden

Product Reviews

Mozilla delays Firefox 39 update over stability issue
Product Reviews
Firefox 39 was finally meant to go out of beta, as its public release was due to be released yesterday for Android, Linux, Mac and Windows. However, Mozilla had to delay the Firefox 39 download because of a stability issue that plagued the browser at ...
Firefox 39 arrives with Hello link sharing, smoother animation and scrolling ...VentureBeat
Firefox 39 beta lets users link Hello to social accountsThe Next Web

alle 4 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Nicholas Nethercote: Firefox 41 will use less memory when running AdBlock Plus

Mozilla planet - 14 uur 11 min geleden

Last year I wrote about AdBlock Plus’s effect on Firefox’s memory usage. The most important part was the following.

First, there’s a constant overhead just from enabling ABP of something like 60–70 MiB. […] This appears to be mostly due to additional JavaScript memory usage, though there’s also some due to extra layout memory.

Second, there’s an overhead of about 4 MiB per iframe, which is mostly due to ABP injecting a giant stylesheet into every iframe. Many pages have multiple iframes, so this can add up quickly. For example, if I load TechCrunch and roll over the social buttons on every story […], without ABP, Firefox uses about 194 MiB of physical memory. With ABP, that number more than doubles, to 417 MiB.

An even more extreme example is this page, which contains over 400 iframes. Without ABP, Firefox uses about 370 MiB. With ABP, that number jumps to 1960 MiB.

(This description was imprecise; the overhead is actually per document, which includes both top-level documents in a tab and documents in iframes.)

Last week Mozilla developer Cameron McCormack landed patches to fix bug 77999, which was filed more than 14 years ago. These patches enable sharing of CSS-related data — more specifically, they add data structures that share the results of cascading user agent style sheets — and in doing so they entirely fix the second issue, which is the more important of the two.

For example, on the above-mentioned “extreme example” (a.k.a. the Vim Color Scheme Test) memory usage dropped by 3.62 MiB per document. There are 429 documents on that page, which is a total reduction of about 1,550 MiB, reducing memory usage for that page down to about 450 MiB, which is not that much more than when AdBlock Plus is absent. (All these measurements are on a 64-bit build.)

I also did measurements on various other sites and confirmed the consistent saving of ~3.6 MiB per document when AdBlock Plus is enabled. The number of documents varies widely from page to page, so the exact effect depends greatly on workload. (I wanted to test TechCrunch again, but its front page has been significantly changed so it no longer triggers such high memory usage.) For example, for one of my measurements I tried opening the front page and four articles from each of nytimes.com, cnn.com and bbc.co.uk, for a total of 15 tabs. With Cameron’s patches applied Firefox with AdBlock Plus used about 90 MiB less physical memory, which is a reduction of over 10%.

Even when AdBlock Plus is not enabled this change has a moderate benefit. For example, in the Vim Color Scheme Test the memory usage for each document dropped by 0.09 MiB, reducing memory usage by about 40 MiB.

If you want to test this change out yourself, you’ll need a Nightly build of Firefox and a development build of AdBlock Plus. (Older versions of AdBlock Plus don’t work with Nightly due to a recent regression related to JavaScript parsing). In Firefox’s about:memory page you’ll see the reduction in the “style-sets” measurements. You’ll also see a new entry under “layout/rule-processor-cache”, which is the measurement of the newly shared data; it’s usually just a few MiB.

This improvement is on track to make it into Firefox 41, which is scheduled for release on September 22, 2015. For users on other release channels, Firefox 41 Beta is scheduled for release on August 11, and Firefox 41 Developer Edition is scheduled to be released in the next day or two.

Categorieën: Mozilla-nl planet

Mark Banner: Firefox Hello Desktop: Behind the Scenes – UI Showcase

Mozilla planet - 16 uur 38 min geleden

This is the third of some posts I’m writing about how we implement and work on the desktop and standalone parts of Firefox Hello. You can find the previous posts here.

The Showcase

One of the most useful parts of development for Firefox Hello is the User Interface (UI) showcase. Since all of the user interface for Hello is written in html and JavaScript, and is displayed in the content scope, we are able to display them within a “normal” web page with very little adjustment.

So what we do is to put almost all our views onto a single html page at representative sizes. The screen-shot below shows just one view from the page, but those buttons at the top give easy access, and in reality there’s lots of them (about 55 at the time of writing).

UI Showcase showing a standalone (link-clicker) view

UI Showcase showing a standalone (link-clicker) view

Faster Development

The showcase has various advantages that help us develop faster:

  • Since it is a web page, we have all the developer tools available to us – inspector, css layout etc.
  • We don’t have to restart Firefox to pick up changes to the layout, nor do we have to recompile – a simple reload of the page is enough to pick up changes.
  • We also don’t have to go through the flow each time, e.g. if we’re changing some of the views which show the media (like the one above), we avoid needing to go through the conversation setup routines for each code/css change until we’re pretty sure its going to work the way we expect.
  • Almost all the views are shown – if the css is broken for one view its much easier to detect it than having to go through the user flow to get to the view you want.
  • We’ve recently added an RTL mode so that we can easily see what the views look like in RTL languages. Hence no awkward forcing of Firefox into RTL mode to check the views.

There’s one other “feature” of the showcase as we’ve got it today – we don’t pick up the translated strings, but rather the raw string label. This tends to give us longer strings than are used normally for English, which it turns out is an excellent way of being able to detect some of the potential issues for locales which need longer strings.

Structure of the showcase

The showcase is a series of iframes. We load individual react components into each iframe, sometimes loading the same component multiple times with different parameters or stores to get the different views. The rest of the page is basically just structure around display of the views.

The iframes does have some downsides – you can’t live edit css in the inspector and have it applied across all the views, but that’s minor compared to the advantages we get from this one page.

Future improvements

We’re always looking for ways we can improve how we work on Hello. We’ve recently improved the UI showcase quite a bit, so I don’t think we have too much on our outstanding list at the moment.

The only thing I’ve just remembered is that we’ve commented it would be nice to have some sort of screen-shot comparison, so that we can make changes and automatically check for side-effects on other views.

We’d also certainly be interested in hearing about similar tools which could do a similar job – sharing and re-using code is definitely a win for everyone involved.

Interested in learning more?

If you’re interested in learning more about the UI-showcase, then you can find the code here, try it out for yourself, or come and ask us questions in #loop on irc.

If you want to help out with Hello development, then take a look at our wiki pages, our mentored bugs or just come and talk to us.

Categorieën: Mozilla-nl planet

Roberto A. Vitillo: Spark best practices

Mozilla planet - di, 30/06/2015 - 18:56

We have been running Spark for a while now at Mozilla and this post is a summary of things we have learned about tuning and debugging Spark jobs.

Spark execution model

Spark’s simplicity makes it all too easy to ignore its execution model and still manage to write jobs that eventually complete. With larger datasets having an understanding of what happens under the hood becomes critical to reduce run-time and avoid out of memory errors.

Let’s start by taking our good old word-count friend as starting example:

rdd = sc.textFile("input.txt")\       .flatMap(lambda line: line.split())\       .map(lambda word: (word, 1))\       .reduceByKey(lambda x, y: x + y, 3)\ .collect()

RDD operations are compiled into a Direct Acyclic Graph of RDD objects, where each RDD points to the parent it depends on:

DAGFigure 1

At shuffle boundaries, the DAG is partitioned into so-called stages that are going to be executed in order, as shown in figure 2. The shuffle is Spark’s mechanism for re-distributing data so that it’s grouped differently across partitions. This typically involves copying data across executors and machines, making the shuffle a complex and costly operation.

stagesFigure 2

To organize data for the shuffle, Spark generates sets of tasks – map tasks to organize the data and reduce tasks to aggregate it. This nomenclature comes from MapReduce and does not directly relate to Spark’s map and reduce operations. Operations within a stage are pipelined into tasks that can run in parallel, as shown in figure 3.

tasksFigure 3

Stages, tasks and shuffle writes and reads are concrete concepts that can be monitored from the Spark shell. The shell can be accessed from the driver node on port 4040, as shown in figure 4.

shellFigure 4 Best practices

Spark Shell

Running Spark jobs without the Spark Shell is like flying blind. The shell allows to monitor and inspect the execution of jobs. To access it remotely a SOCKS proxy is needed as the shell connects also to the worker nodes.

Using a proxy management tool like FoxyProxy allows to automatically filter URLs based on text patterns and to limit the proxy settings to domains that match a set of rules. The browser add-on automatically handles turning the proxy on and off when you switch between viewing websites hosted on the master node, and those on the Internet.

Assuming that you launched your Spark cluster with the EMR service on AWS, type the following command to create a proxy:

ssh -i ~/mykeypair.pem -N -D 8157 hadoop@ec2-...-compute-1.amazonaws.com

Finally, import the following configuration into FoxyProxy:

<?xml version="1.0" encoding="UTF-8"?> <foxyproxy>   <proxies>     <proxy name="emr-socks-proxy" notes="" fromSubscription="false" enabled="true" mode="manual" selectedTabIndex="2" lastresort="false" animatedIcons="true" includeInCycle="true" color="#0055E5" proxyDNS="true" noInternalIPs="false" autoconfMode="pac" clearCacheBeforeUse="false" disableCache="false" clearCookiesBeforeUse="false" rejectCookies="false">       <matches>         <match enabled="true" name="*ec2*.amazonaws.com*" pattern="*ec2*.amazonaws.com*" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />         <match enabled="true" name="*ec2*.compute*" pattern="*ec2*.compute*" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />         <match enabled="true" name="10.*" pattern="http://10.*" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />         <match enabled="true" name="*10*.amazonaws.com*" pattern="*10*.amazonaws.com*" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />         <match enabled="true" name="*10*.compute*" pattern="*10*.compute*" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />         <match enabled="true" name="*localhost*" pattern="*localhost*" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />       </matches>       <manualconf host="localhost" port="8157" socksversion="5" isSocks="true" username="" password="" domain="" />     </proxy>   </proxies> </foxyproxy>

Once the proxy is enabled you can open the Spark Shell by visiting localhost:4040.

Use the right level of parallelism

Clusters will not be fully utilized unless the level of parallelism for each operation is high enough. Spark automatically sets the number of partitions of an input file according to its size and for distributed shuffles, such as groupByKey and reduceByKey, it uses the largest parent RDD’s number of partitions. You can pass the level of parallelism as a second argument to an operation. In general, 2-3 tasks per CPU core in your cluster are recommended. That said, having tasks that are too small is also not advisable as there is some overhead paid to schedule and run a task.

As a rule of thumb tasks should take at least 100 ms to execute; you can ensure that this is the case by monitoring the task execution latency from the Spark Shell. If your tasks take considerably longer than that keep increasing the level of parallelism, by say 1.5, until performance stops improving.

Reduce working set size

Sometimes, you will get terrible performance or out of memory errors, because the working set of one of your tasks, such as one of the reduce tasks in groupByKey, was too large. Spark’s shuffle operations (sortByKey, groupByKey, reduceByKey, join, etc) build a hash table within each task to perform the grouping, which can often be large.

Even though those tables spill to disk, getting to the point where the tables need to be spilled increases the memory pressure on the executor incurring the additional overhead of disk I/O and increased garbage collection. If you are using pyspark, the memory pressure will also increase the chance of Python running out of memory.

The simplest fix here is to increase the level of parallelism, so that each task’s input set is smaller.

Avoid groupByKey for associative operations

Both reduceByKey and groupByKey can be used for the same purposes but reduceByKey works much better on a large dataset. That’s because Spark knows it can combine output with a common key on each partition before shuffling the data.

In reduce tasks, key-value pairs are kept in a hash table that can spill to disk, as mentioned in “Reduce working set size“. However, the hash table flushes out the data to disk one key at a time. If a single key has more values than can fit in memory, an out of memory exception occurs. Pre-combining the keys on the mappers before the shuffle operation can drastically reduce the memory pressure and the amount of data shuffled over the network.

Avoid reduceByKey when the input and output value types are different

Consider the job of creating a set of strings for each key:

rdd.map(lambda p: (p[0], {p[1]}))\     .reduceByKey(lambda x, y: x | y)\     .collect()

Note how the input values are strings and the output values are sets. The map operation creates lots of temporary small objects. A better way to handle this scenario is to use aggregateByKey:

def seq_op(xs, x):     xs.add(x)     return xs def comb_op(xs, ys):     return xs | ys rdd.aggregateByKey(set(), seq_op, comb_op).collect()

Avoid the flatMap-join-groupBy pattern

When two datasets are already grouped by key and you want to join them and keep them grouped, you can just use cogroup. That avoids all the overhead associated with unpacking and repacking the groups.

Python memory overhead

The spark.executor.memory option, which determines the amount of memory to use per executor process, is JVM specific. If you are using pyspark you can’t set that option to be equal to the total amount of memory available to an executor node as the JVM might eventually use all the available memory leaving nothing behind for Python.

Use broadcast variables

Using the broadcast functionality available in SparkContext can greatly reduce the size of each serialized task, and the cost of launching a job over a cluster. If your tasks use any large object from the driver program, like a static lookup table, consider turning it into a broadcast variable.

Cache judiciously

Just because you can cache a RDD in memory doesn’t mean you should blindly do so. Depending on how many times the dataset is accessed and the amount of work involved in doing so, recomputation can be faster than the price paid by the increased memory pressure.

It should go without saying that if you only read a dataset once there is no point in caching it, i it will actually make your job slower. The size of cached datasets can be seen from the Spark Shell.

Don’t collect large RDDs

When a collect operation is issued on a RDD, the dataset is copied to the driver, i.e. the master node. A memory exception will be thrown if the dataset is too large to fit in memory; take or takeSample can be used to retrieve only a capped number of elements instead.

Minimize amount of data shuffled

A shuffle is an expensive operation since it involves disk I/O, data serialization, and network I/O. As illustrated in figure 3, each reducer in the second stage has to pull data across the network from all the mappers.

As of Spark 1.3, these files are not cleaned up from Spark’s temporary storage until Spark is stopped, which means that long-running Spark jobs may consume all available disk space. This is done in order to don’t re-compute shuffles.

Know the standard library

Avoid re-implementing existing functionality as it’s guaranteed to be slower.

Use dataframes

A DataFrame is a distributed collection of data organized into named columns. It is conceptually equivalent to a table in a relational database or a pandas Dataframe in Python.

props = get_pings_properties(pings,                              ["environment/system/os/name",                               "payload/simpleMeasurements/firstPaint",                               "payload/histograms/GC_MS"],                              only_median=True) frame = sqlContext.createDataFrame(props.map(lambda x: Row(**x))) frame.groupBy("environment/system/os/name").count().show()

yields:

environment/system/os/name count Darwin 2368 Linux 2237 Windows_NT 105223

Before any computation on a DataFrame starts, the Catalyst optimizer compiles the operations that were used to build the DataFrame into a physical plan for execution. Since the optimizer generates JVM bytecode for execution, pyspark users will experience the same high performance as Scala users.


Categorieën: Mozilla-nl planet

Michael Kaply: The End of Firefox 31 ESR

Mozilla planet - di, 30/06/2015 - 18:03

With the release of Firefox 39 today also comes the final release of the Firefox 31 ESR (barring any security updates in the next six weeks).
That means you have six weeks to manage your switch over to the Firefox 38 ESR.

If you've been wondering if you should use the ESR instead of keeping up with current Firefox releases, now might be a good time to switch. That's because there are a couple features coming in the Firefox mainline that might affect you. These include the removal of the distribution/bundles directory as well as the requirement for all add-ons to be signed by Mozilla.

It's much easier going from Firefox 38 to the Firefox 38 ESR then going from Firefox 39 to the Firefox 38 ESR.

If you want to continue on the Firefox mainline, you can use the CCK2 to bring back some of the distribution/bundles functionality, but I won't be able to do anything about the signing requirement.

Categorieën: Mozilla-nl planet

Mark Banner: Firefox Hello Desktop: Behind the Scenes – Architecture

Mozilla planet - di, 30/06/2015 - 15:39

This is the second of some posts I’m writing about how we implement and work on the desktop and standalone parts of Firefox Hello. The first post was about our use of Flux and React, this second post is about the architecture.

In this post, I will give an overview of the Firefox browser software architecture for Hello, which includes the standalone UI.

User-visible parts of Hello

Although there’s many small parts to Hello, most of it is shaped by what is user visible:

Firefox Hello Desktop UI (aka Link-Generator)

Hello Standalone UI (aka Link-clicker)

Firefox Browser Architecture for Hello

The in-browser part of Hello is split into three main areas:

  • The panel which has the conversation and contact lists. This is a special about: page that is run in the content process with access to additional privileged APIs.
  • The conversation window where conversations are held. Within this window, similar to the panel, is another about: page that is also run in the content process.
  • The backend runs in the privileged space within gecko. This ties together the communication between the panels and conversation windows, and provides access to other gecko services and parts of the browser to which Hello integrates.
Outline of Hello's Desktop Architecture

Outline of Hello’s Desktop Architecture

MozLoopAPI is our way of exposing small bits of the privileged gecko (link) code to the about: pages running in content. We inject a navigator.mozLoop object into the content pages when they are loaded. This allows various functions and facilities to be exposed, e.g. access to a backend cache of the rooms list (which avoids multiple caches per window), and a similar backend store of contacts.

Standalone Architecture

The Standalone UI is simply a web page that’s shown in any browser when a user clicks a conversation link.

The conversation flow is in the standalone UI is very similar to that of the conversation window, so most of the stores and supporting files are shared. Most of the views for the Standalone UI are currently different to those from the desktop – there’s been a different layout, so we need to have different structures.

Outline of Hello's Standalone UI Architecture

Outline of Hello’s Standalone UI Architecture

File Architecture as applied to the code

The authoritative location for the code is mozilla-central it lives in the browser/components/loop directory. Within that we have:

  • content/ – This is all the code relating to the panel and conversation window that is shipped on in the Firefox browser
  • content/shared/ – This code is used on browser as well as on the standalone UI
  • modules/ – This is the backend code that runs in the browser
  • standalone/ – Files specific to the standalone UI

Future Work

There’s a couple of likely parts of the architecture that we’re going to rework soon.

Firstly, with the current push to electrolysis, we’re replacing the current exposed MozLoopAPI with a message-based RPC mechanism. This will then let us run the panel and conversation window in the separated content process.

Secondly, we’re currently reworking some of the UX and it is moving to be much more similar between desktop and standalone. As a result, we’re likely to be sharing more of the view code between the two.

Interested in learning more?

If you’re interested in learning more about Hello’s architecture, then feel free to dig into the code, or come and ask us questions in #loop on irc.

If you want to help out with Hello development, then take a look at our wiki pages, our mentored bugs or just come and talk to us.

Categorieën: Mozilla-nl planet

About:Community: Firefox 39 new contributors

Mozilla planet - di, 30/06/2015 - 14:45

With the release of Firefox 39, we are pleased to welcome the 64 developers who contributed their first code change to Firefox in this release, 55 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

  • agrigas: 1135270
  • bmax1337: 967319
  • leo: 1134993
  • schtroumps31: 1130045
  • zmiller12: 1138873
  • George Duan: 1135293
  • Abhinav Koppula: 732688, 951695, 1127337
  • Alex Verstak: 1113431, 1144816
  • Alexandre Ratchov: 1144087
  • Andrew Overholt: 1127552
  • Anish: 1135091, 1135383
  • Anush: 418517, 1113761
  • Bhargav Chippada: 1112605, 1130372
  • Boris Kudryavtsev: 1135364, 1144613
  • Cesar Guirao: 1139132
  • Chirag Bhatia: 1133211
  • Danilo Cesar Lemes de Paula: 1146020
  • Daosheng Mu: 1133391
  • Deepak: 1039540
  • Felix Janda: 1130164, 1130175
  • Gareth Aye: 1145310
  • Geoffroy Planquart: 942475, 1042859
  • Gerald Squelart: 1121774, 1135541, 1137583
  • Greg Arndt: 1142779
  • Henry Addo: 1084663
  • Jason Gersztyn: 1132673
  • Jeff Griffiths: 1138545
  • Jeff Lu: 1098415, 1106779, 1140044
  • Johan K. Jensen: 1096294
  • Johannes Vogel: 1139594
  • John Giannakos: 1134568
  • John Kang: 1144782, 1146252
  • Jorg K: 756984
  • Kyle Thomas: 1137004
  • Léon McGregor: 1115925, 1130741, 1136708
  • Manraj Singh [:manrajsingh|Away till 21st June]: 1120408
  • Mantaroh Yoshinaga: 910634, 1106905, 1130614
  • Markus Jaritz: 1139174
  • Massimo Gervasini: 1137756, 1144695
  • Matt Hammerly: 1124271
  • Matt Spraggs: 1036454
  • Michael Weisz : 736572, 782623, 935434
  • Mitchell Field: 987902
  • Mohamed Waleed: 1106938
  • NiLuJe: 1143411
  • Perry Wagle: 1122941
  • Ponç Bover: 1126978
  • Quentin Pradet: 1092544
  • Ravi Shankar: 1109608
  • Rishi Baldawa: 1143196
  • Stéphane SCHMIDELY: 935259, 1144619
  • Sushrut Girdhari (sg345): 1137248
  • Thomas Baquet: 1132078
  • Titi_Alone : 1133063
  • Tyler St. Onge: 1134927
  • Vaibhav Bhosale: 1135009
  • Vidit23: 1121317
  • Wickie Lee: 1136253
  • Zimon Dai: 983469, 1135435
  • atlanto: 1137615
  • farhaan: 1073234
  • pinjiz: 1124943, 1142260, 1142268
  • qasim: 1123431
  • ronak khandelwal: 1122767
  • uelis: 1047529
  • Categorieën: Mozilla-nl planet

    Andy McKay: Cycling

    Mozilla planet - di, 30/06/2015 - 09:00

    In January I finally decided to do something I'd wanted to do in a long time and that's the Gran Fondo from Vancouver to Whistler.

    I've been cycling for a while too and from work, but it was time to get more serious and hopefully lose some weight in the process. So I signed up and September I'll be racing up to Whistler with a few thousand other people.

    Last Saturday I was in Whistler for the Mozilla work week. I got to do some riding, including a quick trip to Pemberton:

    I had the opportunity to ride down from Whistler as a practice. I've enjoyed my cycling, but I looked at this ride with a mixture of anticipation and dread.

    Getting back is a 135.8km ride that looks like this:

    It also meant hanging out at a party with Mozilla on top of the mountain without drinking very much. Something that, if you know me, I tend to find a little difficult.

    As it turns out the ride was great fun. Riding in the sun with views of the Elaho and Howe Sound. The main annoyance was when I had stop for a traffic light in Squamish after so long of continually cycling.

    After Horseshoe Bay I got flat a tyre. When I cycle to and from work I don't carry spares - if anything happens I got on a bus. Repeating that was an error, but fortunately multiple people kindly stopped and offered to help. About 15 minutes later I was up and cycling again.

    Later on, as I was crossing North Vancouver with some other people, a truck pulled up besides us and shouted "You're doing 39km/h!". Somehow after 5 hours on the road I was still having fun and cycling fast.

    I've gone from doing a few days a week, to over 300k on a bike a week and still loving it. I've gone from just being happy to get to Whistler alive to thinking about setting a time for my race. We'll see how that goes.

    Categorieën: Mozilla-nl planet

    Firefox 41: Mozilla optimiert Speicherverbrauch für Adblock Plus-Nutzer - soeren-hentzschel.at

    Nieuws verzameld via Google - di, 30/06/2015 - 02:52

    Firefox 41: Mozilla optimiert Speicherverbrauch für Adblock Plus-Nutzer
    soeren-hentzschel.at
    Werbeblocker sind eine praktische Erfindung, kommen aber zu einem Preis: sie benötigen Ressourcen, teilweise nennenswert mehr als andere Add-ons. Nutzer von Adblock Plus können sich auf eine Optimierung in Firefox 41 freuen, welche besonders ...

    Google Nieuws
    Categorieën: Mozilla-nl planet

    Karl Dubost: Watch A Computing Engineer Live Coding

    Mozilla planet - di, 30/06/2015 - 00:33

    Mike (Taylor) has been telling me about the live coding session of Mike Conley for a little while. So yesterday I decided to give it a try with the first episode of The Joy of Coding (mconley livehacks on Firefox). As mentionned in the description:

    Unscripted, unplanned, uncensored, and true to life, watch what a Firefox Desktop engineer does to close bugs and get the job done.

    And that is what is written on the jar. And sincerely this is good.

    Why Should You Watch Live Coding?

    I would recommend to watch this for:

    • Beginner devs: To understand that more experienced developers struggle and make mistakes too. To also learn a couple of good practices when coding.
    • Experienced devs: To see how someone is coding and learn a couple of new tricks and habits when coding. To encourage them to do the same kind of things than Mike is doing.
    • Managers: You are working as a manager in a Web agency, you are a project manager, watch this. You will not understand most of it, but focus exactly on what Mike is doing in terms of thoughts process and work organization. Even without a knowledge of programming, we discover the struggles, the trials and errors, and the success.

    There's a full series of them, currently 19.

    My Own (Raw) Notes When Watching The Video
    • Watching the first video of Live Coding
    • He started with 3 video scenes and switched to his main full screen
    • He's introducing himself
    • mconley: "Nothing is prepared"
    • He's introducing the bug and explained it in demonstrating it
    • mconley: "I like to take notes when working on bugs" (taken in evernote)
    • mconley: "dxr is better than mxr."
    • He's not necessary remembering everything. So he goes through other parts of the code to understand what others did.
    • Sometimes he just doesn't know, doesn't understand and he says it.
    • mconley: "What other people do?"
    • He's taking notes including some TODOs for the future to explore, understand, do.
    • He's showing his fails in compiling, in coding, etc.
    • (personal thoughts) It's hard to draw on a computer. Paper provides some interesting features for quickly drawing something. Computer loses, paper wins.
    • When recording, thinking with a loud voice gives context on what is happening.
    • Write comments in the code for memory even if you remove them later.
    • In your notes, cut and paste the code from the source. Paper loses, computer wins.
    • (personal thoughts): C++ code is ugly to read.
    • (personal thoughts): Good feeling for your own job after watching this. It shows you are not the only one struggling when doing stuff.
    Some Additional Thoughts

    We met Mike Conley in Whistler, Canada last week. He explained he used Open Broadcasting Project for recording his sessions. I'm tempted to do something similar for Web Compatibility work. I'm hesitating in between French and English. Maybe if Mike was doing something in English, I might do it in French. So people in the French community could benefit of it.

    So thanks Mike for telling me about this in the last couple of weeks.

    Otsukare!

    Categorieën: Mozilla-nl planet

    Air Mozilla: DXR 2.0 (Part 2: Discussion)

    Mozilla planet - ma, 29/06/2015 - 22:44

     Discussion) A discussion of the roadmap for DXR after 2.0

    Categorieën: Mozilla-nl planet

    Air Mozilla: DXR 2.0 (Part 1: Dog & Pony Show)

    Mozilla planet - ma, 29/06/2015 - 22:33

     Dog & Pony Show) Demo of features new in the upcoming 2.0 release of DXR, Mozilla's search and analysis tool for large codebases

    Categorieën: Mozilla-nl planet

    Daniel Glazman: CSS Working Group's future

    Mozilla planet - ma, 29/06/2015 - 20:52

    Hello everyone.

    Back in March 2008, I was extremely happy to announce my appointment as Co-chairman of the CSS Working Group. Seven years and a half later, it's time to move on. There are three main reasons to that change, that my co-chair Peter and I triggered ourselves with W3C Management's agreement:

    1. We never expected to stay in that role 7.5 years. Chris Lilley chaired the CSS Working Group 1712 days from January 1997 (IIRC) to 2001-oct-10 and that was at that time the longest continuous chairing in W3C's history. Bert Bos chaired it 2337 days from 2001-oct-11 to 2008-mar-05. Peter and I started co-chairing it on 2008-mar-06 and it will end at TPAC 2015. That's 2790 days so 7 years 7 months and 20 days! I'm not even sure those 2790 days hold a record, Steven Pemberton probably chaired longer. But it remains that our original mission to make the WG survive and flourish is accomplished, and we now need fresher blood. Stability is good, but smart evolution and innovation are better.
    2. Co-chairing a large, highly visible Working Group like the CSS Working Group is not a burden, far from it. But it's not a light task either. We start feeling the need for a break.
    3. There were good candidates for the role, unanimously respected in the Working Group.

    So the time has come. The new co-chairs, Rossen Atanassov from Microsoft and Alan Stearns from Adobe, will take over during the Plenary Meeting of the W3C held in Sapporo, japan, at the end of October and that is A Good Thing™. You'll find below a copy of my message to W3C.

    To all the people I've been in touch with while holding my co-chair's hat: thank you, sincerely and deeply. You, the community around CSS, made everything possible.

    Yours truly.

    Dear Tim, fellow ACs, fellow Chairs, W3C Staff, CSS WG Members,

    After seven years and a half, it's time for me to pass the torch of the CSS Working Group's co-chairmanship. 7.5 years is a lot and fresh blood will bring fresh perspectives and new chairing habits. At a time the W3C revamps its activities and WGs, the CSS Working Group cannot stay entirely outside of that change even if its structure, scope and culture are retained. Peter and I decided it was time to move on and, with W3M's agreement, look for new co-chairs.

    I am really happy to leave the Group in Alan's and Rossen's smart and talented hands, I'm sure they will be great co-chairs and I would like to congratulate and thank them for accepting to take over. I will of course help the new co-chairs on request for a smooth and easy transition, and I will stay in the CSS WG as a regular Member.

    I'd like to deeply thank Tim for appointing me back in 2008, still one of the largest surprises of my career!

    I also wish to warmly thank my good friends Chris Lilley, Bert Bos and Philippe Le Hégaret from W3C Staff for their crucial daily support during all these years. Thank you Ralph for the countless transition calls! I hope the CSS WG still holds the record for the shortest positive transition call!

    And of course nothing would have been possible without all the members of the CSS Working Group, who tolerated me for so long and accepted the changes we implemented in 2008, and all our partners in the W3C (in particular the SVG WG) or even outside of it, so thank you all. The Membership of the CSS WG is a powerful engine and, as I often say, us co-chairs have only been a drop of lubricant allowing that engine to run a little bit better, smoother and without too much abrasion.

    Last but not least, deep thanks to my co-chair and old friend Peter Linss for these great years; I accepted that co-chair's role to partner with Peter and enjoyed every minute of it. A long ride but such a good one!

    I am confident the CSS Working Group is and will remain a strong and productive Group, with an important local culture. The CSS Working Group has both style and class (pun intended), and it has been an honour to co-chair it.

    Thank you.

    </Daniel>

    Categorieën: Mozilla-nl planet

    Air Mozilla: Mozilla Weekly Project Meeting

    Mozilla planet - ma, 29/06/2015 - 20:00

    Mozilla Weekly Project Meeting The Monday Project Meeting

    Categorieën: Mozilla-nl planet

    Mozilla WebDev Community: Beer and Tell – June 2015

    Mozilla planet - ma, 29/06/2015 - 19:59

    Once a month, web developers from across the Mozilla Project get together to try and transmute a fresh Stanford graduate into a 10x engineer. Meanwhile, we find time to talk about our side projects and drink, an occurrence we like to call “Beer and Tell”.

    There’s a wiki page available with a list of the presenters, as well as links to their presentation materials. There’s also a recording available courtesy of Air Mozilla.

    Osmose: SpeedKills and Advanced Open File

    First up was Osmose (that’s me!) presenting two packages for Atom, a text editor. SpeedKills is a playful package that plays a guitar solo and sets text on fire when the user types fast enough. Advanced Open File is a more useful package that adds a convenient dialog for browsing the file system and opening files by path rather than using the fuzzy finder. Both are available for install through the Atom package repository.

    new_one: Tab Origin

    Next was new_one, who shared Tab Origin, a Firefox add-on that lets you return to the webpage that launched the current tab, even if the parent tab has since been closed. It’s activated via a keyboard shortcut that can be customized.

    Potch: WONTFIX and Presentation Mode

    Continuing a fine tradition of batching projects, Potch stopped by to show off two Firefox add-ons. The first was WONTFIX, which adds a large red WONTFIX stamp to any Bugzilla bug that has been marked as WONTFIX. The second was Presentation Mode, which allows you to full-screen any content in a web page while hiding the browser chrome. This is especially useful when giving web-based presentations.

    Peterbe: premailer.io

    Peterbe shared premailer.io, which is a service wrapping premailer. Premailer takes a block of HTML with a style tag and applies the styles within as style attributes on each matching tag. This is mainly useful for HTML emails, which generally don’t support style tags that apply to the entire email.

    ErikRose: Spam-fighting Tips

    ErikRose learned a lot about the current state of spam-fighting while redoing his mail server:

    • Telling Postfix to be picky about RFCs is a good first pass. It eliminates some spam without having to do much computation.
    • spamassassin beats out dspam, which hasn’t seen an update since 2012.
    • Shared-digest detectors like Razor help a bit but aren’t sufficient on their own without also greylisting to give the DBs a chance to catch up.
    • DNS blocklists are a great aid: they reject 3 out of 4 spams without taking much CPU.
    • Bayes is still the most reliable (though the most CPU-intense) filtration method. Bayes poisoning is infeasible, because poisoners don’t know what your ham looks like, so don’t worry about hand-picking spam to train on. Train on an equal number of spams and hams: 400 of each works well. Once your bayes is performing well, crank up your BAYES_nn settings so spamassassin believes it.
    • Crank up spamc’s –max-size to 1024000, because spammers are now attaching images > 512K to mails to bypass spamc’s stock 512K threshold. This will cost extra CPU.

    With this, he gets perhaps a spam a week, with over 400 attempts per day.

    We were only able to get a 3x engineer this month, but at least they were able to get a decent job working on enterprise software.

    If you’re interested in attending the next Beer and Tell, sign up for the dev-webdev@lists.mozilla.org mailing list. An email is sent out a week beforehand with connection details. You could even add yourself to the wiki and show off your side-project!

    See you next month!

    Categorieën: Mozilla-nl planet

    Mozilla Security Blog: Dharma

    Mozilla planet - ma, 29/06/2015 - 19:54


    dharma

    As soon as a developer at Mozilla starts integrating a new WebAPI feature, the Mozilla Security team begins working to help secure that API. Subtle programming mistakes in new code can introduce annoying crashes and even serious security vulnerabilities that can be triggered by malformed input which can lead to headaches for the user and security exposure.

    WebAPIs start life as a specification in the form of an Interface Description Language, or IDL. Since this is essentially a grammar, a grammar-based fuzzer becomes a valuable tool in finding security issues in new WebAPIs because it ensures that expected semantics are followed most of the time, while still exploring enough undefined behavior to produce interesting results.

    We came across a grammar fuzzer Ben Hawkes released in 2011 called “Dharma.” Sadly, only one version was ever made public. We liked Ben’s approach, but Dharma was missing some features which were important for us and its wider use for API fuzzing. We decided to sit down with our fuzzing mates at BlackBerry and rebuild Dharma, giving the results back to the public, open source and licensed as MPL v2.

    We redesigned how Dharma parses grammars and optimized the speed of parsing and the generating of fuzzed output, added new grammar features to the grammar specification, added support for serving testcases over a WebSocket server, and made it Python 3 ready. It comes with no dependencies and runs out of the box.

    In theory Dharma can be used with any data that can be represented as a grammar. At Mozilla we typically use it for APIs like WebRTC, WebAudio, or WebCrypto.


    dharma_demo

    Dharma has no integrated harness. Feel free to check out the Quokka project which provides an easy way for launching a target with Dharma, monitoring the process and bucketing any faults.

    Dharma is actively in use and maintained at Mozilla and more features are planned for the future. Ideas for improvements are always greatly welcomed.

    Dharma is available via GitHub (preferred and always up-to-date) or via PyPi by running “pip install dharma”.

    References
    https://github.com/mozillasecurity/dharma
    https://github.com/mozillasecurity/quokka
    https://code.google.com/p/dharma/

    Categorieën: Mozilla-nl planet

    Aaron Thornburgh: Not Working in Whistler

    Mozilla planet - ma, 29/06/2015 - 18:06
    A brief retrospective Whistler Rock - Shot with my Moto X 2nd Gen

    I just returned from Whistler, BC, along with 1300 other Mozillians.

    Because we’re a global organization, it’s important to get everyone together every now and then. We matched faces with IRC channels, talked shop over finger-food, and went hiking with random colleagues. Important people gave speeches. Teams aligned. There was a massive party at the top of a mountain.

    +++++

    Typically, I learn the most from experiences like these only after they have ended. Now that I’ve had 48 hours to process (read: recover), some themes have emerged…

    1. Organizing and mobilizing a bunch of smart, talented, opinionated people is hard work.
    2. It’s easy to say “you’re doing it wrong.” It takes courage to ask “how could we do it better?”
    3. Anyone can find short-term gains. The best leaders define a long-term vision, then enable individuals to define their own contribution.
    4. Success is always relative, and only for a moment in time.
    5. Accelerated change requires rapid adaptation. Being small is our advantage.
    6. The market is what you make it. Or else the market will make you.
    7. It’s been said that when technology works, it’s magic. I disagree. Magic is watching passionate people – from all over the worldcreate technology together.

    Also, it has now been confirmed by repeatable experiment: I’m not a people person – especially when lots of them are gathered in small spaces. I’m fucking exhausted.

    Officially signing back on,

    -DCROBOT


    Categorieën: Mozilla-nl planet

    About:Community: Recap of Participation at Whistler

    Mozilla planet - ma, 29/06/2015 - 17:32
    <noscript>[<a href="http://storify.com/lucyeharris/participation-at-whistler" target="_blank">View the story &#8220;Participation at Whistler&#8221; on Storify</a>]</noscript>
    Categorieën: Mozilla-nl planet

    Bogomil Shopov: Voice-controlled UI plus a TTS engine.

    Mozilla planet - ma, 29/06/2015 - 16:02
    A few days ago I’ve attended the launch of SohoXI – Hook and Loop’s latest product that aims to change the look and feel of the Enterprise applications forever. I am close to believing that and not only because I work for the same company as they do. They have delivered extremely revolutionary UI in … Continue reading Voice-controlled UI plus a TTS engine.
    Categorieën: Mozilla-nl planet

    Pagina's