Part III: Profiling Firefox OS.. An Entry point

Gathering profiling Data on Firefox OS can be done in several different ways.
#1) Simpler is better, sometimes a stop watch is a great medium with which to gather timing data for an application you don’t understand.

Picture of StopWatch
Stop Watch

2) In Application Profiling

A great way to accomplish this is to use timestamps in javascript to determine when specific things are happening, and if you are having a bottle neck insdie your application.

Ex:

var d = new Date();

console.log(“The time since epoch = ” + d.getTime());

Once you insert a few of these statements in “strategically” placed points.

Just cd gaia; make install-gaia, this will install the new version of gaia to your phone, and you can see what code path gets triggered at which points.

3)Measuring app startup Times

Turn on show app load times  by loading your settings app.

Click Device Information –> More Information –> Developer –> Show Time to Load.

This is one mechanism for measuring app start times, but this only measure time until mozbrowserfirstpaint which measure the time until first pixels are available for an app.

More details can be found in Bug: 787378

Advertisements

Part II: About Memory Gathering / Dissecting

I have my B2G device in hand….. how do I start gathering memory statistics for the apps I use.

Firstly git clone the b2g repo >

git clone https://github.com/mozilla-b2g/B2G

cd B2G /tools

python get_about_memory.py –help

There are several options you might want to consider with the tool, for now you can just run without any options.

Next Open Firefox Aurora or Nightly, and type about:memory.  At the bottom of the page is a button for loading the memory report from File.

Select and open the file you just saved in B2G/tools/about-memory

Read More »

Part I: A how to for performance testing on Firefox OS.

Performance testing (http://en.wikipedia.org/wiki/Software_performance_testing) for B2G is being done by many dogfooders / early users as we speak.  The beginnings of this effort are to begin a framework for gathering this data, as well as empower both power users and employees to really start to make sense of all this complex data !. 

Toolset: Mind, stop watch, performance profiler, about:memory tools 

Background: 

https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler

http://blog.mozilla.org/nnethercote/2012/11/14/memshrink-progress-week-73-74/

http://andreasgal.com/2010/10/13/compartments/ (an oldie but a goodie)

First Steps in performance measurements, were hashed out over the B2G work week most recently in San Francisco. The most immediate things we want to gather data on are the following.

  • B2g Startup Time:

Measure / Record the startup time for the overall system. We want to know how long it takes to get to the unlock screen. 

  1. Use case: As a user I do not want to wait for a long period of time before my phone will start. 

Requirements:
     — The phone is off
     — Start phone
    — wait for unlock screen, with animation.

  •  B2G Startup Time for each App:
  1.  Use case: As a user I want to be able to open apps one after another and have the operating system be able to quickly load each app, and switch to the homescreen.

Part II of this blog post will go over How To’s of memory gathering / dissecting. 

 

Tune into Part II: About Memory Gathering / Dissecting 

If you are Launching your startup HTML5 is the way to go ( imho )

As we progress through the webapps project there is an astounding see of change coming to HTML5 Apps near you.

If you are starting a new project, I would recommend that you think about some of the ideas I am laying out below.

Graphic Design:

Apps will have different characteristics than webapps.  You generally will not just want to layer css ontop of your page, and consider it mobile enabled and done.

You will have to design a completely different set of views for your mobile app than your desktop site, and possibly even your tablet as each platform will offer different capabilities that you’ll want to take advantage off.  Your layouts will accomodate different styles, and furthermore different functionality.

Redirects: Another thing to consider is that an App doesn’t allow navigation off of the page, so you should think about that and what it means for your app.  You wouldn’t want to redirect your users off of your domain.

Apps should be targeted / focused towards doing one thing well, and bubbling that information up to the user.

Popups: These are a web browser concept, that doesn’t translate into the App experience, so expect that popups won’t work.

So if you want a kick ass App experience,  plan on having completely different views for different device sizes.  The good news is everyone will be writing the same language, and basically using the same stylesheets !

There must be a ton of user UI tips, for writing kick ass mobile /tablet  apps, if you have any add it to the conversation

Infrastructure:

WebApps probably won’t make too many changes to the internal infrastructure of data centers.  But to the infrastructure / mechanisms you use for exposing your product to the world, those are / have changed.  The rest api revolution has been replaced by the Javascript Object revolution.  Exposing your services as part of a Javascript SDK is the new kid on the block, and it’s knocking down walls.

So far I haven’t seen too much change in this area, the cloud is pretty much a given at this point, at least for a startup.

Personnel:

The time for the Android / IoS developer is over, don’t do it, don’t fragment your infrastructure, your support, your ability to ship early and often.. It’s just not worth it.  If you are a startup and anyone is telling you to go native, i would seriously get second / third opinions.

Having said that using Phonegap or something of the like is a good idea to help bridge some of the functionality gaps.

If you want to take a look at how to  load client side / server site javascript in phonegap and all have it process you should take a look at github.com/mozilla/soup

Why:

The advantage of being small is that you can move quickly.  Try doing that with an android release , iphone release, and website release.. All with differing capabilities / code bases, and then dealing with android fragmentation.  It will make you slow, and slow is bad….

Learn More.

Github Webapps MochiTest Repo

Github Webapps MochiTest Repo

Hey just wanted to show everyone the portability / coolness of javascript test frameworks, and how you can achieve cross device api compatibility.

The example that I am going to show is the soon to be performed work on mozilla central to port the webapps extension into the mozilla code base.

The exciting part about this we get to test against code that hasn’t been written just yet. Now since the codebase i want to test will eventually be on mozilla central , but is currently not.  I didn’t select the option of testing against a debug build.

Building Firefox:

https://developer.mozilla.org/En/Developer_Guide/Build_Instructions

MochiTest Basics:

https://developer.mozilla.org/en/Mochitest

 Assuming you have built mozilla central and you are able to run MochiTests, then what next.Well firstly you will want to choose a location for your tests.

Now If you are working on webapps this directory might be: dom/tests/mochitest, as it looks as a lot of tests that are dom related lie there.

You will then have to create a directory “foobar“, and edit Makefile.in and add your directory below

DIRS  += \
  dom-level0 \
  dom-level1-core \
  dom-level2-core \
  dom-level2-html \
  foobar \
  storageevent \
  $(NULL)

Next step would be to create a Makefile.in inside your directory foobar. Attached is a github commit which establishes our base repository.

https://github.com/dclarke/webapps-mochitest/commit/5f9d067b716229bcd9e0ceab2e2766263815bae7

 

https://github.com/dclarke/webapps-mochitest

First step is getting a working mozilla central source.

 

 

 

Web Apps Sikuli / Python testing getting off of the ground

Just thought I’d spend a few minutes and blog about the Web Apps Sikuli Project.

What we have gotten done so far

  • Basic set of tests working in Windows / Mac
  • A working documentation set
  • We have a few people contributing so far

I would like to say thank you to a few people for their support so far:

  • Mohamed Dabbagah our intern from last semester, who has been pitching in whenever he can
  • BYK – https://github.com/BYK – Thanks for the python tips!!

Please remember to not forget to note the Sikuli Test Day will be January 20th 2012

If you have spare cycles, and are interested in the project, check us out on github

Pick up an issue, try to solve, ask questions, contact me.. whichever suites your fancy.

 

-David Clarke

twitter: onecyrenus

email:dclarke@mozilla.com

 

Sikuli testing in python

Recently just started my first open source project, hosting on github, codebase is in Python.

This is a project that is meant to test the Web Apps Runtime for Mozilla.

https://github.com/mozilla/openwebapps/

https://github.com/dclarke/apps-extension.sikuli

If there are any python reviewers out there, it would be great to get some feedback / pull requests if you see anything horribly offensive !

I am interested in learning more about python, so headed to pycon 2012 this year. !


https://us.pycon.org/2012/