|
I'm attending the Velocity conference this year, and I figured I'd post about some highlights here. Two of the sessions I attended were related to mobile web development, and were quite interesting. The others were focused on web operations (scaling/reliability of the servers) - still interesting, but stuff I have less experience with. The two mobile web talks were:
Mobile Web Performance by Estelle Weyl
Slides: http://estelle.github.com/mobileperf/
Quick summary: People don't like their battery drained! Estelle had lots of excellent tips on how to make your web apps efficient. I particularly liked the tip to reduce HTTP request latency on mobile devices by stuffing the resources into browser localstorage on the first page load, and then loading it from there afterwards. Also definitely the tip to avoid using radial gradients - that's been the cause of a few of the Fennec performance issues, and we have bugs filed on those. I really liked how she emphasized that all of these tips are things that may or may not apply depending on the particular site you're trying to optimize.
Taming the Mobile Beast by Matt Welsh and Patrick Meenan
Quick summary: The mobile web has completely different performance characteristics than on desktop! For example, latency is a killer when it comes to mobile web performance. Beyond ~2Mbps bandwidth has almost no effect on page load time; it's all about the round-trip latency. A lot of their content (e.g. carrier proxies screwing with content) was familiar to me from working on the browser back at RIM, but some parts were new to me. For instance, their overview of the cell radio state machine was interesting - the talked about how the cell network can drop the device channel if it goes idle, increasing latency on the next request. I also really liked how they emphasized the sheer number of variables when it comes to measuring mobile performance, including hitting data caps on your test devices near the end of the billing cycle!
[ 0 Comments... ]
I just landed bug 755971 on mozilla-inbound. Assuming it sticks, it changes the scrollWidth and scrollHeight properties on non-scrollable elements so that it doesn't include the border of the element. This means that for an element that looks like this:
<div style="display: table; overflow: auto; width: 100px; height: 100px; border: 5px solid black">foo</div> the scrollWidth and scrollHeight change from 110 to 100.
This behaviour is poorly specified and not consistent across browsers, but this brings Firefox more in line with the definitions in the CSSOM-View specification. It also makes the behaviour consistent across scrollable and non-scrollable elements - in both cases it now returns the padding box size. The behaviour for scrollable elements is unchanged.
Although this change makes sense in general, the reason it came up is because some of our code tries to detect if elements are scrollable by checking if their scrollWidth (or scrollHeight) is larger than their clientWidth (or clientHeight). This check was returning true in cases where non-scrollable elements had a border. By the looks of some questions on stackoverflow, this seems to be a general problem people are encountering, so it made sense to fix.
[ 4 Comments... ]
I was reading Peopleware (excellent book, everybody in the software business should read it) and I found this particularly surprising:
During the 1960s, researchers at Cornell University conducted a series of tests on the effects of working with music. ... To no one's surprise, participants in the two rooms [silent room and room with earphones+music] performed about the same in speed and accuracy of programming. ...
The Cornell experiment, however, contained a hidden wild card. The specification required that an output data stream be formed through a series of manipulations on numbers in the input data stream. ... Although the specification never said it, the net effect of all the operations was that each output number was necessarily equal to its input number. Some people realized this and others did not. Of those who figured it out, the overwhelming majority came from the quiet room.
Many of the everyday tasks performed by professional workers are done in the serial processing center of the left brain. Music will not interfere particularly with this work, since it's the brain's holistic right side that digests music. But not all of the work is centered in the left brain. ... The creative leap involves right-brain function. If the right brain is busy listening to 1001 Strings on Muzak, the opportunity for a creative leap is lost.
What do you think? Do you like listening to music while coding? Do you find it affects your creativity and/or productivity?
[ 11 Comments... ]
A lot of you probably know this already, but I thought I'd put it here anyway for future reference. Now that we've released Firefox for Android Beta, we're getting a lot of bug reports of various websites that behave unexpectedly or just plain don't work (this is great, keep the bugs coming!). Often it turns out that the page is just poorly designed for mobile browsers, and the problem isn't really in the browser but in the mobile-specific content that is served to us.
As one of the first steps when investigating bugs of the kind "Site X misbehaves in Fennec", I always check to see if I can reproduce the behaviour in desktop Firefox using the User Agent Switcher add-on to get the mobile-specific content. The User Agent Switcher add-on is great because it lets you modify the fields (User-Agent HTTP header and some window.navigator properties) that pages often use to do mobile detection. By using a desktop browser with Fennec UA properties, I can narrow down the scope of the bug as being a Fennec-specific bug, a Gecko core bug, or a website error.
If this is useful to you, you can get the addon here. It doesn't come with the Fennec UA settings by default, but allows import/export of settings. I have the XML file for Fennec 15.0a1 (current nightly) available for download here. I also have a page that shows you the necessary UA settings for any browser - just navigate to this page in the browser whose settings you want to see.
There is a caveat though: some websites use other forms of UA detection to serve mobile-specific content. For example, CSS3 Media Queries is one way to do it. I haven't run into too many sites that do this, but that number will (hopefully) grow, so it's something to keep in mind.
[ 3 Comments... ]
I've heard the phrase "web scale" come up a few times recently, and it's kind of been simmering in my mind, so here are some random thoughts to help exorcise it.
Web scale is huge. When you scale things up to the web, you're often scaling things up by a factor of millions or more. There's a huge difference when you're dealing with things at that scale. Events that have a one-in-a-million chance of happening actually do start happening when you're at web scale. This is both bad and good.
Companies like Google and Facebook like operating at web scale, because it gives them a lot of power. They are able to take little itty-bitty pieces of information about their users that individually are almost worthless, but in aggregate is worth billions of dollars. Their users pay a cost in terms of privacy; many do this by choice. However, there's also a different cost that is paid by a few, the cost of a one-in-a-million catastrophic event. If Google accidentally loses the data of .0001% of their users, they might not care very much or try very hard to fix it. At web scale, though, that .0001% is a lot of users, and those users basically get shafted. That's why web scale is scary.
But the same one-in-a-million events also work in our favour. There are lots of stories out there of somebody needing some help, reaching out on the web, and finding it. People separated by continents coming together to work towards a common goal. That, too, is a function of web scale. It may not be easy to find someone on your street or in your town who shares your particular goal, but on the web, you can find those people and make things happen. That's why web scale is good.
The web reminds me of the famous quote by Archimedes: "Give me a place to stand and with a lever I will move the whole world." The web is like that lever; it provides the potential to move the world, but only to those who can wield it. Personally I don't believe that such power should be concentrated into the hands of a few. The web should remain accessible to everyone, regardless of who they are, where they're from, the language they speak, or anything else. It's the only way to prevent an imbalance of power and keep the playing field even.
Easier said than done, though. At web scale the only way to accomplish that is to empower the users themselves. If you put out a product for five individual users, it's easy enough to customize it to suit their individual needs. If you put out a product for five million users, it's impossible. Even a well-understood thing like language localization becomes hard at web scale, because you might find that one of your five million users only speaks languages you don't do localization in. The only way to do it is to give your users the power to do it themselves.
That's why maintaining open standards and decentralizing systems is important. They shift the balance of power back to the users where it's sorely needed. If you're building a product, they let you avoid forcing your users into becoming victims of your scale. It's just one of the many reasons I'm glad I work at a place like Mozilla, where ideas like user sovereignty are built right into our mission and manifesto. But Mozilla operates at web scale too, and we have to be careful that we don't end up victims of our own success, by growing too big too fast and forgetting that scale changes everything.
[ 1 Comment... ]
One of the things I've been working on for the last while is the integration between the Fennec front-end and the core graphics APIs. One of the main problems in this kind of work is having to deal with multiple different coordinate systems and units of measurement. For coordinate systems, we have:
- the page, which is the area determined by the content being rendered
- the screen, which is determined by the physical hardware the user has
- the viewport, which is the part of the page the user sees on the screen
- the displayport, which is the area Gecko is actually rendering to graphics buffers
- the CSS viewport, which is the base relative to which some content dimensions are calculated
For units of measurements, we have:
- device pixels, whose size is fixed by the hardware
- CSS pixels, which can grow or shrink relative to device pixels depending on the zoom
- app units, which are what Gecko uses internally for layout calculations, and are 1/60 of a CSS pixel
With all these different frames of reference and units of measurement it sometimes gets pretty hard to keep it all straight. As a tool to help me visualize this, I wrote a simple SVG file that lets me quickly simulate certain behaviours. The SVG file shows a device overlaid on top of a screenshot of CNN.com, and allows you to drag around the device so that you can see how the viewport and displayport might change. It also allows you to simulate zooming in and out (using the '-' and '+' keys) and asynchronous panning (use 'p' to pin/unpin the displayport).
You can find the SVG file here (warning: it loads a ~1.5MB CNN screenshot). Feel free to play around with it, or hack it up to suit your own needs!
[ 7 Comments... ]
Do you suffer from bugmail overload? Do you often declare bugmail bankruptcy? Have a set of bugmail filters so complex they break every time you change them? If so, this post might be for you!
A few months ago, I too was a chronic sufferer of bugmail overload. The best approaches to handling bugmail I could glean from my fellow Mozillians revolved around using Gmail, tuning email preferences in Bugzilla, and filtering heavily. The problem, however, is that I like getting bugmail. I like being able to watch a component and stay on top of what's going on. It's not so much a case of getting too much bugmail, as it is a case of not being able to process it fast enough.
So I decided to write a bugmail dashboard that would solve this problem. In a nutshell, it scrapes incoming bugmail and extracts all the relevant pieces of information, stuffing them into a MySQL database. A web-based front-end then displays that information in a very compact representation that allows me to view large volumes of bugmail efficiently. Here is a screenshot of what it looks like. And here is a random subset of features:
- Presents information from multiple bugs on the screen simultaneously, so you don't have to wade through different emails to read everything.
- Prioritizes bugs into columns; the leftmost column is most important and rightmost column is least important.
- Marking stuff is as viewed is done on a per-bug basis (using XMLHttpRequest so it's nice and responsive).
- Marking one bug as viewed moves the next bug up so you don't even have to move your mouse, kinda like Firefox's tab close buttons!
- Interface is very mobile-friendly so you can easily process bugmail on your phone during idle moments.
I've been using and improving this dashboard for a couple of months now, and it's getting stable enough that others may want to try it out. I still consider it "alpha" quality though, largely because it's non-trivial to set up and get going. If you're interested in trying it out, grab the source from github.com/staktrace/bugmash and take a look at the README.html file for instructions on how to set it up.
If you have any feedback, please send me email and/or file bugs in github and/or submit pull requests!
[ 0 Comments... ]
Something that's bitten me more than once during Fennec development is making some changes to browser.js, going through the super-long build cycle, running my code, only to find out there was a syntax error of some sort in my change, which causes Fennec to not start up correctly. When this happens, it is a huge waste of time, and quite frustrating to boot.
Although I've filed bug 715242 to track this issue and fix it properly as part of the build process, I've also thrown together a quick way to do this in my local builds.
First, build the js engine as a standalone binary for your machine. If you have a host build of mozilla-central you might already have a working copy in your <mozilla-central-objdir>/js/src directory. If not, do the following (adapted from the SpiderMonkey build instructions):
mkdir -p ~/tmp/js-build
pushd ~/tmp/js-build
<mozilla-central-srcdir>/js/src/configure
make
popd
This will build a "js" binary that you can run with the -c flag to syntax-check JS files. Put this on your $PATH somewhere. Unfortunately, some of the .js files you'll want to syntax check (such as browser.js) are also preprocessed. Figuring out where in the build to find the post-processed versions of these files was too much work, so I went with the simple and easy approach:
grep -v "^#" $1 > ~/tmp/check-this.js
js -c ~/tmp/check-this.js
If you throw the above into a script and run it with a .js file as an argument, it will exit with zero on success and nonzero on failure, so you can conditionally run the rest of your build. I do this in my build scripts, which you can see in my github repo at https://github.com/staktrace/moz-scripts/ - look at the jscheck and build-android.sh files in particular.
[ 0 Comments... ]
So it's been about five and a half months since I started working at Mozilla. Kind of ironic that I haven't yet blogged about it, considering they encourage their employees to blog early and often, and being able to blog about work stuff was definitely one of the things that attracted me to Mozilla in the first place.
Officially I'm on the mobile platform team, working on the parts of the code that deal with the mobile browsers (i.e. Firefox for Android, aka Fennec) interaction with the core Gecko rendering engine. However, since we've been focused on a rewrite of the entire Fennec front-end, everybody on the mobile team has been working on whatever needs to be done, and the lines are pretty blurry anyway. Currently I'm working on the pan/zoom behaviour of Fennec, ensuring the user can navigate around the page smoothly and efficiently, encountering as little "checkerboarding" as possible.
Working at Mozilla so far has been pretty interesting. In the world of software, it's almost the polar opposite of RIM (particularly RIM as it was when I left). Working on open source software in an open development process is obviously a large part of it. All our code is publicly available, and a lot of the discussion that goes on happens on Bugzilla and IRC, where anybody can see and participate.
But even more important, and quite surprising to me, is the emphasis on community. Mozilla has a huge focus on building a community around the web - to the extent that every office has a dedicated community space where they host events. For example, during the last week at the Toronto office, we had a "Girls learning code" event where 11-14 year old girls could come and learn about the web and technology in general. This is an aspect of Mozilla that I think a lot of people aren't really aware of (I was only vaguely aware of it before I started here), but it is a core part of the company and mission.
I don't want to ramble on right now, but I plan to blog on Mozilla-specific things, both technical and non-technical, in the future. I suspect some of those posts will not be of general interest, so I'll keep them off the main blog, but you can get at them by going to https://staktrace.com/spout/?tag=mozilla. The RSS feed will likewise be at https://staktrace.com/spout/getrss.php?tag=mozilla. Feel free to subscribe to that if you want to see Mozilla-specific blog content.
[ 4 Comments... ]
|