Wednesday, January 27, 2010

Googland

Googland

[G] Live Tonight on YouTube: The State of the Union

Posted: 27 Jan 2010 04:28 AM PST

YouTube Blog: Live Tonight on YouTube: The State of the Union

Tonight at 9 p.m. ET we'll be livestreaming the President's State of the Union address on YouTube. As we announced yesterday, not only will you have the opportunity to watch the speech live online, you'll also be able to submit your questions for the President during and after the speech, and the President himself will respond to a collection of your top-voted questions in a live interview at the White House next week.

When the State of the Union address begins at 9 p.m. ET, we'll open a Moderator series on CitizenTube (youtube.com/citizentube) that will allow you to submit and vote on questions (in text or on video) for the President. Be ready to submit your questions right after the speech as we'll only keep the platform open for a few days.

How will we know which questions to bring to the President in the interview? You'll tell us by how you voted. After the votes have been cast, we'll assemble a shortlist of the top questions, ensuring that we cover a range of issues, minimize duplicate questions, and include a mix of both video and text submissions. This is your opportunity for an exclusive interview with the President, so be sure to submit great questions and vote for the ones you think should be asked.

If you're submitting your question on video (which we prefer), please be sure to keep it short (20 seconds or less) and use the highest video and audio quality possible so that we can hear you loud and clear.

After the speech, we'll highlight the video of the entire State of the Union address, so those of you who aren't able to see it live can still watch and participate afterwards. We'll also feature Virginia Governor Bob McDonnell's official GOP response to the President's State of the Union, in what promises to be a lively and important discussion of our nation's future in 2010.

See you tonight at 9 p.m. ET on CitizenTube.

Steve Grove, Head of News and Politics, recently watched "NEWSWEEK & YouTube: Nouriel Roubini on the 2010 Economy."


URL: http://feedproxy.google.com/~r/youtube/PKJx/~3/k5ohZ5GhrdM/live-tonight-on-youtube-state-of-union.html

[G] We're raising the bar on Google Analytics IQ

Posted: 26 Jan 2010 06:27 PM PST

Google Analytics Blog: We're raising the bar on Google Analytics IQ

Since the Google Analytics IQ launch, people from all over the world have taken the online course and test. Web analytics is increasingly important to all kinds of organizations. Online retailers, agencies, large consumer brands and non-profits are just a few of the many kinds of organizations that rely on people who are trained in Google Analytics. So, we've decided to raise the bar on what it means to be Google Analytics qualified and increase the minimum passing score from 75% to 80%.

If you're already Google Analytics qualified, but you received a score less than 80%, don't worry. This change doesn't affect your current qualification. But be sure to review the online course when it's time to renew your qualification (18 months after you initially qualified). At that time, you'll be expected to score at least 80%.

For details or to start the course, visit ConversionUniversity.com. There's a FAQ with details and a link to the Google Analytics IQ test. Best of luck to everyone!


Posted by Alden DeSoto, Google Analytics Team
URL: http://analytics.blogspot.com/2010/01/were-raising-bar-on-google-analytics-iq.html

[G] Libevent 2.0.x: Like Libevent 1.4.x, Only More So.

Posted: 26 Jan 2010 06:27 PM PST

Google Open Source Blog: Libevent 2.0.x: Like Libevent 1.4.x, Only More So.

Libevent 2.0.x is the new version of Libevent from the Tor Project. Libevent is a software library whose purpose is to provide consistent fast interfaces to various operating systems' mutually incompatible fast networking facilities. gives applications two basic interfaces to these networking layers: a low-level interface where the application is notified when an operation (like a network read or write) is ready to begin, and a higher-level interface where Libevent itself manages network operations and the application is notified when the network operations are completed.

It's amazing how complicated things can become when you set out to do a simple task pretty well.

Back in 2003, I found myself working on a project written in C that needed (among other things) to do fast nonblocking IO on a whole bunch of sockets at once. Our placeholder asynchronous IO implementation, based on the widely portable select() and poll() syscalls, wasn't working well on Windows and didn't scale at all.

What does it do?

I'll add a bit of background here, for readers who haven't tried to do their nonblocking IO from scratch before. When you write a program that needs to work with many active network connections at once, you have two basic choices. One choice is to call IO functions that wait (block) until they are done, and to give each connection its own thread or process so that one connection's blocking doesn't force all the connections to block. For many applications, this approach doesn't scale too well.

A better choice is to use so-called "nonblocking" IO functions that make as much progress as they can, and return control to your program once they can make no more immediate progress. With this approach, your program needs some way to tell which connections are ready to do more IO, so that you don't waste CPU time polling connections that aren't ready yet. There are many kernel-provided APIs to do this, but the portable ones all scale badly (like select() and poll(), which are both O(N) in performance), and the fast ones are all non-portable (like kqueue() and epoll() and /dev/poll). This is where Libevent comes in. Libevent provides a consistent interface to wrap the common features of all these interfaces that tell you when connections are ready for IO, so that you can write clean code using nonblocking IO without having to re-code for every possible backend.

So, we started using Niels Provos's Libevent library around 2005. It was around version 1.0 back then, and it had... a few bugs. To get our application working I started submitting patches, and before too long Niels asked me if I'd like to co-maintain it.

Flash-forward to the present day. Libevent had grown an "extras" library to support commonly needed protocols like HTTP and DNS. Libevent had gotten real users too, including Tor, Memcached, and Chromium. With version 1.4, Libevent's core had grown to maturity, and did a pretty good job on most Unixish platforms and a not-too-awful job on Windows. But there were still some issues that made us decide to try for a major development effort in 2.0. I'll touch on the big ones here, explain what progress we've made, and what we still have to do before we can call Libevent 2.0 finished.

Cleaner interfaces
Some of our older interfaces had grown crufty and difficult to use safely. For example, you sometimes needed to remember to follow up every call to event_set() with a corresponding call to event_base_set(), or you might get strange behavior. Some interfaces were a bad idea to begin with, like the ones that relied on global state.

We could have just changed all our APIs to be less error-prone, but that would have broken all the older programs written to use them. Still, leaving the old APIs exposed by default would make it hard for developers to make sure they were avoiding them. As a compromise, we decided to put the preferred APIs in new headers (such as event2/event.h), and the deprecated APIs in compatibility headers (such as event2/event_compat.h), while retaining the old headers (like the old event.h) as wrappers to include both the new and old APIs.


Nearly every non-Windows OS does nonblocking network IO best with the system I described above, where the program first asks the kernel which sockets are ready to read or write and then asks the kernel to perform as much IO on them as could succeed right now without blocking. On Windows, though, the "tell me which sockets are ready" part is not so efficient or scalable. Windows's select() function (which Libevent 1.4 uses) is O(N), its WSAWaitForMultipleEvents() function doesn't support more than 64 sockets at a time, and so on.

Windows does have a good networking API, however. It just follows a different paradigm. Instead of asking the OS to tell you when an operation would be able to make progress, you tell the OS to begin an operation asynchronously, and ask the OS later (via an , or IOCP) to tell you which operations have finished.

It's quite hard to implement a notify-on-readiness interface using a notify-on-completion system like Windows provides. Fortunately, however, it's pretty easy (and frequently desirable!) to implement a notify-on-completion interface using a Unix-style notify-on-readiness API, so that's what we decided to do.

Supporting IOCP on Windows has been the most far-reaching challenge in Libevent 2.0, and has led to improvements throughout the rest of the (non-Windows-specific) codebase. I'll say more when I talk about individual improvements below.

Though most of the groundwork for an IOCP implementation is laid, the code itself is fairly immature. If you fetch the latest code from subversion, you can enable data transfer through an existing socket with IOCP. IOCP-enhanced connect and accept operations are not yet supported, nor is UDP. We hope to get these done pretty soon.


Buffered-IO improvements

Earlier Libevent versions had a "bufferevent" abstraction to handle the common case where you want to queue data received and data to be sent over a TCP connection, and receive notification as more data arrives or is sent. The interface here was a good match for IOCP, but the existing implementation was too inflexible and inefficient for serious use. Among other problems, its storage format relied on large circular buffers, it allowed only a single implementation for the interface, it behaved poorly on Windows, and it was just generally slow.


In Libevent 2.0, we've rewritten bufferevent from the ground up. The data storage format has changed from circular buffers to a linked list of buffers, reminiscent of the classic mbuf interface. We've added support for sending files with sendfile() and friends, and fixed up Windows support. The interface now supports multiple backends, OO-style, to allow multiple implementations of the "buffered IO" API. So far, we have five such backends: the basic socket implementation, a filtering wrapper implementation, an SSL-based implementation (see below), a socketpair-style implementation, and an IOCP-based implementation.

Preliminary results around April 2009 indicated that the rewritten codebase had improved our large-payload HTTP benchmark performance by between 35 and 174 percent. We hope that as we profile and benchmark this code more aggressively, we can find more opportunities for improvement here.


Improved multithreading

Older versions of Libevent allowed one event loop structure per thread; adding or deleting events from another thread wasn't supported. This was not only an annoyance for writers of multithreaded applications; it made IOCP support nigh-impossible, since we needed to have the IOCP loop run in separate threads from the main event thread.

The basic work here is finally done; as of last week, there are no major non-locked parts of Libevent remaining. We may still need to do performance tuning here: different operating systems provide mutex implementations with wildly differing characteristics.


Our next big multithreading initiative will be better support for parallelizing event callbacks across multiple CPUs on demand. This will be trivial for Win32 IOCP callbacks, but will require actual coding for older Unix backends. To ease migration, we'll need to allow programs to enable this functionality one callback at a time, so that we don't force them to upgrade all of their code at once.


As noted above, there's now a bufferevent backend that uses the OpenSSL library to encrypt traffic using the SSL/TLS family of protocols. This wasn't as simple as writing a regular data filter, since the protocol's support for session renegotiation allows a single virtual read/write operation to be implemented as multiple reads and writes to the network.


The OpenSSL cryptography library has support for doing TLS encryption directly to the network or over a user-provided IO object. We've taken both approaches, so that an OpenSSL bufferevent can either deliver data to a network socket or to another bufferevent. This way, Unix programs can have a bufferevent that speaks SSL directly to the network, and Windows programs can wrap an SSL layer over an IOCP-based backend.

We'd eventually like to add support for other free SSL libraries, such as GnuTLS and NSS, though we're not planning to work on this for Libevent 2.0.x unless somebody wants to contribute the code.

As you might imagine, we've added and rewritten a lot of code between Libevent 1.4 and Libevent 2.0. Without good unit tests, we'd probably have introduced a fair number of bugs.


Unfortunately, our old unit tests weren't so good. Though the overall coverage was decent (about 72%), some parts of the code were hardly tested at all (the DNS code and the IO buffer code were both under 60% coverage). The test suite was fairly fragile, too: many tests relied on global state, which made it hard to write new ones, especially if they required inducing strange error conditions.


For Libevent 2.0, we put a major effort into our testing code. Tests now run in separate processes, so they can't affect one another no matter how badly they trash global state. This not only stopped us from adding new bugs, but also revealed a few longstanding ones. Thanks to this change, it's easy to test far more error conditions than we could test before. This has gotten us up to around 80% test coverage overall, with the least-tested module at around 72%.

Before we release Libevent 2.0, I want our test coverage to be at least 80% for every module. I'd also like to do a manual coverage audit to look for any untested sections that seem particularly error-prone.



Next steps
In the coming months, we'll want to get the Libevent 2.0.x series finished. This will mainly involve fixing known bugs in the Sourceforge trackers, finishing the IOCP code, and testing the heck out of everything.

In parallel, I've been working on a short book to serve as an introduction to nonblocking networking in general, and to Libevent in particular. The latest draft is at http://www.wangafu.net/~nickm/libevent-book/.

After Libevent 2.0.x is stable and released, we'll be able to start looking at missing features for Libevent 2.1.x. These aren't at all final yet, but I'm hoping to get improved thread-pool support for IOCP and non-IOCP users alike, and better support for UDP-based protocols. We'll probably have many other changes to make based on user feedback from Libevent 2.0.

Thanks to Google for their support of the project.


By Nick Mathewson, Tor Project
URL: http://google-opensource.blogspot.com/2010/01/libevent-20x-like-libevent-14x-only.html

[G] Site creation, sharing management and more with the Google Sites API

Posted: 26 Jan 2010 05:18 PM PST

Official Google Enterprise Blog: Site creation, sharing management and more with the Google Sites API

Since we launched the Google Sites Data API last fall, we've heard great feedback from businesses and schools using the API to update sites from 3rd party applications, migrate data from legacy workspace solutions into Google Sites and more.

Today, we're releasing several improvements to the API: the abilities to list a user's sites, create new sites, copy existing sites, and manage sharing permissions. You can read more about these updates to the Google Sites Data API on the Google Code Blog.

Posted by Jeremy Milo, Google Apps Marketing Manager

Get timely updates on new features in Google Apps by subscribing to our RSS feed or email alerts.
URL: http://googleenterprise.blogspot.com/2010/01/site-creation-sharing-management-and.html

[G] Spelling Suggestions and Thumbnail View in Google Docs

Posted: 26 Jan 2010 02:55 PM PST

Official Google Enterprise Blog: Spelling Suggestions and Thumbnail View in Google Docs

Google Docs lets you create, store, and share work files with teammates and other colleagues. Today we're making it easier for you to search across your files and find your documents with spelling suggestions in Google Docs search results. When you search from your Google Documents List, we automatically check whether your query uses the most common spelling of a given word. If you're likely to get better search results with an alternate spelling, you'll see a "Did you mean..." spelling suggestion. Never again will you wonder why your search for "agedna" (agenda) came up with zero results!

We also launched a new thumbnail view that displays small previews of your files. When combined with personalized relevance in search results, the thumbnail view makes it even faster to find the file you're looking for. You can toggle between list and thumbnail views using new buttons on the top right of the toolbar.


Finally, we're increasing the maximum file size for the Upload and share any file feature on Google Docs, so now you can upload, store, and share any file up to 1GB in size with Google Docs.

Posted by Nitin Mangtani, Product Manager, Google Apps
URL: http://googleenterprise.blogspot.com/2010/01/spelling-suggestions-and-thumbnail-view.html

[G] A thumbnail is worth about one hundred words

Posted: 26 Jan 2010 11:27 AM PST

Official Google Docs Blog: A thumbnail is worth about one hundred words

Earlier today, we added a new view option to your Documents List: thumbnail view.



While the standard "list view" displays the item title and information like sharing state, the thumbnail view displays small previews of your files. We generate thumbnails for all Google Docs types and most common files (photos, PDFs, etc). You can toggle between the two using new buttons on the top right of the toolbar.

When combined with search by relevance, the thumbnail view makes it really easy to find the file you're looking for.

And for all us spelling-challenged and typo-prone folks, we added spelling correction in search. Never again will you need to wonder how your search for "agedna" (agenda) came up with zero results. :-)


Finally, we recently finished rolling out the upload and store any file feature, so everyone should now be able to upload, store, and share any file in Google Docs. We also increased the maximum file size based on your feedback, so you can now uploads files up to 1 GB in size.

Posted by: Vijay Bangaru, Product Manager, Google Docs
URL: http://googledocs.blogspot.com/2010/01/thumbnail-is-worth-about-one-hundred.html

[G] Google Voice & Project CARE connect with DC's homeless vets

Posted: 26 Jan 2010 11:27 AM PST

Google Public Policy Blog: Google Voice & Project CARE connect with DC's homeless vets

Posted by Harry Wingo, Policy Counsel

This weekend, Google along with dozens of other D.C. organizations, attended the Winterhaven Homeless Veterans Stand Down at the Washington DC Veterans Affairs Medical Center. The annual event helps homeless Veterans get back on their feet with job clinics, medical aid, dental care, and housing assistance.

One of the first pieces of information you put on a job application is your phone number, but what if you don't have one?

In an effort to help that problem, Google and Project CARE gave away nearly 400 special Google Voice accounts to support homeless vets looking to connect with employers and loved ones. The Google Voice team has been offering this program in the San Francisco Bay Area for more than two years and we are excited to extend it to the D.C. area.

It was a small gesture, but hopefully a useful one as these Veterans move to get their lives back on track.


URL: http://googlepublicpolicy.blogspot.com/2010/01/google-voice-project-care-connect-with.html

[G] Google Voice comes to iPhone and Palm WebOS

Posted: 26 Jan 2010 09:05 AM PST

Official Google Mobile Blog: Google Voice comes to iPhone and Palm WebOS

A few weeks ago, Alex Nicolaou, Engineering Manager, wrote about the benefits of the fast and feature-rich iterative web app. Delivering Google services via mobile browsers has worked well for the Gmail team, so we decided to follow the same approach with Google Voice.

Today, we're excited to introduce the Google Voice web app for the iPhone and Palm WebOS devices. This HTML5 application provides you with a fast and versatile mobile experience for Google Voice because it uses the latest advancements in web technologies. For example, AppCache lets you interact with web apps without a network connection and local databases allow you to store data locally on the device, so you don't lose data even when you close the browser.

One of the great benefits of web applications is that you don't need to download and install an app on your phone. Instead, simply point your mobile browser to m.google.com/voice and sign in to your Google Voice account.

Then you can make calls from your phone that show your Google Voice number as the caller ID. You can also listen to voicemail and read voicemail transcripts, send and receive text messages for free, and take advantage of the low international call rates offered by Google Voice.



For quick access to the most important features like "Dialer", "Compose SMS", "Inbox" or "Contacts," you can add shortcuts to your iPhone home screen or Palm Launcher -- so cheap calls and messaging will be just a single click away. And because the Google Voice web app uses advanced features of modern HTML5 browsers, it offers native app-like performance and speed.

For more information visit m.google.com/voice or take a look at the Google Mobile Help Center. Please note, the web app is compatible with all versions of Palm WebOS and iPhone OS 3.0 and higher.

A Google Voice account is required to use the app, and Google Voice is currently only available in the United States. To learn more about Google Voice or request an invite, visit www.google.com/voice or read the Google Voice blog.

Posted by Marcus Foster, Product Manager and David Singleton, Engineering Manager
URL: http://googlemobile.blogspot.com/2010/01/google-voice-comes-to-iphone-and-palm.html

[G] Google Voice for iPhone and Palm WebOS

Posted: 26 Jan 2010 09:05 AM PST

Google Voice Blog: Google Voice for iPhone and Palm WebOS

Today we are launching a new Google Voice mobile web app for iPhone OS 3.0 and higher and Palm Web OS devices, harnessing the power of HTML5, a new web technology that makes it possible to run faster, richer web-based applications right in the browser.


In addition to letting you access a streamlined version of your Google Voice inbox, the new web app also lets you display your Google Voice number as the outbound caller ID (so return calls come back to your Google Voice number), send and receive text messages for free, and place international calls at Google Voice's low rates.



To get started, visit m.google.com/voice in your mobile browser. For quick access, don't forget to create a shortcut to this URL on your home screen or Palm Launcher.

Just a reminder: you'll need a Google Voice account and a voice plan on your cell phone to place calls using this web app. Don't have a Google Voice account? Request an invite.

Posted by Michael van Ouwerkerk, Software Engineer
URL: http://googlevoiceblog.blogspot.com/2010/01/google-voice-for-iphone-and-palm-webos.html
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)