Been asked a few times in the last few days about where my slides are from my MySQL keynote from *last* year.

Ooops.

Um, yeah.  Sorry about that.  Here’s a link to ‘The SmugMug Tale’ slides, and you can watch the video below:

Sorry for the extreme lag.  I suck.

The important highlights go something like this:

Use transactional replication.  Without it, you’re dead in the water. You have no idea where a crashed slave was.
Use a filesystem that lets you do snapshots.  Easily the best way to do backups, spin up new slaves, etc. I love ZFS.  You’ll need transactional replication to really make this painless.
Use SSDs if you can. We can’t afford to be fully deployed on SSDs (terabytes are expensive), but putting them in the write path to lower latency is awesome.  The read path might help, too, depending on how much caching you’re already doing.  Love hybrid storage pools.
Use Fishworks (aka Open Storage) if you can.  The analytics are unbeatable, plus you get SSDs, snapshots, ZFS, and tons of other goodies.
Use transactional replication. This is so important I’m repeating it.  Patch it into MySQL (Google, Facebook, and Percona have patches) or use XtraDB if you use replication.  We use the Percona patch.

Holler in the comments if something in the presentation isn’t clear, I’ll answer.  Apologies again.

Shameless plug - we’re hiring. And it’s a blast.

I like both Adobe (Lightroom rocks!) and Apple (iPad rocks!), but I’ve been asked over and over again what I think about Apple’s new 3.3.1 policy. You know, the one that basically bans cross-platform development frameworks. And, in particular, basically nails the Flash coffin shut on iPhone/iPod/iPad. So, what do I think?

I love it.

And I’m surprised more developers, end users, business leaders, and general web standards lovers everywhere aren’t posting about how great this is.

It’s good for end users.

The App Store already has a signal-to-noise problem. With hundreds of thousands of apps, finding the good stuff is tough. Bear in mind that every single one of those Apps was built by someone intentionally designing for these devices – and we’ve still got plenty of junk in amongst the gems. Now imagine a bunch of developers just cross-publishing to lots of devices – ignoring all of the strengths of each of those devices. The signal to noise ratio gets worse, fast. Ugh.

It’s good for the web.

For me, this one is the biggie. These devices are a dual-platform: iPhone SDK and HTML. Don’t like the iPhone SDK? Build for HTML. And finally, finally, someone has stepped up and done something about the de-facto Flash monopoly. Flash has helped the web and HTML standards to stagnate. It’s sorta like a drug. It’s whizzy and slick, granted. But it’s a nightmare, too. Flash crashes constantly. Its performance is terrible (when a 1Ghz mobile processor in the iPad plays video more smoothly than Flash on a 16-core Mac Pro with a hefty GPU, that’s a problem). And it smashes through web paradigms left and right. Why? Because there’s no competition.

Look at the browser world, on the other hand. With Microsoft, Mozilla, Google, and Apple duking it out, we’re seeing a breathtaking pace of innovation. Browser stability and performance is improving at an astonishing rate. There’s no reason Flash shouldn’t be super-stable and fast by now – but it isn’t. It’s like the Internet Explorer doldrums all over again – Flash is holding us back, just like IE used to. I’d rather be building for something with a scary fast pace of innovation than something stale.

The iPad is already spurring HTML5 adoption even faster than before. Witness all the video and games sites that are already scrambling to announce and ship their HTML5 interfaces. Bring it on!

I want to build for the web, not for Flash.

It’s good for developers.

And by that, I mean “good developers.”

Good developers are language agnostic. They’ll write in whatever language is worth the effort.

Good developers love great toolsets and great platforms. The iPhone SDK is amazing.

Good developers want their creations to be perfectly tuned to their purpose. The iPhone/iPod/iPad interfaces demand and deserve lots of individual attention, not to be marginalized by some middleware cross-platform publisher.

Good developers want their products found and used. The App Store signal-to-noise issue is a daunting one – more shovelware won’t help.

Good developers want a stable community, with lots of advice, sample code, libraries, etc. A fragmented development landscape prohibits that – a unified one encourages it.

I could go on – you get the point. Best of all? It weeds out poor developers. And if the iPhone SDK and HTML5 aren’t your thing – go build somewhere else. I’m sure there’ll be another computing revolution in a decade or two that you can ignore yet again.

(and if you’re a good developer – we’re hiring and we’re having more fun than you can possibly imagine)

It’s good for Apple.

They get better apps. Happier end users. More productive good developers. Fewer bad developers. And, of course, they make more money. They did invent the software, devices, and App Store, afterall. Why should they marginalize themselves out of their own business?

It’s even good for Adobe

Granted, not quite as good for Adobe as having Flash on these devices. But lets not forget that Adobe has a stable of great applications, like Illustrator and Photoshop, which aid iPhone development. Their sales will still boom.

Finally, Adobe is incentivized, finally, to actually improve Flash. I’ll bet if Adobe actually made Flash stable, fast, and power efficient, it could get added to the iPhone for use in-browser. It’s not like Apple enjoys seeing half rendered web pages in their browser – they just enjoy customer complaints about crashing and poor performance less. Believe me – I know all about customer complaints due to poor Flash behavior.

But that window of opportunity is closing – the owners of those web pages don’t enjoy their stuff being half-rendered either. They’ll rush to fix that problem – without Flash – if Adobe doesn’t fix it for them.

So there you have it. Thanks, Apple, for doing what’s best for the web, your customers, and developers like me. The future is bright. Long live web standards!

(this post written on an iPad in WordPress’ excellent app)

UPDATE #1:

I understand many disagree, and have their own reasons. Go write for Android, another great platform that’s more open.  Maybe if you do, Android will ‘win’.  I think you’re confusing platform choice and development choice here.  Personally, I’d love to have more platform choice.  Who wouldn’t?  But Apple did invent this thing.  They certainly deserve to make whatever decisions they want about it.  If you’re right, and I’m wrong, those decisions will kill the platform.    I happen to think I’m right, and I happen to think Flash needs to seriously improve – and the Apple’s the only way that’s gonna happen.

Note that I don’t have an opinion on things like MonoTouch, which I know nothing about.  It could very well be that Apple painted with too wide of a brush here and excluded some things that should really be included.  I just don’t know.  I do know, though, that history has shown that cross-platform languages and frameworks have an abysmal success rate.  The last thing we need is watered down apps built for the lowest common denominator.

Finally, yes, SmugMug uses Flash.  I’m sure we’ll continue to use it.  Like I said, it’s slick and whizzy and like a drug.  We used it because it was the only tool for the job.  Adobe did a great thing with their h.264 support, and we love our Flash apps – when they work.  But it’s been awfully frustrating to watch Flash continue to crash and perform poorly for our customers, especially because Adobe doesn’t seem to care.  They certainly don’t respond to us when we ask for help, and they certainly haven’t fixed their issues with multiple releases.  I’m hopeful that this sudden pressure and increased competition will cause them to bring Flash up to the level of their other superb products like Lightroom.  If not, you’ll certainly see us move away from Flash as HTML5 support and performance continues to improve, just like everyone else on the web.  We can play Quake II in HTML5, for heaven’s sake!

UPDATE #2:

Steve Jobs on Adobe.  Amen, brother.

The debate over HTML5 vs. Flash is great for comments and page views, but all that chatter obscures the bigger issue: Should developers and designers invest in HTML5?

According to Eric A. Meyer, an author and HTML/CSS expert, the answer is a definitive yes. In the following Q&A, Meyer explains why HTML5, CSS and JavaScript are the "classic three" for developers and designers. He also pushes past the HTML5 vs. Flash bombast to offer a rational and much-needed comparison of the toolsets.

HTML5's feature set

Mac Slocum: How is HTML5 different than HTML as we currently know it?

Eric Meyer: It's really the HTML we're all used to plus more elements. But that's the 80/20 answer. HTML5 adds new elements for things like sections of a document and articles, and figures and captions for figures. So it covers things that a lot of us do all the time, like create <div class="figure"> and then <p class="caption"> inside of that to go along with an image. Now there's just an element called "figure" and you insert an image and you have an element after that called "caption."

There's been an attempt to look at what people are doing. What class names are people using over and over again? What structures are they setting up over and over again? Because HTML doesn't have elements that directly address those.

The HTML5 spec also attempts to very precisely and exhaustively describe what browsers should do in pretty much any given circumstance. Older HTML specifications would simply say: "These are the elements. These are the attributes. Here are some basic parsing rules. Here is what you're supposed to do if you encounter an error." HTML5 has these really long algorithms that say: "Do this, then this, then this, then this. And if you hit a problem, here, do this other thing." There's a lot of debate as to whether that's even a good idea. But if the vision that's encoded in those algorithms is brought out -- I'm not saying it will be, but if it is, then browsers will be a lot more interoperable.

But that's the base level answer. As you push further into the more obscure corners, then the answer to "how is HTML5 different?" becomes much more complicated.

MS: Is HTML5 becoming a full-fledged development environment?

EM: I don't see it stepping forward into full-fledged programming. But I do see it pushing HTML forward so that it's a better foundation for web apps. That's one of HTML5's primary goals. There are sections of it that are devoted solely to how to deal with web application environments.

The thing that's most directly applicable to making HTML more web-application friendly is the attempt to include what's known as microdata. That's semantic information and little snippets of data that can be embedded directly into what we think of as pages right now. But these can become the views a web application presents. It's the kind of stuff that we put in cookies now.

But HTML is not getting for loops or switch statements. That's going to stay with JavaScript. In that sense, no, HTML is not becoming a programming language.

What developers and designers need to know about HTML5

MS: What skills do developers need to take full advantage of HTML5?

EM: Developers need to know HTML5. They need to know JavaScript and they need to know CSS. That's the classic three.


MS: How about designers?

EM: Designers need to know mark-up. They need to know HTML5. They need to be able to write CSS and understand web layout. And they need to have at least a decent grasp of what JavaScript does. I don't necessarily insist that everyone who ever touches the web be able to write their own web app by hand, but designers should understand how JavaScript works.

There are a lot of people who call themselves web designers who are really just designers who put their designs on the web. And there's nothing wrong with being just a designer. But they're not necessarily web designers. They're visual designers. There's a difference.

MS: Would you recommend starting with web development skills and then adding Flash and others later?

Yeah. Make that your grounding and then add things to it if you like. You're making a very dangerous bet to not have web tools at your disposal. The developer should be able to do web work. And it's not a bad idea to add Flash to the tool belt.

HTML5 vs. Flash: A rational comparison

MS: Without getting into the "Flash killer" stuff, how does HTML5 compare to Flash?

EM: HTML5 itself and Flash are vastly different. They have different things that they're trying to do. But the HTML5 plus CSS plus JavaScript package is more. I think that's an easier comparison to make to Flash because Flash is supposed to be this total environment. You can put things on the screen and you can script it and you can define interaction. And HTML5-CSS-JavaScript lets you do that as well.

We got to the point a couple of years ago where the HTML-CSS-JavaScript stack can technically do just about anything that the Flash environment makes possible. It's just a lot harder at the moment to do that in HTML5-CSS-JavaScript because Flash has about a decade's head start on authoring environments.

There are a number of people, myself included, who have been observing for a while now that the current web stack feels like Flash did in 1996. Look at the canvas demos, for example. The canvas demos we're seeing now are totally reminiscent of the Flash demos we used to see in the '96 era, where it was like: "Hey, look! I have three circles and you can grab one with a mouse and flick it. And then it bounces around the box and there's physics and collision and animation and they're blobby and woo hoo."

MS: What's your take on plugins? Are they inherently inelegant?

EM: That's been my feeling for a long time. That any plug-in is kind of inelegant and the wrong way to be going about this. And I don't reserve that just for Flash. I really mean any plug-in. The fact that we need plug-ins to play movies has never felt right.

MS: If, for a given application, HTML5 and Flash can provide the same result, why would a developer go with HTML5? What's the motivation?

EM: HTML5 is native to the medium. It's the feeling that if we're going to do web stuff, let's do web stuff. Let's not do Flash stuff that happens to be represented in a web page. So I think that's the philosophical drive.

The technical drive, to a large degree, is that companies don't want to be beholden to somebody else. And doing everything in Flash means that they're effectively beholden to Adobe. With web technologies, the only entity that can reasonably be said to hold the keys to the kingdom is the W3C. And even if the W3C for some reason turned into "evil goatee Spock" tomorrow and said "we want licensing fees," everyone would go, "yeah, no."

HTML5 and mobile applications

MS: Does HTML5 give mobile developers more latitude? Is there benefit in developing applications outside Apple's approval process?

EM: Absolutely. No question. There are some people who have argued that the whole App Store phase is a fad. Granted, a very popular and lucrative and probably long-lived fad, but that it's still a fad.

The argument is that 10 years from now we're going to look back at rebuilding apps for every mobile device and go "What the hell were we thinking?" It's the same way kids who graduate from decent web development programs today don't understand why anyone ever tried to layout a page with tables. I've had conversations with people who literally just can't understand. Even when you explain, "Well, there was no CSS." They're like, "But surely there was something better because that's just awful."

Betting against the web is the sure losing bet of technology. Over the long-term, that's where I see things going.

Note: This interview was condensed and edited.