A friend of mine launched a cool plugin for Microsoft Project. It's called Tap on the Shoulder. The idea behind it is that you can integrate MS Project with any email system to send out notifications to your team when tasks start and end. It's a really cool idea and helps Project get closer to the feature sets of some other tools. There's a free trial, so you should be able to give it a try before deciding to spend $49 to get a license.

If you use Project to track your team's progress, this should help keep you on track.

The conference is ending as I type. It was a lot of fun, and I learned plenty about tools that I never knew about. I have a better insight into HTML5, CSS3, the future of JavaScript performance, and so much more. The organizers and support staff did an incredible job on this conference, and I cannot wait to come back again (hopefully next year). I even have ideas about something I may be able to present in 2 years, if I am allowed.

I was honestly hoping to write more, but time and a bit of self-consciousness did not permit it. Please feel free to comment or ask any questions, and I can try to answer them. I look forward to going back to my job and showing some of these videos to my team.

Now, I'm just kicking back and waiting for the flight home tomorrow. Good bye, Velocity!

The last really interesting talk I attended was about YouTube's use of Flash and HTML5. They had some really interesting issues that they have had to deal with. Plus, there are some really odd side effects that they both observed and intentionally caused.

First, they are at the point where the two versions are functionally similar. The HTML5 version of the player does not have quite as many features, but you can try it out by going here. The biggest feature gap is in rights management. Currently, Flash has a proprietary rights management system to protect the content. HTML5 lacks that sort of protection now. Otherwise, there is no reason why the two versions should be different for very long.

The most interesting part of the talk was around the performance differences. HTML5 generally outperforms the Flash version of the player in actually getting loaded and up on the screen. They were saying that the difference was about 200ms. However, once the play button was pushed or there was a seek, the Flash player usually started playing about 2 seconds faster. This isn't really because Flash is better, though. It's because the edge cache doesn't have as many of the HTML5 versions of the videos because it is nowhere near as popular.

The problem remains, though, that Flash was slower on the uptake. They dealt with this by doing some strange hacks here and there. The most clever (and scary) of which was creating an image in a script block in the head tag that points to the CDN that holds the video. That way, the connection was already open by the time the page got to rendering the Flash widget. It's really clever, but I'd hate to see this be necessary for long.

There were a couple other cool things out there. HTML5 can actually do more exact seeking since it does not need to seek to a key frame. There was some tweaking on the API for controlling an embedded player since the HTML5 player has to be in an iframe. This tweak uses the postMessage method on the window, which I have never heard about. I want to look into that and its support. That could solve some of the issues we've had previously with communicating between a parent and an iframe on different domains.

All said, there was some interesting, funny, and scary stuff here.

One of the cool things about this conference is that they had the 4 major browsers represented: Chrome, Firefox, IE, and Opera. Yes, Opera is a major browser, and it's a really nice one too (see earlier posts about my Opera experiment).

I missed part of the Chrome talk, but I did hear about some prefetching of link data to help provide a snappier response when you navigate around the web. The obvious question of ad tracking came up. I also worry about the poor site that happens to be featured on a major page on the web. They not only get the clickthroughs, but they also get the pain of the traffic that never actually arrives, as it were.

The Firefox talk focused a lot on the features of HTML5 and customized JavaScript APIs that are being added. The upgrades are looking really good. Apparently Firefox 5 is going to be launching in a couple weeks. 6 and 7 are later in the year, but they are apparently only 6 weeks apart. I appreciate the faster development cycles and getting upgraded browsers into users' hands quickly. However, I don't like the break from Firefox's sensible numbering scheme. Chrome does the versions like this, but I like that Firefox, IE, and Opera all come with really visible changes to the end user when they do major version bumps. In any case, the version number doesn't really matter. What I want to see is if Firefox will suffer the same problem that Chrome does with the upgrade path for its users. I don't want to have to support 10 versions of every major browser, all at different points in the implementations of the really neat upcoming features.

IE was up next with some nice graphs and demonstrations of IE9 performance, especially against IE8. This is really the second time I have seen this talk. The last time was before IE9 was actually released as a finished product. The leaps are definitely impressive. I have to compliment the two presenters I've seen on their poise. It is difficult to walk into a room of people who are almost always using Firefox and Chrome to talk to them about IE. For the actual content, the most notable part for me was the background compilation of the JavaScript. This uses the other cores that so many computers have these days to compile JavaScript even as you may be running the exact same code. The next time through, though, it will be faster because it will be running native code.

Finally Opera got some time in the sun. The funny thing is that Opera has actually implemented most of these things already. They don't have hardware acceleration in their browser yet, but they have done a lot of forward-thinking things since some relatively early versions. The talk was mostly about how Opera owns the mobile market. I like the idea of selling the typically reluctant developers on this by showing them how many of their users actually use Opera on mobile devices (whether mini or mobile). He also talked about some of the difficulties of sites that do not respect the X-Forwarded-For header. In any case, it was good to see Opera getting some time on stage to talk about their product. He had to rush through the Firefly information and mobile debugging towards the end, but those are both great features if you have never tried them before.

I don't really have a lot to write on any particular keynotes. There were three that really stood out to me of the ones I attended. There were a few that I did not attend for networking and interest purposes.

The first one I want to mention is Jon Jenkins talking about some operational case studies. He had some really interesting information about scaling and how that can be handled in a cloud computing world. There were two important components to the talk. First, it's nice to scale down to your traffic. Since you're not dealing with real hardware anymore, you can have your computing capactiy track with your actual traffic/data/constraining operations. The second component was scaling up at useful times. The given example was doing a deployment by copying the fleet to a new set of virtual servers, deploying the new software there, and then flipping your load balancer over to the updated fleet. Then, you also have a nice rollback option of just flipping the load balancer back.

The second keynote I want to mention was about SSDs. It was short, profane, and funny. The end result: use SSDs in your computers and servers.

Finally, John Resig did a really good (I think) talk on holistic performance analysis of JavaScript. Unfortunately, I missed about the first 10-15 minutes of the talk. I will try to watch it later and report back.

I went to a few other session this afternoon that were interesting and informative, but they did not evoke much in the way of a coherent response. Some talk about DBA roles in the DevOps world and talk about Yahoo's issues with their homepage were interesting. In all, I wouldn't say that there was a lot of really new information there for me.

I did want to hit on the short session I attended before calling it a day. I got to see some more of the new features on WebPageTest. The more I see, the more I want this set up at work. The first feature that is only available on private instances (not on webpagetest.org) allows you to determine when the page stops changing. It will even create a weird picture that highlights the area of the page that changes last. With highly dynamic web apps, this could be a really interesting way to determine what is really going on as the page loads. I think you can combine this with the video capture capability and have a reasonable view that can be shown to people without using the tool. I find that one of the biggest issues with training people on these highly dynamic apps is that screenshots in documentation cannot convey the true dynamic nature of the application. These videos can.

The second really cool feature is called replay. You can have the system perform the request(s) you want. Then, you can actually set it up so that it replays the request without actually making any network requests. That way, you can measure the pure browser-side latency impact of the JavaScript, CSS, and DOM structures on your page. This is really cool and will do a lot to help get rid of that network jitter.

I abbreviated the title here a bit because the talk was really just about CSS3. Nicole Sullivan provided some useful tips about dealing with CSS in general, especially some of the features of CSS3.

As usual, the overall name of the game is graceful degradation with good performance. While IE6 (which we will seemingly never be rid of) does not support any of these features, that may not be a big issue. Rounded corners, drop shadows, and transparency can just become square corners, no shadow, and opacity. Is that really a huge issue? Will the IE6 users be saddened by not having rounded corners? How will they know unless they have a newer browser somewhere?

There are other features that won't degrade as well. The provided example was the carat in a breadcrumb. There's a unicode character that you can use in the CSS to provide this, but it won't work in IE6. You need to provide some sort of explicit fallback here.

In the end, it's about balance. You need to find a good compromise in the middle.

Then, we got into the tips. There were a few really notable tips. First, we'll talk about CSS selectors. I didn't know before this that they are evaluated right to left. The browser will use the right-most constraint to find all the elements that match and then traverse up the tree until the matches are weeded out. At first, this seems absolutely terrible. If you think about the actual way the DOM and selectors are implemented, it starts to make sense why this happens. Traversing from the root up the tree is painful because a child selector may not be immediately beneath the parent. It could be several levels deep. Starting from the deepes part makes the most sense, algorithmically. This also means that selectors ending in a * begin with ALL elements in the DOM and filter from there. That's a very bad idea.

Additionally, regex and attribute selector patterns are considerably slower (for fairly obvious reasons), so they are also discouraged. The real shock (which also makes sense when you really sit down to think about how the browser has to work) is that specifying something like "div.foo" is slower than saying ".foo". This is because the class is found first, then they make sure that it's a div tag that was found. I don't believe that there is a drastic difference, but you shouldn't really have classes that are shared among different tag types if you want them to behave differently on the tag types in question.

Finally, Nick Zakas and Nicole announced at the end that they had written a new CSS Lint tool that covers all of this and more. It's written in JavaScript, and they open sourced it right in front of us on github. If you have ideas, you should go and look at it. They are happy to take more rules.

Another interesting keynote was John Rauser's conversation about data. His point was clear. The metrics that we spend so much time looking at are not that helpful. Sure, I often look at the average, p50, p90, p99, and p99.9 times. However, that only gives you a vague idea of the distribution of the actual data. You may very well miss some interesting features that occur between p50 and p75 using just these metrics. The only way to truly understand the outliers is to actually look at them.

Histograms are typically the best way to actually look at and understand this data. I really want to get back to the office next week and start playing around with some of our service metrics. I'd like to create some histograms to start really showing me what is going on. I have a problematic service right now that could really benefit from some more in-depth analysis of the data in this way.

John also made the point that there are no tools that really do this for you. He did have a really cool graph that showed a heat map overlayed with the time series data. This gave you an idea of the distribution along with the actual average latencies. I don't think this really shows you the true distribution, though. if there's a place where the curve does not fall off quite as quickly, a color comparison would have a hard time actually showing that kind of information. In any case, I expect to be generating some interesting histograms next week.

Since there are so many keynotes, some of them fly by so quickly, I'm not going to respond to all of them. There are a couple that I thought were awesome.

The first real keynote of the morning was by Theo Schlossnagle about a career in our field. It was refreshing to hear two things.

First, it was nice to hear someone saying that moving jobs every few years is not a good idea. Practice in this field is what created all the experts who are speaking at this conference. It's the time ane experience that these experts have that really sets them apart. They know their field, and they know what works.

The other things that he talked about was what I live in. That is, he broke down the line between development an operations. I carry a pager once every few months and have to support what I write. As he said, the number of things that pull you out of bed at night will quickly go to 0 when you are on the hook for supporting those systems.

All in all, it was a well-put description of how people should really approach this industry.

Max Firtman started off by saying that we are guilty and that users hate us. In fact, he hates us. Then, he gets down to business.

Most of the things we take for granted in desktop usage are worse in mobile applications (network, latency, hardware). The experience and context are also very different. The browsers will behave differently than their desktop counterparts. He put up the headers from a feature phone. The accepts header was absolutely obscene. It enumerated exactly everything that the device can handle. You'll never see that large a header on a desktop.

Mobile browser issues abound. There are tons of them, most of them limited. Some are proxied while others directly access the sites. Most of them have no documentation, name, or debugging tools. His suggestion for dealing with the lack of debugging tools (whether on the device or in an emulator) is proxies. His recommendations are Charles Proxy or Fiddler. The proxy can help you understand the network traffic that you would usually see in a waterfall chart. For real devices, he also provided some other options, but I think the proxy is probably the best option. He did provide an option for doing some on-device JavaScript debugging, but I am very suspect about the impact of the performance of the site's JavaScript.

For some statistics, not surprisingly smartphones are the smallest part of the market and the largest part of the usage. The inverse is true for feature phones.

"We need to forget about pixels." I cannot be happier with this statement.

He also mentioned (for the 2nd time I've heard it) not always being connected. The idea of having enough data loaded onto the device to continue using the device in a degraded way until the connection comes back is very interesting. When he expended on this, he talked about an application cache that can be built in so that you can load the page with no connection. It's cool, but the way to have a robust (and updatable) cache is to basically use your own. The base page has to be very small with a bit of JS to determine if the cache is dead. I don't really like that hack, but it may be the only way with how things have been implemented.

He makes a very interesting point about mobile versions of sites. First, you should not redirect. His United.com example shows that over 1 second was spent on the iPhone redirecting twice (once to www.united.com, and then to mobile.united.com). Second, the search engines don't care if you are providing different content on the mobile version of the site. We are always talking about these things on the desktop platform, but it applies even more to the mobile platforms.

There is also the problem of complexity. We can occasionally see difficulties in processing the DOM on desktop platforms. It's even worse on mobile. That processing time is precious. The same applies to CSS and JS parsing. Those are worried on desktop platforms. Imagine how much time they probably take on an older mobile phone. I can hear the batteries screaming.

It's kind of worrying (and comforting, perhaps) that the same issues come up in poor implementations on both desktop and mobile platforms. One example provided is a hyperlink with no href. This is just poor behavior in general.

He has some really interesting ideas about how to trim sites down. A lot of designers ask us to provide background images, icons, etc. that make the site look nice. It really hurts to get those complex designs on mobile devices, though. The design is often lost on the user. Since CSS3 supports gradients, you can still get a lot of the effects that people love to put in designs. Interestingly, the support of sprites and inline images are also heavily supported on mobile platforms. The difficulty here is that you need to figure out if the device requesting actually supports these features. Since this can change the CSS (and/or images) you provide to the user, you have to do this or risk breaking your user experience.

The cool thing idea he also provided was a way to use canvas to draw the arrow (sideways carat) that was used on the original design. Canvas can create a data URL so that you can use that in the same way you might use an inline image. Unfortunatley, this is only available on the latest versions of browsers for mobile platforms. I wish I could force people to upgrade their browsers (both desktop and mobile) so that I can use some of these newer features without all the pain of browser detection, which is traditionally so error-prone. That said, he makes a big point out of providing the experience but not being too concerned about the support level. This is easier said than done, but a well-created design will degrade gracefully without certain capabilities.