June 25th, 2013
There are two main use cases that asm.js addresses.
asm.js is not limited to games. The performance it can bring to web applications opens up many interesting possibilities for speeding up existing web tasks, or bringing new experiences to the Web. Efforts to port video decoders and photo processing tools using asm.js are also seeing performance increases from taking advantage of existing C++ code without plugins or browser-specific technology.
There have been several attempts to provide a solution for C++ developers wishing to target the Web. We believe asm.js is the best solution, and here are a few of our reasons why:
2. It’s fast.
3. It dramatically reduces the cost of supporting the Web.
For developers already working with C++, Emscripten makes the Web just another port target. Once it’s integrated into your tool chain, the web version can be recompiled alongside your other platforms whenever any updates are needed. We have ported full properties in very short time periods.
4. It reduces or eliminates the need for plugins.
Companies that turn to plugins to enable their games or applications often see a significant friction in user adoption due to security warnings. asm.js provides an alternative path that eliminates the security messaging issue while still providing much of the performance, all within a safe execution environment.
5. It enables reuse of existing C++ libraries.
There is a wealth of open source C++ libraries out there waiting to come over to the Web. This is a vast amount of coding effort whose value has now been unlocked for web developers.
asm.js is still a new technology, and we have plenty of work to do to provide its full potential to the developer community. Mozilla is grateful to Epic and other game industry leaders that have already started to work on products using asm.js. These early examples are helping to prove the value, shape the technology, and encourage other browsers to priorities optimizations for it. The best way to help support the development of asm.js is to start using it and let us know what you think by adding comments to this post. If you are a game developer or have a performance intensive application and choose to port it over, share your work with the world and let us know about it!
For an in-depth look into what asm.js is and isn’t, have a look at this post by Alon Zakai. Well worth the read!
June 5th, 2012
It has been almost 6 months since the project started so I thought it was way overdue to recap how things have been going. I am excited about the interest this project is receiving from both active Mozilla Contributors (employees and volunteers) and the academic community. I’m working hard to deliver on your hopes for direct access to the results of this project.
Update on the Interviews
The Bugzilla Anthropology project has been moving along well when it comes to the interview work. We have completed 20 interviews plus 2 write-ins during the first quarter of this year. The raw transcripts are posted at the following link:
Work has been ongoing to parse through and summarize the results of these interviews into a digestible form. We have had considerable help from Olga Baysal and Reid Holmes from the Cheriton School of Computer Science at the University of Waterloo who are working tirelessly to parse through all the data we collected. They are categorizing the 1,213 comments gathered over the course of the interviews. This will result in two documents, the first is a 3 page summary that available at the following link:
This initial document discusses how the final longer summary will be categorized and how much activity was seen in each one.
Thank you very much Olga and Reid, this is a huge effort and we really appreciate your work so far. I eagerly await seeing the final 25-30 page summary.
Update on the Metrics
We have been working with the Mozilla Metrics team to surface information that can help us better visualize macro trends as they play out in Bugzilla. This will help us measure change over time and see problems coming before they reach a critical point. To help deal with the massive scope of the information stored in Mozilla’s Bugzilla, we are copying some of this data into an Elastic Search database that only includes the meta data of each bug. This lets us do massive queries without hindering production by bringing Bugzilla’s DB to a standstill. Progress on this work has been slower than I would like but we are making gradual progress.
We are working to make this data public via a REST interface but in the mean time, for those that have LDAP level access at Mozilla, you can see some of the visualization prototypes we have been working on at the following link:
Several of these prototypes are in use in production already. However, work is still ongoing and here is what stands between us and a public REST interface:
1. Complete schema modification to make sure that the database can handle queries relating to review queues.
2. Insure that proper automated testing is in place to verify that the data in the ES database is consistent with that found in Bugzilla’s DB. We have seen issues here so this is important.
3. Address the remaining security concerns around the meta data associated with open security bugs.
None of these are that large in scope, however, the metrics team has been very tied up and has had difficulty finding time to work on them. Last week saw a jump in progress on the first item and I’m hopeful we will see that crossed off the todo list soon. I have also attended very constructive meetings that show this rising in priority for the Metrics team which is also a positive sign we will see this done sooner than later.
December 20th, 2011
Project Wiki Page: https://wiki.mozilla.org/Bugzilla_Anthropology
What is this all about?
The goal of the program is to take a deep look at how people are currently engaging with Bugzilla. We want to see what we can learn about the tool’s good, bad, and frustrating qualities. You can’t look at Bugzilla without understanding how people work. The research is also surfacing information on the life cycle of bugs and how people interact with them along the way. The primary goals are as follows:
- Identify the information we want to gather.
- Interview stakeholders across the organization and community.
- Surface statistics that are relevant to its use.
- Identify best practices, useful hacks, tools, and key problem areas.
- Provide an overview of how Bugzilla is being used.
- Complete the research by the end of January 2012.
How are we going about doing this?
In an effort to get to the root causes of issues and find the hidden best practices, we are gathering data in two ways. First, we are conducting 1 hour interviews that probe into various topics focusing on how people interact with bugs throughout their life cycle.
The second method is statistical. We are diving into the considerable dataset we have stored in Bugzilla’s historical log. We hope to surface trends that help point out problem areas where we can improve as well as shed light on what’s working well so we can highlight those successes.
What have we learned so far?
We have just completed 10 interviews and posted the raw transcripts last week. We held off posting this material until we felt we had the absolute minimum representative coverage. The transcripts are raw feedback, they have been verified by the contributors, and they have all volunteered, in true Mozillian fashion, to put their names on them. Thank you to all the brave contributors that went first in the hopes of improving things for all.
Interview Transcripts: https://wiki.mozilla.org/Bugzilla_Anthropology#Interviews
We have also been working with Metrics to gather data on Bugzilla usage. Much of this data is still behind layers of security as the tools that help visualize trends are still prototypes. Once the tools are ready, the security group will need to review the system as it includes statistical information on security bugs. We will need to work with them to double check that we aren’t leaking out sensitive material before reducing the security to LDAP or preferably making it publicly available.
How can people contribute?
The best way to help is to review the data, give us feedback on a new set of interview candidates, and anything new you think we should be exploring. We intend to do another 10 interviews as the next phase. We will be including more community members in this round as they are currently under represented. The current list of questions we are asking and who is on our radar as candidates can be found at the following Etherpad. Feel free to add suggestions here:
Interview Etherpad: https://etherpad.mozilla.org/BugzillaInterviews
Once we start to surface the statistical side, I will write up another post.
If you have any questions you would like to see added to the interviews, have any feedback on the project or results that you would like to share, you can find me on IRC in the #pm channel, email me at firstname.lastname@example.org or comment below.