Tuesday, 27 December 2011

Zippity - and automated performance tests for Firefox Mobile

Many have wondered how we get the device coverage with our automated Performance tests.  Here's one way:

What you see running here are the Zippity tests (a plug in available for Firefox mobile ), running the pageload tests on a number of different devices.  I also have logcat attached and running, to catch any possible crashes.

Pageload tests load a series of predefined webpages, to gauge pageload speed.  There are also Startup tests (which start the application several times to measure startup speed); as well as SunSpider and V8 tests.   Lastly, you can ping your memory metrics to Zippity.  

Having the crowd available to help run these tests (just install the plug in), helps us get the device coverage up and ensures we find things like native crashes, hopefully sooner, rather than later.

Kudos to Mark Finkle for this great tool.

I made this video last winter, when I was still in Helsinki:

...and here is one of my songs from my performance at Hotel Utah, San Francisco on December 19, 2011:  http://theutah.org/performance/johnhammink/20111219/againsttheglass

Sunday, 11 December 2011

A plug for the Fullscreen, Gamepad, and Mouse Lock gaming APIs

Sometimes, when things are moving as quickly as they generally do here at the Moz (as in the open web generally), the best that one can do is channel the work of others to try and stay on track with everything.   It certainly beats trying to do everything oneself, at the breakneck speed at which envisioning the new technology - and technology itself - unfolds.

On that note, kudos to Dave HumphriesRob Hawkes and Chris Pearce for their recent blog posts on these brand new APIs.  And so, by way of a rehash...

Fullscreen, Gamepad and Mouse Lock APIs are available in a single experimental desktop build of Firefox.  There are also builds that support these features here.

These APIs are estimated to land soon in the nightly builds.

The Fullscreen API:

Scheduled to ship in firefox 10 by the end of January, you can still try out some of the examples in the latest nightly builds.

Based on the  W3C's draft spec, this API enables any HTML element to be made "fullscreen", which hides the browsers UI and stretches the element to cover the entire screen area.

To use it, the developer calls void mozRequestFullScreen(), which, if the request is granted (there are security implications here) gets a mozfullscreenchange event back to the specifying element; otherwise a mozfullscreenerror is dispatched.

The user can ESC or F11 to exit full screen mode.   As with YouTube or other fullscreen videos, navigating (ALT+TAB) will cause fullscreen mode to exit.

There is a cross-browser full-screen API example here. 

The Gamepad API:

As directed by the W3C spec, Javascript and Firefox now gives developers the possibility to connect a gamepad directly to the computer (using USB or Bluetooth) - a domain previously only available to gaming consoles and native computer games.  

You can try it out here; note that you''ll need that custom build.   This wiki page contains more implementation specifics.

Rob Hawkes made a great demo video:

The Mouse Lock API:

This API hides the cursor and locks it to the center of the screen, thus enabling developers to make games and visualizations of a 3D world (otherwise the cursor would go off the side of the screen or hit the edge). With the cursor locked, the user can roam X, Y, Z axes without restrictions.

David Humphrey and his students at Seneca College are currently implementing this API based on the W3C spec.

There are demo files available.

We're tracking Mouse Lock API on Bugzilla. You can also check out David Humphrey’s series of posts on the development of the Mouse Lock API.

I'm just now trying these out myself; of course, if you find any issues, please feel free to file a bug.

Saturday, 10 December 2011

Fall tour of the Acoustic Circuit, S.F. Bay Area

From Freight & Salvage Coffeehouse, Berkeley,  November 22, 2011
If I don't (yet) get to unleash the beast on my software evangelism (a quintessentially nerdy pursuit) the least I can do is hit the acoustic singer/songwriter music circuit around the Bay area (which I'm currently doing).  It's only been a few short weeks since I've started touring regularly in addition to my awesome day job  (longer geographic swaths in the works on both the music and work fronts), but it's already been a hell of a ride.
From St. Lukes Church, San Francisco, November 20, 2011
From Rockit Room, San Francisco,  November 24, 2011
From Panama Red Coffeehouse, Concord, December 9, 2011

From Berkeley City Club, November 17, 2011

Here is one of my songs from my performance at the Hotel Utah, San Francisco, from December 19, 2011.

Tuesday, 6 December 2011

When going down is good

I've often complained about how jumping out of an airplane with an experienced tandem guide is safer than merging onto the 101.  It's certainly more fun.

Monday, 28 November 2011

Let's have a look at some recently landed Web APIs for Firefox

So, without further ado (as there's been too much "to do" about it) let's take a look at what we presently have (landed or about to land) regarding our latest (Firefox) Web APIs.

You'll need the latest xul fennec builds to run these.  Technically, these also run on the latest birch nightly, but that one is presently undergoing a major facelift due to rendering and related issues.

I'd suggest using a tablet. (For the SMS app, you'll need a phone with simcard and a special build, but we'll get to that presently).

All example testpages to which we'll be referring are available under the directory at:  http://people.mozilla.org/~jhammink/webapi_test_pages/

If you find a bug with any of the demos and/or APIs themselves (and we hope you will:) please write them here:

Make sure to include your device model & Android version, as well as the nightly fennec version you are using,  in the bug.

Battery API demo:

This API tests the different charging states of the battery, along with charging level and discharging time.  Try launching the page with the device plugged in, and  then unplugging (and/or vice versa).  Note that the charging/discharging time presently shows Infinity  until the battery has charged/discharged about 2% of its total capacity.

Does the testpage show the correct battery state for the device?  Does it correctly generate an alert when the charging state changes?  Is the level correct (when compared against native battery app level)?  Does it give a numerical discharging/charging time after some time in the same charging state?

Camera API demo:
This API presently tests the browser's ability to directly capture pictures from the device camera.

Point the device camera at the object you want to shoot  and click capture.

Is the picture rendered correctly (as opposed to  upside down, or sideways) both in the pre-capture and the preview?  Is the picture quality consistent with what your camera normally delivers?  Are there any other issues?  Please feel to play around with it a bit.

IndexedDB API demo:

Since accessing the native file system from the web introduces a huge risk, there needs to be a way to handle offline storage directly on a device.  Enter IndexedDB.   Actually, this api has been around since Firefox 4 (and subsequently for quite a few Chrome and other browser versions since) but the W3C spec got a rewrite recently and it's been well overdue for an upgrade.

When the browser first tries to create a local database, a prompt requests permission:

Subsequently, once this is allowed, the db initializes, and after some time, reports back on the number of records:

Our current demo matches a hash of zipcodes against a city (you must have zipcodes.csv present in same dir to work - this demo does), doing all the database access operations.  (Note that we're presently missing the functionality to do the reverse!) Once the CSV is loaded into the device local database, the  lookup should be instantaneous (note that all the steps are not depicted here):

Note that I've been getting dramatically different results from device to device.   Sometimes it works, sometimes not.   To be sure the feature is still a work in progress, so let me know what your experiences are.

Vibrator API demo:

Web apps, just like native ones,  need a way to send feedback to various sensors - including notification vibes.   The W3C spec lays a foundation, which we've implemented.  Note that you'll need a device with a vibrator to test this one:

You'll need a special build for this one also.  Try out each of the scenarios and verify the result.     Are we getting the correct number of buzzes, given the spec?  As with any of our APIs here, you can check the implementation by typing the string "view-source:" (without the quotes) before the "http://....".  Try it.

SMS API demo:
Note that you'll need an android phone with a working SIM card to try these demos.  Until this feature lands, you may also may also need a  special build with this feature.


The simplesend is a page that lets you send SMS messages to any phone.  Try it!  Is your message able to get through?  Any other issues?  Note that,  for testing purposes,  you can also try sending the messages directly to the same phone from where they originate.

This next example lets you do exactly that:  send and receive SMS messages from the same webpage instance:

This page is similar to the previous one, but also has an event handler for incoming messages.

Don't forget to study the page source, for each of these pages, to understand how these APIs are implemented.

And, once again, don't hesitate to file a bug if something doesn't appear to be working correctly, or if you have an idea about some features you'd like to see.  

Addendum:  The Web API test pages are now available in github:  https://github.com/jhammink/WebAPI-test-pages

Monday, 21 November 2011

Mozilla's Web API - on testing a framework.

So, hello again to you all.  It's been ages since I last posted at this space - but for good reason:  I've taken my performance show on the road again, and, at the same time, begun my work at Mozilla.  I find myself, once again, in the happy place of doing, on a daily basis, two different things that I love.

Primarily, my work has been around our Web API, and how we will write -and eventually automate - tests against it.  But how will we do this?

Our API is intended to "expand what the web can do".   One of the most important implications is the ability to access - in a secure fashion - our device hardware from the web.  To that end, there are such things as Vibrator API, Battery API, Settings API, Accelerometer and Sensor API, a new and improved Geolocation API, Sound API....from which we can work our device directly from the web!

So, how does one test a bunch of APIs as a user would use them?    Well, one thing (and I've been involved with such an effort before) is to build an Application Framework - essentially a series of mock-up and atomic apps that each demonstrate a single API.  

Over time, these atomic apps will be folded into more feature rich ones - to demonstrate the capabilities and (hopefully - we're QA after all) reveal any bugs that mixing and matching these APIs will uncover.

Another aspect that is important - particularly where automation is concerned - is a way of getting "golden values".   We will build a series of simple native applications for each OS that will help us to obtain these values for comparison.

Watch this space -  in the (very near) future we will demonstrate how many of the web apis work; how we will build HTML/JS test pages around them and test many of the features as a user would use them; build our golden apps in java and/or python (depending on our target platform), and, eventually, work the lot into an automation framework.   All of the code will be freely available on github.

I'm hoping for many outcomes; one of them being that you will learn (if you don't know already) how any of the technologies depicted here actually work, but also that you might jump in and help out - when the time is ready - by expanding what we've started here and our web api testpages, enriching our automation core apps, and really putting those apis through the paces, at their intended purpose.

Stay tuned!

Wednesday, 12 October 2011

Absence is the inverse of presence

"When the changes come, hallelujah! When the changes come, there's nothing you can do."
- from a song by Matt Weidemann
Kisu.  Helsinki, 2010

Kisu, my buddy of 14 years, the "Itty-bitty-kitty" passed away Monday morning at the age of 15. I think the sense of loss and absence has only just begun.

We had planned for a veterinary visit already on Thursday, but the week went on as I became more focused on my new job.

So we changed our plans to Monday. I had some idea in the back of my mind that she wouldn't make it that far. She started failing already on Saturday; that was the last time she could make it to my lap; by Sunday, she could no longer get up on her own.  I moved her from the window (it was the last beautiful day of the rainy California autumn), which was open, to the bed. I played her a little dulcimer for a few minutes and also sang her a few old songs she may remember from her earlier years. During the dulcimer part, she rallied around and with much shaky effort and managed to give me that loving look I've been blessed with so many times. During the night, she reached out with her paws to me a couple of times. By Monday morning, she had slipped away.  I wonder, what, if anything, she's experiencing now?

We all have our legacies and journeys to tell about, but somehow the years with Kisu were extraordinary.  She came into my life when a younger, more worried me was living with a girlfriend, anxiously unemployed in a tiny Soviet-looking apartment in Helsinki. Although the situation eventually resolved itself by the end of summer, having the one-year old Kisu around  (who was left to us by a recent divorcee) was, in a pattern set for the rest of her life, an incredible reassurance. Her playful antics were the perfect (or as good as could be expected) distraction from the anxiety of a 27 year old, who doesn't know any better how things usually work out for the better; literally thousands of CVs later and I had found myself some pretty lucrative work, and had reached an island in the storm.

Over the years, Kisu was with me during the meteoric rise and riches accompanying the IPO of the company which gave me my first real job; she moved with me from the heights of Kallio, Helsinki, up to the forests of Espoo, and eventually across the Gulf of Finland to Tallinn, Estonia, where I set out on my own and eventually connected with another company that encountered even more meteoric success than the first one had. She patiently waited with friends during my jet-setting years, when I always seemed to be catching a flight to some remote corner of the world (sometimes she caught the flight with me!). Then she eventually reunited with me when we moved together to a huge house in the Swedish countryside. Eventually, she even moved with me back to my original homeland of Ohio, U.S.A.; enduring my irritating months with one not-too-happening nor well-advised startup, and finally made one last great journey of her amazing feline life: a trip, by car, from Cleveland, Ohio to Silicon Valley, California. Again, enduring the stresses of a dysfunctional contract (but one where I learned oodles), taking me, through another contract hunt, finally to my present job, one where I feel secure and appreciated for the first time in years.

Kisu lived in Finland, Estonia, Sweden, and the United States (including traveling across it) and visited Chile and Russia. She's been to homebrew robotics and programming nights, with gaggles of caffeinated pals, living room jam sessions, real commercial recording sessions, Christmases and Thanksgivings, hosted more guests than I can imagine and been the guest of at least five families that I can remember. She's been through the most excessive of good times and the leanest of lean times and everything in between. She's sat by the side of my computer as I've worked, in my lap when I've cried and across from me, watching eagerly, when I've sang. And we met in that tiny apartment on Alppikatu; she died in a motel. In some ways, it seems, we've taken a step back together.  Just her and me.

I live alone, and have for some time now. Sometimes I have thought that cat is the only thing keeping me from going crazy.

On the Monday evening following hear death, I removed all traces of her from the apartment (well, not exactly all, but the unused litterbox, food). I knew that I couldn't stand to have that stuff around, and that it would be difficult to deal with, the more time passed.

I still sense her in the ways that she's not there: expectations of a soft padding up to the bed, of her watching me from the bed or chair when I came in the door everyday; of her sniffing the breeze out the window, and watching the activities, the seasons change, the rain, the sunshine. And then there are the intangibles of absence: the absolute dead quiet of the room, the sense that someone else is right out of earshot or just around the corner. Kisu is present in her absence.

Like a boat making its way through a calm stream, our legacy is as much about the ripples that remain after us. That which is present, and of us, in our absence. In this way, we persist. Although I have to give myself some credit, I feel that Kisu, in her lifetime, took me (well, she took the journey with me) from a place of anxiety, through some incredible moments and backdrops, to a much more hopeful place. If I make the best of this, now, will she, as she persists now, be ever intertwined with this new future?

Kisu and me. Denver Colorado, Summer 2011