Apple have finally unveiled a tablet computer, the iPad. The anticipation leading up to this launch and the speculation surrounding it has been truly staggering. Yet I find myself strangely underwhelmed by the device.

Continue Reading…

Netbooks are the endpoint of four decades of computing — the final, ubiquitous manifestation of “A PC on every desk and in every home”. But netbooks are more than just PCs. If the Internet is the ultimate force of democratization in the world, then netbooks are the instrument by which that democracy will be achieved.

A well-written and informative overview of the request/response communications between client and server over the HTTP protocol.

An online tool that makes it easy for you to create, link together, preview, and share mockups of your website or application. Wireframes, on-the-fly, in the browser. Cool.

Mark Pilgrim offers a fascinating insight into early HTML development and concludes with the interesting, yet arguable, statement, “The ones that win are the ones that ship.”

But none of this answers the original question: why do we have an <img> element? Why not an <icon> element? Or an <include> element? Why not a hyperlink with an include attribute, or some combination of rel values? Why an <img> element? Quite simply, because Marc Andreessen shipped one, and shipping code wins.

That’s not to say that all shipping code wins; after all, Andrew and Intermedia and HyTime shipped code too. Code is necessary but not sufficient for success. And I certainly don’t mean to say that shipping code before a standard will produce the best solution. Marc’s <img> element didn’t mandate a common graphics format; it didn’t define how text flowed around it; it didn’t support text alternatives or fallback content for older browsers. And 16, almost 17 years later, we’re still struggling with content sniffing, and it’s still a source of crazy security vulnerabilities. And you can trace that all the way back, 17 years, through the Great Browser Wars, all the way back to February 25, 1993, when Marc Andreessen offhandedly remarked, “MIME, someday, maybe,” and then shipped his code anyway.

Mark Nottingham tells us about Traffic Server: [via]

A long time ago, the word in high-performance proxy-caching was Inktomi’s Traffic Server. It was so fast it was referred to as being “carrier grade” and this could be said without people smirking, and it was deployed by the likes of AOL, when AOL was still how most people accessed the Internet.

A few years ago, some Yahoo! engineers found that code sitting on a shelf and decided to have a play. What they found was that it was still faster than pretty much every thing else out there. So they started using it, and built a team around it.

Fast forward to today, when the source code for Traffic Server is suddenly available as an Apache Incubator Project.

John Resig of jQuery fame has given up on Google Groups due to its total mismanagement of spam:

The primary problem with Google Groups boils down to a systemic failure to contain and manage spam. Only a bottom-up overhaul of the Google Groups system would be able to fix the problems that every Google Group faces.

Spammers are now spoofing the email addresses of existing group participants to sneak their messages through. You’ll see it coming from existing group users - or even the group moderators themselves. This cheat completely bypasses the moderation system since the spammers are pretending to be pre-moderated users. The Google Groups system is completely fooled.

Life is too short for the stress and aggravation that Google Groups provides.

Using SSH as a proxy server (to avoid your company’s/country’s [firewall]): SSH has a built in SOCKS proxy that you can use in any program that can run over a SOCKS proxy. This includes Firefox (really, all browsers), Thunderbird, Pidgin/Adium (as well as almost all other IM clients like Google Talk, AIM, etc) and a ton of other networking programs we all use. Using SSH with the -D flag lets you create a dynamic ssh tunnel that acts as a SOCKS proxy, and sends all your traffic from the endpoint of your SSH connection.

And a small collection of other SSH secrets that are [fun][useful][illegal] (delete as appropriate).

Anyone who has visited YouTube.com in the past four years knows that you can embed video in a web page. But prior to HTML5, there was no standards-based way to do this. Virtually all the video you’ve ever watched “on the web” has been funneled through a third-party plugin — maybe QuickTime, maybe RealPlayer, maybe Flash. (YouTube uses Flash.) These plugins integrate with your browser well enough that you may not even be aware that you’re using them. That is, until you try to watch a video on a platform that doesn’t support that plugin.

HTML5 defines a standard way to embed video in a web page, using a <video> element. Support for the <video> element is still evolving, which is a polite way of saying it doesn’t work yet. At least, it doesn’t work everywhere. But don’t despair! There are alternatives and fallbacks and options galore.

And Mark Pilgrim goes on to explore this fascinating and long-overdue addition to web-developer’s armoury. As we have come to expect from Pilgrim, all the technicalities are covered and the essay is written in an easy-to-understand manner with exquisite presentation. The “bible” for video-over-web people everywhere.

A JavaScript library to make Microsoft Internet Explorer behave like a standards-compliant browser. It fixes many HTML and CSS issues and makes transparent PNG’s work correctly under IE5 and IE6.