SitePoint Podcast #89: Podcast of the Year

Episode 89 of The SitePoint Podcast is now available! This week your hosts are Patrick O’Keefe (@iFroggy), Stephan Segraves (@ssegraves), Brad Williams (@williamsba), and Kevin Yank (@sentience).

Download this Episode

You can also download this episode as a standalone MP3 file. Here’s the link:

SitePoint Podcast #89: Podcast of the Year (MP3, 44.1MB, 48:11)

Episode Summary

Here are the topics covered in this episode:

We’re Podcast of the Year!
Google Patches a Big Security Hole
Google’s Online Book for Web Newbies
Improving Perceived Performance with Spinners
Poll: What’s the Worst MySQL Mistake?
Keyboard-triggered Tooltips: Why Not?
Internet Explorer 9 Benchmark Cheating

Browse the full list of links referenced in the show at http://delicious.com/sitepointpodcast/87.

Host Spotlights

Brad: min.us
Stephan: Instapaper’s Backup Method
Patrick: Why You Need to Open the Kimono in Social Media

Show Transcript

November 26, 2010: A big Google security hole gets patched, how all spinners are not created equal, and Internet Explorer 9 cheats on a test. I’m Kevin Yank and this is the SitePoint Podcast #89, Podcast of the Year.

We did it guys! We are Podcast of the Year!

Brad: Yay!

Kevin: According to the .net Magazine that I went to London and went to the awards ceremony and I was there with Karn Broad, the producer for our interview shows, and yeah, it was amazing. We were up against The Big Web Show which one Video Podcast of the Year and well deserved to Jeffrey Zeldman and his co-host Dan Benjamin, they put on a really interesting interview show every week. But, yeah, we won the audio category guys! Congratulations.

Patrick: So paint a picture for us, Kevin, give us a visual. What was it like?

Brad: I envision like the Oscars or something. Like some grand ballroom!

Patrick: What was it like, how cool was it? Make it dramatic.

Kevin: There was no podium, but I think they did away with the podium at the Oscars a while ago now. It was held in The Ministry of Sound dance club in London, so just on the south bank of the Thames near Waterloo if you know London, that’s where The Ministry of Sound is, apparently this iconic dance club. I have several music geeks here in the office who are jealous that I was gonna get to spend an evening in the famous Ministry of Sound; I’ll be honest with you it just looked like a dance club to me.

Patrick: Oh!

Kevin: But, the nerds poured in and at about 7 o’clock they turned down the music a little and a stand-up comic who is very well known in England started emceeing, and I don’t even know his name, I don’t even know who the guy is, but everyone who is local went, “Aw, he’s hilarious! He’s on TV all the time, I need to get my picture with him because my wife is such a huge fan!” That’s a direct quote from Karn our producer, by the way. And so he stepped up and category by category called out the, well, through to the announcer who was on the PA who announced the nominees. They had like a big video done on the big screen behind him that kind of went through the nominees and showed either screenshots or bits of logos and things like that, just sort of a motion graphics kind of presentation showing off each of the nominees in each category, and then they threw back to the emcee who announced the winner. And, yeah, Karn and I — the podcast category was the very first category of the night, they called our name and Karn Broad and I stepped up and thanked the crowd. There were several cheers when the SitePoint Podcast was named among the nominees; we definitely had some fans in the audience so it was a really fun night. And after that we as winners were whisked up into the VIP lounge, which between you and me was actually the “stand in front of the sponsors banner and get your photo taken for their magazine” lounge. But, yeah, we got to chill out and hang out with other winners like Jeffrey Zeldman and Faruk Ate? who we’ve mentioned on this podcast before and is the author of Modernizr, which I think won Open Source Project of the Year, and a few other locals, Jeremy Keith, who you might know on Twitter as @adactio, was in attendance because his digital agency was nominated, Clearleft, was nominated for Digital Agency of the Year, but Jeffery Zeldman took that one out as well with Happy Cog. In fact, Zeldman won no less than three different categories at the awards; he was the man of the night for sure.

Patrick: I love us and everything, I mean we’re awesome and all that, but I have to say after seeing the initial list of nominees I was a little intimidated as far as our chances, but, not to say we don’t produce a quality show because we do, and it’s great to be honored, but I guess there was no video taken, huh?

Kevin: No. There were some photos; there was a photographer in the back of the crowd with a long lens who was taking photos of people as they accepted their awards, but they didn’t mention that to the winners, so we didn’t know where to look for the photos, so I think there might be a photo of Karn and I sort of side-on standing in front of the trophy somewhere, if I find that I’ll let you know. The awards are officially announced at thenetawards.com, this is the same site where we were asking you to go and vote for us earlier in the year, now it just lists the winners in each category, but I think they’re gonna make their big splash in the next issue of their magazine, that being #210, which I assume comes out next month. So I think Karn is going to send me a copy of that and hopefully we can see our names in print.

Brad: I think we need to make sure to thank Paul Boag for stepping aside and allowing us to actually win this thing (laughter).

Kevin: He won last year and I think yeah just quietly there was a separate video and audio category because, yeah, the Zeldman and Benjamin show is a class act and it would’ve been really stiff competition. But, yes, thank you to the .net Awards, I intend to from now on refer to this as “the award winning SitePoint Podcast.”

Patrick: Has a nice ring to it.

Kevin: Without further ado let’s get into our stories because we’ve got a bit to get through. So, Brad, why don’t you lead us off.

Brad: So, Google had a little embarrassing moment over the past week, an actual 21 year old Armenian developer found a little security hole in the Google Apps API Script, and according to him he actually contacted Google a number of times trying to report the vulnerability and could not get through. So, what’s the next best thing you can do? Well, set up a site and show everybody what you found. So he actually set up a site on BlogSpot that hosted this page and the script that he wrote, and if you visited that site and you were logged into Google or Gmail currently, any type of a Google site, the website would immediately grab your Google email and send you an email and say, hey, I just got your email. And that’s as simple as the exploit was but as you can imagine that’s a pretty big exploit especially for somebody like Google to miss. So it was actually kind of a big story there; luckily as soon as Google saw the website they took the site down, they say they fixed the exploit, and the developer actually in my mind probably did about the best thing he could have other than just reporting it. Since he wasn’t getting a response he actually set up a site to show it but he didn’t tell anybody what it was, he didn’t release this is how you do it, this is what you do, he actually just kind of showed it off from a functional standpoint, which I think is a little bit better than what I’ve seen a lot of other people do when they find exploits, so definitely hats off to him. But it was a little scary, especially Google, a site as big as Google, I mean I’m sure all of us maybe other than Patrick have at least something at Google that we use.

Patrick: Even Patrick.

Brad: Okay, even Patrick. But seeing a vulnerability as big as this that escaped Google has got to make you worry a little bit.

Kevin: Yeah. I had a look into this Google Apps Script API, and in fact before Google fixed it no one even knew what API he was using. He was as you say very tightlipped about exactly how he was managing to do it and I suppose that was fairly responsible of him to do. But as soon as Google had fixed the problem they posted a little note saying that their first response was to take down the site from BlogSpot; obviously, BlogSpot is Google’s blogging platform so they had full control over that site, but from what I have read I’m guessing this exploit did not depend on the page being hosted by BlogSpot. I think he probably could’ve put it just about anywhere. But, yeah, Google’s response says, “We quickly fixed the issue in the Google Apps Script API,” and just by saying that everyone suddenly knew exactly which API, which part of the Google ecosystem had the error in it. So hat’s off to Google, I don’t think they had to be as open as that but I’m glad they were because this Google Apps Script API is something that I wasn’t familiar with beforehand. They went on to say “That vulnerability could have allowed for emails to be sent to Gmail users without their permission if they visited a specially designed website while signed into their account. We immediately removed the site that demonstrated this issue and disabled the functionality soon after. We encourage responsible disclosure of potential application security issues to security@google.com.” That closing remark there suggests to me that what they’re saying is, uh, yeah, we know he said he tried to contact us and didn’t get a reply, well, he didn’t go through the right channels. They seem to be implying that if he had dropped a line to that very special email address they would have gotten right on to it. What do you think, do you buy that Brad?

Brad: I don’t know, I mean the developer’s name is Vahe G., and he’s not real specific about how he contacted Google, he just said he contacted Google a few different ways and they just don’t answer emails. So, you know, sure if you just email certain areas of Google it’s probably going to be very hard to get through. So, but it would’ve been nicer if he actually said I did email this, this, this and this and nobody responded, but he didn’t actually say that so it’s hard to say. I mean I know you can only imagine the amount of emails that Google gets a day across their various services, so it’d be very easy for an email or two to get lost I’m sure.

Patrick: If you Google ‘Google Security’, oddly enough—and not to say they couldn’t have changed this because obviously Google controls the index—but if you Google it my first hit here, the first site listed is google.com/corporate/security.html, and actually in the description of the search result is the email address, security@google.com, so it seems like it would be difficult to miss if you searched for it via Google anyway.

Kevin: Yeah, I see that! My first result is the Google Online Security Blog at googleonlinesecurity.blogspot.com, and hmm, was last updated Thursday, November 11th, so they have not talked about this particular vulnerability on the Google Online Security Blog. But I think it’s more about helping—

Patrick: General Internet safety and security.

Kevin: Yeah, yeah, exactly. So this API, this Google Apps Script API that had the vulnerability in it, I had a look at the documentation for it and it’s really a lot like— I don’t know if you, listener, have been around long enough to remember the heyday of Microsoft Office and when everyone did … like there were a lot of businesses whose accounting hung off of intricate combinations of VBScript running in something like Microsoft Excel or something like that. But these scripting languages that run inside of your office applications. Well, Google Apps Script API is really the Google Apps version of that, so if Google Apps is your office suite in The Cloud then the Google Apps Script API is what lets you write these scripts that run within your office suite in The Cloud. So rather than being like JavaScript that runs in your browser this is scripts that you write and deliver to Google and then Google runs them on their servers against the documents and data that you store in your Google account. And it looks like if I had to guess, given the evidence at hand, what the developer discovered is one of the APIs, one of the parts of Google’s Apps that you can get at through this API, is your Gmail address book. And I don’t know if he was able to somehow exploit that part of the API to get the currently logged in user’s address or even it was something just a whole lot simpler, that the API did expose your Google account name and that he from that could guess your Gmail account and send you email, something like that. But the fact that any old site, a BlogSpot blog page for example, could do that using JavaScript is a bit scary so I’m glad they fixed that.

Brad: It’s kind of funny, if you look at the — TechCrunch has a screenshot of what the website looked like before they took it down and it actually has Google ads all over it (laughter). Not only is there an exploit but at least there’s some Google ads on there too.

Kevin: Well, you can’t fault the guy for trying to make a little pocket change in the process. It’s a tough life being a security researcher; no one wants to pay you anything.

Patrick: No one even wants to respond to your email.

Stephan: Until you get hacked.

Kevin: Yeah. Another Google story is something that I picked up from the SitePoint Tech Times newsletter this past week from Louis Simoneau, our lead technical editor here at SitePoint, and this is a comic book from Google called 20 Things I Learned about Browsers and the Web. Not a comic book, just an online book, sorry, I’m just used to Google expressing everything they have to say in comic book form, it seemed like that’s what they were doing for a while there. But this is a site, 20thingsilearned.com, where the 20 is a number, 20thingsilearned.com, and this is a very slick presentation of an online book, and it’s a book that’s— You remember when we talked about that story where what was it less than eight percent of people stopped on the street in New York City knew what a web browser was?

Brad: This is the book they should be reading?

Kevin: Yeah, it seems like Google took that to heart and went alright, well, we’re gonna write the book on this stuff. And so it explains in layman’s terms with really sort of charming illustrations by an artist named Christoph Neimann, how the Web works. And you can flip through this thing and if you’ve played with these, you know, the slick e-book reader experiences on things like Apple iPad where you get that very tactile kind of page curl effect, well it’s the same thing as that, you get that sort of thing. But the illustrations a lot of them are animated and it’s all done with HTML5 web technology and it’s pretty impressive. I notice one of the things in the prologue that they talk about is you get to find out what happens if your laptop gets run over by a truck, and I flipped through to that page to find out and it turns out that’s in a chapter called Cloud Computing where they tell you that it’s okay if your laptop gets run over by a truck as long as you store all of your data in The Cloud using Google services. (Laughter)

Patrick: Did anyone get a Dr. Seuss vibe on this because it’s listed as Thing One, Thing Two, Thing Three and so on, and they have little guys dressed in red.

Brad: Yeah, as soon as I saw Thing One that’s actually the first thing that popped in my head, especially with the graphics.

Patrick: The idea of Cloud computing it was interesting to read that part about how — no, it wasn’t Cloud Computing, what section was it, it was another section that talked about keeping your data in The Cloud and how it was better for safety. I think it was using apps, using the Web apps, how it’s safer because you don’t have to download things, and I thought well that’s one way to look at it I guess. You know me and The Cloud, so, yeah.

Brad: I really like that Google’s done quite a few of these little sites about various different topics, but they’re really — I mean at the end of the day they’re really showcasing some really cool HTML5 stuff here.

Kevin: Yeah, that’s true. If you haven’t spotted it try clicking the little light bulb switch in the bottom right corner of the page, you can switch the page into dark mode if you’re reading in the dark and it does a really nice fade. It’s all very slick; I haven’t had a look at the code behind the scenes to see how accessible this is, for example, if you have JavaScript turned off. In fact, I’m gonna try that now, I’m gonna disable JavaScript and reload this page and see what happens.

Patrick: And when Kevin’s Skype connection crashes we’re gonna be in a lot of trouble.

Kevin: I get a completely blank page. This is not nice. Okay. With JavaScript turned off you just get a completely blank web page, so that’s not a whole lot of fun. Even though if you look at the markup of the page there’s plenty of content there. Seems like JavaScript is required on the Web these days, that’s one of the 20 things I learned about the Web by reading this book. A nice touch I found is if you go away from the site and come back it will offer to let you resume reading where you left off last time, very nice.

Improving Perceived Site Performance with Spinners is a blog post on the YUI Blog. Again, this is from the Tech Times Newsletter, Louis Simoneau put together a nice list of what’s new on the Web links, and I grabbed a couple of those for the show today because they really pushed my buttons. And this one is a story explaining how it’s pretty well known that if you’re gonna make your users wait you want to show them some sort of animation or give them something to look at, hopefully something that moves whether it’s a progress bar or a spinner if you don’t have a way of determining exactly what progress is being made. But if you give them something to look at, something that moves, you’ll give them the feeling that something is happening and it makes that wait feel less long. Well, it looks like Yahoo! has done some research here, or in fact Piotr, they say, who spoke at the London Ajax meetup this week, “Piotr, one of the creators of the rather good jsfiddle.net talked about spinners, the pretty common ‘I’m doing something’ indicator and how users perceive them.” And he says that depending on exactly how it’s displayed it can give a different sense of the time that’s passing or how long it takes. Have you guys ever experienced this where you’ve watched a spinner and felt time slow to a crawl because it just is doing the same thing over and over and over again?

Patrick: I think the idea of a loading screen in general, I don’t know, it’s the same kind of thing in principle, right, is loading something whether it be like a Flash animation or just one of those spinners. I don’t know, I don’t know that it’s ever had much of an effect to me, but the idea for me is that if it’s loading, it’s loading, and that’s what it’s showing me. But if it’s not showing me it’s loading I just assume it’ll be there in a second, so I don’t know, maybe a blind assumption.

Kevin: I’m playing with the example they have here, and this survey that he ran and it shows two buttons and you can click load A and load B and when you click load A it shows a little progress spinner and then completes. And if you click load B it does a similar thing but just with a slightly different presentation. Reading again from the blog post here, “When you click the button there’s a delay before the spinner is shown and then a short random time later the results are shown, then you click another button and the same thing happens and then you say which one is faster.” And according to the results “By delaying the display of the spinner slightly users perceive things to be happening quicker, but if you wait too long they start to think that something’s broken, 0.4 seconds seems to be the optimal delay.” If you let them click and then before you display the spinner rather than displaying it right away you wait 0.4 seconds and then display the spinner. It’s like when the spinner appears the user‘s brain resets and goes, okay, I’m seeing the spinner now I’m starting to wait, and it then loses track of that original 0.4 seconds that you waited and makes the whole thing feel a little faster, very interesting.

It’s like the amount of time that the spinner is displayed is interpreted as the amount of time the wait, and the longer you can get away with without making it look broken the better the result, very interesting.

Patrick: Put this knowledge into action today.

Kevin: Yeah, exactly. Something we did last new show that I wanted to do again this week was take a look at the SitePoint Poll because I had a lot of fun when we talked about whether, what was it, whether Silverlight was dead or not. And the SitePoint Poll this week is, and there’s a whole blog post and forum thread associated with this, but I thought we could just sort of shoot from the hip here and this one’s especially for the developers amongst us so, Brad, pay attention. What do you think the worst MySQL mistake is, A) not using Innodb, B) not using PDO or MySQLi, C) not using Input Validation, or D) not using UTF-8?

Brad: For me I would definitely without a doubt say Input Validation. I mean if you’re not sanitizing any type of user input right into the database you’re just asking for SQL injection. And that’s something I remember back to one of my — back when I was learning classic ASP and I was real active in the classic ASP section of the SitePoint Forums. I was still learning and one day one of my larger sites was hacked, like all the information was wiped out and ‘you’ve been hacked’ messages everywhere and I couldn’t for the life of me figure out why, and that’s the day I learned about SQL injection and I had this thread I bookmarked and I look at it maybe once a year because it brings back some, well, not great memories but memories nonetheless. And that was literally people in the forums walking me through. This is SQL injection, you’re not validating anything you’re doing in your queries. So ever since that day that’s always been a really key aspect of anything I develop is to make sure that it’s — the input is validated as absolutely tight as it can be.

Patrick: That sounds like a scavenger hunt idea for SitePoint Podcast listeners, find that thread and put it in the comments (laughs).

Brad: It’s out there. It’s probably from like 2001, 2002 maybe.

Patrick: No, no hints!

Brad: Oh, sorry, it’s out there.

Patrick: Okay, well, there you go.

Kevin: Stephan, what do you think?

Stephan: Oh, I have to agree with Brad. I don’t think any of the others, I mean they’re mistakes but I wouldn’t say they’re catastrophic like Input Validation, lack of Input Validation. I mean I agree with Brad, it’s the worst thing you can do.

Patrick: Third it. Third it, Kevin, third it.

Kevin: Oh, yeah, you think Input Validation as well. Well, I’m not sure Input Validation qualifies as a MySQL mistake, to be honest.

Stephan: Oh, come on, semantics.

Brad: Oh, boy, is this a trick question? He totally set us up for this one.

Kevin: (Laughs)

Patrick: You have access to the SitePoint backend, edit the poll. No, I’m just kidding.

Kevin: Yeah, I could, I could. Well, yeah, you know what I mean though; Input Validation is something that you do at the level of your scripting language before you get to your database. And, yeah, I would totally agree that if we’re just talking about problems you can make in web development not validating your input is a pretty huge one, and you end up in the front page of TechCrunch just like Google did this week because people discover ways to insert stuff into your site that you didn’t intend them to or you didn’t expect them to, and often to catastrophic results. But, yeah, I’d call that a scripting issue whereas some of the other ones, Innodb of course is the preferred database engine for use with MySQL these days but it’s not the default. When you first set up MySQL by default if you create a new table and you don’t tell it what type of engine to use it’s gonna use the older MyISAM engine which is really fast for doing select queries on just out of the box, just raw select query performance is really good, but as soon as your queries get complicated or you’re doing a lot of writes into your database things slow down, especially because MyISAM doesn’t support this thing called row-level locking where it’s able to be writing one record in the table while selecting another part of the table. And those sort of high tech features are what make Innodb in practice perform a lot better, and so yeah, we several times have accidentally broken our MySQL configuration and we’ve wondered why a particular application has suddenly slowed to a crawl and it’s because the session table that’s getting updated for every single page request on our site is a MyISAM table all of a sudden, it slows right down.

Patrick: So what you’re saying is that it’s not a fair fight here, it’s not a fair fight, because one of them essentially allowing people to execute whatever they want on your website.

Kevin: Yeah, yeah.

Patrick: It will always sink the boat.

Kevin: PDO and MySQLI, those are features of PHP that make dealing with a MySQL database better, they’re a more modern API, and so I’d say yeah you probably should be using something like that, but it’s not a huge deal if you don’t. UTF-8 just means that you’re accommodating larger numbers of characters and storing them properly in your database whereas, again, the default that you get out of the box with MySQL is they use Latin-1 character set that’s not aware of these things like curly quotes and things like that, and so when those get stored in the database they get stored and retrieved correctly but your database doesn’t know what it’s dealing with so it’s not an ideal situation. Let’s take a look at the results here and, well, it looks like the SitePoint Community agrees with you guys because Input Validation has won with 58% of the vote, Innodb 12%, PDO and MySQLI 12% and UTF8 18%. But, yeah, it looks like no one cares about semantics (laughter), Input Validation is a big enough problem that if you have that problem it’s a problem across everything you do. Alright, Input Validation wins. Validate your input boys and girls.

Why aren’t tool tips triggered by the keyboard? This is a question raised by James Edwards, a frequent blogger for sitepoint.com, and he’s well known as an accessibility guru. And he is wondering out loud in this blog post on sitepoint.com whether the tool tips you see when you hover over things with your mouse should also appear when you tab to them with your keyboard. What do you think guys?

Patrick: I don’t really tab to things with my keyboard except to text fields so it’s not really an experience that I have thought of.

Kevin: Well, this is something that you could definitely do. If you put a title attribute on the fields in your form you could have these sort of pop-up tool tips that assist you with filling in those fields, but I guess no one does those because generally people don’t hover their mouse over their form fields, they tab to them or they click on them to give them focus and then they start typing. So I guess what he’s suggesting, especially for keyboard users who would want to be able to access things like tool tips on links and stuff like that, that you would put again with a title attribute, currently there’s no way of doing that, right now you have to hover with the mouse if you want to get that information. And, yeah, I guess he’s wondering if those tool tips would be improved, would be made more functional, more accessible if browsers displayed them when you tabbed to things. Obviously, yeah, Patrick if you’re a mouse user, and I guess most people are, you would never see them then, at least not from keyboard focus, you’d still see them from mousing around. So I guess what you’re saying is they wouldn’t get in your way if they did?

Stephan: It doesn’t affect me either way, right, if I’m using my keyboard I don’t usually tab through a website. I’m on the SitePoint page and it takes me forever just to get to what I want if I’m tabbing.

Kevin: Yeah, yeah. Definitely.

Brad: Yeah, I’m kind of, I mean I’m the same way, I’m a mouse user certainly, but I’m kind of of the habit if there’s something, a button or whatever on a site and I’m curious if it has more information I usually just hover it to see if there is more, and a lot of times there is these days, so it’s kind of become a habit that if I’m looking for more information I’ll hover whatever that item is and see what pops up.

Kevin: This of course is an accessibility issue because there are users out there who for whatever reason have motor impairments and they can’t use a mouse and so they use a keyboard or sometimes even like a wand that they hold in the mouth that they then tap the keyboard keys with, and therefore they are entirely interacting with the Web through the keyboard. And browsers like Opera especially have an especially good support for keyboard navigation, but all browsers these days have at least basic support of tabbing through all of the elements, or all of the clickable elements in the page anyway, and allowing you to focus them one at a time and then interact with them. On the surface I think it would seem like having the tool tips appear on keyboard focus would be a good thing for these types of users, it would improve the accessibility of the information that you probably couldn’t get at otherwise if you weren’t a mouse user. But when I was thinking about this it occurred to me that even if you are a mouse user and you don’t tab around the page you still do move keyboard focus around the page, so as you said, Patrick, if you click in a form field you are effectively doing the same thing as someone who would tab to that form field, you’re giving it keyboard focus. And if at that point the browser went, oh, he’s put keyboard focus on that field, I’m going to display the tool tip, I’m not sure that would be ideal, that tool tip might cover some other label or some other part of the page that you were referring to when you wanted to fill in that form field and that wouldn’t be too great.

Patrick: Right, yeah, that’s a good point. I was thinking about that but I guess I was thinking of like when I mouse over something and a tool tip pops up it doesn’t steal focus, but I mean if it did steal focus that would be an issue obviously.

Kevin: The other thing that I thought is sometimes, I don’t know if you guys do this, but sometimes a form is really complicated and you’re not really sure what the difference between two fields are, and so you might want to have your keyboard focus in one field but go and check the tool tip that’s applied to another field. I know we’re splitting hairs now, but this is like the more I think about it the less easy a problem this is to solve and I guess that’s why browsers still haven’t implemented a way to access tool tips using the keyboard. I bet Opera could figure out a way though, it seems like Opera always leads the way with these kinds of features, the slight accessibility refinements that push the Web forward into slightly more polished territory. These obscure things that the majority of users would never even notice or care about, it seems like Opera tends to be the browser that sweats those details.

Well, I like James Edwards’ blog posts on this sort of stuff because there’s always great food for thought. This thing that we take for granted about how the Web works you realize wow, yeah, there’s a whole class of people out there that they’d never be able to see the tool tips in a page.

Patrick: And now our story that helps grow our listener base.

Kevin: (Laughs) Oh, it’s the Internet Explorer story.

Brad: Yeah, there’s trouble afoot, or allegations afoot I should say that Internet Explorer 9, which is still in Beta, might have cheated a little bit or maybe fudged some numbers on the SunSpider JavaScript Benchmark Test, which is becoming one of the standard tests to kind of benchmark a browser JavaScript engine. So Rob Sayre, a Mozilla engineer, which is kind of interesting, first discovered this and he says IE might be cheating. He noticed that Internet Explorer 9 was around 10 times faster than all the other browsers he tested in a particular test which is the math quartic test. So what he did is he made a few modifications to that section of the test, and one was by adding a true value and by adding a return value which essentially do nothing just to see what would happen. And after he made that change it took Internet Explorer 9 twenty times longer to run the two new tests versus the original which was a big red flag on why would adding two things that virtually do nothing increase it to 20 milliseconds versus one millisecond on that test.

Kevin: Especially since Google Chrome and Opera, which he also did the same tests with, they as you would expect showed very minimal differences in the timing when he made those changes to the code.

Brad: As they should. I mean you know adding two lines of code that essentially do nothing, or they were two separate tests but changing a little bit in each test that basically does nothing should have little to no effect on the runtime, but it had a major effect on Internet Explorer 9 which raised some flags. But Microsoft actually came out and they kind of explained what happened and they’re blaming this on what they called Dead Code Elimination. And they actually explained it pretty well, I was reading a few different posts, so from the Internet Explorer Blog they explained, “Dead code elimination optimizations look for code that has no effect on a running program and removes the code from the program. This has the benefit of both reducing the size of the compiled program in memory and running the program faster. And essentially the benchmark test is an expensive loop that essentially does nothing.” And so what they’re saying is IE9 actually recognizes that, rips out all the code that does nothing, which is pretty much the test, and that’s why it’s running 20 times faster than all the other browsers, so that’s Microsoft’s answer.

Kevin: So whether it was malicious, or—I’m not sure if malicious is the right word. Whether they were knowingly being duplicitous or not they are admitting that Internet Explorer 9 kills on this particular benchmark simply by recognizing that it’s not worth running and not running it at all. So it sees this code it goes, oh, that code doesn’t do anything useful, I’m just gonna skip it, and that’s how it kills at this benchmark. So they’re basically saying that if you want meaningful performance results you need to write a better benchmark. But, looking at the discussion that went on on Hacker News around this it seems like, I don’t know, they’re calling it into question a bit. For example, the dead code in question is a for loop in the test, and someone on Hacker News just rewrote that code as a while loop, which if you know your JavaScript you know that a for loop is just a fancy way of expressing a while loop with a counter variable in it most of the time. And so re-expressing it as a while loop doesn’t change the meaning of the code, doesn’t change what the code does, in fact, the internal representation of that code by the browser should be pretty much the same. And yet, just making that change from a for loop to a while loop is enough to fool Internet Explorer into not recognizing that the code is dead and running it. And so what the skeptics are saying is that, Microsoft your “dead code elimination”, is oddly specific to the exact code that was used in this benchmark. It’s as if their dead code elimination was written specifically to eliminate tests from this particular benchmark, not from real world code. What do you think, Brad, do you buy Microsoft’s story?

Brad: I want to, but at the end of the day it’s Microsoft.

Patrick: Sure you do, Brad, sure you do. You really want to; I can see you falling over yourself.

Kevin: (Laughs)

Brad: Hey, you know what, I’m a huge supporter of Windows 7 so nobody can say I hate everything Microsoft.

Patrick: Oh! A long-time supporter.

Brad: Long-time supporter from day one, so I want to believe them, you know, who knows, it’s a Beta, I think it’s one of these things that’ll go back and forth and when the final version comes out we’ll see where it’s at. It’s hard to say, it is kind of interesting that all these different changes they’re making and it’s spitting back quite a bit different results, but it’s a Beta at the end of the day, so maybe there are some bugs in this dead code elimination process.

Patrick: I wish Microsoft would’ve just come out with some swagger on this and not even gave an explanation and just said, you know what, this is us saying take your benchmark and shove it, it means nothing and just throw some swagger on this thing and sound really cool going about it but, no, they have to have an explanation.

Kevin: I don’t think Microsoft can afford much swagger with web developers these days.

Stephan: I love a good conspiracy theory.

Kevin: Yeah?

Stephan: Yeah, this is enjoyable.

Kevin: What I like is that the numbers that were revealed show the true performance though. If the dead code elimination renders this particular benchmark the results meaningless, well, then by simply adding those bits and pieces that do nothing and then running that code again across all the browsers, the table of results in the story here tell the story, which is that as of right now Google Chrome and Opera are still faster browsers than Internet Explorer on this particular test. With the extra do-nothing code added Google Chrome passes the test in about 9 ½ seconds, Opera runs the test in about 7.9 seconds, sorry, not seconds, milliseconds, and Internet Explorer is way up at 20 milliseconds. So, it’s true that whether intentionally or not the dead code elimination here is making it appear like Internet Explorer runs faster on this test when in fact it runs slower. How much these tests have to do with real world performance is the big question, and if Microsoft wrote a big article about dead code elimination and how it actually sped things up in the real world that’s something I’d be really interested to see because if they can get more performance out of their browser by skipping code that doesn’t need to be run, if they detect that code in the real world even though the code they do is run more slowly, then great, that’s a valid approach I’d say.

Stephan: Yeah, because I always put empty for loops in my code.

Kevin: (Laughs) Yes, point taken, that’s the big question I have, whether this has anything to do with real world code.

So let’s talk about the real world with our host spotlights, these are things that we look at every show that we four hosts have noticed in the real world that we think are worth your attention. Brad, why don’t you start us off.

Brad: Sure. My Host Spotlight is a website called Min.us. And I love domains like this, I don’t know why but they’re catchy. And basically it’s probably the simplest photo sharing site I’ve ever seen. And I like photo sharing sites, everyone’s very social, we’re always sharing photos, so the easier you can make it on me the better, and literally you load this site up and it says just drag pictures onto the page. So you can drag one picture, you can drag 50 pictures and drop them in your browser and it will load them all up into a little gallery, it’ll give you sharing links for each individual image as well as the gallery, it will give you a zip download link, it’s really cool and it couldn’t be easier. So it just popped up a month or two ago and I just got wind of it the other day, but it’s a pretty slick little app.

Kevin: It seems like they’d have to have some sort of limits to keep you from putting your whole 50 gigabyte photo library on there.

Brad: Yeah, I would imagine. I wasn’t one of those guys that dropped 10 gigs worth of photos to see what happens, but I’m sure someone’s tried it so I would imagine there’s some type of limits.

Kevin: Very slick though. Stephan what have you got?

Stephan: Well, I’ve been a big Instapaper supporter on this show.

Kevin: Oh, yes, you and me both.

Stephan: But I was reading Marco’s blog and he has a really write-up on how he’s doing his backups for Instapaper and his method for backing up his code and the database, and I thought the database portion was relevant to the show just because we were talking about MySQL just a minute ago and his database method uses MySQL replication and it writes the binary log, which is a feature—I don’t know how many people are familiar out there with this feature—but it contains the events that happen to the database and you can go back to these events and bring, if someone destructively inserts or deletes from the table, we can go back and look at the events and rebuild the database based on those events. So he goes through this process and it’s really neat, it’s a good read if you’re a database developer or a MySQL/PHP guy.

Kevin: Yeah. This is something we talked about I think was it the Magnolia Bookmark sharing service when they lost their database and we said it would be great if more web services were public about their backup strategies. This is exactly what I had in mind when we were talking about that.

Stephan: Yeah, I mean this is a good strategy for sites where you can have a master and a slave database, I think this is really cool to have.

Kevin: Patrick, what do you got for us?

Patrick: So my Spotlight is a blog post by Jay Baer over at convinceandconvert.com, and the post is called Why You Need to Open the Kimono in Social Media. And my favorite part of the post, the part I want to highlight are the two videos in it. So what happened was the Boston Bruins they’re a hockey team in the NHL, National Hockey League, here in the U.S. and there are teams from Canada as well, and someone posted a video online, about a 20 second video, and it was of a Bruins fan I guess, they were dressed as a Bruins fan, damaging a portion of the restroom where the Bruins play their games, basically kicking a pillar and it becoming a hole, and it looks like they hurt themselves and basically they’re damaging property. And they posted this online; you can’t really see their faces very much.

Kevin: It’s like a security camera video?

Patrick: Two people, one person kicking something and one person recording it, so it’s amateur footage, right, so what happened, the cool part of this, the funny part, is you have to check out the second video because the Bruins actually put out a response video to this video of someone damaging their property. And if you haven’t followed their Bruins Hockey Rules campaign, basically they have a — their mascot is a bear, a Bruin, and so they have a person in a bear suit who has been in their commercials and online and I think on television as well giving the rules of being a Bruins fan and rooting for the team. So, in this particular video the bear is fixing the hole and patching it, and I don’t want to give it away because I can’t do it justice but it’s a short clip, the sound in it and the whole thing, it’s excellent, it’s really cool, it’s really funny and probably maybe the most interesting thing is that they turned it around in 18 hours. So they recorded this video, they shot it, the edited it, they got approval for it, they got it online in 18 hours, and I think it’s a great example of an organization using kind of the Internet and social media to generate and positive buzz and respond to something and just get the name out there. So it’s a really funny video, definitely check it out.

Kevin: Amazing. If you haven’t listened to Podcast 88 we have our interview with Jay Baer and Amber Naslund, the co-authors of The Now Revolution book, and yeah, we talked with them for several minutes at BlogWorld Expo and that’s a great interview worth checking out if you want to hear more stuff along these lines.

Patrick: That’s a good mind there, Kevin, I totally forgot about that.

And that brings this show to an end. Guys, let’s go around the tables.

Brad: I’m Brad Williams from webdevstudios.com and you can track me down on Twitter @williamsba.

Patrick: I’m Patrick O’Keefe of the iFroggy Network, I blog at managingcommunities.com, find me on Twitter @iFroggy, i-f-r-o-g-g-y.

Stephan: I’m Stephan Segraves, I blog about getting groped by the TSA at badice.com (laughter) and you can find me on Twitter @ssegraves.

Kevin: That’s a booming business that TSA blogging at the moment.

Patrick: They may need to dedicate a domain name for that one.

Kevin: Yeah, gropedbythetsa.com, get it now. You can follow me on Twitter @sentience, and follow SitePoint on Twitter @sitepointdotcom, that’s sitepoint d o t c o m. Visit us at sitepoint.com/podcast to leave comments on this show and to subscribe to receive every show automatically. The SitePoint Podcast is produced by Carl Longnecker and I’m Kevin Yank, thanks for listening. Bye, bye.

Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.