Nerdlife

Totally forgot to post this, but I’ll be the speaker at tonight’s (Monday July 27) Boston WordPress Meetup at Microsoft’s New England R&D Center (1 Memorial Dr in Cambridge). If you’re interested in hearing about WordPress plugins, or WordPress in general, feel free to show up. Should be a blast!

I’ll post my slide deck after the presentation.

Ryan, my mentor from when I was at MoCo, wrote an excellent article on spriting a few days ago. Man, I miss all the good conversations…that’s what I get for not subscribing to the webdev feed. That’s all changed now.

I have an interesting history with spriting. For both of my internships (Mozilla and Yahoo), one of my first projects was to sprite sites (AMO & Yahoo! Real Estate, respectively). AMO is still using my work (for now), and YRE long ago gave up on rounded corners, and have few icons now, so spriting is more or less useless for them now.

I guess that qualifies me to weigh in a bit. I’m not going to talk about the memory usage or anything on the client-side past delivery for two reasons. First: size in RAM has a tiny impact on page-loads compared to downloading for most users. Second: I’m horrible unqualified to talk about how web browsers load and store images in ram. Not my field.

There are some issues (many fixable) with spriting:

• In both instances of spriting I got an email a few months after I left the company asking me where my source sprite file was located. Once it was due to me not putting the file in the right place, but the fact still remains that a source sprite file is one more thing to lose, and losing it is pretty annoying.
• Not everyone knows how to compress images properly. If you do it wrong, you’ll end up with a huge PNG file that is worse than a bunch of small files.
• Spriting removes any connection between CSS styles and the images they are associated with. If I want to know what a class with a background image looks like, I have to either find a reference to it on the site, or figure out where the hell -123px -72px is. It’s more or less obfuscating your CSS.
• repeat-x or repeat-y images need to span the whole width/height of the sprite…they should have their own sprite files (if you have enough of them)
• Like Ryan said, images that are supposed to be near the left of an element (i.e. they need an arbitrary amount of space to the right of them) should be at the right side of the sprite. This makes an internationalized site that supports right-to-left text (an insanely difficult thing to achieve, and something which many MoCo sites do impressively well) much more difficult. It’s very frustrating to discover halfway through that your sprites show up wrong in RTL. Not many sites need to worry about this, but it’s annoying if you do.

With that being said, spriting can be useful when done properly. A very good example is how Yahoo Mail sprites. They group similarly-size things in a file. They have an icon file, a rounded corners file, etc. This makes things easier to manage, but still suffers from some of the above issues.

I don’t know how Yahoo’s build process works, but to make sprites worth it I would propose some kind of CSS build step. Ideally all the developer would have to do is specify which images are displayed which ways (whether there needs to be whitespace to the left, right, top, or bottom), and the system will build the sprite and generate a complied CSS file that is minimized and concatenated.

AMO’s build process got halfway there. It was originally a shell script written by yours truly, converted to python by FWenzel. The shell script is described here (the python script is essentially the same). It concatenates a bunch of files, compresses them with YUI Compressor, and creates a PHP file with the current revision numbers (to append to the URL for long expires headers). Pretty standard web build system.

I’d really love to see a system that also parses out background*: rows with comments at the end (identifying what type of spriting should be done), places them, replaces the URL, and adds a background-position. That, combined with AMO’s build process, would allow an algorithm to determine what’s best for download times vs. memory usage.

The best part: an automated system would easily allow bucket tests on load times based on different sprite files. Now wouldn’t that be useful?

I know I’m a little late on the bandwagon, but I’m sick of seeing articles claiming Google is losing so much money from YouTube. They’re based on estimates that I find a little absurd.

Let’s take just one example – http://www.internetevolution.com/author.asp?section_id=715&doc_id=175123&:

Disclaimer: I’m going to use low-ball estimates to guess where Google stands. I am by no means a professional when it comes to estimating this, or even educated in such things, but I feel like Google has so many tricks up their sleeves that I have only slightly less credibility than Credit Suisse or Bear Stearns. I repeat: I am making up numbers

Bandwidth

Maybe I’m not understanding something here, but from what I know a mutually beneficial peering agreement doesn’t require paying for anything other than labor or hardware. ISPs don’t want to provide users with fast internet without having it bounce around too many places, as does Google. Assuming Google has a datacenter close enough to every major ISP to just peer to them (not unreasonable), their only potential non-labor cost is communication between their datacenters. But wait! Hasn’t Google been buying up dark fiber left and right? That means their costs are adding additional capacity and redundancy, plus network maintenance (hardware and labor). Like I said, I’m not a hardware guy, but knowing people who owned datacenters, this is how I understood it. Please call me stupid if I’m wrong, but I’m going to cut this down to $10,000 (~$3.5M/year).

Revenue Share

This one’s just BS…they’re counting “making less money” as an expense. Sure, it’s less money, but that’s a little misrepresenting, no? Plus, I assume the estimating companies already took this into account. $0

Content Acquisition

Google isn’t dump…I doubt they’re putting themselves in the red solely on content costs. Media companies also get a huge amount of exposure from being on YouTube that they can’t get anywhere else (Excluding TV shows and Hulu, but YouTube mostly deals in music videos anyway). So let’s cut this in half and say $360,000 (~$131/year, a lot of clams, and generous in my opinion!).

Hardware

“Given market estimates of about $2 per gigabyte”. Really? Google is famous for using off-the-shelf hardware. I can buy a 1TB HDD for $100, and I’m not buying a million of them. I’m not saying this quote isn’t accurate when you account for electricity, cooling, redundancy, etc, but Google is far above the average for all of these, so I feel like using a market estimate is unfair. I’m gonna cut this in half, so $18,000 (~$6.5M/year).

New Results

Let’s calculate Google’s break-even point for YouTube:

Now I’m not saying that Google is definitely making money off of YouTube, but $630K/day is less than Credit Suisse estimates Google’s daily revenue at, so it’s entirely possible they’re in the black.

http://sc08.supercomputing.org/html/CarnegieMellomExcels.html (Mellom?)

I was invited to compete in the SC08 student competition last November (yes, I’m behind on my blogging, I know). It was a fun couple of days: it’s amazing how much companies spend on convincing other companies to buy things from them. Some highlights:

• Microsoft dressed up all of their booth reps in AstroTurf (they had a golf theme)
• One of my teammates won a Wii raffle
• There was more computing power than I’d ever seen
• Winning the competition after 8 hours locked in a conference room coding

I’d like to give two incredibly huge thank yous:

First to the Pittsburgh Supercomputing Center for sponsoring the trip. They were really great, letting us do more or less what we wanted, and paying for everything. Thanks for putting up with us Laura!

The second to nVidia for their last minute donation of a prize. My entire team got Tesla C1060 GPGPUs. These things are insanely powerful: we got to program on them for part of the competition. Talk about generous: we had already won and it came up in some post-victory chats with nVidia reps that we got to program with their CUDA architecture (surprisingly easy), so they figured they’d let us keep coding on them. Now all I need is a kilowatt PSU and a mobo with 2 PCIe slots. Either that, or the card pays for my upcoming trip to San Juan .

Recently I’ve been working on a project that involves a lot of data visualization, with a lot of non-technical stakeholders. I needed a way to both play around with the ideas in my head and convey these ideas to non-technical colleagues.

I’m not a fan of HTML prototyping, since I find it takes too long and results in too much detail work, and Photoshop seems like overkill. Luckily, I follow Hacker News religiously, which had a few links to the Balsamiq blog over the last few months. So I gave Balsamiq a try, and boy was I impressed!

Balsamiq is, in its simplest form, a drag-and-drop board with a bunch of UI elements. But the incredibly simplicity of it really works, as it gets you down to the basic components of a page. My only gripe is that this does get frustrating for customized uses. For example, I wanted to show certain types of charts, but instead had to settle with doing funky things with their “progress bars”, which only matched the shape of my desired elements. I’d really like to have the ability to add my own UI elements. Also, pulling images from the web reloads them constantly instead of just downloading the image locally.

All in all, one of the few applications that I would be willing to actually pay for. Also, a great demo of what can be done with Adobe Air, and actually makes me want to poke around with Flash for the first time in years…this is an entirely new niche for Flash.

Full disclosure: Balsamiq gives away licenses to bloggers, so I didn’t actually pay for it, but I was on the verge of pulling out my credit card when I saw that exception.