In May we announced Google Wallet—an app that makes your phone your wallet—with Citi, MasterCard, Sprint and First Data. With Google Wallet, you can tap, pay and save using your phone and near field communication (NFC).
We’ve been testing it extensively, and today we’re releasing the first version of the app to Sprint. That means we’re beginning to roll out Google Wallet to all Sprint Nexus S 4G phones through an over-the-air update—just look for the “Wallet” app. Here’s a demo of Google Wallet in action:
Google Wallet enables you to pay with your Citi MasterCard credit card and the Google Prepaid Card, which can be funded with any of your existing plastic credit cards. As a thanks to early adopters, we’re adding a $10 free bonus to the Google Prepaid Card if you set it up in Google Wallet before the end of the year.
When we announced Google Wallet, we pledged a commitment to an open commerce ecosystem. We appreciate Citi and MasterCard for being our launch partners. And today, Visa, Discover and American Express have made available their NFC specifications that could enable their cards to be added to future versions of Google Wallet.
Our goal is to make it possible for you to add all of your payment cards to Google Wallet, so you can say goodbye to even the biggest traditional wallets. In fact, we’ve got a video of our first customer, someone who is ready to replace his famously over-stuffed wallet. We hope Google Wallet gives him “serenity now.”
This is still just the beginning, and while we’re excited about this first step, we look forward to bringing Google Wallet to more phones in the future. You can learn more about Google Wallet at google.com/wallet.
Monday, September 19, 2011
Saturday, September 17, 2011
An update from YouTube NextUp Japan
This month, the 10 winners of our YouTube NextUp contest in Japan attended Creator’s Camp at Digital Hollywood University in Tokyo. The YouTubers learned to use the magic of green screens, worked with editing pros, talked with industry professionals on brand management and got some hands-on time with high-end digital cameras. We have a summary video of the week’s activities here, and learn many of the same lessons from the YouTube Creator Playbook.
One of our favorite parts of Creator Camp is seeing the creativity coming out of the YouTubers collaborations, so we put together a playlist for you.
The YouTube NextUp winners are already working on their first big projects after Creator Camp, and here’s a few you can look forward to:
Mami Ihara, Partner Program Specialist, recently watched “坂本龍馬 Japanese samurai ryoma sakamoto.”
One of our favorite parts of Creator Camp is seeing the creativity coming out of the YouTubers collaborations, so we put together a playlist for you.
The YouTube NextUp winners are already working on their first big projects after Creator Camp, and here’s a few you can look forward to:
- HotchiKazuhiro starts work on his 26-part animated fantasy epic Jugaia
- SQUASHfilms will be touring all of Japan’s world heritage sites and making videos from each
- Two of the NextUp winners will shoot videos from the Northeastern Japan areas affected by the tsunami and earthquake — ChrisNolandTV chronicling rebuilding of the coastal cities and dfarm777 looking at the areas’ stray pets recovery effects
Mami Ihara, Partner Program Specialist, recently watched “坂本龍馬 Japanese samurai ryoma sakamoto.”
Friday, September 16, 2011
This week's Trends: anniversaries, webcams, and the future
Each weekday, we at YouTube Trends take a look at the most interesting videos and cultural phenomena on YouTube as they develop. We want take a moment to highlight some of what we've come across this week:
Check back every day for the latest about what's trending on YouTube at: www.YouTube.com/Trends
Kevin Allocca, YouTube Trends Manager, recently watched "You're not gonna be the great breakdancer you think you are."
- We looked at how the anniversary of 9/11 became a dominant topic on YouTube.
- We studied the unexpected pop-culture resurgence of Back to the Future 2.
- We tracked the popularity of iPhone concept videos.
- We saw some interesting public displays from around the world.
- We collected dramatic footage from a chemical fire in Canberra.
- And these two seniors trying to work their webcam became the major viral hit of the week:
Check back every day for the latest about what's trending on YouTube at: www.YouTube.com/Trends
Kevin Allocca, YouTube Trends Manager, recently watched "You're not gonna be the great breakdancer you think you are."
Watch Austin City Limits Music Festival all weekend on YouTube
This year marks Austin City Limits Music Festival’s 10th anniversary, and starting today, we're streaming the festival live on YouTube. Check out the trailer for the event:
Looking for big headliners? Rock? Rap? Indie? Electronic? Get your fill of bands including Coldplay, Social Distortion, Big Boi, TV on the Radio, Fleet Foxes, Cut Copy and over 30 more artists. Check out the full webcast schedule and mark your calendars—it’s going to be a great weekend of music.
The Dell and AMD-sponsored webcast kicks off today at 11:30 a.m. PT on youtube.com/aclfestival. We’ll see you there!
Sarah Bardeen, Music Community Manager, recently watched “Austin Kiddie Limits 2011.”
Looking for big headliners? Rock? Rap? Indie? Electronic? Get your fill of bands including Coldplay, Social Distortion, Big Boi, TV on the Radio, Fleet Foxes, Cut Copy and over 30 more artists. Check out the full webcast schedule and mark your calendars—it’s going to be a great weekend of music.
The Dell and AMD-sponsored webcast kicks off today at 11:30 a.m. PT on youtube.com/aclfestival. We’ll see you there!
Sarah Bardeen, Music Community Manager, recently watched “Austin Kiddie Limits 2011.”
Thursday, September 15, 2011
Watch Jonah Hill live on YouTube this Friday at 4pm PT
Fans of comedy star Jonah Hill, pull up a chair and join us. Jonah’s stopping by YouTube this Friday for a live streaming Q&A at 4pm PT to celebrate the release of his new movie, Moneyball.
The film tells the story of how baseball’s Oakland A’s used statistical analysis to compete against teams with much higher payrolls. As the A’s are one of two baseball teams local to YouTube HQ, we’re particularly happy to welcome Jonah as our guest.
As well as starring opposite Brad Pitt in Moneyball, Jonah appeared in some of the most popular comedies of recent years, including Knocked Up, The 40 Year Old Virgin and Funny People, all of which were directed by comedy auteur and mentor Judd Apatow. We’ll be asking Jonah about this and more, and he’s looking for you share your questions too:
Find out the human-interest story behind the statistics when we throw Jonah some curveballs. Fans of comedy know he’s sure to knock a few out of the park.
Mark Day, Comedy Programs Manager, recently watched “Dr Seuss Versus Shakespeare. Epic Rap Battles of History #12.”
The film tells the story of how baseball’s Oakland A’s used statistical analysis to compete against teams with much higher payrolls. As the A’s are one of two baseball teams local to YouTube HQ, we’re particularly happy to welcome Jonah as our guest.
As well as starring opposite Brad Pitt in Moneyball, Jonah appeared in some of the most popular comedies of recent years, including Knocked Up, The 40 Year Old Virgin and Funny People, all of which were directed by comedy auteur and mentor Judd Apatow. We’ll be asking Jonah about this and more, and he’s looking for you share your questions too:
Find out the human-interest story behind the statistics when we throw Jonah some curveballs. Fans of comedy know he’s sure to knock a few out of the park.
Mark Day, Comedy Programs Manager, recently watched “Dr Seuss Versus Shakespeare. Epic Rap Battles of History #12.”
Time, technology and leaping seconds
Google’s Site Reliability team is responsible for keeping Google’s services and data centers up and running 24/7. In this post, you’ll hear about a project our Site Reliability Engineers took on to make sure that the fluctuations of time don’t adversely affect Google’s products and services. If you like this (detailed) glimpse at the tech behind the scenes, come back for more about this team’s work in the future. -Ed.
Have you ever had a watch that ran slow or fast, and that you’d correct every morning off your bedside clock? Computers have that same problem. Many computers, including some desktop and laptop computers, use a service called the “Network Time Protocol” (NTP), which does something very similar—it periodically checks the computers’ time against a more accurate server, which may be connected to an external source of time, such as an atomic clock. NTP also takes into account variable factors like how long the NTP server takes to reply, or the speed of the network between you and the server when setting a to-the-second or better time on the computer you’re using.
Soon after the advent of ticking clocks, scientists observed that the time told by them (and now, much more accurate clocks), and the time told by the Earth's position were rarely exactly the same. It turns out that being on a revolving imperfect sphere floating in space, being reshaped by earthquakes and volcanic eruptions, and being dragged around by gravitational forces makes your rotation somewhat irregular. Who knew?
These fluctuations in Earth’s rotational speed mean that even very accurate clocks, like the atomic clocks used by global timekeeping services, occasionally have to be adjusted slightly to bring them in line with “solar time.” There have been 24 such adjustments, called “leap seconds,” since they were introduced in 1972. Their effect on technology has become more and more profound as people come to rely on fast, accurate and reliable technology.
Why time matters at Google
Having accurate time is critical to everything we do at Google. Keeping replicas of data up to date, correctly reporting the order of searches and clicks, and determining which data-affecting operation came last are all examples of why accurate time is crucial to our products and to our ability to keep your data safe.
Very large-scale distributed systems, like ours, demand that time be well-synchronized and expect that time always moves forwards. Computers traditionally accommodate leap seconds by setting their clock backwards by one second at the very end of the day. But this “repeated” second can be a problem. For example, what happens to write operations that happen during that second? Does email that comes in during that second get stored correctly? What about all the unforeseen problems that may come up with the massive number of systems and servers that we run? Our systems are engineered for data integrity, and some will refuse to work if their time is sufficiently “wrong.” We saw some of our clustered systems stop accepting work on a small scale during the leap second in 2005, and while it didn’t affect the site or any of our data, we wanted to fix such issues once and for all.
This was the problem that a group of our engineers identified during 2008, with a leap second scheduled for December 31. Given our observations in 2005, we wanted to be ready this time, and in the future. How could we make sure everything at Google stays running as if nothing happened, when all our server clocks suddenly see the same second happening twice? Also, how could we make this solution scale? Would we need to audit every line of code that cares about the time? (That’s a lot of code!)
The solution we came up with came to be known as the “leap smear.” We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens. This meant that when it became time to add an extra second at midnight, our clocks had already taken this into account, by skewing the time over the course of the day. All of our servers were then able to continue as normal with the new year, blissfully unaware that a leap second had just occurred. We plan to use this “leap smear” technique again in the future, when new leap seconds are announced by the IERS.
Here’s the science bit
Usually when a leap second is almost due, the NTP protocol says a server must indicate this to its clients by setting the “Leap Indicator” (LI) field in its response. This indicates that the last minute of that day will have 61 seconds, or 59 seconds. (Leap seconds can, in theory, be used to shorten a day too, although that hasn’t happened to date.) Rather than doing this, we applied a patch to the NTP server software on our internal Stratum 2 NTP servers to not set LI, and tell a small “lie” about the time, modulating this “lie” over a time window w before midnight:
In an experiment, we performed two smears—one negative then one positive—and tested this setup using about 10,000 servers. We'd previously added monitoring to plot the skew between atomic time, our Stratum 2 servers and all those NTP clients, allowing us to constantly evaluate the performance of our time infrastructure. We were excited to see monitoring showing plots of those servers’ clocks tracking our model's predictions, and that we were continuing to serve users’ requests without errors.
Following the successful test, we reconfigured all our production Stratum 2 NTP servers with details of the actual leap second, ready for New Year's Eve, when they would automatically activate the smear for all production machines, without any further human intervention required. We had a “big red button” opt-out that allowed us to stop the smear in case anything went wrong.
What we learned
The leap smear is talked about internally in the Site Reliability Engineering group as one of our coolest workarounds, that took a lot of experimentation and verification, but paid off by ultimately saving us massive amounts of time and energy in inspecting and refactoring code. It meant that we didn’t have to sweep our entire (large) codebase, and Google engineers developing code don’t have to worry about leap seconds. The team involved in solving this issue was a handful of people, distributed around the world, who were able to work together without restriction in order to solve this problem.
The solution to this challenge drove a lot of thinking to develop better ways to implement locking and consistency, and synchronizing units of work between servers across the world. It also meant we thought more about the precision of our time systems, which have a knock-on effect on our ability to minimize resource wastage and run greener data centers by reducing the amount of time we must spend waiting for responses and rarely doing excess work.
By anticipating potential problems and developing solutions like these, the Site Reliability Engineering group informs and inspires the development of new technology for distributed systems—the systems that you use every day in Google’s products.
Have you ever had a watch that ran slow or fast, and that you’d correct every morning off your bedside clock? Computers have that same problem. Many computers, including some desktop and laptop computers, use a service called the “Network Time Protocol” (NTP), which does something very similar—it periodically checks the computers’ time against a more accurate server, which may be connected to an external source of time, such as an atomic clock. NTP also takes into account variable factors like how long the NTP server takes to reply, or the speed of the network between you and the server when setting a to-the-second or better time on the computer you’re using.
Soon after the advent of ticking clocks, scientists observed that the time told by them (and now, much more accurate clocks), and the time told by the Earth's position were rarely exactly the same. It turns out that being on a revolving imperfect sphere floating in space, being reshaped by earthquakes and volcanic eruptions, and being dragged around by gravitational forces makes your rotation somewhat irregular. Who knew?
These fluctuations in Earth’s rotational speed mean that even very accurate clocks, like the atomic clocks used by global timekeeping services, occasionally have to be adjusted slightly to bring them in line with “solar time.” There have been 24 such adjustments, called “leap seconds,” since they were introduced in 1972. Their effect on technology has become more and more profound as people come to rely on fast, accurate and reliable technology.
Why time matters at Google
Having accurate time is critical to everything we do at Google. Keeping replicas of data up to date, correctly reporting the order of searches and clicks, and determining which data-affecting operation came last are all examples of why accurate time is crucial to our products and to our ability to keep your data safe.
Very large-scale distributed systems, like ours, demand that time be well-synchronized and expect that time always moves forwards. Computers traditionally accommodate leap seconds by setting their clock backwards by one second at the very end of the day. But this “repeated” second can be a problem. For example, what happens to write operations that happen during that second? Does email that comes in during that second get stored correctly? What about all the unforeseen problems that may come up with the massive number of systems and servers that we run? Our systems are engineered for data integrity, and some will refuse to work if their time is sufficiently “wrong.” We saw some of our clustered systems stop accepting work on a small scale during the leap second in 2005, and while it didn’t affect the site or any of our data, we wanted to fix such issues once and for all.
This was the problem that a group of our engineers identified during 2008, with a leap second scheduled for December 31. Given our observations in 2005, we wanted to be ready this time, and in the future. How could we make sure everything at Google stays running as if nothing happened, when all our server clocks suddenly see the same second happening twice? Also, how could we make this solution scale? Would we need to audit every line of code that cares about the time? (That’s a lot of code!)
The solution we came up with came to be known as the “leap smear.” We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens. This meant that when it became time to add an extra second at midnight, our clocks had already taken this into account, by skewing the time over the course of the day. All of our servers were then able to continue as normal with the new year, blissfully unaware that a leap second had just occurred. We plan to use this “leap smear” technique again in the future, when new leap seconds are announced by the IERS.
Here’s the science bit
Usually when a leap second is almost due, the NTP protocol says a server must indicate this to its clients by setting the “Leap Indicator” (LI) field in its response. This indicates that the last minute of that day will have 61 seconds, or 59 seconds. (Leap seconds can, in theory, be used to shorten a day too, although that hasn’t happened to date.) Rather than doing this, we applied a patch to the NTP server software on our internal Stratum 2 NTP servers to not set LI, and tell a small “lie” about the time, modulating this “lie” over a time window w before midnight:
lie(t) = (1.0 - cos(pi * t / w)) / 2.0What this did was make sure that the “lie” we were telling our servers about the time wouldn’t trigger any undesirable behavior in the NTP clients, such as causing them to suspect the time servers to be wrong and applying local corrections themselves. It also made sure the updates were sufficiently small so that any software running on the servers that were doing synchronization actions or had Chubby locks wouldn't lose those locks or abandon any operations. It also meant this software didn’t necessarily have to be aware of or resilient to the leap second.
In an experiment, we performed two smears—one negative then one positive—and tested this setup using about 10,000 servers. We'd previously added monitoring to plot the skew between atomic time, our Stratum 2 servers and all those NTP clients, allowing us to constantly evaluate the performance of our time infrastructure. We were excited to see monitoring showing plots of those servers’ clocks tracking our model's predictions, and that we were continuing to serve users’ requests without errors.
Following the successful test, we reconfigured all our production Stratum 2 NTP servers with details of the actual leap second, ready for New Year's Eve, when they would automatically activate the smear for all production machines, without any further human intervention required. We had a “big red button” opt-out that allowed us to stop the smear in case anything went wrong.
What we learned
The leap smear is talked about internally in the Site Reliability Engineering group as one of our coolest workarounds, that took a lot of experimentation and verification, but paid off by ultimately saving us massive amounts of time and energy in inspecting and refactoring code. It meant that we didn’t have to sweep our entire (large) codebase, and Google engineers developing code don’t have to worry about leap seconds. The team involved in solving this issue was a handful of people, distributed around the world, who were able to work together without restriction in order to solve this problem.
The solution to this challenge drove a lot of thinking to develop better ways to implement locking and consistency, and synchronizing units of work between servers across the world. It also meant we thought more about the precision of our time systems, which have a knock-on effect on our ability to minimize resource wastage and run greener data centers by reducing the amount of time we must spend waiting for responses and rarely doing excess work.
By anticipating potential problems and developing solutions like these, the Site Reliability Engineering group informs and inspires the development of new technology for distributed systems—the systems that you use every day in Google’s products.
Saying thanks—in person—to our Google Top Contributors
“Oh, you’re BlueQuoll!”
You heard a lot of enthusiastic cries of recognition at the Global Top Contributor Summit, as Googlers and members of our Top Contributor program got to leave their laptops behind and meet one another face to face. This two-day event held in and around our headquarters in Mountain View brought together some of our most prolific and knowledgeable users from the Google product forums for the first time.
Top Contributors are the folks you may know by “bkc56” in the Gmail forum, “Noisette” in the Google Earth forum and “theylmdl” in the German Webmaster forum—Google users who volunteer their time to help others with questions and troubleshooting issues. We began the program in 2005 to support this important group, and today there are more than 350 Top Contributors who are active in our forums. They also give Google teams important feedback to help shape the development of our products. In short, they’re some of Google’s most passionate users, and we wanted to take the time to share our appreciation.
At the summit, more than 250 Top Contributors joined us from around the world, representing 40+ product forums in 20+ languages. To see just how global this amazing bunch is, check out the map we set up to showcase their hometowns:
At the event, our Top Contributors met with Google engineers who demo’ed upcoming features, giving them the unique opportunity to give feedback and ask questions. This was also an opportunity for our Top Contributors to meet each other, and make a new friend or two.
We hope this summit gave our Top Contributors more insight into how Google works and expressed just how much we appreciate their help and dedication. In fact, they’re such a dedicated bunch that some of the Top Contributors were even spotted during the summit answering forum questions. To see them in action, head on over to the Google product forums.
Find out about how you can become a Top Contributor in our Help Forum guide.
You heard a lot of enthusiastic cries of recognition at the Global Top Contributor Summit, as Googlers and members of our Top Contributor program got to leave their laptops behind and meet one another face to face. This two-day event held in and around our headquarters in Mountain View brought together some of our most prolific and knowledgeable users from the Google product forums for the first time.
Top Contributors are the folks you may know by “bkc56” in the Gmail forum, “Noisette” in the Google Earth forum and “theylmdl” in the German Webmaster forum—Google users who volunteer their time to help others with questions and troubleshooting issues. We began the program in 2005 to support this important group, and today there are more than 350 Top Contributors who are active in our forums. They also give Google teams important feedback to help shape the development of our products. In short, they’re some of Google’s most passionate users, and we wanted to take the time to share our appreciation.
TCs from the AdSense, Gmail and Webmaster forums hang out with Googlers (in red)
At the summit, more than 250 Top Contributors joined us from around the world, representing 40+ product forums in 20+ languages. To see just how global this amazing bunch is, check out the map we set up to showcase their hometowns:
At the event, our Top Contributors met with Google engineers who demo’ed upcoming features, giving them the unique opportunity to give feedback and ask questions. This was also an opportunity for our Top Contributors to meet each other, and make a new friend or two.
Bottom right: TC treebles, as he’s known in the Maps and Places for business forums, talks with the custom maps team
We hope this summit gave our Top Contributors more insight into how Google works and expressed just how much we appreciate their help and dedication. In fact, they’re such a dedicated bunch that some of the Top Contributors were even spotted during the summit answering forum questions. To see them in action, head on over to the Google product forums.
Find out about how you can become a Top Contributor in our Help Forum guide.
Subscribe to:
Posts (Atom)
