Video: When We Build
The web is buzzing, and rightly so, about Wilson Miner’s incredibly inspiring talk from the 2011 Build Conference in Belfast. You may recognize Miner’s name from his role in developing Django, as part of the team that built Apple.com or as one of the founders of Everyblock.
Miner’s talk is not your typical web developer talk; in fact, he hardly mentions the web for most of it. Rather, Miner focuses on the broader impact that technologies, and the developers and designers who create them, have on our world, and how that world in turn shapes us. Miner reminds us that we aren’t building “just websites” but shaping the world we will live in for much of the foreseeable future. And, as the Alistair Smith quote shown in the talk says, “at times of change, the learners are the ones who will inherit the world, while the knowers will be beautifully prepared for a world which no longer exists.”
So turn off your music, throw the video in fullscreen mode and give it 38 minutes. Trust us, you won’t be sorry.
After you’re done be sure to visit Miner’s website, which has links to all the material used in the talk, including books, videos, music and images for anyone who would like to learn more.
Google Works on Internet Standards with TCP Proposals, SPDY Standardization
As part of Google’s continuing quest to dole out web pages ever more quickly, the search giant has proposed a number of changes to Transmission Control Protocol (TCP), the ubiquitous Internet protocol used to reliably deliver HTTP and HTTPS data (and much more besides) over the ‘net.
Google’s focus is on reducing latency between client machines and servers, and in particular, reducing the number of round trips (either client to server and back to client, or vice versa) required. When data is sent over a TCP connection, its receipt must be acknowledged by the receiving end. The sending end can only send a certain number of packets before it must wait for an acknowledgement. The time taken to receive an acknowledgement is governed by the round-trip time (RTT). With high bandwidth, high latency connections, clients and servers can end up spending most of their time waiting for acknowledgements, rather than sending packets.
When a new connection is made, a computer may initially send three packets before acknowledgement is required. Google wants to increase this to 10. With 10 packets, a browser can typically deliver an entire HTTP request to a server before it has to stop and wait for a reply.
TCP connections require a certain amount of negotiation between client and server, requiring a round trip, before data can be sent. Google is proposing to modify TCP so that some data can be sent during that negotiation, so that the server will have it on hand already, and can start processing it straight away.
TCP waits a predetermined time (the RTO or retransmission timeout) for acknowledgments to arrive. If the RTO expires, unacknowledged packets are assumed lost and retransmitted. This ensures that if the data has been lost in transmission that the sender is never waiting for an acknowledgement that will never arrive. This timeout value varies according to the network conditions and RTT, with a default of three seconds. Google wants to reduce this default to 1 second, so that if data has been lost, neither end needs to wait so long before it has another go.
Finally, Google wants to use a new algorithm to adjust how TCP connections react to packet loss. Packet loss can indicate networks that are congested, and TCP reacts by reducing the rate at which data is sent when this congestion is detected. The company claims that the algorithms currently used to respond to this packet loss can exact too great a penalty, making connections slow down too much and for too long, and that its new algorithm is better.
In addition to these proposed changes, Google is also suggesting other modifications, especially to make TCP recover better on mobile networks.
Changing TCP is not to be taken lightly. The protocol is already suffering due to buffer bloat undermining its built-in handling of network congestion. While Google’s proposed changes are well intentioned and might improve network performance, they come with the risk that an overlooked problem or a bad interaction with other traffic could cause widespread damage to the internet.
The proposed changes to TCP to reduce latencies and start sending data sooner are a continuation of previous work Google has done to try to make web serving, in particular, faster. The company has previously proposed other modifications to protocols such as SSL to similarly accelerate data transmission.
More far-reaching than these SSL tweaks is Google’s proposed alternative to the HTTP protocol that underpins the web: SPDY.
Initially, SPDY was a proprietary Google protocol implemented only in Google’s Chrome browser. That’s changing, however. Amazon’s Silk browser includes SPDY support, and Firefox 11 will include preliminary SPDY support. Partially motivated by SPDY’s uptake, the IETF’s HTTPbis Working Group — the team of industry experts tasked with maintaining and developing the HTTP specification — is considering the development of a new specification, HTTP/2.0, with the goal of improving the performance of HTTP connections. The working group will solicit suggestions from the industry, and with two, soon to be three implementations already, SPDY is likely to be well placed among those suggestions.
This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.
Photo: Ariel Zambelich/Wired.com
‘HTML5 Please’ Helps You Decide Which Parts of HTML5 and CSS 3 to Use
Keeping track of the ever-evolving HTML5 and CSS 3 support in today’s web browsers can be an overwhelming task. Sure you can use CSS animations to create some whiz-bang effects, but should you? Which browsers support it? What should you do about older browsers?
The first question can be answered by When Can I Use, which tracks browser support for HTML5 and CSS 3. You can then add tools like Modernizer to detect whether or not a feature is supported, so that you can gracefully degrade or provide an alternate solution for browsers that don’t support the features you’re using. But just what are those alternate solutions and polyfills? That’s what the new (somewhat poorly named) HTML5 Please site is designed to help with.
HTML5 Please offers a list of HTML5 elements and CSS 3 rules with an overview of browser support and any polyfills for each element listed (CSS 3 is the much more heavily documented of the two, which is why the HTML5 emphasis in the name is perhaps not the best choice). The creators of the site then go a step further and offer recommendations, “so you can decide if and how to put each of these features to use.”
The goal is to help you “use the new and shiny responsibly.”
HTML5 Please was created by Paul Irish, head of Google Chrome developer relations, Divya Manian, Web Opener for Opera Software, (along with many others) who point out that the recommendations offered on the site “represent the collective knowledge of developers who have been deep in the HTML5 trenches.”
The recommendations for HTML5 and CSS 3 features are divided into three groups — “use”, “use with caution” and “avoid”. The result is a site that makes it easy to figure out which new elements are safe to use (with polyfills) and which are still probably too new for mainstream work. If the misleading name bothers you, there’s also Browser Support, which offers similar data.
If you’d like to contribute to the project, head over to the GitHub repo.
Connect with ZionCG