Contributor spotlight: Swarnava

Mozilla, and specifically SUMO, relies on the talents of our contributors to make a difference. This month we’d like to give a big shout out to one of our Top Ten Contributors: Swarnava Sengupta!

Swarnava has provided close to 2800 answers in our forums- that’s a lot of help! Even better, most of those are ‘first responses’- which are the crucial first steps to giving our users the help they need. Even more impressive is that he’s done all of this and entered the Top Ten in under one year.

He also helps translate SUMO Knowledge Base articles in the Bengali language. He hopes to become a forum moderator someday, but is already the Bengali Locale Leader.

User questions come for all types of Firefox problems- and Swarnava specializes in crash related issues and browser hijacking problems. His advice to new contributors is that you don’t need to be an expert to help- which is so true! He points out that there is no need to feel shy, as he isn’t a developer or an expert. It’s just a matter of showing people Knowledge Base articles that help with their problem- that’s it. He has a really good point, as no one starts out as an expert-and the more help you give, the easier it gets.

Swarnava works from Kolkata, India. He puts in online 24/7 support via mobile & also uses Twitter to help with Army of Awesome. This sounds like a lot- but even with the big time difference between Mountain View, CA and Kolkata we see him online all the time! When not online helping Swarnava is in school. In addition to SUMO & Army of Awesome, Swarnava helps test beta products for Kaspersky Labs and Symantec Corporation. He maintains Bengali translations on Utorrent, Malwarebytes, and for some Firefox Addons. This is pretty impressive for someone who is 17 years old! He also chats with Friends using texts or Facebook. It’s not surprising that his favorite hobby is using the computer- especially as he aims to become a Computer Engineer. I’d say he’s well on his way to a successful career! If you’d like to hear more from Swarnava you can find him [online, of course] at:

facebook.com/heavengod

twitter.com/h34v3ng0d

HTML out of the Browser

Amongst my friends, I’m known as something of a Star Wars nerd. My longtime nick has been cfjedimaster (a combination of two passions, the other being ColdFusion), I work in a room packed to the gills with Star Wars toys, and I’ve actually gotten inked up twice now with Star Wars tats. That being said, it was another movie that had the most influence on my current career – Tron.

Tron_poster

I had already discovered an interest in computers before then, but it was Tron that really crystallized the idea for me. All of sudden I imagined myself being the programmer – creating intelligent programs and dominating the grid. Yeah, I know, I was a nerd back then too.

My dreams, though, ran into reality rather quickly during my time as a Comp Sci major in college. First – I discovered that “Hey, I’m good at math!” means crap all when you hit Calculus 3, and secondly, I discovered that I really wasn’t that interested in the performance of one sort versus another. I switched to English as a major (always a good choice) but kept messing around with computers. It was during this time that I was exposed to Mosaic and the early web.

I quickly jumped into the web as – well – I’ll put it bluntly – easier programming than what I had been exposed to before. I can remember LiveScript. I can remember my first Perl CGI scripts. This wasn’t exactly light cycle coding but it was simpler, fun, and actually cutting edge. I’ve spent a good chunk of my adult life now as a web developer, and while I certainly have delusions of the web being a pristine environment, it has been good to me (and millions of others) and I’m loving to see how much it evolves over time.

One of the most fascinating ways that web technologies have grown is outside of the web itself. In this article I’m going to look at all the various ways we can reuse our web-based technologies (HTML, JavaScript, and CSS) in non-web based environments. While it would be ludicrous to say that one shouldn’t learn other technologies, or that web standards work everywhere and in every situation, I feel strongly that the skills behind the web are ones open to a large variety of people in different disciplines – whether or not you got that PhD in computer science!

Mobile

This is typically the point where I’d discuss how important mobile is, but it’s 2014 and I think we’re past that now. Mobile development has typically involved either Java (Android) or Objective-C (iOS). Developers can also use web standards to build native applications. One solution is Apache Cordova (AKA PhoneGap).

Cordova uses a web view wrapped in a native application to allow web developers to build what are typically referred to as hybrid applications. Along with providing an easy way to get your HTML into an app, Cordova provides a series of different plugins that let you do more than what a typical web page can do on a device. So for example, you have easy access to the camera:

navigator.camera.getPicture(onSuccess, onFail, { quality: 50,
    destinationType: Camera.DestinationType.DATA_URL
});
 
function onSuccess(imageData) {
    var image = document.getElementById('myImage');
    image.src = "data:image/jpeg;base64," + imageData;
}
 
function onFail(message) {
    alert('Failed because: ' + message);
}

You can also work with the accelerometer, GPS, contacts, the file system, and more. Cordova provides a JavaScript API that handles the communication to native code in the back end. Best of all, the same code can be used to build native applications for multiple different platforms (including Firefox OS, now supported in Cordova & PhoneGap).

To be clear, this isn’t a case of being able to take an existing web site and just package it up. Mobile applications are – by definition – completely different from a simple web site. But the fact that you can use your existing knowledge gives the developer a huge head start.

Another example of this (and one that is hopefully well known to readers of this site) is Firefox OS. Unlike Cordova, developers don’t have to wrap their HTML inside a web view wrapper. The entire operating system is web standards based. What makes Firefox OS even more intriguing is support for hosted applications. Firefox OS is a new platform, and the chance that your visitors are using a device with it is probably pretty slim. But with a hosted application I can easily provide support for installation on the device while still running my application off a traditional URL.

Consider a simple demo I built called INeedIt. If you visit this application in Chrome, it just plain works. If you visit it in a mobile browser on Android or iOS – it just works. But visit it with Firefox and code will trigger to ask if you want to install the application. Here is the block that handles this.

if(!$rootScope.checkedInstall && ("mozApps" in window.navigator)) {
 
    var appUrl = 'http://'+document.location.host+'/manifest.webapp';
    console.log('havent checked and can check');
    var request = window.navigator.mozApps.checkInstalled(appUrl);
 
    //silently ignore
    request.onerror = function(e) {
        console.log('Error checking install '+request.error.name);
    };
 
    request.onsuccess = function(e) {
        if (request.result) {
            console.log("App is installed!");
        }
        else {
            console.log("App is not installed!");
            if(confirm('Would you like to install this as an app?')) {
                console.log('ok, lets try to install'); 
                var installRequest = window.navigator.mozApps.install(appUrl);
 
                installRequest.onerror = function() {
                    console.log('install failure: '+this.error.name);
                    alert('Sorry, install failed.');    
                };
 
                installRequest.onsuccess = function() {
                    console.log('did it');
                    alert('Thanks, app installed!');    
                };
            }
            $rootScope.checkedInstall=true;
        }
    };
 
} else {
    console.log('either checked or non compat');                
}

Pretty simple, right? What I love about this is that the code is 100% ignored outside of Firefox OS but automatically enhanced for folks using that operating system. I risk nothing – but I get the benefit of providing them a way to download and have my application on their device screen.

FF OS prompting you to install the app

Desktop

Of course, there are still a few people who sit in front of a gray box (or laptop) for their day to day work. Many desktop applications have been replaced by web pages, but there are still things that outside the scope of web apps. There are still times when a desktop app makes sense. And fortunately – there’s multiple ways of building them with web standards as well.

So you know the code example I just showed you? The one where Firefox OS users would be given a chance to install the application from the web page? That exact same code works on the desktop as well. While still in development (in fact, the application I built doesn’t work due to a bug with Geolocation), it will eventually allow you to push your web based application both to a mobile Firefox OS user as well as the other billion or so desktop users. Here’s the application installed in my own Applications folder.

INeedIt as a desktop app

As I said though – this is still relatively new and needs to bake a bit longer before you can make active use of it. Something you can use right now is Node Webkit. This open source project allows you to wrap Node.js applications in a desktop shell. Executables can than be created for Windows, Mac, and Linux. You get all the power of a “real” desktop application with the ease of use of web standards as your platform. There’s already a growing list of real applications out there making use of the framework – some I had even used before what realizing they used Node Webkit behind the scenes.

As an example, check out A Wizard’s Lizard, a RGP with random dungeons and great gameplay.

Screen shot - Wizard's Lizard

Native App Extensions

In the previous section we covered applications built with web standards. There are also multiple applications out there today, built natively, that can be extended with web standards. As a web developer you are probably already familiar with Firefox Add-Ons and Chrome extensions. There is an incredibly rich ecosystem of browser extensions for just about any need you can think of. What interests me however is the move to use web standards to open other products as well.

Did you know Photoshop, yes, Photoshop, now has the ability to extended with Node.js? Dubbed “Adobe Generator”, this extensibility layer allows for a script-based interface to the product. One example of this is the ability to generate web assets from layers based on a simple naming scheme. If you’ve ever had to manually create web assets, and update them, from a PSD, you will appreciate this. The entire feature though is driven by JavaScript and all makes use of a public API you can build upon. The code, and samples, are all available via GitHub.

Generator running within Photoshop

What Next?

Coming from the perspective of someone who has been in this industry for way too long, I can say that I feel incredibly lucky that web standards have become such a driving force of innovation and creativity. But it is not luck that has driven this improvement. It is the hard work of many people, companies, and organizations (like Mozilla) that have created the fertile landscape we have before us today. To continue this drive requires all of us to become involved, evangelize to others, and become proponents of a web created by everyone – for everyone.

Bug Verification Day

Hello Mozillians!

Wednesday, April 16th, we will be holding our weekly Bug Verification Day. This event is held on the #testday IRC channel and it’s addressed to everyone willing to get involved in improving Firefox.

You don’t need to have any previous experience in working with bugs. Ask for help on the #testday channel and someone there will give you assistance. More details are available in the wiki page we set up for you.

If you’re unable to attend these meetings and still want to get involved, you can verify bugs on your own time. Just add the [bugday-20140416] tag to the whiteboard or a comment for every bug you work on, so we know you participated to this event.

Join us and help make Firefox better!

Announcement: Web QA Team badges

We are very excited to announce the creation of our new Web QA team badges! They represent all levels of involvement with our team.

Web_QA_Badges_Sorceror

Each badge lists the criteria for qualification. Start with a One and Done task, or by attending a Web QA Test day! Start running our automation or submit a pull request. You can get involved by advertising our team activities, and joining the conversation in our IRC channel #mozwebqa. You could even submit a design for our next badge! There are lots of ways to start working with our team.

The team would like to thank Ivana Catovic, yet again, for her beautiful designs. We are lucky to have a contributor with such talent!

For more information on our team badges, visit our Web QA Badges profile. Nominate yourself for a badge! Make sure your badges profile includes the correct data so we can verify your work.

Start with the Web QA Enthusiast badge and work up from there! If you have any questions you can always contact the Web QA team.

 

Powerful tools for developing Web Apps

In the recent years, web development changed drastically. The emergence of the mobile web and the new form factor of smart phones created the demand for different solutions than the former desktop-only web.

Since then a lot of frameworks and tools have been created, with new ones being added almost weekly. Now, we web developers are faced with a different problem: for every development concern, there are multiple options to consider, without clear pros or cons. It is easy to feel intimidated not only by the choices available, but also by how similar those choices are.

Every day, web developers have to successfully overcome this issue and turn this diversity from a daunting proposition into an empowering one.

But why reinvent the wheel all the time?

A set of solid recommendations for app developers

Mozilla is putting together a core set of tools and recommendations that we believe are the most useful for making Web apps.

The key considerations for what we might recommend are:

  • Sufficiently well-documented and straightforward to use for an average developer (we will concisely document the required knowledge one needs in order to engage with the technology).
  • Loosely coupled and as modular as possible (so you can follow one recommendation but not another if you are so inclined).
  • Tested on Mozilla products (i.e. the UI components will perform well on Firefox OS, etc), but with cross-platform apps in mind

The upcoming, initial set of recommendations involves a toolchain that’s core to any modern web app, like a JavaScript framework, templating interface, UI framework and task runner. We will employ existing solutions wherever possible and write libraries or utilities to fill in the gaps.

On an ongoing basis, we’ll expand this systematically across the different parts of the development experience, such as offline handling or the use of various Web APIs.

All of this will be delivered in one central spot: The App Center on the Mozilla Developer Network (MDN), our established, renowned resource for web app development.

But I already have it all figured out!

We encourage you to share your success story with us. Heck, share your failures too. We need all the feedback we can get from everyday web developers. If you have a tool chain of your own, with your favorite JavaScript framework, etc., we’re not interested in converting you to something else. We’re trying to help developers who aren’t sure how to go about making these kinds of decisions.

Come join us!

In the Mozilla tradition, this is a community-driven process. This means your input is encouraged and appreciated, and we would like your help to make this a successful initiative!

The main discussions around this will happen in the following places:

For the initial tool chain recommendations, I started a thread on the mailing list already, go ahead and weigh in.

If you have ideas for topics worth exploring in future iterations, don’t be shy and open a new thread to get the discussion started.

What’s next?

If this whets your appetite, then great! 2014 is an exciting year to be a web app developer. We’ll keep you updated here on Hacks, as well as the MDN App Center over the coming months.

Bug Triage Day

Hi everyone!

Monday, April 14th we will be holding our weekly Bug Triage Day. Join us on the #testday IRC channel and get involved!

You don’t need to have any previous experience in working with bugs. Ask for help on #testday and someone there will offer you assistance. Details are also available in this event’s wiki page.

If you aren’t able to attend this event but still want to get involved, you can triage bugs on your own time.  Just add the [bugday-20140414] tag to the whiteboard or a comment for every bug you work on, so we know you participated to this event.

Join us and help make Firefox better!

Firefox 29 Beta 7 testday results

Hello everyone!

Friday, April the 11th, we held another Testday for Firefox 29 Beta 7. A big thank you is in order for all of you helping us running tests on multiple platforms, doing exploratory testing and updating bugs. More details about the work done can be found in the etherpad.

Special thanks go out to: florin_nechita, madamezou, tiziana, emerson, lakshmi, bsupreeth, sudharani, Meghraj, cbaba20, and to all our moderators! Your work is always appreciated.

We look forward to seeing you at the next Testday, so follow us on QMO for details!

Bug Verification Day

Hi everyone!

Wednesday, April 23rd, we will be holding our weekly Bug Verification Day. This event is held on the #testday IRC channel and it’s addressed to everyone willing to get involved in improving Firefox.

You don’t need to have any previous experience in working with bugs. Ask for help on the #testday channel and someone there will give you assistance. More details are available in the wiki page we set up for you.

If you’re unable to attend these meetings and still want to get involved, you can verify bugs on your own time. Just add the [bugday-20140423] tag to the whiteboard or a comment for every bug you work on, so we know you participated to this event.

Join us and help make Firefox better!

Firefox 29 Beta 7 Testday, April 11th

Greetings Firefox friends,

We are happy to announce that Friday,  April 11th, we are organizing the Firefox 29.0 Beta 7 Testday. We will be testing a new beta build with focus on recent changes and fixes. You can see all the details in this etherpad.

No previous testing experience is needed. Just join us on the #testday IRC channel and our moderators will offer you guidance and answer your questions.

Join us and let’s make Firefox better together!

Firefox 27 Bug Statistics

I’m writing today to present the bug statistics for Firefox 27. My apologies for the tardiness of this blog post; too many things have got in my way recently. I try to get these posts out at the end of life of the respective Firefox version as that allows me to present the statistics across the entire life-cycle of a Firefox version. For Firefox 27, this should have coincided with Firefox 28′s release a few weeks ago. Again, my apologies for getting this out later than usual.

The first story I want to tell is about the high-level breakdown of all tracked bug in this release. As you can see below there was a marked drop in the total bug volume in Firefox 27. Perhaps unsurprisingly this allowed us to focus a bit more which resulted in a smaller amount of unresolved and unconfirmed bugs being shipped in this release. The numbers are still much higher than we would like but it is a small victory for the overall quality of Firefox if these numbers continue to trend downward.

Firefox27_TotalBugs

The second story I want to tell is about the percentage of incoming bugs confirmed. This is typically an indication of the effectiveness of our incoming bug triage practices. As the volume of incoming bugs decreases we like to see the number of confirmed bugs increase. Unfortunately we have been trending the opposite direction for some time. Previously I had attributed this to the ever increasing volume of bugs but I can no longer rely on this excuse. Looking forward to Firefox 28 I can say that we’ve made remarkable improvement in this area in an effort to reverse this trend. I’ll share more on that in a few weeks.

Firefox27_Confirmed

The third story I’d like to share is that of when fixes landed for Firefox 27. The following chart I’ve plotted the average time-line for the past few releases along with Firefox 27′s time-line. In general we expect to see an ever increasing curve toward through the Nightly cycle, trailing off as we proceed through Aurora and Beta, with spikes in the first half of these cycles.

Firefox 27 appeared to be trending higher than average as we approached the end of each cycle. While these numbers are not completely out of control it does put a bit of extra strain on QA. After all, the later a fix lands, the less time we have to test it. Ultimately this creates risk to the quality of the product we ship, but as long as we recognize that we can try to plan for it accordingly.

Firefox27_Fixes-by-Date

The fourth story I want to tell is about the number of bugs reopened. We typically reopen a bug when something is fundamentally flawed with the initial implementation and/or if a patch needs to be backed out. Even in cases where a regression is found, we tend to leave the bug closed and deal with the regression in its own bug report. As such, a high volume of bugs being reopened is usually indicative of a release that saw much churn and may point to quality issues in release.

Unfortunately Firefox 27 continues the story of many of the version before it and represents a marginal increase in the number of bugs reopened. Of course, the other side of this story may be that testing was more effective. It’s hard to say concretely just looking at the bug numbers.

Firefox27_Reopened

The fifth story I want to tell is one of stability. The following chart shows the number of topcrash bugs reported against Firefox 27 as compared to previous releases. For those unaware, a topcrash bug are those crashes which show up most frequently in the wild and present the greatest risk to quality and security for our users. The unfortunate story for Firefox 27 is that we’ve seen an end to the downward trend that we saw started with Firefox 25 and continued with Firefox 26. The volume of topcrashes puts Firefox 27 in the same ballpark as the rash of point-releases we saw in Firefox’s teens.

Of course there’s two sides to every story. The other side of this may very well be that we got better at reporting stability issues and that resulted in a higher volume of known bugs. It’s hard to say for sure.

Firefox27_Topcrashes

The final story I want to tell today is about the percentage of regressions reported post-release. As we hone our processes, bring on more engineers, and get assistance from more contributors, we’ve been getting better at finding and fixing regressions. It’s inevitable that the more code landing in a release increases the potential for regression. Naturally this leads to an increase in the total number of regressions reported. Firefox 27 was no different so I thought I’d look at regressions a little differently this time around.

The following chart shows the ratio of regressions reported before release to regressions reported after release. A release with a high-volume of post-release regressions is a failure from a QA perspective because it means many bugs slipping through our fingers. I wouldn’t expect the number of post-release regressions to ever be 0 but we need to strive to always be better.

Firefox 27 represents a huge victory on this front. We saw a huge drop in the number of Firefox 27 regressions reported post-release. For months we’ve sought to improve our triage processes, engage more with developers, and work harder to involve volunteers in our day to day efforts. It’s nice to see these efforts finally paying off.

Firefox27_Regressions

That’s Firefox 27, in a nutshell, from a QA perspective. I think it’s useful to be able to reflect on the bug numbers and see what kind of an impact our efforts are having on the product. I really do enjoy visualizing the data and talking about our “victories”, but it’s just as interesting seeing what the data is telling us about where we may have failed. I believe that learning from failures has far more impact than building on successes and acts as a great motivator. What we want to avoid is those crippling failures. I think Firefox 27 is a nice iterative step forward.

Firefox 30 Aurora Testday, April 18th

Greetings mozillians,

We are happy to announce that Friday,  April 18th, we’re going to hold the Firefox 30.0 Aurora Testday. We will be testing the latest Aurora build, with focus on recent changes and fixes. Detailed instructions on how to get involved can be found in this etherpad.

No previous testing experience is required so feel free to join via #testday IRC channel and our moderators will offer you guidance and answer your questions.

Join us next Friday and let’s make Firefox better!