Tomorrow I'm flying to Melbourne for the week. I plan to be working regular hours, albeit in a different time zone. See you online!
Saturday, 26 September 2009
Friday, 25 September 2009
Lately I've been thinking about Luke 12 which says in part
Then Jesus said to his disciples: "Therefore I tell you, do not worry about your life, what you will eat; or about your body, what you will wear. Life is more than food, and the body more than clothes. Consider the ravens: They do not sow or reap, they have no storeroom or barn; yet God feeds them. And how much more valuable you are than birds! Who of you by worrying can add a single hour to his life? Since you cannot do this very little thing, why do you worry about the rest?
"Consider how the lilies grow. They do not labor or spin. Yet I tell you, not even Solomon in all his splendor was dressed like one of these. If that is how God clothes the grass of the field, which is here today, and tomorrow is thrown into the fire, how much more will he clothe you, O you of little faith! And do not set your heart on what you will eat or drink; do not worry about it. For the pagan world runs after all such things, and your Father knows that you need them. But seek his kingdom, and these things will be given to you as well.
Does this advise us not to think, plan or work hard? Surely not, since so many other parts of the Bible (including words of Jesus himself) tell us to do those things. So I suppose the important thing here is primarily to get our priorities straight, and then to work hard but not worry for a moment about the results.
This is difficult for me because there are many things I care deeply about, including my work, my family, and my friends, so I worry about them. I don't think it's wrong to care about these things; Jesus certainly cared deeply about many people. Apathy is an easy alternative to worry but I don't think it's what God wants. This is a very practical issue for me because at times over the last year or two I've not been sleeping as well as usual because of work-related stress.
I think what God intends is for me to care deeply but trust him even more deeply, for me to do all I can and leave all results entirely in his hands, to be always joyful knowing that he is the ultimate benefactor.
Do not be anxious about anything, but in everything, by prayer and petition, with thanksgiving, present your requests to God. And the peace of God, which transcends all understanding, will guard your hearts and your minds in Christ Jesus.
This is hard for me to do, it's a constant spiritual exercise, but by grace I've had some success lately. I'll need to keep at it.
Wednesday, 23 September 2009
Tuesday, 22 September 2009
v1.mozLoadFrom(v2) behaves much like the
load method of
HTMLMediaElement. It stops playing the currently loaded resource and loads a new resource. However, it does not run the HTML5 media selection algorithm; instead it just takes
currentSrc and loads that. What makes
mozLoadFrom useful is that it tries to avoid re-downloading the resource data. It grabs all the cached and buffered data already associated with
v2 and makes it available to
v1 as well. In fact these elements carry on sharing data, so that any future data downloaded by
v2 is available to the other. Typically this means that only one of the elements will actually be downloading data and the other one won't need to download anything at all. (Although if the entire resource doesn't fit in the media cache, you can end up in situations where the elements are playing different points in the stream and both reading from different offsets.)
mozLoadFrom is useful if you need to manipulate multiple views of the same video/audio stream. For example you might be playing a video and at the same time you want a script to seek forwards or backwards and gather periodic snapshots into a series of <canvas>es. Or you might have a set of videos playing in the page at a smallish size and want to display a selected one in the front covering most of the window, without having to mess with the original thumbnail video. The main reason I implemented
mozLoadFrom is to make it easier to display full-screen video in Firefox or extensions.
The tricky part of the implementation is that the media cache was originally designed so that a block in the cache could only belong to one decoder at a time. With
mozLoadFrom a block can be owned by multiple decoders at a time. In the original design, a block is always in exactly one of four states: free, readahead (it's ahead of the current playback point), played (it's behind the current playback point), and metadata. Now a block can be a readahead block for one decoder and a played block for another decoder.
I was quite worried it would be hard to extend the design this way, but in fact I was able to do it in about a day of intense hacking. This probably reflects well on the original design of the media cache. In particular, basing eviction decisions on the "predicted time of next use" was easy to extend; when a block has multiple owners, its predicted time of next use is the earliest time that any of its owners predicts for it.
Update Ian Hickson points out that new API is not needed here since HTML5 allows concurrent loads of the same absolute URI to share data regardless of HTTP caching instructions. So instead of
mozLoadFrom we could just use
v1.src = v2.currentSrc to get the same effect. I should do that...
Sunday, 20 September 2009
On Thursday night the Auckland Web Meetup was held at the Media Design School. The topic was "HTML5" and the presenters were Microsoft's "IE8 Technical Evangelist" Giorgio Sardo and me and Chris Double from Mozilla. There were about 200 people in the audience, mostly Web developers.
Giorgio presented first and gave a broad "IE8 for Web developers" presentation. He showed a funny (but somewhat pointless) promo video for IE8, went through all the Web-facing platform improvements in IE8 (with demos and showing code in Visual Studio), and demoed their Firebug clone. His basic message was "we care about standards (including HTML5), we're doing it, our release cycles are slow because we have the most users but we will get there." What I thought was very interesting was that he made no attempt to distance themselves from HTML5 or even say that they'd be selective about which HTML5 features made sense to implement. His message tacitly assumed that HTML5 is simply something they will do. He portrayed Microsoft as part of the community contributing the development of HTML5, which isn't really true but at least Adrian Bateman's sent a few emails to public-html recently. I was really curious about what Microsoft says about HTML5 to Web developers so I was glad to have the chance to see this presentation.
One minor thing I should mention: Giorgio demoed a new Microsoft Expression tool that lets you compare the rendering of your Web page in different browsers. It's pretty cool, for example you can hover over an element in one browser view and it will highlight the same element in the other browser's view. Currently it supports Firefox and IE6/7/8. However it only supports static rendering, you can't interact with the page and script doesn't run. Also, for some reason it doesn't actually use the IE6 and 7 engines to render the views! Instead it uses IE8's IE7-mode to render "IE7", and --- somewhat bizarrely --- they *re-implemented* an "IE6-alike" layout engine to approximate what IE6 does. Those seem like strange technical decisions that will limit the usefulness of the tool, since Web developers will probably still need to test in real IE6 and IE7 builds.
My presentation was a short history of WHATWG and HTML5, a discussion of the HTML5 goals and why they're controversial in some quarters, a discussion of how HTML5 will affect Web developers, and a walk-through of major HTML5 features (including related features such as Workers and Sockets) that we have in Firefox or will soon have. I mentioned the database controversy to try to communicate that that area is not settled. I showed a bunch of demos which were very well received. Chris Double talked about <video> and showed some demos (mostly Paul Rouget's) which were also very well received. I've uploaded my slides. Here are the demos (they should all work in latest Firefox trunk builds):
- Michael Ventnor's accelerometer-enhanced "Mario Kart" based on Hans Schmucker's version using SVG filters
- Geolocation in Google Maps (OK, this one and the previous one aren't actually HTML5, but I wanted to make the point that HTML5 isn't the only channel bringing Web platform improvements.)
- Austin Chau's postMessage demo
- Leslie Orchard's drag-and-drop demo
- A demo I wrote of HTML5 parsing SVG and MathML without XML (need to set "html5.enabled" in about:config to true)
- 2D <canvas> demo "BlobSallad"
- A couple of WebGL (i.e. 3D <canvas>) demos that I'm not sure I can redistribute. But they're awesome!
- Paul Rouget's "Green Screen" <video> demo
- Paul Rouget's movement tracker <video> demo
- Paul Rouget's content injection <video> demo
At the end there was a panel discussion. We spent a lot of the time on the video codec issue. Chris did a great job of explaining that people shouldn't have to pay license fees to serve or consume video on the Web --- he actually got widespread spontaneous applause. The Web developer audience may not start using Theora tomorrow but they understand and sympathize with why we're doing it.
Overall I really enjoyed the evening and I think it was fairly successful at explaining and promoting HTML5. I'm encouraged that Microsoft seems to be endorsing it, and I hope that we see a massive implementation effort in IE9.
Tuesday, 8 September 2009
A lot of people have the idea that a successful "knowledge economy" requires much cheaper and faster broadband than what we have available in NZ today. I strongly disagree. If that was so, then Japan, South Korea and China would be dominating the United States in software development and Internet services, but they are not, or at least their strength is in volume, not innovation.
This Herald blogger suggests that if only we had faster, cheaper broadband, users would be figuring out amazing things to do with it. I don't understand this argument at all. Users can't do anything with broadband except use services provided by software developers. NZ's network is adequate enough to build and deploy any service developers can think of, and if you want to reach a mass market you can trivially host your services in the USA or elsewhere. (Chris Double in our office runs TinyVid, hosted in the USA, as a hobby, for goodness sake.)
Major research universities in the USA often presented similar arguments to large funding agencies: give us a lot of money to build amazing infrastructure (networks, computers, etc) and cool new ideas will be spontaneously generated. I don't think that was ever really true; the great ideas seem to come from getting smart people together and giving them freedom to work on their interests with adequate supporting infrastructure to experiment on; I can't think of any examples of great ideas that were inspired by a superabundance of infrastructure. Sure, if you had a megabit network and no-one else did, or Unix workstations when everyone else had DOS PCs, you had an edge, but by the mid-90s when I entered grad school at CMU commodity PCs and networks were powerful enough to support cutting-edge research in most areas of computer science. That didn't stop the universities asking for infrastructure money though!
Perhaps I could argue that making it easier to consume software and services is actually a long-term drag on the "knowledge economy". I got into programming because my first computer had almost no software on it and no way to get any more --- so all I could do with it was write my own. How many bright kids are hooked on Facebook, Youtube and game consoles when they could be coding their own dreams into reality?
Based on my experiences I certainly have gripes about problems dragging on NZ's "knowledge economy", but broadband isn't one of them.