My Opera Development

We've been working hard, and this morning we released another small bug package.

Fixed:

• Empty pictures in activity feed
• Writing ´ in links messes them up
• Group membership application goes to creator, but updates group's inbox unread count
• Wallpaper details page doesn't have "Skins" menu item.
• My Opera message setting changes do not work from http URLs
• Subscriptions containing only an excerpt does not show any content in activity feed or news.

As always, you can report new bugs in the the My Opera forums. You can also search the forums to see if someone else already reported it.

Good news everyone!

Static resources on My Opera are served through our mini CDN infrastructure consisting of geo-localized Varnish front-end servers. Cosimo has already mentioned this in previous devblog posts + comments. Having this cache layer allows us to more quickly deliver static contents (CSS and JavaScript for instance) to our users across the world, because a user is directed to whichever server is closest, reducing latencies. It also frees up local resources and the network bandwidth to our back-end static server. Of course, this caching also comes in addition to client-side caching handled by users' browser and proxy caching.

With multiple layers of caching like this, it's no longer trivial to ensure that our users have the correct version of the static content whenever we roll out a new release. The latest addition to our static file handling is to append a substring of the SHA1 hash of a JavaScript file's contents to its filename on deployment. The hash, even though only a substring of the full 160 bits hash, is pretty much guaranteed to be unique for each release (and in particular between one release to the next). The hash will also be the same in case of rolling back a JavaScript file to an earlier version. This means that if we need to revert back to an earlier version of a JavaScript file, the filename will always be the same.

The benefit for our users, is that caches can set an extremely high cache expiry, keeping a version in cache forever (or at least until it's eventually purged in favor of hotter cache entries). It also prevents all the redundant requests browsers need to perform in order to re-validate a cache entry. Another benefit is that we can keep multiple versions of JavaScript files physically on disk, in case somebody needs to request older versions of JavaScript files. This is something you cannot do when simply appending an ignored query string to a static file request URL to bypass caching of static resources (which in many cases is a dynamic timestamp, practically giving you no caching potential at all).

On the other hand, versioning our JavaScript files means that we need to keep track of all the base names of all JavaScript files and which is the version of each currently used in a release. In order to do so, we create a mapping between the original source files and their versioned counter-parts. This is resolved when loading JavaScript files so that users always get the correct version.

So all in all, we're now able to ensure that with each release, our users receive the proper JavaScript files consistent with the new release while still benefiting from long cache expiries.

Today we released a bunch of fixes for My Opera. Before I go into the details, I would like to describe the workflow we use for developing My Opera. It can be categorized into three types: Hot fixes, bug packages and tasks.

Hot fixes should be fixed as soon as possible. They have the highest priority at any given point in time, and our developers are always looking into these whenever they come in. An example of a hot fix was when groups could not edit album details earlier this week. This was examined, fixed and released within a couple of hours after it was discovered.

When fixes aren't all that hot, they get batched up and stacked into bug packages. The bug packages contain between 10 and 20 fixes which several developers are working on together. A bug package is generally scheduled to run for a two week period, but it could take more or less time depending on the intricacy of the fixes. Before the bug packages are sent live, they go through a testing period where the fixes are verified, for the most part by other developers than the one fixing them.

The last category is feature development and tasks. These usually take longer than two weeks to implement, and are not wanted in bug packages as they can easily delay the release. An example of a task is when we added support for Facebook's new API some weeks ago. We also have some umbrella tasks, such as infrastructure maintenance, and continuous tasks, such as integration and deployment.

Today's release was a bug package. Here's the changelog:

• Finally, timestamps for user content are localized according to language selection!
• The date format was different between blog posts and comments, and has now been fixed.
• E-mail subscriptions to content is now enabled by default for newly registered users.
• Fixed some e-mail notifications not being sent under certain conditions.
• Fixed localization problem on Polish translations for blog post comments.
• The zip smiley is no longer as worried as before.
• A warning is now shown at the rename account page that content linked from within blog posts will still point to the old username.
• Password recovery mails were broken by some e-mail clients. An HTML template is now sent as well to ensure that the link for password recovery is not broken.
• The “Limit search to certain forums” field was not populated on certain group forum pages.
• Blog posts with no title containing only an image is now giving a suggested title in the news feed.
• <abbr> now has a default style.
• Entities are no longer double encoded in blog search results.
• Shoutbox entries now show the user's username when no full name is entered.
• The popular blogs page now contains fresher content.
• A published/draft status is added to Metaweblog getRecentPosts responses.
• The text is no longer broken on the album upload form when the album title contains a single quote.
• The mynews.dml panel no longer yields a 403 Forbidden response when attempting to mark all as read.
• We also have numerous internal fixes that would bore you to tears to read.