Tuesday, 30 March 2010
In addition to making it easier for users to export their data, we also enable them to authorize third party (non-Google developed) applications and websites to access their data at Google. One of the more common examples is allowing a social network to access your address book in order to send invitations to your friends.
While it is possible for a user to authorize this access by disclosing their Google Account password to the third party app, it is more secure for the app developer to use the industry standard protocol called OAuth which enables the user to give their consent for specific access without sharing their password. Most Google APIs support this OAuth standard, and starting today it is also available for the IMAP/SMTP feature of Gmail.
The feature is available in Google Code Labs and we have provided a site with documentation and sample code. In addition, Google has begun working with other companies like Yahoo and Mozilla on a formal Internet standard for using OAuth with IMAP/SMTP (learn more at the OAuth for IMAP mailing list).
One of the first companies using this feature is Syphir, in their SmartPush application for the iPhone, as shown in the screenshots below. Unlike other push apps, Sypher's SmartPush application never sees or stores the user’s Gmail password thanks to this new OAuth support.
We look forward to finalizing an Internet standard for using OAuth with IMAP/SMTP, and working with IMAP/SMTP mail clients to add that support.
Monday, 29 March 2010
Since its inception in 2005, the Google Summer of Code program has brought together nearly 3,400 students and more than 3,000 mentors from nearly 100 countries worldwide - all for the love of code. Through the program, accepted student applicants are paired with a mentor or mentors from participating projects, thus gaining exposure to real-world software development scenarios. They also receive an opportunity for employment in areas related to their academic pursuits. And best of all, more source code is created and released for the benefit of users and developers everywhere.
Full details, including pointers on how to apply, are available on the Google Open Source Blog.
By Leslie Hawthorn, Google Open Source Team
Monday, 22 March 2010
It’s easy to understand the benefit of partial response and partial update. Imagine that you are writing a new Android calendar widget, and you want to display the time and title of the recently changed events on your Google Calendar. With the old Calendar Data API, you would request your calendar’s events feed and receive a large amount of information in response -- including lots of extra data like the attendee list and the event description.
With the addition of partial response, however, you can now use the
fieldsquery parameter to request only relevant information -- in this case, event titles and times. Constructing such a request using the
fieldsquery parameter is simple:
By including the
entryargument and specifying
gd:when, this request ensures that the partial response contains only the title and time for each event, along with a small amount of wrapping metadata.
But say you want to also enable the widget to change the time of calendar events. With partial update, you can easily accomplish this: simply edit the data you received in the partial response and use the HTTP
PATCHverb to send the modified data back to the server. The server then intelligently interprets your
PATCH, updating only the fields you chose to send. Throughout this entire read-modify-write cycle, the unneeded data remains server-side and untouched.
Now for a quick demo. If you’re currently logged into a Google account, compare the size of your full calendar feed and your partial calendar feed. When we ran this test, our full calendar feed contained 160 kB of data while the partial feed only contained 8 kB -- the partial response successfully reduced total data transfer by 95%! Performance enhancements like this are especially apparent on a mobile device, where every byte of memory and every CPU cycle count. In nearly all clients, partial response and partial update make it more efficient to send, store, parse, cache, and modify only the data that you need.
As of today, partial response and partial update are supported in four Google APIs:
- The YouTube Data API supports partial response and partial update.
- The Calendar Data API supports partial response and partial update with Java client library support.
- The Picasa Web Albums Data API supports partial response and partial update with Java client library support.
- The read-only Sidewiki Data API supports partial response with Java client library support.
Thanks for joining us in our effort to make APIs on the web as fast and as efficient as possible!
By Kyle Marvin and Zach Maier, Google Data Protocol Team
Friday, 19 March 2010
We are now happy to announce that we have rolled out our new service to all our Subversion users. As a result, most common Subversion operations are about 3 times faster than they used to be.
One of the features of Subversion's HTTP-based protocol is that anyone can browse repositories through a normal web browser. Many open source projects hosted on Google Code use this feature to host websites for their project or post the latest versions of their software. We didn't anticipate how popular this would be when we designed our first Subversion service, but our new system has special optimizations for browser access. Latency for these pages are much lower and international users will see a dramatic improvement. We also set the appropriate caching headers, which can be manually controlled with the google-cache-control Subversion property.
To improve our reliability, our new service now has a custom replication system based on the Paxos algorithm. Whenever you make a change to your repository, the new data is now copied to several different data centers before our service reports that the commit has succeeded --- so you can code in peace knowing that your data is stored safely in multiple locations.
If you haven’t already, we encourage you to try out our new Subversion service and let us know what you think.
By Jon Trowbridge and Tony Zale, Google Project Hosting
Tuesday, 16 March 2010
Ignite will be at this year’s Google I/O! Last year, we had talks on big data, cartography and DIY devices -- a "typical" Ignite line-up. This year, our line-up includes folks like Cheezburger CEO, Ben Huh, and digital artist, Aaron Koblin. However, we also want you! We want to hear your cool ideas, hacks, how-to's, and war stories.
Each Ignite talk is 5 minutes long -- with 20 slides and only 15 seconds a slide (they auto-advance) -- and I'll be hosting the talk at I/O. If you’re not sure what to talk about, watch Scott Berkun's excellent How and Why to Give an Ignite Talk.
Submit your talk by March 31st, and we’ll announce the selected speakers on April 3rd. Those who are chosen to give an Ignite talk will receive a free ticket to Google I/O.
If you need further inspiration, you can watch any of the hundreds of Ignite videos at Ignite Show.
By Brady Forrest, O'Reilly/Ignite
By Brady Forrest, O'Reilly/Ignite
With the meaning of open in mind, Google Code set out to foster best practices in developer documentation, build a community around web and open source development and demonstrate the power of Google technologies. Over the past five years code.google.com has come a long way from eight APIs, maturing into a destination for developers to explore our growing family of APIs and developer products, whether they speed up the web, alleviate cross-browser issues, make hosting web applications easy and scalable or make the web a more social place.
Google Code has also become an interactive place to share ideas. Not only can developers prototype their work in a Code Playground, they can also use Project Hosting on Google Code, a fast, reliable and easy way for developers to host all kinds of open source projects. Today, there are more than 240,000 projects registered, with commits coming in at about 17,000 per day...about 1 every 5 seconds. We also host 800 open source projects of our own, including four projects (Android, Chrome, Chrome OS and GWT) with over a million lines of code each.
It’s been an amazing five years, but there’s still a lot of work ahead. We’re dedicated to helping the developer and open source communities thrive in as many ways as we can. To celebrate our birthday and thank everyone for supporting code.google.com over the years we’re rolling out a new, faster Subversion server, which will double the source code storage for Project Hosting on Google Code from 1GB to 2GB. Happy coding!
By Chris DiBona, Open Source Programs Manager
Monday, 15 March 2010
I/O will feature the following fireside chats:
- Fireside chat with the Android team
Speakers: The Android team with Chris DiBona moderating
Pull up a chair and join the Android team at Google for a fireside chat. It's your opportunity to ask us about the platform and to tell us where you'd like to see it go in the future.
- Fireside chat with Android handset manufacturers
Come join us for a fireside chat with the top Android handset manufacturers. Hear about the types of devices being planned for 2010 and get your device-specific questions answered.
- Fireside chat with the App Engine team
Speakers: Brett Slatkin, Guido van Rossum, Matt Blain, Max Ross, Don Schwarz, Alfred Fuller, Kevin Gibbs, Sean Lynch
It's been an busy year for the App Engine team with lots of new features and lots of new developers. Come tell us about what you've loved and what still bugs you. With several members of the App Engine team on deck, you'll get the answers to your questions straight from the source.
- Fireside chat with the Google Chrome and Chrome OS teams
Speakers: Ian Fette, Brian Rakowski, Linus Upson, Caesar Sengupta, Matt Papakipos
Curious about what's new in Google Chrome, or what makes Google Chrome OS so exciting? We'll talk briefly about the major developments over the past year, and then field questions from the audience. If you're dying to know something, this is the place to find an answer.
- Fireside chat with the Enterprise team
Speakers: Chris Vander Mey, Scott McMullan, Ryan Boyd, David Glazer, Ken Lin
With the launch of the Google Apps Marketplace, we've introduced a new way to expose your software to businesses - and a new way to extend Google Apps. If you're interested in building apps, what we're thinking about, or if you have other questions about the Marketplace, pull up a chair.
- Fireside chat with the Geo team
Speakers: Thor Mitchell, Peter Birch, Matt Holden, Ben Appleton, Bart Locanthi, Thatcher Ulrich
Here's your opportunity to pick the brains of the people behind the Maps, Earth, and Maps Data APIs! We'll take a quick walk through the milestones of the last year, and then open it up to your questions. Don't miss your opportunity to get the straight scoop on all that's new in the world of Google Geo APIs.
- Fireside chat with the GWT team
Speakers: Bruce Johnson, Joel Webber, Ray Ryan, Amit Manjhi, Jaime Yap, Kathrin Probst, Eric Ayers
If you're interested in what the GWT team has been up to since 2.0, here's your chance. We'll have several of the core engineers available to discuss the new features and frameworks in GWT, as well as to answer any questions that you might have.
- Fireside chat with the Social Web team
Speakers: David Glazer, DeWitt Clinton, John Panzer, Joseph Smarr, Sami Shalabi, Todd Jackson
Social is quickly becoming an integral part of how we experience the web, and this is your chance to pick the brains of the people who are working on Buzz, the Buzz API and the underlying open protocols such as Activity Streams and OAuth which are an essential component of a truly open & social web.
Posted by Christine Tsai, Google I/O team
Friday, 12 March 2010
For businesses, Gmail contextual gadgets can boost employee productivity by complementing email in a context-specific and actionable way. Appirio, a cloud solution provider, provided a demonstration of the potential of Gmail contextual gadgets and other experimental features
with their new product PS Connect:
Soon we’ll be opening Gmail contextual gadgets as an extension for trusted testing by developers. If you have a good idea for this type of gadget today, please fill out this form. And for those of you who will be attending Google I/O in May, be sure to check out our session on building Gmail contextual gadgets.
By Dong Chen, Gmail Contextual Gadgets team
Tuesday, 9 March 2010
There are three simple steps for a Google Apps Marketplace application:
1) Have or create a cloud application and host it on the platform of your choice
2) Integrate your cloud app with Google Apps using available APIs
3) Create a manifest file describing your application and list it for sale on the Marketplace
The Google Apps Marketplace launched with more than 50 applications from companies like Intuit and Atlassian, with more coming soon from companies like NetSuite and SuccessFactors. We hope you'll join them by integrating with Google Apps and selling your applications on the Google Apps Marketplace to our more than 25 million users and 2 million businesses.
For more information on the Google Apps Marketplace, please see our post on the new Google Apps Developer blog. You can also dive into the details of how to sell your application in the Google Apps Marketplace by visiting our Developer Programs site and technical documentation. And if you'll be at Google I/O this year, you can learn first-hand from the team in the Google Apps sessions on May 19-20 in San Francisco.
Check out the Campfire One announcement on YouTube:
By Ryan Boyd, Google Apps Marketplace Team
Monday, 8 March 2010
By Leslie Hawthorn, Open Source Team
Reading the Google Code blog, it is hard not to marvel at the fundamental transformation that is taking place in the business of code. By the business of code, I mean the economics of developing and selling software. My first exposure to the software business was as a teenager in Germany some twenty five years ago. Driver's education there is quite expensive because one has to take many mandatory lessons. After all, once you have passed you get to drive on the Autobahn, which, to this date, has long stretches without a speed limit! I thought I was being clever by agreeing to write software for a driving school in exchange for free lessons. It turns out the clever one was the owner of the driving school who turned around and sold the software to several other schools.
So what would it have taken for me then to become an ISV (independent software vendor), other than actually having the idea? These were the early days of PCs. I would have had to spend a lot of money on marketing and a lot of time on in-person sales and on-premise / telephone support. Most ISVs at the time grew locally for that reason and it was not uncommon to have highly fragmented markets with literally dozens of different vendors. As the software would have grown past the very simple initial functionality that I had created, I would have had to write pretty much everything I needed myself. Need billing? Write a billing module. Need asset tracking? Write an asset tracking module. The marketplace for components evolved only much later and was almost as fragmented as the ISV market.
This situation persisted until quite recently. In fact, in 2003 I spent a year getting to know the market for software for trucking companies in the US (Why? That's a long story). That market still had essentially the same characteristics: highly fragmented, regional customer bases, and almost 100% monolithic custom systems.
Since then, the situation has changed dramatically. Today, creating new software means focusing on what the unique contribution is that one wants to offer and figuring out how to integrate with everything else. Need a spreadsheet? Use Google Apps. Need telephony? Use Twilio (disclosure: Twilio is a USV portfolio company). Marketing can happen on the web through keyword advertising and, better yet, SEO and customer sharing. For many solutions, even sales can be entirely web-based (enter a credit card!). Support can happen over the web and often users can support each other through community. Add cloud computing to the mix and you eliminate the fixed cost that was such a high barrier to entry in the early days of the web (I remember the extraordinary bills for servers and bandwidth in 1999!).
All of this has made it possible for small teams to create big successes. It is amazing what a few great coders can do, leveraging all the services that are now available. It is,however, not just the cost side of the business of code that has changed dramatically. Competition has gone global. Someone in a faraway place can create a system, and it is instantly available everywhere. The days of the profitable, regional ISV business are over. The source of competitive advantage has also shifted. In the past, if your solution had better features, you could land a sale even against a competitor that had more customers. Now, better features don't mean that much if the larger competitor has built a network effect into their business. Imagine trying to start a LinkedIn or Salesforce competitor with better features. So the very same forces that are making it much easier to get started are making it much harder to build a successful and sustainable business.
Does that mean that there will be fewer opportunities going forward? Maybe. But there is a strong countervailing force that is creating important new opportunities: the code of business is also changing. By the code of business, I mean how companies and industries (and even societies) are organized. At Union Square Ventures, we are convinced that over time, the Internet will transform most, if not all, industries as much as it is changing the software business. This has started with the media industry, where after years of prediction of change we are now seeing massive shifts.
The reason that the code of business will change is that much of it is based on historic constraints on the bandwidth and latency of information flows. For instance, a command-and-control type hierarchy is still at the heart of (almost) all large corporations. Information flows up the hierarchy with middle management in charge of aggregating information flows. Commands then flow down with middle management translating into finer grained actions. This basic structure dates back to a time of messengers and telegraphs. Corporations are slowly shifting away towards more of an Internet architecture of "small pieces, loosely joined" -- but in many cases the end state may mean that the "pieces" are independent, small companies instead of units of a large company.
These changes will take a great deal of time (decades) because existing structures have a ton of inertia. Far more people tend to be interested in preserving the status quo than in making radical changes. Also, when a whole system needs changing, it is often difficult to get there one piece-at-a-time because all the components need to fit together. But as they start to occur in other industries, the opportunities will be massive. To give just one example, consider education: the size of the textbook industry alone in the US is estimated at $7 billion annually. This is a pure content business ripe for disruption.
Enough reading -- time for everyone with a transformative idea to start coding!
By Albert Wenger, Union Square Ventures and Continuations.
Thursday, 4 March 2010
Wednesday, 3 March 2010
SCVNGR is a platform for quickly and easily building location-based mobile games. Each game is all about doing challenges at places. Go here and take a photo, go there and solve this riddle. You happen to be at this coffee shop? Awesome! Try this challenge and earn a couple points! SCVNGR powers games for all sorts of institutions ranging from Princeton to Harvard to the Smithsonian Institutes to SIGGRAPH and even the U.S Navy.
If you're attending Google I/O this year, you'll get to try out our mobile game at the conference! (Don't forget to bring your Android phone, if you've got one!) I'm not going to give it all away here, but I do want to talk about one of the especially cool features that we're rolling out using some neat Google APIs.
One of the biggest challenges that our game-builders face is how to build location-based challenges that truly verify the user has actually made it to the right location. There are some non-technical solutions to this problem, such as creating riddles that require the user to be there to solve them (i.e. what is the third word on the fourth line of the plaque on the back wall) or taking photos which are then verified manually by the community or the game developer themselves.
We've also looked at a number of more technical solutions. The most obvious being to take the geo-tagged coordinates of each of the locations with a game and then use GPS to ensure that the player is within a certain radius of the location. Unfortunately, GPS verification has issues when the locations are indoors (as many are) and can vary greatly in accuracy across difference devices.
A new option, one that we're launching in a couple of weeks, uses QR codes planted at locations within the game-board. Players must scan these QR codes to verify that they've made it to the right spot. We're using the Google Charts API as an easy way to programmatically generate QR codes. Of course, generating and planting the QR codes is only half of the equation. You've also got to be able to decode them from the phones during the game. We experimented with a couple of options as to how to best achieve this.
Our first thought was to simply have the players snap pictures of the QR code which we'd then post back to our server, decode and respond with whether or not that was in fact the right QR code (or a QR code at all). The benefit of this solution was only having to utilize one QR code processing library for both our iPhone and Android applications. But we ran into a couple issues right up front:
- The time cost incurred by having to transmit a reasonably high-resolution image to our servers.
- Most players aren't very good at taking pictures of QR codes. They move the lens of the camera very close and snap the picture. (It's actually best to take the picture from 12-24 inches away to enable the camera to focus sharply on the QR code.) This led to a high-number of failed submissions before we were actually able to recognize a valid QR code.
Add all this up and it created a pretty poor game-play experience.
So we turned to the ZXing project (pronounced Zebra Crossing) which is an open source barcode processing library written in Java and highly suited to the Android environment. Running the ZXing code right on the device rid us of the time-delay introduced by transmitting images to the server. But we still had the issue of the high-fail rate of the user snapping unsuitable images. Rather than trying to implement any form of "auto-scanning", we've chosen to simply grab images from the camera every 1/8 of a second or so, scan them and stop the process once a QR code is recognized.
As for the iPhone, ZXing has an objective-c port for the iPhone, but in order to grab images in real-time from the camera, you'll have to use a private API call for iPhone OS 3.1. Luckily, Apple has officially authorized its public usage until it's made public.
We're hard at work integrating QR codes into the great game that we're building for Google I/O and we hope you'll get a chance to play. The I/O team will let you know when the game is ready! The SCVNGR team will also be there in person, so please come by and say hello! We'd love to get your thoughts on the game or just chat about some of the Google APIs that we've used within SCVNGR.
By Seth Priebatsch, Chief Ninja of SCVNGR
In today's launch of the API on code.google.com we are highlighting the core design principles towards integrating with Google PowerMeter. In particular we outline the underlying data model and the accompanying protocols to ensure that Google PowerMeter provides consumers access to their energy consumption with utmost care in maintaining the user's privacy and control on access to the information. We also highlight, with code samples and client implementations, how to easily start building your PowerMeter-compatible device.
Tune into our blog and subscribe to our notification list for announcements on upcoming developments. We are thrilled to bring together a rich framework to help more developers integrate with Google PowerMeter with our open, standards-based API. We are looking to expose expanded features of this framework to the developer community in the coming months.
Finally, we want your feedback! Ask questions, suggest topics, and share your stories. You can do this at the Developer Lounge section of the Google PowerMeter forum.
We hope you join us for the ride ahead.
By Srikanth Rajagopalan, Product Manager