Interblogs
In reply to
Feb 4th
Radley Marx wrote a short piece on ‘myths’ about HTML5; I read his post, and what struck me about it was that, despite a few salient points, it seemed mostly FUD. Particular gems stuck out, such as his assertion that HTML5 will create unblockable banner ads, that we’ll see a resurgence of unwelcome ’splash pages’, or that HTML5 will be just as crashy as Flash. It reeked of the kneejerk reaction I would expect from someone whose information comes entirely from the pro-Flash camp. Most of the assertions he makes are either wildly inaccurate or misrepresent the truth badly.
Myth 1 – HTML5 Video is only for the iPhone
On the iPhone, YouTube pops up Quicktime to play the video, because that’s what plays h.264 video on the iPhone. On Safari on Windows and Mac, it uses Quicktime for decoding as well. On Chrome, it uses Chrome’s built-in video rendering.
Also, if you visit www.youtube.com/html5 on any browser, it gives you a page asking if you want to enter the HTML5 beta – not any actual video. You should have checked the link first.
Myth 2 (section 1 – penetration)
HTML5 isn’t here yet? No, it’s not. Support for HTML5, however, is growing. Chrome, Firefox, and Safari all support HTML5 and CSS3 to varying degrees; Safari and Chrome both support h.264 video, and Firefox supports Ogg Theora video.
The point is not ‘everyone should switch to HTML5 immediately for everything’, but rather ‘Now’s the time to start thinking seriously about what HTML5 can offer you’. For example, in the case of Vimeo, I can turn on HTML5 instead of Flash (at my option). As a result, videos on Vimeo use far less CPU – On the Mac, a typical Vimeo video uses 100% of one CPU and 20% of another to play Flash video, vs. only 20% of one to play HTML5 video. If you don’t want it, change it back.
Myth 2 (section 2 – flexibility)
This one was a doozy, but I’ll try to address some of the points.
- Customizing the video player – see SublimeVideo for an example of the customizations you can do to an HTML5 video player. Works in Safari and Chrome.
- Movie clips – we just covered this, the <video> tag does this.
- Native apps – I assume you mean Adobe AIR? Personally, I can’t stand it. Every single app I’ve used that was written in AIR didn’t behave like a native application, was slow, and used up far more memory than an app should. It’s great for banging out a quick, cross-platform app, but no one I know uses it if they have a choice.
As for the rest – no, HTML5 doesn’t do all of that. It wasn’t meant to. That’s the sort of thing Flash is (maybe) good for.
Myth 3 – Canvas is inflexible, and nigh-useless for real work
- Canvas doesn’t support fonts – except those supported by browsers. True, but browsers like Safari and Chrome are also adding support for downloadable fonts, meaning that you, as a designer, can make a font available to the browser to use.
- Canvas only supports limited interactivity, so games are a no-go – I’m not sure what you mean by ‘limited interactivity’. You can capture mouse and keyboard events. Did you want more? You can certainly create games, and people are starting to do so. As a primitive example, check out this Wolfenstein 3D-esque 3D engine using Canvas.
Sure, it’s not the most advanced example, but it only took a few seconds of googling to find. There are much more complex and innovative examples out there.
- Tools – Ironically, the very company you seem to be trying to defend, Adobe, has tools that will do this. Check out this demo from October of someone using Illustrator and Dreamweaver to create Canvas-based content.
Myth 4 – HTML5 has all the problems of Flash, and will bring back splash pages
- CPU hogging. Well, of all the things I’ve seen in HTML5, none of them are cpu-intensive, except the one thing you linked (which looks like it’s doing some very inefficient things very often). Meanwhile, in my experience, without Flash blocking the entire web is geared towards draining laptop batteries as much as possible. Not ideal.
- Banner ads – Flash blockers aren’t the best way to get rid of ads, they’re just the best way to get rid of annoying flash that gets past your ad blocking filters. If you want to get rid of ads, use an ad-blocker that will stop your browser from downloading the Javascript that puts the ads there in the first place. This will work for HTML5 just as well.
- Splash pages – HTML5 means a return of splash pages? No. People who know how to build a good user experience won’t suddenly forget when they stop using Flash.
- Crashes. You start talking about crashes, then talk about CPU use. There’s no correlation. Regardless, Flash on Mac especially is horrendously buggy. Safari is far, far more stable now that I block the Flash plugin from doing anything unless I tell it to. This isn’t going to change, because Adobe doesn’t care about the Mac market. If they ever start to care, then maybe we’ll start seeing some improvements.
Conclusion
I’m not entirely sure what the point of your blog post was. You seem to spend it all spouting off knee-jerk reactions, of the kind that implies you’re a Flash developer, and you’re afraid that you’re going to become irrelevant. Maybe it’s just me, but that’s how it comes across.
But it doesn’t make any sense. Adobe is not afraid of Flash being killed off by HTML5; you’ve pointed out several reasons yourself why it won’t – things like throwaway browser games, or voice/video apps. The fact is that the design goals of Flash and the design goals of HTML5 overlap in some areas, but definitely not all of them. Flash isn’t going away any time soon (though I’d be thrilled if it did). What we will start to see is compatibility. Let Flash do what only Flash can do well, but let the browsers do the rest, and let them do it better. Instead of Adobe trying to optimize for every case, let Adobe focus Flash on what it needs to do best.
What it comes down to is Adobe execs making this about ‘us or them’. They keep talking about how they have this awesome version of Flash for the iPhone waiting in the wings, but Apple is cruelly depriving its users of the joys of Flash. In reality, Adobe hasn’t bothered to give Mac users a working, stable version of Flash. For that matter, even the Mozilla Maemo team is having problems with Flash performance; Stuart Parmenter announced today that they have RC3 of Firefox for Maemo ready, but they had to turn off plugins because Flash slowed things down too much.
So let’s stop this fighting. Adobe used to be a great company, maybe it will be again. They can continue to make tools, whether Flash survives or not, whether HTML5 becomes commonplace or not. That’s where their money is, and that’s fine. What we need to stop is this misdirection, the fear, uncertainty and doubt that people are spreading about ‘Flash vs. iPad’ and so on. It doesn’t help anyone if you force them to take sides.
Messenger
Jan 11th
In response to the issues happening on Twitter between a friend of mine, Corinna, and one of Vancouver’s premiere bloggers, Rebecca, I asked a question on Twitter. The question was this: why was Corinna blocked from the Best of 604 awards, a claim that I heard from Corinna on Sunday night. I asked on Twitter for some clarification: why was she banned?
I try not to take sides, even when it involves my friends, until I know both sides of the story clearly. Still, I don’t know Rebecca except by reputation, and I know Corinna personally, so I took her words at face value.
This morning, I got an e-mail from Rebecca, trying to clear up the situation. Without commentary on its contents, I thought I’d post it here so other people could see her side of the story.
First of all, you can read what Corinna had to say over on her blog. Then, you can read the below e-mail and see what you think.
Hi Dan,
I just wanted to clear the air about the Best of 604 Awards as I’ve seen some chatter lately on Twitter.
They have and always will be people’s choice awards. People nominate and people vote, me or judges are and never will be involved. For the 2009-2010 event I opened up a Twitter account and updated the home page http://bestof604.com.
I’m not sure why anyone would think they are “banned”, I’m not even sure in what context. I have a complete list of winners available here, listing all 1st, 2nd and 3rd place bloggers:
http://www.miss604.com/2008/12/best-of-604-winners-and-the-morning-after.htmlThe event hasn’t even been setup this year but I did announce nominations will once again be open March 1st. That’s about all the planning that has taken place so far.
If you have any concerns, please let me know as this is 100% about the blogs that people love and want to support — from mainstream news to knitting, it doesn’t matter.
Cheers,
Rebecca
So that’s what Rebecca had to say. I’m not going to pass any judgement in either direction yet. There’s still some details I feel like I’m missing before I make my final judgement, but hopefully this will help clear the air, and not fan the flames.
Python-pingdom: accessing Pingdom from Python
Aug 6th
So after messing around with Pingdom a bit, I discovered that they have an API. More importantly, I discovered that there’s no Python module for their API, and that their API uses SOAP, which sucks.
Their API doesn’t actually expose a whole heck of a lot very well, but there’s enough there to play with and I thought someone might find some use for the work I’ve done so far on what might become a Pingdom module for Python. Now, this is my first Python module, so if I’m doing anything horribly stupid (I probably am), feel free to let me know.
You can find the source code on the github page for the project. More >
Memcached, gems, and Macports
Jun 10th
I actually really like Macports; it’s got a lot of software, it’s well-maintained, it works really well. Kudos to the Macports guys.
We have been having a problem with ruby though, or specifically with the memcached gem for Ruby. The problem is that it won’t compile with the latest versions of libmemcached. The latest, you see is 0.30, but it won’t compile with 0.26 or higher. In fact, if you’re using version 0.14 of the memcached gem, it won’t compile with 0.24 or lower. Oh, and it won’t compile with 0.25 either.
In fact, it won’t compile at all with any version of libmemcached for most people, and if it does it rarely works.
Unfortunately, the version of libmemcached required, 0.25.14, is only available (as far as I can find) on Evan Weaver’s blog post mentioning it. For people like me who like to keep everything package-managed when possible, this is a hassle. There’s no one-line command to make everything work, set it all up, and get it going. Kind of ugly, imho.
Fortunately, the ports system is as flexible as it is powerful, and you can easily hack the ports file to know about this new, better version. For you, I have done this, and you can find it in my github repo if you so desire, though I’ll include it here for reference. Behold!
Notice the ‘variant’ section at the bottom; that’s all I had to add to add support for this edge-case to Macports. Hopefully, as a result, the Macports maintainer will be willing to add this change into the official portfile. I suppose we’ll see. In the meantime, if you want to add this functionality, you need only replace your current portfile with the one in my GitHub repo. Instructions, paths, and commands are all at that URL. Enjoy!
Fantasy Cricket: Initial Migration (Part 1)
May 20th
We’ve recently migrated cricket.com’s Fantasy Cricket application from a single server running at ServerBeach to a multi-server cluster running on Mosso’s Cloud Servers system. In an attempt to document the problems we’ve had and the solutions we’ve found, I’ve decided to write down my thoughts and memories, and the processes we went through, in the hopes that it will help others.
Atomic Migrations
The actual act of copying the data from one server to another is simple. It’s not difficult to take a point-in-time snapshot of a Rails app and move it to another server. The difficult part, when dealing with a dynamic website, is keeping the two servers in sync.
Because of DNS propagation issues, you will continue to have clients hitting the old server while some users start hitting the new server as well. This can cause concurrency issues; if a user is hitting the old server, then they may make modifications to their account (or in our case, modifications to their team) that will not show up on the new site once their DNS changes. This can be a pretty big issue, and we came up with a pretty useful method of dealing with the issue that eliminates concurrency issues with minimal impact on the users.
Testing the Server
The first step was to copy the app over and get it ‘working’. To do this, we used a dump of the MySQL database, using the mysqldump utility included with MySQL. We got the app up and working, tested it, and made sure that it was going to work properly (i.e. all Ruby gems were installed, etc.). Next we took a fresh dump of the database using the –master-data option to mysqldump, which includes the information necessary to set up a replication slave.
MySQL Replication
MySQL provides realtime replication between two servers, and it’s pretty simple to set up. Setting up MySQL replication between the two servers required briefly opening MySQL to the outside world (having it listen on port 3306), but we used iptables firewalling rules to ensure that no one else could connect. Once replication was set up, we knew that the new server would be an exact replica of the old server. The application was working, the database was identical, and so on. Any changes happening on the old server would happen instantly on the new server.
MySQL provides functionality called multi-master replication, which allows two servers to be written to, and have them push their changes back and forth between two servers. While I’ve set this up and used it in the past, it’s more complicated to set up and can be a pain to maintain. If replication fails in one direction, you can get inconsistent results between the two. For this reason, we wanted to ensure all of our traffic would switch over all at once – an atomic migration. Either all traffic hits the new site, or all traffic hits the old site. This is where Apache comes in.
Apache’s mod_proxy
We use Apache to run our websites, including our rails applications (using Passenger’s mod_rails). The solution we came up with was to make use of Apache’s built-in modules to ease our transition. We set up two config files, the original (which we had already) and a new configuration that, instead of serving pages, proxied all traffic to the secondary server. In essence, all traffic to the old site was transparently proxied to the new server, and the responses were proxied back. This is the config snippet we used:
This had two benefits: first of all, it was instantaneous and atomic – all users would see traffic from the same server, either the old one or the new one. We wouldn’t have any frustrating situations where one user would hit the old server and another user would hit the new one. Secondly, it’s quick and easy. If there were problems on the new server that we hadn’t forseen, it would be easy for us to switch everything back to the old server (by swapping out the config files again).
The Changeover
In order to ensure we didn’t run into any collisions with replication, our solution was to stop Apache entirely for a second, then bring it back online with the new config. This ensured that if there was any latency between the master (old) and slave (new) servers, it would catch up in the second that we were down. After we made the change, we checked, and the site was up and running. Users were all logged out, but beyond that the experience was largely smooth. Once we knew the server was working, we changed the DNS to point to the new server, and the changeover had finished. We were live on our new (virtual) server.
In Part 2, I plan to discuss the initial scaling issues we found, as we tried to learn the bounds of Mosso’s virtual servers, and of our own application and server design.