Posted:
Author Photo
By Scott Knaster, Google Code Blog Editor

The Dead Sea Scrolls were lost in the Judean desert for more than 2000 years before being rediscovered in 1947. Now The Digital Dead Sea Scrolls project makes five of the ancient documents available online to everyone.



The online scrolls contain incredibly high-resolution photography (up to 1200 megapixels) and an English translation along with the original Hebrew text. Looking through the scrolls online is a remarkable mashup of ancient artifacts and modern technology.

Not everything can be done online: sometimes you need to be there. When a magnitude 5.8 earthquake struck near Washington, D.C. last August, the Washington Monument suffered visible damage. This week the U. S. National Park Service sent its "difficult access team" to rappel up and down the monument to check for damage. Civil Engineer Emma Cardini seemed to enjoy the task and was quoted as saying "It’s really cool to see the planes flying under you". See, that’s why it’s great to be an engineer.

Birds fly, too – but dinosaurs with feathers? Check out this news from Canada about the discovery of amber-bound feathers that belonged to dinosaurs and birds from the late Cretaceous period.


Fridaygram is a weekly post containing a cool Google-related announcement and a couple of fun science-based tidbits. But no cake.

Posted:

By Matt Braithwaite, Transparency Engineering Tech Lead

More than a year ago, we launched our Transparency Report, which is a site that shows the availability of Google services around the world and lists the number of requests we’ve received from governments to either hand over data or to remove content. We wanted to provide a snapshot of government actions on the Web — and in recent cases like Libya and Myanmar, we were glad to see users start to get back on our services.

Today, we’re releasing the raw data behind our Government Requests tool in CSV format. Interested developers and researchers can take this data and revisualize it in different ways, or mash it up with information from other organizations to test and draw up new hypotheses about government behaviors online. We’ll keep these files up-to-date with each biannual data release. We’ve already seen some pretty cool visualizations of this data, despite the lack of a machine-readable version, but we figure that easier access can only help others to find new trends and make new inferences.

The data has grown complex enough that we can no longer build a UI that anticipates every question you might want to ask. For example, the Transparency Report doesn’t allow you to ask the question, "Which Google products receive the greatest number of removal requests across all countries?" Using Google Fusion Tables you can answer that question easily. (The top four are Google Web Search, YouTube, orkut, and Blogger.)

We believe it’s important to keep providing data to anchor policy conversations about Internet access and censorship with real facts — and we’ll continue to add more raw data and APIs to the Transparency Report in the future. So much can be done when engineers and policy wonks come together to talk about the future of the Internet, and we’re psyched to see the graphs, mashups, apps, and other great designs people come up with.

To kick things off, we’re sponsoring a forum to demonstrate the power of what can happen when engineering and policy work together. If you're an EU-based hacker, we invite you to apply to join us for an all-expenses-paid hackathon using this data at the EU Parliament in Brussels on November 8-9, 2011.


Matt Braithwaite is the Tech Lead for Google's Chicago-based Transparency Engineering team. He has a beard (not shown).

Posted by Scott Knaster, Editor

Posted:

Author PictureBy Amy Walgenbach, Google Developer Marketing

Our developer program started in 2005 with a handful of APIs and developer advocates. Fast forward to today: Google offers over 100 APIs, dozens of developer tools, and a raft of developer advocates around the world. Obviously, a lot has changed and the Web has matured significantly. Google has also evolved and matured, and we felt that it was time to step back and rethink how we interact with and support our developer community. We believe we can make it easier to find what you’re looking for, and facilitate connections with others in the Google Developer community. We know we can do better and we want your input so that we can understand your needs — and what drives you — better.


Now we want to hear from you.

We want to know what inspires you as a developer and how Google can support you. What does being a Google developer mean to you? Tell us what’s important to you and how we can make your experience as a Google developer better. Like any good open source project, the Google developers project needs your contributions. Share your story so we can we better support your success — and we may just pick you to be featured.

You can add a video (it's easy, really!) directly from the page, on your mobile phone, or write to us here. However you share with us, we’re looking forward to hearing what you have to say.


Amy Walgenbach is the Product Marketing lead for the Google+ platform and leads developer marketing for games at Google.

Posted by Ashleigh Rentz, Editor Emerita

Posted:

This guest post was written by Beau Harrington, Senior Development Director, Kabam

Cross-posted with the Google Commerce Blog

Kabam was part of the initial launch of Google+ Games with two game titles, Dragons of Atlantis and Edgeworld, and we recently added Global Warfare. For these games, we integrated Google In-App Payments and we’re pleased with our games’ monetization to date. There are a couple things we learned along the way that we’re happy to share with the community.

Integrating In-App Payments

Integrating In-App Payments in our games was very simple, especially when compared to other payment platforms. There is excellent documentation available, complete with examples for each step of the purchase flow. We also used open-source libraries such as ruby-jwt to generate the tokens required for each purchase option.

We designed our games and purchase pages around the expectation of instant feedback, making sure to incorporate page loads or refreshes wherever possible. For example, in Edgeworld, a player attacking an enemy base can load the list of Platinum options instantly, without waiting for the list of payment options to load. After their Platinum purchase, the player is immediately brought back to the game, with their new currency and items waiting for them.

Pro tip: strive to reduce purchaser friction

One of the keys to maximizing revenue is to remove as much friction as possible from the purchase flow, making sure as many people as possible get from one step of the flow to the next. Many payment platforms send players to their own website and multi-page checkout flow. The Google In-App Payments approach allows us to keep players on our game page for the entire flow, making sure we can manage more of the process and reduce abandonment.

Additionally, the player's credit card information is stored securely, so once a player has made a purchase anywhere using In-App Payments, their information is available for future purchases without additional data entry. Finally, JavaScript callbacks provided by In-App Payments allow us to show the effects of the purchase immediately, improving customer satisfaction.

General recommendations

For those experienced in this space, the following may seem rudimentary. At the same time, I’d be remiss not to include these recommendations as they are important to developing a successful game payments system:
  • Make sure your payment flow is as seamless as possible, never giving the player the opportunity to get bored waiting for something to load. 
  • Record and monitor each step of the payment flow in order to identify potential problems. 
  • Run A/B tests on your purchase option page to optimize the number of players who make a purchase, as well as the amount of the average purchase. 
We are proud to be among the first companies on Google’s exciting new monetization platform, and we look forward to the continuing growth in features, functionality and developer tools.

Beau Harrington is Senior Development Director of Kabam

Posted by Scott Knaster, Editor

Posted:

By Jeremie Lenfant-Engelmann, Google Web Fonts Engineer

We’ve received lots of requests from developers for a dynamic feed of the most recent web fonts offered via Google Web Fonts. Such a feed would ensure that you can incorporate Google Web Fonts into applications and menus dynamically, without the need to hardcode any URLs. The benefits of this approach are clear. As Google Web Fonts continues to add fonts, these fonts can become immediately available within your applications and sites.

To address this need, we’ve built the Google Web Fonts Developer API, which provides a list of fonts offered via Google Web Fonts. Results can be sorted by alpha, date added, popularity, number of styles available, and trending (which is a measure of fonts growing rapidly in usage). Check out the documentation to get started.

Some developers have helped us test this new API over the last few months, and the results are already public. Take a look at TypeDNA’s photoshop plugin as well as Faviconist, an app that makes generating favicons as simple as can be, and Google Web Fonts Families, a list of Google Web Fonts that have more than one style.

We look forward to seeing what you come up with!

Jeremie Lenfant-Engelmann is a Software Engineer on the Google Web Fonts team.

Posted by Scott Knaster, Editor

Posted:

By Alexandra Levich, Product Manager

Cross-posted from the Chromium Blog

We recently expanded the reach of the Chrome Web Store from the U.S. to 24 more countries. Developers from around the world have already launched successful apps in the Chrome Web Store to US users. Now all developers can reach a global user base.

What makes this global reach even more interesting is the global payments infrastructure that goes along with it. The store allows developers from 20 countries to sell apps in the store, and users to buy apps in their local currency. We also recently launched the In-App Payments API, which allows developers (U.S.-only for now; international soon) to sell virtual goods in their apps. Integration is easy and transaction fees are only 5%. Graphicly, an early user of in-app payments, saw its net revenues double after starting to use the API and experienced an even bigger rise in profit margins due to increased conversions and lower transaction fees.

In keeping with our international theme, we’d like to highlight a few developers from different parts of the world who have utilized Chrome’s global reach to find success in the store:
  • Audiotool is an online music production app that was built by a team of German developers. They saw the Chrome Web Store as a way to present their app to an international audience. Audiotool’s traffic increased by 20% after launching in the store, and this motivated the team to release another app in the store.
  • Psykopaint is the brainchild of French developer Mathieu Gosselin. The Chrome Web Store provided Mathieu an opportunity to get his photo painting app noticed outside of France. Traffic to Psykopaint has jumped by 700% since it launched in the store and Mathieu has found that Chrome Web Store users tend to be more engaged than other users.
  • Finally, Nulab, a Japanese company, launched its online diagramming app, Cacoo, in the store to expand its user base outside Japan. In just a few months after Cacoo was released in multiple languages in the Chrome Web Store, the app already accounts for 20% of Cacoo’s user base.
The experience of Audiotool, Psykopaint and Nulab shows that no matter where you’re located, you can always find a global audience for your applications in the Chrome Web Store. To learn more about the stories of these and other successful Chrome Web Store developers, read our case studies. And if you want to find out more about posting your app in the store, visit our documentation at code.google.com/chrome/webstore.


Alex Levich is a product manager working on Chrome Web Store.

Posted by Scott Knaster, Editor

Posted:

By Scott Knaster, Google Code Blog Editor

Hackathons are a blast. There are few experiences better than writing code all night with dozens or hundreds of others, consuming free food, and converting that sweet sleep deprivation into creativity as you hack. As hackathons go, this one is spectacular: Hack4Transparency takes place in Brussels at the European Parliament. The goal of this event is to make data more accessible and intelligible to consumers and to government.


You expect food and WiFi at a hackathon. But this is really cool: if you’re selected to attend, the hackathon pays your travel and accommodation expenses, and a couple of the best hacks will win a prize of €3.000. If that got your attention, read the full story on our Open Source Blog, and then apply to attend.

When I was a wee hacker, I would sometimes break up my coding sessions with a primitive videogame called Pong. Physicists at Cambridge University are still playing this game, sort of, except now they’re knocking a single electron back and forth. As if that Pong ball wasn’t small and easy to miss enough already.

Finally, if you have some time this weekend and you’re not coding or playing video games, you can check out this excellent collection of sounds from spaceflights posted by NASA. You can even make them into ringtones, so if you want to hear a 50-year-old Sputnik beep when your friends call, go for it.

Posted:

By Rania Hadi, MENA Outreach Manager

Get your laptops ready – Google is coming to town! We are announcing our back-to-back Google Days in Dubai and Amman in October. Packed with dynamic sessions on all things Google, Googlers will provide developers, webmasters, students, IT and business professionals the chance to see and learn about the latest technologies.

g|uae will take place from Oct 19-20, and g|Jordan from Oct 23-24. Building on previous Google Days in MENA, each day of the 2-day conferences will cater to a different audience. From developers to computer science students, digital advocates to entrepreneurs, women in technology to tech marketers, we will have a wide variety of sessions delivered by a cross section of international Googlers. They’ll be there to interact with you, answer questions, brainstorm ideas, and provide both beginner lectures and hands-on codelabs and workshops.

While we’d love to accommodate as many as possible, space is limited so please register for g|uae and g|jordan as soon as possible. You will then be fully registered as soon as we send you a confirmation. If you still aren’t convinced, check out the fun we’ve had at past events.



Hope to see you at g|uae and g|jordan 2011!


Rania Hadi has been with Google since 2004 and now works on Outreach in MENA. She focuses on building relationships and promoting Google technologies with the developer and tech communities.

Posted by Scott Knaster, Editor


Posted:

By Richard Dunn, Technical Lead, Google+ platform for Hangouts

Cross-posted from the Google+ Platform Blog

In the three months since we launched face-to-face-to-face communication in Google+ Hangouts, I’ve been impressed by the many ways people use them. We’ve seen Hangouts for game shows, fantasy football drafts, guitar lessons and even hangouts for writers to break their solitary confinement. That’s just the beginning. Real-time applications are more engaging, fun, and interactive, but were hard for developers to deliver. Until now.

Today we’re launching the Developer Preview of the Hangouts API, another small piece of the Google+ platform. It enables you to add your own experiences to Hangouts and instantly build real-time applications, just like our first application, the built-in YouTube player.

The integration model is simple -- you build a web app, register it with us, and specify who on your team can load it into their Hangout. Your app behaves like a normal web app, plus it can take part in the real-time conversation with new APIs like synchronization. Now you can create a "shared state" among all instances of your app so that all of your users can be instantly notified of changes made by anyone else. (This is how the YouTube player keeps videos in sync.) And we’ve added our first few multimedia APIs so you can, for example, mute the audio and video feeds of Hangout participants.

When you’re ready to start hacking, we’re ready for you -- read the documentation, sign up, and start coding. We’re anxious to get your feedback, since this is a very early version of the API. We’ll be making improvements and moving towards full production based on what we learn together. And we’ll be releasing new updates on a regular basis, so stay tuned!

Follow the conversation on Google+.

Richard Dunn is Technical Lead, Google+ platform for Hangouts


Posted by Scott Knaster, Editor

Posted:

By Yaniv Inbar, Google APIs Client Team

During Google I/O 2011, we announced a major milestone by releasing the Beta version of the open source Google APIs Client Library for Java. This release included service-specific libraries and samples for Google APIs, built on our new client library generation infrastructure. Since that version 1.4 launch, we’ve been comfortable enough with the stability and features of the library that we want you to start building real production Java 5, Android, and Google App Engine applications and send us your feedback.

Today we are announcing a new milestone for the Java client library. With the version 1.5 release, we’re making available the open source Google OAuth Client Library for Java in Beta, with support for both OAuth 1.0a and OAuth 2.0. OAuth is an open standard for allowing a client application to securely gain access to a user’s private data stored on Google without ever asking for their password. Most Google APIs support OAuth 2.0, and we want to encourage adoption of OAuth 2.0 more widely on the web. That’s why we built this library to work with any API on the web -- not just Google APIs -- that comply with the OAuth specifications. Our current implementation of OAuth 2.0 is based on draft 10, but we will update it soon to the final draft, once it becomes an official standard. We encourage you to try it and send us your feedback.

Here is an example of how easy it is to use the OAuth 2.0 library to make a request using the library for the Google+ API (check out more samples):
// Set up the HTTP transport and JSON factory
HttpTransport httpTransport = new NetHttpTransport();
JsonFactory jsonFactory = new JacksonFactory();

// Set up OAuth 2.0 access of protected resources
// using the refresh and access tokens, automatically
// refreshing the access token when it expires

GoogleAccessProtectedResource requestInitializer =
new GoogleAccessProtectedResource(accessToken, httpTransport,
jsonFactory, clientId, clientSecret, refreshToken);

// Set up the main Google+ class
Plus plus = new Plus(httpTransport, requestInitializer, jsonFactory);

// Make a request to access your profile and display it to console
Person profile = plus.people().get("me").execute();
System.out.println("ID: " + profile.getId());
System.out.println("Name: " + profile.getDisplayName());
System.out.println("Image URL: " + profile.getImage().getUrl());
System.out.println("Profile URL: " + profile.getUrl());
Finally, we are making available a Beta version of the open source Google HTTP Client Library for Java. This is the common HTTP client library that the above two libraries are built on, and is built to work with any API on the web. It features a pluggable HTTP transport abstraction that allows it to work seamlessly on any of the supported Java platforms, support for efficient JSON and XML data models for parsing and serialization, and a pluggable JSON and XML parser so you can use whatever works best for you. Please try it and send us your feedback.

We are looking forward to finding out what you can build using these libraries on Google APIs. Please let us know how we can make the libraries easier to use and better suited for your needs.

As we announced at Google I/O 2010, we've been developing APIs that can provide descriptions of themselves via metadata. This new technique makes it easier to create and maintain client libraries that support more languages, work with more APIs, and are easier to use than ever before. This post announces one of several recent major milestones for our client libraries.


Yaniv Inbar is a Senior Software Engineer and Technical Lead of the Google APIs Client Libraries & Tools team. He is the lead developer of the open source Google APIs Client Library for Java. Yaniv has worked at Google for 5 years, and has a total of 12 years industry experience as a software engineer.

Posted by Scott Knaster, Editor

Posted:

By Scott Knaster, Google Code Blog Editor

YouTube is not just for uploading any more. This week YouTube launched a bunch of editing tools that enable you to trim your videos, add effects like Sepia and Thermal, replace the audio track, and even rotate that priceless video you shot while accidentally holding the phone upside down – or is that just me?



Those funny YouTube videos might even be good for your health. We are simple computer folk here, not medical doctors, but check out this article about the physical benefits of laughing and related topics.

After reading about laughing and scouring YouTube for hilarity, you can calm yourself with these unfunny but remarkable images of distant planets. Hmm, I wonder if they can edit YouTube videos on their worlds.


Fridaygram is our way of telling you about something new and (we hope) interesting from Google, along with tidbits about nature, science, and other nerd-cool topics. Fridaygram posts are more fun than a barrel of opee sea killers.

Posted:
Jacob
Gustavo
By Jacob Moshenko and Gustavo Moura, Software Engineers

In January of this year we launched BigQuery integration with Google Apps Script. What we didn’t mention was that we were building this on top of our Google APIs Discovery Service. Thanks to the ease and flexibility of writing clients based on this API, today we’re announcing integration with three more APIs, and revamping our BigQuery support.

As of now, we have also integrated the Tasks API, Prediction API, and URL Shortener API in addition to the BigQuery API. You can now include these APIs in your scripts, apps, and sites pages. As with other Apps Script services, we handle all of the server communications as well as authorization, which makes this a great way to build mashups and workflows using our APIs.

To get started, simply enable the APIs you’re interested in from the "Use Google API services" menu in the script editor.


Using this feature will prompt you to save your script. Once you have done so, the Google APIs Services dialog will appear and you can choose which APIs to use, which versions to use, and what name to use when referencing them from your scripts.


After you complete this step, the API methods will be automatically populated as you type using the standard Apps Script autocomplete mechanism. For detailed information about each API, visit our reference documentation. We have also created a tutorial with a simple, fun application to help you get started using scripts.

As we iron out this new technology and listen to your feedback we plan to aggressively integrate even more APIs. If you have any questions or experience any problems let us know on our support forum.

Jacob Moshenko is a Software Engineer working on the Google APIs developer experience. He believes that Google APIs should be easy to use, especially from Google platforms.

Gustavo Moura has been a Software Engineer at Google since 2007. He has been part of the Google Docs team since 2009. Prior to that, he worked on AdWords.

Posted by Scott Knaster, Editor

Posted:

By Chris Chabot, Google+ Developer Relations

Cross-posted with the Google+ Platform Blog

The Google+ project brings the nuance and richness of real-life sharing to software. The Google+ platform brings that nuance and richness to all of the web. We started with Google’s own products, added the +1 button for site owners and content publishers, and introduced games from a handful of partners. That’s just the beginning though — we want every one of you who builds applications to be able to include rich sharing, identity, and conversations in your app. Today, we’re taking the next step on that journey by launching the first of the Google+ APIs.

Let's Go Public

Google+ gives users full control over their information, supporting everything from intimate conversations with family to public showcases and debates. This initial API release is focused on public data only — it lets you read information that people have shared publicly on Google+. For example, if you want to get my profile information, you can use the people.get method by sending the following HTTP request:

GET https://www.googleapis.com/plus/v1/people/108189587050871927619?key=yourAPIKey

which returns the following JSON encoded output (excerpted for brevity):
{
"kind": "plus#person",
"id": "108189587050871927619",
"displayName": "Chris Chabot",
"image": {
"url": "https://lh5.googleusercontent.com/-cQNLOQzkGpE/AAAAAAAAAAI/AAAAAAAAEjo/M9_pXL-ra4Q/photo.jpg"
},
"organizations": [
{
"name": "Google+ Developer Relations",
"title": "Developer Advocate & Manager",
"type": "work"
}
]
}
Similarly, you can get a list of my most recent public posts by using the activities.list method:

GET https://www.googleapis.com/plus/v1/people/108189587050871927619/activities/public?key=yourAPIKey

Because we’re starting with public data only, you simply need to register your app before making requests. And if you aren't yet sure which Google+ user is running your app (for example, because they're installing it for the first time), then you can use the new plus.me OAuth2 scope to ask the user who they are.

After your application has requested this scope, you can use the special “me” identifier rather than the long numeric identifier:

GET https://www.googleapis.com/plus/v1/people/me

On The Shoulders of Giants

We love the way the programmable web has evolved, so we’re using existing standards and best practices wherever we can:
  • Our API methods are RESTful HTTP requests which return JSON responses.
  • Our payload formats use standard syntax (e.g. PoCo for people info, ActivityStrea.ms for activities).
  • We use OAuth 2 for secure trusted access to user data.
In addition, since most of us no longer write raw HTTP requests these days, we provide libraries for your favorite language: Java, GWT, Python, Ruby, PHP, Objective-C, and .NET. These libraries are all open source, so we’d love to have your feedback and help with them.

developers.google.com

You can find more information about the Google+ platform, including today’s new APIs to public data, at developers.google.com/+ on our new Google Developers site. This site will be the place to go for access to documentation, terms and policies, discussions with other developers, tools that make development on the +Platform easier and more fun and, of course, the place where announcements concerning new releases will be made.

Included in our policies are three simple guidelines that we aspire to in our own products, and that we’d like all applications built on the Google+ platform to follow also: put the user first, be transparent, and respect user data. The goal behind these guidelines, as with all of the features and fine print, is to work together to build products that our users will love.

And now …

For all of you developers who have been asking for a Google+ API, this is the start. Experiment with it. Build apps on it. Give us your feedback and ideas. This is just the beginning; the Google+ platform will grow and we value your input as we move Google+ forward.

Follow the conversation on Google+.

Chris Chabot is a Developer Advocate on the Google+ Team.

Posted by Scott Knaster, Editor

Posted:

By Amir Shevat, Developer Relations

Registration for Google Developer Day in Tel Aviv is now open! To sign up, visit the GDD Tel Aviv webpage , click Register Now, and fill out the form. We hope to see you at GDD 2011 in Israel.

Amir Shevat is a Developer Relations Program Manager for Google. He is an Open Source developer at heart and fully licensed geek.

Posted by Scott Knaster, Editor

Posted:

By Scott Knaster, Google Code Blog Editor

This week the Google Green Blog reported on Google’s use of energy in our buildings and data centers. All Google’s services combined use about as much energy per person in a month as a 60-watt light bulb burning for 3 hours, and the energy that is used is offset completely. You can read the details here, with a separate post describing our carbon offsets program.

Smart people at Tufts University used an infinitesimal amount of energy to power the smallest known electrical motor. The motor is a single molecule of butyl methyl sulphide, measuring a billionth of a meter across. Researchers are going to try to get a bunch of these molecules together to create super-tiny gears and see what cool things they can learn.

Bigger machines also made nerdy news this week. NASA released images that show evidence of human activity on the moon at the landing sites for Apollo 12, 14, and 17. The photos show where the lunar rover parked, tools used by the astronauts, and even astronaut footprints, all of which are intact 40 years after they were created. However, there is still no known photographic evidence of the Googlunaplex.

Fridaygram posts are just for fun. They're designed for your Friday afternoon and weekend enjoyment. Each Fridaygram item must pass only one test: it has to be interesting to us nerds.

Posted:

By Chirag Shah, Developer Programs Engineer

Today we are announcing a major milestone for another one of the Google APIs client libraries. The Google APIs Client Library for PHP has officially reached Beta.

This means we're comfortable enough with the stability and features of the library that we'd like you to start building real production applications on top of it and send us your feedback. The library now includes service-specific libraries and samples for several Google APIs, built on our new client library generation infrastructure.

The Google API PHP client supports the following Google APIs right now, with more on the way.
To grab the latest version of the library, simply run the following commands:
curl "http://google-api-php-client.googlecode.com/files/google-api-php-client-0.4.1.tar.gz" -O
tar -xvf google-api-php-client-0.4.1.tar.gz
cd google-api-php-client/examples/
Here is some sample code that demonstrates how to use the library and the Google Books API to search for and print the titles of free ebooks by Henry David Thoreau:
<?php
require_once 'path/to/src/apiClient.php';
require_once 'path/to/src/contrib/apiBooksService.php';

$client = new apiClient();
$client->setApplicationName("My_Books_API_Example");
$service = new apiBooksService($client);

$optParams = array('filter' => 'free-ebooks');
$results = $service->volumes->listVolumes('Henry David Thoreau', $optParams);

foreach ($results['items'] as $item) {
print($item['volumeInfo']['title'] . '<br>');
}
Let us know what you think. We would love to hear your feedback and are always happy to help you out on the forums.

Since Google I/O 2010, we've been developing APIs that can provide descriptions of themselves via metadata. This new technique makes it easier to create and maintain client libraries that support more languages, work with more APIs, and are easier to use than ever before. This post announces one of several recent major milestones for our client libraries.


Chirag Shah is a Developer Programs Engineer on the Google+ team.
In his spare time, he enjoys listening to music and contributing to open source projects.


Posted by Scott Knaster, Editor


Posted:

By Pieter Senster, Software Engineer

In June we released Swiffy, an experimental tool to convert Flash to HTML5, on Google Labs. We were thrilled with the response: in the first month, Swiffy users converted hundreds of thousands of files.

We received a lot of feedback from developers after the launch, and we learnt a lot from studying the warnings generated in the conversion process. As a result, we’ve released several improvements over the last few weeks. For example, Swiffy now supports shape tweening and drop shadow, blur and glow filters, all using SVG, CSS and JavaScript. Some of these filters can be seen in action in this Chrome ad (on a browser with SVG filter support).

We’ve also made Swiffy easier to use. You can now convert files of up to 1MB, and you’ll get a QR code to preview the output on a mobile device. We’ve also made it clear that you can host the Swiffy runtime (the JavaScript file that controls the animation) yourself if you need to.

Although Google Labs is winding down, Swiffy will continue to be available. We’re moving Swiffy to a new home: http://www.google.com/doubleclick/studio/swiffy (or, for those in a hurry, g.co/swiffy). Although it’s no longer a Labs product, it is still in beta, so it may not be able to convert all your Flash files, but we’re working to improve it all the time.

Pieter Senster is a Software Engineer on the Swiffy team. He's currently planning his first diving trip to the Great Barrier Reef.

Posted by Scott Knaster, Editor


Posted:

By Scott Knaster, Google Code Blog Editor

Blogger rolled out some nice new stuff this week. It’s different inside and out. As a heavy user of Blogger (you’re soaking in it!), I’m happy with anything that helps us make a better blog for you to read. If you have a Blogger blog of your own, here are a couple of the changes you’ll notice:
  • Each settings page has a button that starts a new post. Creating posts is what bloggers do most, and now you always can get to the post editor with one click.
  • You can see traffic and other stats in one place. The new Overview page shows you page views, comment activity, follower counts, and more.
For more information on what’s new in Blogger, and to find out how to turn on the new features, see this Blogger Buzz post.

Adding features to software is hard enough. Bumping celestial bodies around is another matter entirely. Hexi Baoyin of Tsinghua University has suggested giving a gentle shove to an asteroid so that it ends up in Earth orbit. Why? For science!

Of course, technology of the future involves more than just potentially rearranging our solar system. For example, check out what happened when two chatbots had a conversation. Looks kind of like the pilot for a new TV show.

We love science, technology, fun, and Fridays. So most weeks we put all those things together and write Fridaygram, a post that’s not meant to be taken too seriously.

Posted:
Yaniv
Matthias
By Yaniv Inbar and Matthias Linder, Client APIs Team

Over the last year, we’ve launched a number of developer APIs, such as the Tasks API, the Books API, the Search API for Shopping, and the CustomSearch API. At Google I/O we announced a number of developer tools, such as the APIs Explorer and the APIs Console. Over that time, we have been actively developing a library to support the Microsoft .NET Framework.

Today we are announcing a major milestone by releasing the Beta version of the open source Google APIs Client Library for .NET. This includes service-specific libraries and samples for Google APIs, built on our new client library generation infrastructure. We're now comfortable enough with the stability and features of the library that we want you to start building real production applications. Currently we support Microsoft .NET 3.5 and 4.0 and Mono 2.6.7 (and higher). In the future we hope to also support Windows Phone 7 and Microsoft Silverlight.

To demonstrate how easy to use the library can be, here is a snippet from the goo.gl sample to shorten a URL using the goo.gl service:

// Create an instance of the UrlShortener-service.
var service = new UrlshortenerService();

// Make a "Shorten URL" request.
string urlToShorten = "http://maps.google.com/";
Url response =
  service
.Url.Insert(new Url { LongUrl = urlToShorten }).Fetch();

// Print the shortened url.
string shortUrl = response.Id;
Console.WriteLine(urlToShorten + " -> " + shortUrl);
To use this code, you only have to add references to the Google APIs Client Library for .NET, and the Google.Apis.Urlshortener.v1.dll.

Please send us your feedback on how we can make your experience with the library easier and better suited for your needs.

Since Google I/O 2010, we've been developing APIs that can provide descriptions of themselves via metadata. This new technique makes it easier to create and maintain client libraries that support more languages, work with more APIs, and are easier to use than ever before. This post announces one of several recent major milestones for our client libraries.


Yaniv Inbar is a Senior Software Engineer and Technical Lead of the Google APIs Client Libraries & Tools team. Yaniv has worked at Google for 5 years, and has a total of 12 years industry experience as a software engineer.

Matthias Linder is a Software Engineering Intern. Matthias is interested in game development, microcontrollers, and paragliding.


Posted by Scott Knaster, Editor