Création des Logiciels de gestion d'Entreprise, Création et référencement des sites web, Réseaux et Maintenance, Conception
seo Google I/O Scavenger Hunt Winners 2013
Seo Master present to you: The astute conference attendee would have noticed hidden QR codes around the conference, as well as the scannable QR codes on everyone's badge. We wanted to find a fun way for people to bond with their new phones, as well as network with other attendees, so we set about creating a scavenger hunt game using Google App Engine & Friend Connect. The app handled game logistics (a leaderboard, URL endpoints), and we printed up a bunch of custom QR code stickers that pointed to game URLs.
App Engine made writing the scavenger hunt app much easier than it otherwise would have been. The initial version of the app took one developer less than a day to turn out, and we continued to add functionality and tweak it as I/O approached and we tested it in real-world situations. The versioning deployment made it very easy to test and push out new versions without disrupting existing users.
The overall structure of the app was very straightforward: every QR-code had a unique URL, which was embedded into the generated QR code. A URL was associated with a number of points to be awarded and a destination URL (such as the user's profile information, in the case of a user's badge QR code). Users were signed in using Friend Connect, which allowed us to avoid concerns of authenticating users and managing sessions.
When a user visited a URL for the first time, we recorded that fact so they couldn't try and get extra points with repeat visits, then sent them to the destination URL. We also kept a running count of the user's score against the User entity, so as to not have to count up their points on every request. Generating the leaderboard was a simple matter of querying for the users with the most points and displaying them.
QR codes were generated using the Chart API, which simply takes a string of text and a few other parameters, and returns a fully formed QR code.
The three resourceful and persistent folks below beat out the competition to rise to the top of the scavenger hunt ranks - going to great lengths, including swag bribery, to gain points. A hearty (if belated) congratulations to the winners of the Google I/O mobile scavenger hunt!
1st Place - Abraham Williams
2nd Place - Waylon Flinn
3rd Place - Pete Richards
We hope everyone that participated learned how to use their Android phones a little better, met people they otherwise wouldn't have, and had some fun :)
App Engine made writing the scavenger hunt app much easier than it otherwise would have been. The initial version of the app took one developer less than a day to turn out, and we continued to add functionality and tweak it as I/O approached and we tested it in real-world situations. The versioning deployment made it very easy to test and push out new versions without disrupting existing users.
The overall structure of the app was very straightforward: every QR-code had a unique URL, which was embedded into the generated QR code. A URL was associated with a number of points to be awarded and a destination URL (such as the user's profile information, in the case of a user's badge QR code). Users were signed in using Friend Connect, which allowed us to avoid concerns of authenticating users and managing sessions.
When a user visited a URL for the first time, we recorded that fact so they couldn't try and get extra points with repeat visits, then sent them to the destination URL. We also kept a running count of the user's score against the User entity, so as to not have to count up their points on every request. Generating the leaderboard was a simple matter of querying for the users with the most points and displaying them.
QR codes were generated using the Chart API, which simply takes a string of text and a few other parameters, and returns a fully formed QR code.
The three resourceful and persistent folks below beat out the competition to rise to the top of the scavenger hunt ranks - going to great lengths, including swag bribery, to gain points. A hearty (if belated) congratulations to the winners of the Google I/O mobile scavenger hunt!
1st Place - Abraham Williams
2nd Place - Waylon Flinn
3rd Place - Pete Richards
We hope everyone that participated learned how to use their Android phones a little better, met people they otherwise wouldn't have, and had some fun :)
2013, By: Seo Master
seo Enabling Public Service: All for Good and Google App Engine 2013
Seo Master present to you:
You may have seen the post on the Google Blog about All for Good, the new site that makes it easy to find and share volunteer activities within the United States. The site was built collaboratively by Google and several partners. We're especially proud that it was built using 100% open source Python code. All for Good's first release includes both gadgets and a free API, making it even easier for casual developers to build applications and embed All for Good listings in their own apps and sites.
If you're interested in seeing your software talents dedicated to community service, check out the API documentation, our Getting Started Guide and the complete source code for the core engine. We're especially looking forward to see what applications the developer community will create for mobile platforms and for Facebook. Happy Hacking!
by Guido van Rossum, Software Engineering Team2013, By: Seo Master
You may have seen the post on the Google Blog about All for Good, the new site that makes it easy to find and share volunteer activities within the United States. The site was built collaboratively by Google and several partners. We're especially proud that it was built using 100% open source Python code. All for Good's first release includes both gadgets and a free API, making it even easier for casual developers to build applications and embed All for Good listings in their own apps and sites.
If you're interested in seeing your software talents dedicated to community service, check out the API documentation, our Getting Started Guide and the complete source code for the core engine. We're especially looking forward to see what applications the developer community will create for mobile platforms and for Facebook. Happy Hacking!
by Guido van Rossum, Software Engineering Team2013, By: Seo Master
seo Google Compute Engine: Computing without limits 2013
Seo Master present to you: 
By Craig McLuckie, Product Manager, Google Compute Engine
Over the years, Google has built some of the most high performing, scalable and efficient data centers in the world by constantly refining our hardware and software. Since 2008, we've been working to open up our infrastructure to outside developers and businesses so they can take advantage of our cloud as they build applications and websites and store and analyze data. So far this includes products like Google App Engine, Google Cloud Storage, and Google BigQuery.
Today, in response to many requests from developers and businesses, we're going a step further. We're introducing Google Compute Engine, an Infrastructure-as-a-Service product that lets you run Linux Virtual Machines (VMs) on the same infrastructure that powers Google. This goes beyond just giving you greater flexibility and control; access to computing resources at this scale can fundamentally change the way you think about tackling a problem.
Google Compute Engine offers:
You can learn more about Google Compute Engine here. We’re going to pace ourselves and start with Google Compute Engine in limited preview (sign up here), but our goal is to give you all the pieces you need to build anything you want in the cloud. Whether you need a platform like Google App Engine, or virtual machines like Google Compute Engine, these days, you define your limits. We’re just at the start of what the cloud can do.
Craig McLuckie is the Product Management Lead for Google Compute Engine. He spends his days working with an amazing engineering team to open Google’s infrastructure to the world.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Craig McLuckie, Product Manager, Google Compute Engine
Over the years, Google has built some of the most high performing, scalable and efficient data centers in the world by constantly refining our hardware and software. Since 2008, we've been working to open up our infrastructure to outside developers and businesses so they can take advantage of our cloud as they build applications and websites and store and analyze data. So far this includes products like Google App Engine, Google Cloud Storage, and Google BigQuery.
Today, in response to many requests from developers and businesses, we're going a step further. We're introducing Google Compute Engine, an Infrastructure-as-a-Service product that lets you run Linux Virtual Machines (VMs) on the same infrastructure that powers Google. This goes beyond just giving you greater flexibility and control; access to computing resources at this scale can fundamentally change the way you think about tackling a problem.
Google Compute Engine offers:
- Scale. At Google we tackle huge computing tasks all the time, like indexing the web, or handling billions of search queries a day. Using Google's data centers, Google Compute Engine reduces the time to scale up for tasks that require large amounts of computing power. You can launch enormous compute clusters - tens of thousands of cores or more.
- Performance. Many of you have learned to live with erratic performance in the cloud. We have built our systems to offer strong and consistent performance even at massive scale. For example, we have sophisticated network connections that ensure consistency. Even in a shared cloud you don’t see interruptions; you can tune your app and rely on it not degrading.
- Value. Computing in the cloud is getting even more appealing from a cost perspective. The economy of scale and efficiency of our data centers allows Google Compute Engine to give you 50% more compute for your money than with other leading cloud providers. You can see pricing details here.
- Compute. Launch Linux VMs on-demand. 1, 2, 4 and 8 virtual core VMs are available with 3.75GB RAM per virtual core.
- Storage. Store data on local disk, on our new persistent block device, or on our Internet-scale object store, Google Cloud Storage.
- Network. Connect your VMs together using our high-performance network technology to form powerful compute clusters and manage connectivity to the Internet with configurable firewalls.
- Tooling. Configure and control your VMs via a scriptable command line tool or web UI. Or you can create your own dynamic management system using our API.
You can learn more about Google Compute Engine here. We’re going to pace ourselves and start with Google Compute Engine in limited preview (sign up here), but our goal is to give you all the pieces you need to build anything you want in the cloud. Whether you need a platform like Google App Engine, or virtual machines like Google Compute Engine, these days, you define your limits. We’re just at the start of what the cloud can do.
Craig McLuckie is the Product Management Lead for Google Compute Engine. He spends his days working with an amazing engineering team to open Google’s infrastructure to the world.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Google App Engine @ I/O: Java, offline processing, great partners. and more 2013
Seo Master present to you: 
2009 has been a busy year for the App Engine team, but all along we've looked forward to Google I/O and the excitement it brings to Google's developer community. At I/O last year, App Engine was brand new and many attendees were just getting familiar with the project. Well, what a difference a year makes - this year, in addition to sharing new information about our project, we got to learn about an amazing host of App Engine projects from you, our developers!
First, the big news - we are excited to announce open signups for our Java language runtime. During Wednesday's keynote, Engineering Manager Kevin Gibbs and Product Manager Andrew Bowers demoed the combined power of App Engine and GWT, all with easy deployment from the Eclipse IDE. If you've not tried our new language yet, please head over to the Admin Console to signup, then download the SDK and get programming.
The engineers behind Google App Engine for Java presented two sessions. First, Toby Reyelts and Don Schwarz introduced the new runtime with App Engine: Now Serving Java, including details of how our Java language layer exposes the power of Google's infrastructure. Be sure to check out the interactive game they demo'd with audience participation! Digging a bit deeper, Max Ross showed us The Softer Side of Schemas - how he mapped Java Persistence Standards to App Engine's datastore.
In addition to the new Java runtime, App Engine developer Brett Slatkin previewed some eagerly anticipated functionality: offline tasks. In his talk Offline Processing on App Engine: a Look Ahead, Brett revealed the first few milestones of App Engine's plan for offline processing with our upcoming Task Queue API. Leveraging the power of a web hook (an HTTP request body and URL) as the fundamental unit of execution on the web, this new API will allow you to organize and enqueue tasks for efficient background processing. Stay tuned to the App Engine blog for this feature's launch.
The App Engine team is always eager to share information about our infrastructure and how things work under the hood. Alon Levi kicked things off Wednesday morning with From Spark Plug to Drive Train: Life of an App Engine Request, in which he showed new information about how an application's incoming requests are received, scheduled, and executed by App Engine. Ryan Barrett presented some of the theoretical, yet practical challenges faced by the App Engine team with Transactions Across Datacenters (and Other Weekend Projects). Finally, Brett Slatkin took the stage once again, with Building Scalable, Complex Apps on App Engine, to give you insights on advanced data structures and algorithms.
In addition to the App Engine team, we were thrilled to have App Engine customers and partners present about their experience with the platform:
Thanks for making this year's Google I/O a fantastic success! We have much more in store for 2009, so be sure to watch the App Engine blog for updates!
Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.2013, By: Seo Master
2009 has been a busy year for the App Engine team, but all along we've looked forward to Google I/O and the excitement it brings to Google's developer community. At I/O last year, App Engine was brand new and many attendees were just getting familiar with the project. Well, what a difference a year makes - this year, in addition to sharing new information about our project, we got to learn about an amazing host of App Engine projects from you, our developers!First, the big news - we are excited to announce open signups for our Java language runtime. During Wednesday's keynote, Engineering Manager Kevin Gibbs and Product Manager Andrew Bowers demoed the combined power of App Engine and GWT, all with easy deployment from the Eclipse IDE. If you've not tried our new language yet, please head over to the Admin Console to signup, then download the SDK and get programming.
The engineers behind Google App Engine for Java presented two sessions. First, Toby Reyelts and Don Schwarz introduced the new runtime with App Engine: Now Serving Java, including details of how our Java language layer exposes the power of Google's infrastructure. Be sure to check out the interactive game they demo'd with audience participation! Digging a bit deeper, Max Ross showed us The Softer Side of Schemas - how he mapped Java Persistence Standards to App Engine's datastore.
In addition to the new Java runtime, App Engine developer Brett Slatkin previewed some eagerly anticipated functionality: offline tasks. In his talk Offline Processing on App Engine: a Look Ahead, Brett revealed the first few milestones of App Engine's plan for offline processing with our upcoming Task Queue API. Leveraging the power of a web hook (an HTTP request body and URL) as the fundamental unit of execution on the web, this new API will allow you to organize and enqueue tasks for efficient background processing. Stay tuned to the App Engine blog for this feature's launch.
The App Engine team is always eager to share information about our infrastructure and how things work under the hood. Alon Levi kicked things off Wednesday morning with From Spark Plug to Drive Train: Life of an App Engine Request, in which he showed new information about how an application's incoming requests are received, scheduled, and executed by App Engine. Ryan Barrett presented some of the theoretical, yet practical challenges faced by the App Engine team with Transactions Across Datacenters (and Other Weekend Projects). Finally, Brett Slatkin took the stage once again, with Building Scalable, Complex Apps on App Engine, to give you insights on advanced data structures and algorithms.
In addition to the App Engine team, we were thrilled to have App Engine customers and partners present about their experience with the platform:
- The Walk Score team shared their experience combining App Engine with other products in App Engine Nitty-Gritty: Scalability, Fault Tolerance, and Integrating Amazon EC2.
- Ola Bini gave a language implementor's view of our new Java runtime with JRuby and Ioke on Google App Engine for Java.
- Daniel Wilkerson presented distributed database theory in A Design for a Distributed Transaction Layer for Google App Engine.
- Guillaume Laforge from SpringSource did a rapid walkthrough of Groovy and how to write Groovy applications for App Engine with Groovy and Grails in App Engine
Thanks for making this year's Google I/O a fantastic success! We have much more in store for 2009, so be sure to watch the App Engine blog for updates!
Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.2013, By: Seo Master
seo Developers go big for business at Google I/O 2010 2013
Seo Master present to you: There was a big focus on developing software for businesses at Google I/O this year, centered around three themes: build and sell apps in the Marketplace, customize and extend Google's apps, and build your own apps for internal use. The news kicked off the day before Google I/O with the announcement of Gmail contextual gadgets and many enhancements for Google Apps Script, including JDBC support. Then during the keynote, we launched Google App Engine for Business and announced our collaboration with VMware, and continued with the announcement of Google Wave (Labs) availability in Google Apps and Exchange support in Android 2.2 (aka Froyo).
Altogether there were more than a dozen technical sessions focused on the enterprise and more than 20 Google Apps Marketplace vendors demoing in the Enterprise Developer Sandbox.
Here’s a recap of a few of the sessions below. You can find the videos and slides for these sessions on the linked session title:
We’re excited to see the great strides our enterprise developer community has made, and we're looking forward to seeing even more innovation and progress at next year’s I/O. We hope to see you then!
Posted by Ryan Boyd, Google Apps team2013, By: Seo Master
Altogether there were more than a dozen technical sessions focused on the enterprise and more than 20 Google Apps Marketplace vendors demoing in the Enterprise Developer Sandbox.Here’s a recap of a few of the sessions below. You can find the videos and slides for these sessions on the linked session title:
- Scripting Google Apps for business process automation - Google’s Evin Levey showed off the latest developments from Google Apps Script, and explained how developers can use the tool to automate business processes.
- Reach new customers fast: Learn how to sell your cloud app on the Google Apps Marketplace - Google’s Scott McMullan was joined by Jay Simmons (Atlassian), Chuck Dietrich (SlideRocket) and Amit Kulkarni (Manymoon) to discuss best practices for launching an app in the Google Apps Marketplace. This session was followed by a technical overview of how developers integrate apps with the Marketplace.
- Building context-aware extensions for Gmail - Deep dive on Gmail contextual gadgets - Google recently launched Gmail contextual gadgets, allowing developers to intelligently surface their apps directly in the Gmail message UI based on the content of the message. In this session, Dan Holevoet of Google explained how to create and distribute these gadgets.
- Run corporate applications on Google App Engine? Yes we do. Google CIO Ben Fried and his team discussed how Google runs real-world business applications on App Engine, and gave practical advice on how enterprise IT developers can make App Engine work with firewalls, legacy systems and proprietary systems. We unveiled this video yesterday along with the rest of the App Engine videos, but are reiterating it here as this session is quite relevant to the enterprise.
- Making Freemium work - converting free users to paying customers - In this panel moderated by Google’s Don Dodge, venture capitalists Brad Feld, Dave McClure, Jeff Clavier, Matt Holleran and Joe Kraus discussed strategies for building free products that can be upgraded to paid versions.
We’re excited to see the great strides our enterprise developer community has made, and we're looking forward to seeing even more innovation and progress at next year’s I/O. We hope to see you then!
Posted by Ryan Boyd, Google Apps team2013, By: Seo Master
seo The App Engine Team’s trip to I/O 2010 (Recap & Videos) 2013
Seo Master present to you: This year’s Google I/O included a flurry of announcements and presentations for the App Engine team. Thanks to everyone who attended our sessions, stopped by the Sandbox, or came to meet the team at our office hours. It was great to meet all of you. For the App Engine developers out there that weren't able to make it out this year, we wanted to give you a quick recap on what you missed.
We opened up the first day’s keynote with App Engine’s very own Kevin Gibbs announcing App Engine for Business and doing a demo of the new Business Admin Console. There’s lots of great new features coming with App Engine for Business so if you missed the announcement, please read more about it and sign up to be a part of the preview. We also announced our work with VMWare to connect our development tools in order to allow developers to use SpringSource tools and Google Web Toolkit to build applications and deploy them on App Engine.
If you were watching the keynote, you might have missed the announcement that we released version 1.3.4 of the App Engine SDK which included a brand new bulkloader and experimental support for OpenID and OAuth. The Blobstore API is also no longer experimental and supports files up to 2GB in size.
In addition to all the high profile announcements in the keynote, we also hosted a number of great sessions about App Engine development for the rest of the conference. Thanks to the dedicated I/O organizers, videos of all the App Engine sessions are now available so anyone can watch them (with more to come in the next few days):
There’s plenty of great information in all the presentations, so for those of you that missed, we highly recommend you watch the videos and read the slides. For everyone else that made it to I/O this year, thank you for making this year’s I/O a complete success. It’s incredibly energizing for us to see all your hard work, thoughtful questions, and great ideas on App Engine. We’re already excited to see what you all surprise us with at next year’s I/O!
By Sean Lynch, App Engine Team
2013, By: Seo Master
We opened up the first day’s keynote with App Engine’s very own Kevin Gibbs announcing App Engine for Business and doing a demo of the new Business Admin Console. There’s lots of great new features coming with App Engine for Business so if you missed the announcement, please read more about it and sign up to be a part of the preview. We also announced our work with VMWare to connect our development tools in order to allow developers to use SpringSource tools and Google Web Toolkit to build applications and deploy them on App Engine.
If you were watching the keynote, you might have missed the announcement that we released version 1.3.4 of the App Engine SDK which included a brand new bulkloader and experimental support for OpenID and OAuth. The Blobstore API is also no longer experimental and supports files up to 2GB in size.
In addition to all the high profile announcements in the keynote, we also hosted a number of great sessions about App Engine development for the rest of the conference. Thanks to the dedicated I/O organizers, videos of all the App Engine sessions are now available so anyone can watch them (with more to come in the next few days):
- Appstats - RPC instrumentation and optimizations for App Engine - Guido van Rossum went into detail on how to use Appstats, a new tool for App Engine developers which provides deep insight into why requests are slow and what they’re doing under the covers.
- Run corporate applications on Google App Engine? Yes we do - Ben Fried (Google’s CIO) and his team joined us to give an update on their progress of moving Google’s corporate applications to App Engine, the problems they ran into, and the success they had. They also announced that two of their apps are now being open sourced for anyone to use.
- Batch data processing with App Engine - Mike Aizatsky introduced Mapper, a new tool which allows App Engine developers which makes it simple to write code that is run over large datasets such as a Blobstore file or Datastore entities.
- Data migration in App Engine - Matthew Blain gave a complete introduction to the brand new Bulk Loader which shipped as part of App Engine’s 1.3.4 SDK. The session also provided a look into how to use the Bulk Loader with Java applications and ways to import complex data models from a number of different sources.
- What's hot in Java for App Engine - The same duo from last year’s introduction of the Java SDK, Don Schwarz and Toby Reyelts, were back again this year to give an update on the progress of the Java SDK. Performance optimizations, compatibility, and new APIs are all covered giving a peak under the hood for Java developers.
- Building high-throughput data pipelines with Google App Engine - Brett Slatkin reviewed the Task Queue and introduced a number of strategies used to improve the performance of applications doing very high volumes of task queue work. This session is based on lessons learned by Brett while building PubSubHubbub on App Engine.
- Testing techniques for Google App Engine - Max Ross argued the virtues of proper software testing and then went to detail on how to test your App Engine code properly and how to use App Engine to test all the rest of your code.
- Next gen queries - Alfred Fuller closed out the conference with a great overview of recent improvements to the Datastore query planner and the new types of queries that are possible, as well as a look at a few features on the horizon.
There’s plenty of great information in all the presentations, so for those of you that missed, we highly recommend you watch the videos and read the slides. For everyone else that made it to I/O this year, thank you for making this year’s I/O a complete success. It’s incredibly energizing for us to see all your hard work, thoughtful questions, and great ideas on App Engine. We’re already excited to see what you all surprise us with at next year’s I/O!
By Sean Lynch, App Engine Team
2013, By: Seo Master
seo Enabling Cloud Portability with Google App Engine for Business and VMware 2013
Seo Master present to you: Today we announced Google App Engine for Business, with a host of new features to help enterprises run their business applications on Google’s infrastructure (read our blog post to learn more). We’re also excited to announce our work with VMware to connect our developer tools, making it possible to create rich, multi-device web applications that can be hosted in a variety of Java-compatible hosting environments. Call it cloud portability for the enterprise -- productively build apps that you can deploy onto Google App Engine for Business, a VMware environment (your vSphere infrastructure, your choice of vCloud partners, or VMforce), or other infrastructure such as Amazon EC2.
As part of this announcement, we’re providing early access to these tools -- you can start using them right now by downloading the latest milestone version of VMware’s SpringSource Tool Suite (STS). If you prefer to wait for the general release, you can sign up to be notified.
Spring Roo
With Spring Roo, a next-generation rapid application development tool, Java developers can easily build full applications in minutes, using the Java Persistence API (JPA) to connect to new or existing databases. Roo outputs standard Java code, so it’s easy to refine the back end with the SpringSource Tool Suite and the front end with the Google Web Toolkit SDK, using Roo as much or as little as desired.
Google Web Toolkit SDK
New data presentation widgets in Google Web Toolkit speed development of traditional enterprise applications, increase performance and interactivity for enterprise users, and make it much easier to create engaging mobile apps with a fraction of the investment previously required.
SpringSource Tool Suite
Using the Eclipse-based SpringSource Tool Suite, developers can now choose to deploy their application in their current VMware vSphere environment, in VMware vCloud, directly to Google App Engine for Business, or elsewhere. We call this cloud portability.
Google Web Toolkit Speed Tracer
Speed Tracer now helps developers identify and fix performance problems not only in the client and network portions of their apps, but also on the server. By incorporating server-side time traces from both Spring Insight and Google App Engine AppStats, Speed Tracer provides a consolidated view of where sluggishness actually comes from -- be it client, network, or server -- so it’s much easier to see what to fix.
If you’re building business apps, we hope you’ll find these tools make it easier and more fun to get your job done. Maybe you’ll save time and money by developing and testing apps on App Engine, and then deploying to your VMware environment. Maybe you’ll run a second instance of your apps on App Engine for disaster recovery. Or, maybe you’ll take your existing on-premise apps and extend them to the web and to mobile devices in a fraction of the time it might have otherwise taken. The point is, whatever you decide, you can be confident that it’s possible, and that you’re not locked in.
We’re happy to be working with VMware to bring increased interoperability, portability and choice to enterprise developers. We invite you to download the latest milestone version of STS and try these tools for yourself.
2013, By: Seo Master
As part of this announcement, we’re providing early access to these tools -- you can start using them right now by downloading the latest milestone version of VMware’s SpringSource Tool Suite (STS). If you prefer to wait for the general release, you can sign up to be notified.
Spring Roo
With Spring Roo, a next-generation rapid application development tool, Java developers can easily build full applications in minutes, using the Java Persistence API (JPA) to connect to new or existing databases. Roo outputs standard Java code, so it’s easy to refine the back end with the SpringSource Tool Suite and the front end with the Google Web Toolkit SDK, using Roo as much or as little as desired.
Google Web Toolkit SDK
New data presentation widgets in Google Web Toolkit speed development of traditional enterprise applications, increase performance and interactivity for enterprise users, and make it much easier to create engaging mobile apps with a fraction of the investment previously required.
SpringSource Tool Suite
Using the Eclipse-based SpringSource Tool Suite, developers can now choose to deploy their application in their current VMware vSphere environment, in VMware vCloud, directly to Google App Engine for Business, or elsewhere. We call this cloud portability.
Google Web Toolkit Speed Tracer
Speed Tracer now helps developers identify and fix performance problems not only in the client and network portions of their apps, but also on the server. By incorporating server-side time traces from both Spring Insight and Google App Engine AppStats, Speed Tracer provides a consolidated view of where sluggishness actually comes from -- be it client, network, or server -- so it’s much easier to see what to fix.
If you’re building business apps, we hope you’ll find these tools make it easier and more fun to get your job done. Maybe you’ll save time and money by developing and testing apps on App Engine, and then deploying to your VMware environment. Maybe you’ll run a second instance of your apps on App Engine for disaster recovery. Or, maybe you’ll take your existing on-premise apps and extend them to the web and to mobile devices in a fraction of the time it might have otherwise taken. The point is, whatever you decide, you can be confident that it’s possible, and that you’re not locked in.
We’re happy to be working with VMware to bring increased interoperability, portability and choice to enterprise developers. We invite you to download the latest milestone version of STS and try these tools for yourself.
2013, By: Seo Master
seo Announcing Google App Engine for Business 2013
Seo Master present to you: We launched Google App Engine two years ago to enable application developers to rapidly build and scale their apps on Google’s infrastructure, without having to worry about maintaining their own servers. Today, we’re excited to bring this platform to IT departments, with the announcement of Google App Engine for Business. Google App Engine for Business lets organizations build and maintain their applications on the same scalable architecture that powers Google applications, with added management and support features tailored specifically for the enterprise.
Google App Engine for Business introduces a number of new features that our enterprise customers have been asking for, including:
Google App Engine for Business is currently in preview, opened to a limited number of enterprises. Learn more about how you can participate, and check our roadmap to follow features as they become available.
2013, By: Seo Master
Google App Engine for Business introduces a number of new features that our enterprise customers have been asking for, including:
- Centralized administration: A new, company-focused administration console lets you manage all the applications in your domain.
- Reliability and support: 99.9% uptime service level agreement, with premium developer support available.
- Secure by default: Only users from your Google Apps domain can access applications and your security policies are enforced on every app.
- Pricing that makes sense: Each application costs just $8 per user, per month up to a maximum of $1000 a month. Pay only for what you use.
- Enterprise features: Coming later this year, hosted SQL databases, SSL on your company’s domain for secure communications, and access to advanced Google services.
Google App Engine for Business is currently in preview, opened to a limited number of enterprises. Learn more about how you can participate, and check our roadmap to follow features as they become available.
2013, By: Seo Master
seo Android Meet App Engine, App Engine Meet Android 2013
Seo Master present to you: By Chris Ramsdale, Product Manager, GWT and GPE
Imagine this: you've spent the past few months hammering away at the latest mobile game sensation, Mystified Birds, and you are one level away from complete mastery. And then it happens. In a fit of excitement you throw your hands up, and along with them your Nexus S, which settles nicely at the bottom of the pool you happen to be relaxing next to. The phone is rendered useless. Luckily, your insurance policy covers the replacing the device and the Android Market handles replacing your apps. Unluckily though, all of your Mystified Birds data went the way of your device, leaving you to start from scratch.
Wouldn't it be great if your new device not only contained all of your apps, but all of your valuable data as well? We think so. With Google Plugin for Eclipse (GPE) v2.4 it's much easier to build native Android apps that can take data with them wherever they go. And there's no better place to host your backend service and store your data than Google's cloud service, App Engine.
With the latest release of GPE, we're bringing together these two great Google platforms, Android and App Engine, with a set of easy-to-use developer tools. Diving a bit deeper, here are some of the features offered in GPE 2.4:
Project Creation
With GPE 2.4, you now have the ability to create App Engine-connected Android projects. This new Eclipse project wizard generates fully functioning Android and GWT clients that are capable of talking to the same App Engine backend using the same RPC code and business logic.
Cloud to Device Messaging Support
Polling for backend changes on a mobile device is inefficient and will result in poor app performance and battery drain. As a solution for Android developers, the Android team built Cloud to Device Messaging (C2DM), a service for sending lightweight pings to notify apps when they have pending data. We heard back from developers that integrating with C2DM results in a lot of boilerplate (and sometimes fragile) code that they would rather not maintain. With the 2.4 release of GPE, when you create a new App Engine connected Android project, you'll get this code for free. All you have to do is hook up the app-specific code to customize the handling of the C2DM notification.
RPC Generation and Tooling
Writing and maintaining RPC code (code that allows your app to communicate with backend servers) is monotonous and error prone. Let's face it, you're a mobile developer and the last thing you want to be spending time on is writing (or debugging) this type of code. In GPE 2.4 we're introducing tooling that removes this task for you, and will generate all of the underlying RPC boilerplate code within a few clicks. You specify the model objects that will be used between client and server, and GPE generates the RPC service, DTOs, and client-side calling code. To make this even better, the generated code works across Android and GWT apps, so any future changes that you make will only need to be made once.
Want to get started? Download GPE 2.4 Beta here. Note that you'll need to install the Android Developer Tools (ADT) plugin as a prerequisite, which can be found here.
If you have any feedback, we'd love to hear it and the GPE Group is the right place to submit it. The App Engine and Android Developer Groups are also great sources of information.
Chris Ramsdale is Product Manager for GWT and GPE: cramsdale@google.com
Posted by Scott Knaster, Editor
2013, By: Seo Master
Imagine this: you've spent the past few months hammering away at the latest mobile game sensation, Mystified Birds, and you are one level away from complete mastery. And then it happens. In a fit of excitement you throw your hands up, and along with them your Nexus S, which settles nicely at the bottom of the pool you happen to be relaxing next to. The phone is rendered useless. Luckily, your insurance policy covers the replacing the device and the Android Market handles replacing your apps. Unluckily though, all of your Mystified Birds data went the way of your device, leaving you to start from scratch.
Wouldn't it be great if your new device not only contained all of your apps, but all of your valuable data as well? We think so. With Google Plugin for Eclipse (GPE) v2.4 it's much easier to build native Android apps that can take data with them wherever they go. And there's no better place to host your backend service and store your data than Google's cloud service, App Engine.
With the latest release of GPE, we're bringing together these two great Google platforms, Android and App Engine, with a set of easy-to-use developer tools. Diving a bit deeper, here are some of the features offered in GPE 2.4:
Project Creation
With GPE 2.4, you now have the ability to create App Engine-connected Android projects. This new Eclipse project wizard generates fully functioning Android and GWT clients that are capable of talking to the same App Engine backend using the same RPC code and business logic.
Cloud to Device Messaging Support
Polling for backend changes on a mobile device is inefficient and will result in poor app performance and battery drain. As a solution for Android developers, the Android team built Cloud to Device Messaging (C2DM), a service for sending lightweight pings to notify apps when they have pending data. We heard back from developers that integrating with C2DM results in a lot of boilerplate (and sometimes fragile) code that they would rather not maintain. With the 2.4 release of GPE, when you create a new App Engine connected Android project, you'll get this code for free. All you have to do is hook up the app-specific code to customize the handling of the C2DM notification.
RPC Generation and Tooling
Writing and maintaining RPC code (code that allows your app to communicate with backend servers) is monotonous and error prone. Let's face it, you're a mobile developer and the last thing you want to be spending time on is writing (or debugging) this type of code. In GPE 2.4 we're introducing tooling that removes this task for you, and will generate all of the underlying RPC boilerplate code within a few clicks. You specify the model objects that will be used between client and server, and GPE generates the RPC service, DTOs, and client-side calling code. To make this even better, the generated code works across Android and GWT apps, so any future changes that you make will only need to be made once.
Want to get started? Download GPE 2.4 Beta here. Note that you'll need to install the Android Developer Tools (ADT) plugin as a prerequisite, which can be found here.
If you have any feedback, we'd love to hear it and the GPE Group is the right place to submit it. The App Engine and Android Developer Groups are also great sources of information.
Chris Ramsdale is Product Manager for GWT and GPE: cramsdale@google.com
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo The Go programming language is coming to Google App Engine 2013
Seo Master present to you: By David Symonds, Nigel Tao, and Andrew Gerrand of the Go Team
The growing ranks of Go programmers will soon have another platform: Go will be the third language, after Python and Java, in which to write Google App Engine apps. This is an exciting new experimental feature of App Engine and a major milestone for Go.
Go is an open source language, initially designed at Google, that was released in November 2009 and has seen significant development since launch. It is a statically typed, compiled language with a dynamic and lightweight feel. It’s also an interesting new option for App Engine because Go apps will be compiled to native code, making Go a good choice for more CPU-intensive tasks. Plus the garbage collection and concurrency features of the language, combined with excellent libraries, make it a great fit for web apps.
As of today, the App Engine SDK for Go is available for download, and we will soon enable deployment of Go apps into the App Engine infrastructure. If you’re interested in starting early, sign up to be first through the door when we open it up to early testers. Once it proves solid, we’ll open it up to everyone, although it will remain an experimental App Engine feature for a while.
You don’t need an existing Go installation; the SDK is fully self-contained, so it’s very simple to get a local web app up and running. The SDK is a really easy way to start playing with Go.
More details can be found at the Go Programming Language blog.
Posted by Scott Knaster, Editor
2013, By: Seo Master
The growing ranks of Go programmers will soon have another platform: Go will be the third language, after Python and Java, in which to write Google App Engine apps. This is an exciting new experimental feature of App Engine and a major milestone for Go.
Go is an open source language, initially designed at Google, that was released in November 2009 and has seen significant development since launch. It is a statically typed, compiled language with a dynamic and lightweight feel. It’s also an interesting new option for App Engine because Go apps will be compiled to native code, making Go a good choice for more CPU-intensive tasks. Plus the garbage collection and concurrency features of the language, combined with excellent libraries, make it a great fit for web apps.
As of today, the App Engine SDK for Go is available for download, and we will soon enable deployment of Go apps into the App Engine infrastructure. If you’re interested in starting early, sign up to be first through the door when we open it up to early testers. Once it proves solid, we’ll open it up to everyone, although it will remain an experimental App Engine feature for a while.
You don’t need an existing Go installation; the SDK is fully self-contained, so it’s very simple to get a local web app up and running. The SDK is a really easy way to start playing with Go.
More details can be found at the Go Programming Language blog.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Google App Engine: a new version and a preview of future plans 2013
Seo Master present to you: 
By Greg D’Alesandre, Senior Product Manager, Google App Engine
Google App Engine, which provides the ability to develop and host applications on Google’s infrastructure, has grown tremendously since it launched in preview status in 2008. More than 100,000 developers use App Engine every month to deliver apps that dynamically scale with usage without the need to manage hardware or software. App Engine now hosts more than 200,000 active apps that serve over 1.5 billion site views daily.
Over the last three years, we’ve collected great feedback from our customers and now believe that the biggest thing we can do to help our customers is to graduate App Engine from preview status. When App Engine graduates from preview status, which we expect to do in the second half of this year, we’ll add additional enterprise-grade features that allow us to support many more business application scenarios. Graduation from preview status also indicates a longer term commitment by Google to the product and provides a deprecation policy whereby we will support prior versions of product APIs for a guaranteed amount of time, allowing applications written to prior API specifications to continue to function.
Today, we’re moving forward with our business focus with the release of App Engine 1.5.0 which includes Backends, improved Task Queues, a new experimental Go runtime, and more:
We’re announcing these features and pricing changes in advance so that our customers have time to review them. Adding business features will help App Engine meet a broader set of needs and the new, more transparent pricing model will help customers better align their App Engine investment with their business goals. Learn more about these changes on the App Engine blog.
Finally, we are really excited to graduate from Preview and we want to let everyone know how much we appreciate the support, commitment, and feedback we have received. We look forward to working with you for years to come.
Greg D'Alesandre is now the Senior Product Manager for App Engine after coming back from riding the Google Wave in Sydney. And he's obsessed with chocolate, no, seriously, obsessed.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Greg D’Alesandre, Senior Product Manager, Google App Engine
Google App Engine, which provides the ability to develop and host applications on Google’s infrastructure, has grown tremendously since it launched in preview status in 2008. More than 100,000 developers use App Engine every month to deliver apps that dynamically scale with usage without the need to manage hardware or software. App Engine now hosts more than 200,000 active apps that serve over 1.5 billion site views daily.
Over the last three years, we’ve collected great feedback from our customers and now believe that the biggest thing we can do to help our customers is to graduate App Engine from preview status. When App Engine graduates from preview status, which we expect to do in the second half of this year, we’ll add additional enterprise-grade features that allow us to support many more business application scenarios. Graduation from preview status also indicates a longer term commitment by Google to the product and provides a deprecation policy whereby we will support prior versions of product APIs for a guaranteed amount of time, allowing applications written to prior API specifications to continue to function.
Today, we’re moving forward with our business focus with the release of App Engine 1.5.0 which includes Backends, improved Task Queues, a new experimental Go runtime, and more:
- With Backends (for both Python and Java), App Engine can now support applications that require long running and high memory processes. This feature allows for new classes of applications such as report generation apps and custom search engines to be hosted on the platform.
- The improvements to Task Queues allow for applications to control how tasks are executed and easily share the work using the new REST-based APIs. This API access expands App Engine’s compatibility with other on-premise and cloud services, furthering our commitment to an open development platform.
- With 1.5.0 we are launching an experimental runtime for the Go Programming Language. Go is an open source, statically typed, compiled language with a dynamic and lightweight feel. It’s also an interesting new option for App Engine because Go apps will be compiled to native code, making Go a good choice for more CPU-intensive tasks. As of today, the App Engine SDK for Go is available for download, and we will soon enable deployment of Go apps into the App Engine infrastructure. If you’re interested in starting early, sign up to be first through the door when we open it up to early testers. If you’d like to learn more, read it about it on the Go Blog.
We’re announcing these features and pricing changes in advance so that our customers have time to review them. Adding business features will help App Engine meet a broader set of needs and the new, more transparent pricing model will help customers better align their App Engine investment with their business goals. Learn more about these changes on the App Engine blog.
Finally, we are really excited to graduate from Preview and we want to let everyone know how much we appreciate the support, commitment, and feedback we have received. We look forward to working with you for years to come.
Greg D'Alesandre is now the Senior Product Manager for App Engine after coming back from riding the Google Wave in Sydney. And he's obsessed with chocolate, no, seriously, obsessed.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Pricing plan announced for Google Cloud SQL 2013
Seo Master present to you: 
By Joe Faith, Product Manager
Google Cloud SQL provides a fully managed database service for Google App Engine applications. Hosted on Google's infrastructure and based on the familiar MySQL database, Google Cloud SQL automatically provisions and maintains your databases, allowing you to focus on your applications and services.
In March, we were delighted to welcome our 10,000th developer on Google Cloud SQL, joining businesses like Daffodil, who halved their development time by building on Google's platform.
Since the preview launch in October 2011, we’ve been busy working on improving the performance, adding features like scheduled backups, and multihoming to increase availability and improve performance. We are also now offering more powerful instances with up to 4GB of RAM. Today, we are announcing our pricing, with two options to choose from:
Google Cloud SQL is currently in limited preview. If you want to give us a try, start here: https://developers.google.com/cloud-sql/.
Joe Faith is a Product Manager on the Google Cloud Team. In a previous life he was a researcher in machine learning, bioinformatics, and information visualization, and was founder of charity fundraising site Fundraising Skills.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Joe Faith, Product Manager
Google Cloud SQL provides a fully managed database service for Google App Engine applications. Hosted on Google's infrastructure and based on the familiar MySQL database, Google Cloud SQL automatically provisions and maintains your databases, allowing you to focus on your applications and services.
In March, we were delighted to welcome our 10,000th developer on Google Cloud SQL, joining businesses like Daffodil, who halved their development time by building on Google's platform.
Since the preview launch in October 2011, we’ve been busy working on improving the performance, adding features like scheduled backups, and multihoming to increase availability and improve performance. We are also now offering more powerful instances with up to 4GB of RAM. Today, we are announcing our pricing, with two options to choose from:
- For developers who want to try out the service, or who have lightweight applications, we offer a flexible "per use" pricing scheme. For example, you can get started with a cloud hosted MySQL database for around a dollar per month. You pay for just what you use.
- For developers with more traffic, there are package plans that are more economical and help you predict your costs in advance.
Google Cloud SQL is currently in limited preview. If you want to give us a try, start here: https://developers.google.com/cloud-sql/.
Joe Faith is a Product Manager on the Google Cloud Team. In a previous life he was a researcher in machine learning, bioinformatics, and information visualization, and was founder of charity fundraising site Fundraising Skills.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Developing Enterprise-class apps on Google App Engine and the Google Apps Marketplace 2013
Seo Master present to you: 
By Ron Zalkind, CTO and Co-Founder, CloudLock
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
At CloudLock, we're all about cloud data protection. When we decided to build CloudLock for Google Apps, we had three main challenges to solve:
Why App Engine?
After researching all the choices available to us, we concluded that Google App Engine was the right choice for us.
1. Data stays within the Google infrastructure - Since CloudLock classifies document sharing permissions to help companies control who has access to what and what is accessible to whom, the location of this highly sensitive data is paramount. Using Google App Engine lets us scan, analyze and present information to our customers natively within the Google infrastructure without any of the data leaving to a third party.
Google's datastore had the attributes we were looking for in a persistent storage solution. It offers a high replication option for high reliability, and since it is implemented on top of BigTable and Google's distributed file system, it runs on the same core infrastructure that powers other Google services like Gmail and Google Apps.
CloudLock customer Brian Bolt from Boise State University put it best, saying "Our security team appreciates the fact that the CloudLock solution is developed and hosted on the Google App Engine platform; and since CloudLock is powered by Google’s App Engine, our data never leaves Google’s Cloud Infrastructure."
2. Scaling with App Engine is easy - While being able to handle the largest Google Apps customers was a top concern, being able to do so on an ongoing basis was another issue we had to solve. Using the Google App Engine Task Queue service, CloudLock is able to analyze massive amounts of data continually. App Engine makes it very easy to start as many background tasks as needed to deal with bursts of load.
The Google Apps Marketplace
The Google Apps Marketplace gives Google Apps customers access to hundreds of applications to extend the capabilities of the core productivity suite. Installing an app from the marketplace is seamless, with a wizard-like interface that makes apps immediately available in a few clicks. The installation securely white-lists the app and grants access to specific domain resources such as Google Docs.
Google’s App Engine Users service allows application developers to easily integrate their app with Google’s account management system (Google account or Google Apps accounts) and OpenID for Single Sign-On. Using the Users service and the marketplace installation we were able to deliver an app that is very easy to install into a domain and gain secure access into the domain's data.
By choosing Google App Engine and the Google Apps Marketplace, we were able to create an application that keeps our customers’ data secure within the Google infrastructure, meets the scaling challenges of the largest Google Apps users, and is immediately and easily available to users.
CloudLock for Google Apps is available directly from the Google Apps Marketplace and runs on Google App Engine.
Update 7:50 AM: This blog post was modified to correctly represent App Engine's certification state. As of May 2011, App Engine is pursuing SAS70-II certification to align it with the other products in the Google Apps suite.
Come see CloudLock in the Developer Sandbox at Google I/O on May 10-11.
Ron Zalkind is the CTO and a Co-Founder of CloudLock, runs the Boston Google App Engine User Group, and has been known to roll up his sleeves and write code while blasting Jay-Z in his headphones.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Ron Zalkind, CTO and Co-Founder, CloudLock
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
At CloudLock, we're all about cloud data protection. When we decided to build CloudLock for Google Apps, we had three main challenges to solve:
- Security of data - No matter which system you use for governance, compliance, and access controls, you want that data to be safe.
- Enterprise scalability - By nature, many of the companies facing data governance and regulatory compliance requirements are larger organizations. Because of that, we needed to build CloudLock with the largest Google Apps customers in mind from day one.
- Low administrative overhead - We wanted to be able to make the most effective use of our development resources. With App Engine, we spend time building apps rather than managing infrastructure.
Why App Engine?
After researching all the choices available to us, we concluded that Google App Engine was the right choice for us.
1. Data stays within the Google infrastructure - Since CloudLock classifies document sharing permissions to help companies control who has access to what and what is accessible to whom, the location of this highly sensitive data is paramount. Using Google App Engine lets us scan, analyze and present information to our customers natively within the Google infrastructure without any of the data leaving to a third party.
Google's datastore had the attributes we were looking for in a persistent storage solution. It offers a high replication option for high reliability, and since it is implemented on top of BigTable and Google's distributed file system, it runs on the same core infrastructure that powers other Google services like Gmail and Google Apps.
CloudLock customer Brian Bolt from Boise State University put it best, saying "Our security team appreciates the fact that the CloudLock solution is developed and hosted on the Google App Engine platform; and since CloudLock is powered by Google’s App Engine, our data never leaves Google’s Cloud Infrastructure."
2. Scaling with App Engine is easy - While being able to handle the largest Google Apps customers was a top concern, being able to do so on an ongoing basis was another issue we had to solve. Using the Google App Engine Task Queue service, CloudLock is able to analyze massive amounts of data continually. App Engine makes it very easy to start as many background tasks as needed to deal with bursts of load.
The Google Apps Marketplace
The Google Apps Marketplace gives Google Apps customers access to hundreds of applications to extend the capabilities of the core productivity suite. Installing an app from the marketplace is seamless, with a wizard-like interface that makes apps immediately available in a few clicks. The installation securely white-lists the app and grants access to specific domain resources such as Google Docs.
Google’s App Engine Users service allows application developers to easily integrate their app with Google’s account management system (Google account or Google Apps accounts) and OpenID for Single Sign-On. Using the Users service and the marketplace installation we were able to deliver an app that is very easy to install into a domain and gain secure access into the domain's data.
By choosing Google App Engine and the Google Apps Marketplace, we were able to create an application that keeps our customers’ data secure within the Google infrastructure, meets the scaling challenges of the largest Google Apps users, and is immediately and easily available to users.
CloudLock for Google Apps is available directly from the Google Apps Marketplace and runs on Google App Engine.
Update 7:50 AM: This blog post was modified to correctly represent App Engine's certification state. As of May 2011, App Engine is pursuing SAS70-II certification to align it with the other products in the Google Apps suite.
Come see CloudLock in the Developer Sandbox at Google I/O on May 10-11.
Ron Zalkind is the CTO and a Co-Founder of CloudLock, runs the Boston Google App Engine User Group, and has been known to roll up his sleeves and write code while blasting Jay-Z in his headphones.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Evite’s Use of Google App Engine 2013
Seo Master present to you: 
By Dan Mesh, Vice President of Engineering at Evite
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
Evite is one of web's oldest social planning services. Since the launch in 1998, Evite has delivered over a billion party invitations. Although it has served us well, after ten years of operation it became necessary to replace the aging platform, and position Evite for another decade of successful party planning.
The reengineering effort took well over a year. Our development team replaced Java with Python and saw a significant increase in developer productivity. However, dealing with a ten year-old Oracle database remained a challenge. To overcome scalability limitations and inflexibility of a large relational DBMS, we designed and implemented a proprietary data store. We conducted a series of A/B tests and gradually started migrating production traffic to the new system.
Our initial motivation to use Google App Engine was fast provisioning. We introduced App Engine as a temporary solution while we increased scale and optimized our proprietary data store. However, once we imported user profile data and put App Engine backend services in production, we never looked back.
Importing a large data set of user profiles from Oracle RAC into App Engine was challenging at first because we had to perform a bulk import and then keep the data synchronized between the two datastores. As we developed our data synchronization tools we gained better understanding of the API and performance characteristics of the App Engine datastore.
Once we synchronized profile data and enabled production traffic, App Engine really started to impress. We would watch our daily traffic grow and observe App Engine’s automatic scaling in action. Additional server instances would come online to meet increased demand and disappear as traffic lowered, without any sysadmin intervention. Despite our proficiency in the use of cloud computing resources and system automation, it was never this easy to provision new servers. As Grig, Evite’s devops guru, likes to say "It's not in production until it's monitored and graphed." App Engine’s dashboard automatically manages instances and graphs system usage data.
Following our positive experience with Evite profiles, we have continued to use App Engine for other services. Occasional frustrations with elevated error rates on the Master/Slave Datastore disappeared as we switched to the High Replication Datastore. At this point we see no technical obstacles to using App Engine more extensively. Architectural decisions and best practices implemented by the App Engine team are very well aligned with the choices we made in designing Evite’s new platform. This makes it easy to deploy additional services and data sets to App Engine.
The real obstacle to using App Engine exclusively for most Evite services is risk management. As reliable and cost-effective as App Engine has been for us, it is difficult to depend completely on a single vendor/service provider. To ensure availability of our application we use multiple cloud providers. Unfortunately, this strategy prevents us from using certain App Engine features and API's because we do not have adequate replacements for them in other deployment environments.
Evite’s new platform built on Python, NoSQL and App Engine has been a success. Our new web application has been well received by users, and our first iPhone app is receiving positive reviews. (Android version is in the works). We look forward to continued use of App Engine for data warehousing, rapid launches of new services and other projects.
Come see Evite in the Developer Sandbox at Google I/O on May 10-11.
Dan Mesh is a Vice President of Engineering at Evite. His extended responsibilities include espresso deliveries and release day food orders.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Dan Mesh, Vice President of Engineering at Evite
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
Evite is one of web's oldest social planning services. Since the launch in 1998, Evite has delivered over a billion party invitations. Although it has served us well, after ten years of operation it became necessary to replace the aging platform, and position Evite for another decade of successful party planning.
The reengineering effort took well over a year. Our development team replaced Java with Python and saw a significant increase in developer productivity. However, dealing with a ten year-old Oracle database remained a challenge. To overcome scalability limitations and inflexibility of a large relational DBMS, we designed and implemented a proprietary data store. We conducted a series of A/B tests and gradually started migrating production traffic to the new system.
Our initial motivation to use Google App Engine was fast provisioning. We introduced App Engine as a temporary solution while we increased scale and optimized our proprietary data store. However, once we imported user profile data and put App Engine backend services in production, we never looked back.
Importing a large data set of user profiles from Oracle RAC into App Engine was challenging at first because we had to perform a bulk import and then keep the data synchronized between the two datastores. As we developed our data synchronization tools we gained better understanding of the API and performance characteristics of the App Engine datastore.
Once we synchronized profile data and enabled production traffic, App Engine really started to impress. We would watch our daily traffic grow and observe App Engine’s automatic scaling in action. Additional server instances would come online to meet increased demand and disappear as traffic lowered, without any sysadmin intervention. Despite our proficiency in the use of cloud computing resources and system automation, it was never this easy to provision new servers. As Grig, Evite’s devops guru, likes to say "It's not in production until it's monitored and graphed." App Engine’s dashboard automatically manages instances and graphs system usage data.
Following our positive experience with Evite profiles, we have continued to use App Engine for other services. Occasional frustrations with elevated error rates on the Master/Slave Datastore disappeared as we switched to the High Replication Datastore. At this point we see no technical obstacles to using App Engine more extensively. Architectural decisions and best practices implemented by the App Engine team are very well aligned with the choices we made in designing Evite’s new platform. This makes it easy to deploy additional services and data sets to App Engine.
The real obstacle to using App Engine exclusively for most Evite services is risk management. As reliable and cost-effective as App Engine has been for us, it is difficult to depend completely on a single vendor/service provider. To ensure availability of our application we use multiple cloud providers. Unfortunately, this strategy prevents us from using certain App Engine features and API's because we do not have adequate replacements for them in other deployment environments.
Evite’s new platform built on Python, NoSQL and App Engine has been a success. Our new web application has been well received by users, and our first iPhone app is receiving positive reviews. (Android version is in the works). We look forward to continued use of App Engine for data warehousing, rapid launches of new services and other projects.
Come see Evite in the Developer Sandbox at Google I/O on May 10-11.
Dan Mesh is a Vice President of Engineering at Evite. His extended responsibilities include espresso deliveries and release day food orders.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo GQueues Mobile: a case for the HTML5 web app 2013
Seo Master present to you: 
By Cameron Henneke, Founder and Principal Engineer of GQueues
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
With the proliferation of mobile app stores, the intensity of the native app vs. web app debate in the mobile space continues to increase. While native apps offer tighter phone integration and more features, developers must maintain multiple apps and codebases. Web apps can serve a variety of devices from only one source, but they are limited by current browser technology.
In the Google IO session HTML5 versus Android: Apps or Web for Mobile Development?, Google Developer Advocates Reto Meier and Michael Mahemoff explore the advantages of both strategies. In this post I describe my own experience as an argument that an HTML5 app is a viable and sensible option for online products with limited resources.
Back in 2009 I started developing GQueues, a simple yet powerful task manager that helps people get things done. Built on Google App Engine, GQueues allows users to log in with Gmail and Google Apps accounts, and provides a full set of features including two-way Google Calendar syncing, shared lists, assignments, subtasks, repeating tasks, tagging, and reminders.
While I initially created an “optimized” version of the site for phone browsers, users have been clamoring for a native app ever since its launch two years ago. As the product’s sole developer, with every new feature I add, I consider quite carefully how it will affect maintenance and future development. Creating native apps for iOS, Android, Palm, and Blackberry would not only require a huge initial investment of time, but also dramatically slow down every new subsequent feature added, since each app would need updating. If GQueues were a large company with teams of developers this wouldn’t be as big an issue, although multiple apps still increase complexity and add overhead.
After engaging with users on our discussion forum, I learned that when they asked for a “native app,” what they really wanted was the ability to manage their tasks offline. My challenge was clear: if I could create a fast, intuitive web app with offline support, then I could satisfy users on a wide variety of phones while having only one mobile codebase to maintain as I enhanced the product.
Three months ago I set out to essentially rewrite the entire GQueues product as a mobile web app that utilized a Web SQL database for offline storage and an Application Cache for static resources. The journey was filled with many challenges, to say the least. With current mobile JavaScript libraries still growing to maturity, I found it necessary to create my own custom framework to run the app. Since GQueues data is stored in App Engine’s datastore, which is a schema-less, “noSQL” database, syncing to the mobile SQL database proved quite challenging as well. Essentially this required creating an object relational mapping layer in JavaScript to sit on top of the mobile database and interface with data on App Engine as well as input from the user. As a bonus challenge, current implementations of Web SQL only support asynchronous calls, so architecting the front-end JavaScript code required a high use of callbacks and careful planning around data availability.
During development, my test devices included a Nexus S, iPhone, and iPad. A day before launch I was delighted to find the mobile app worked great on Motorola Xoom and Samsung Galaxy Android tablets, as well as the Blackberry Playbook. This fortuitous discovery reaffirmed my decision to have one codebase serving many devices. Last week I launched the new GQueues Mobile, which so far has been met with very positive reactions from users – even the steadfast “native app” proponents! With a team of developers I surely could have created native apps for several devices, but with my existing constraints I know the HTML5 strategy was the right decision for GQueues. Check out our video and determine for yourself if GQueues Mobile stacks up to a native app.
Come see GQueues in the Developer Sandbox at Google I/O on May 10-11.
Cameron Henneke is an entrepreneur based in Chicago who loves Python and JavaScript equally. While not coding or answering support emails, he enjoys playing the piano, backpacking, and cheering on the Bulls.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Cameron Henneke, Founder and Principal Engineer of GQueues
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
With the proliferation of mobile app stores, the intensity of the native app vs. web app debate in the mobile space continues to increase. While native apps offer tighter phone integration and more features, developers must maintain multiple apps and codebases. Web apps can serve a variety of devices from only one source, but they are limited by current browser technology.
In the Google IO session HTML5 versus Android: Apps or Web for Mobile Development?, Google Developer Advocates Reto Meier and Michael Mahemoff explore the advantages of both strategies. In this post I describe my own experience as an argument that an HTML5 app is a viable and sensible option for online products with limited resources.
Back in 2009 I started developing GQueues, a simple yet powerful task manager that helps people get things done. Built on Google App Engine, GQueues allows users to log in with Gmail and Google Apps accounts, and provides a full set of features including two-way Google Calendar syncing, shared lists, assignments, subtasks, repeating tasks, tagging, and reminders.
While I initially created an “optimized” version of the site for phone browsers, users have been clamoring for a native app ever since its launch two years ago. As the product’s sole developer, with every new feature I add, I consider quite carefully how it will affect maintenance and future development. Creating native apps for iOS, Android, Palm, and Blackberry would not only require a huge initial investment of time, but also dramatically slow down every new subsequent feature added, since each app would need updating. If GQueues were a large company with teams of developers this wouldn’t be as big an issue, although multiple apps still increase complexity and add overhead.
After engaging with users on our discussion forum, I learned that when they asked for a “native app,” what they really wanted was the ability to manage their tasks offline. My challenge was clear: if I could create a fast, intuitive web app with offline support, then I could satisfy users on a wide variety of phones while having only one mobile codebase to maintain as I enhanced the product.
Three months ago I set out to essentially rewrite the entire GQueues product as a mobile web app that utilized a Web SQL database for offline storage and an Application Cache for static resources. The journey was filled with many challenges, to say the least. With current mobile JavaScript libraries still growing to maturity, I found it necessary to create my own custom framework to run the app. Since GQueues data is stored in App Engine’s datastore, which is a schema-less, “noSQL” database, syncing to the mobile SQL database proved quite challenging as well. Essentially this required creating an object relational mapping layer in JavaScript to sit on top of the mobile database and interface with data on App Engine as well as input from the user. As a bonus challenge, current implementations of Web SQL only support asynchronous calls, so architecting the front-end JavaScript code required a high use of callbacks and careful planning around data availability.
During development, my test devices included a Nexus S, iPhone, and iPad. A day before launch I was delighted to find the mobile app worked great on Motorola Xoom and Samsung Galaxy Android tablets, as well as the Blackberry Playbook. This fortuitous discovery reaffirmed my decision to have one codebase serving many devices. Last week I launched the new GQueues Mobile, which so far has been met with very positive reactions from users – even the steadfast “native app” proponents! With a team of developers I surely could have created native apps for several devices, but with my existing constraints I know the HTML5 strategy was the right decision for GQueues. Check out our video and determine for yourself if GQueues Mobile stacks up to a native app.
Come see GQueues in the Developer Sandbox at Google I/O on May 10-11.
Cameron Henneke is an entrepreneur based in Chicago who loves Python and JavaScript equally. While not coding or answering support emails, he enjoys playing the piano, backpacking, and cheering on the Bulls.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Guido van Rossum releases Mondrian-clone: Rietveld 2013
Seo Master present to you:
Guido van Rossum, Python creator and member of the App Engine team, gave a talk on Mondrian which is the tool he created to work with the code review process at Google.
The Mondrian tool itself was tied to internal technology, but he took the time to built an inspired version on App Engine. Part of the work was having it work with Subversion as the SCM. The name of the tool is Rietveld, and here is what Guido said on the Python mailing list to announce it:
Brady Forrest has a nice write-up of the announcement and Joe Heck pointed out that this is not the same as another open source solution called Review Board.
For more details on the tool check out Guido's article.2013, By: Seo Master
Guido van Rossum, Python creator and member of the App Engine team, gave a talk on Mondrian which is the tool he created to work with the code review process at Google.
The Mondrian tool itself was tied to internal technology, but he took the time to built an inspired version on App Engine. Part of the work was having it work with Subversion as the SCM. The name of the tool is Rietveld, and here is what Guido said on the Python mailing list to announce it:
I've always hoped that I could release Mondrian as open source, but it was not to be: due to its popularity inside Google, it became more and more tied to proprietary Google infrastructure like Bigtable, and it remained limited to Perforce, the commercial revision control system most used at Google.
What I'm announcing now is the next best thing: an code review tool for use with Subversion, inspired by Mondrian and (soon to be) released as open source. Some of the code is even directly derived from Mondrian. Most of the code is new though, written using Django and running on Google App Engine.
I'm inviting the Python developer community to try out the tool on the web for code reviews. I've added a few code reviews already, but I'm hoping that more developers will upload at least one patch for review and invite a reviewer to try it out.
Brady Forrest has a nice write-up of the announcement and Joe Heck pointed out that this is not the same as another open source solution called Review Board.
For more details on the tool check out Guido's article.2013, By: Seo Master
seo Elastic Path: commerce in the cloud 2013
Seo Master present to you: 
By Eddie Chan, Software Engineer at Elastic Path Software
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
Elastic Path develops a very flexible enterprise ecommerce platform. Many global brands rely on the Elastic Path platform to power their ecommerce solutions.
Many ecommerce sites are actually complex web applications. Catalog management, shopping cart functionality, promotion engine, order fulfillment, and backend integrations are just some of the challenges involved in running a full-fledged online store.
Since 2008, our Java-based platform has been the ecommerce backbone of a couple of online stores that are being migrated to run on App Engine. Like many complex web applications, these stores used to run in a multi-server environment (Apache Tomcat with a MySQL database) hosted in a colocation center.
As the diagram above shows, our goal is to have Elastic Path running entirely on the App Engine cloud. The storefronts have already been migrated, and the database and remaining parts of the Elastic Path platform will be fully on the cloud soon.
Why are we doing this? There are many benefits to being on App Engine:
Our migration’s high-level approach was to move everything except the persistence layer onto App Engine, and then resolve issues with the technical limitations such as the class whitelist and request length. We also had to modify some third-party libraries to work around App Engine’s restrictions on operations such as class loading, threads, and sockets.
We didn’t migrate the persistence layer because Elastic Path uses a relational database; converting our entire object graph to the Datastore is not feasible now. We are working closely with Google on alternatives. In the interim, we are still using a MySQL database and have kept our persistence layer running within a Tomcat application in the colo. We implemented a creative solution: the non-persistence layers of Elastic Path run on App Engine and communicate with the Tomcat-hosted persistence services via Spring Remoting. The back-and-forth remoting was expensive and impacted the performance of our application so we implemented some data caching. For this, we turned to App Engine’s Memcache, which improved performance by an order of magnitude (less than 2 seconds average response times vs. 2 minutes or more without Memcache).
Other App Engine technologies we use heavily include AppStats for performance tuning, URL Fetch for the Spring Remoting described above, and the fantastic Maven GAE plugin that we use for packaging and automated deployments. As we continue to push our platform up to the cloud, we hope to utilize more of App Engine’s cool features. If you’d like to learn more about Elastic Path, how we are migrating our Java platform to run on the cloud, and how you might be able to migrate your application to App Engine, drop by our booth in the App Engine section of the Developer Sandbox. See you there!
Come see Elastic Path Software in the Developer Sandbox at Google I/O on May 10-11.
Eddie Chan is an ecommerce developer at Elastic Path Software in beautiful Vancouver, Canada. He and his brilliant team work closely with Google and are currently focused on migrating existing online stores to App Engine.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Eddie Chan, Software Engineer at Elastic Path Software
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
Elastic Path develops a very flexible enterprise ecommerce platform. Many global brands rely on the Elastic Path platform to power their ecommerce solutions.
Many ecommerce sites are actually complex web applications. Catalog management, shopping cart functionality, promotion engine, order fulfillment, and backend integrations are just some of the challenges involved in running a full-fledged online store.
Since 2008, our Java-based platform has been the ecommerce backbone of a couple of online stores that are being migrated to run on App Engine. Like many complex web applications, these stores used to run in a multi-server environment (Apache Tomcat with a MySQL database) hosted in a colocation center.
As the diagram above shows, our goal is to have Elastic Path running entirely on the App Engine cloud. The storefronts have already been migrated, and the database and remaining parts of the Elastic Path platform will be fully on the cloud soon.
Why are we doing this? There are many benefits to being on App Engine:
- Increased security
- Easier deployments and operations
- Scalability
- Cost-effectiveness
- Built-in monitoring
Our migration’s high-level approach was to move everything except the persistence layer onto App Engine, and then resolve issues with the technical limitations such as the class whitelist and request length. We also had to modify some third-party libraries to work around App Engine’s restrictions on operations such as class loading, threads, and sockets.
We didn’t migrate the persistence layer because Elastic Path uses a relational database; converting our entire object graph to the Datastore is not feasible now. We are working closely with Google on alternatives. In the interim, we are still using a MySQL database and have kept our persistence layer running within a Tomcat application in the colo. We implemented a creative solution: the non-persistence layers of Elastic Path run on App Engine and communicate with the Tomcat-hosted persistence services via Spring Remoting. The back-and-forth remoting was expensive and impacted the performance of our application so we implemented some data caching. For this, we turned to App Engine’s Memcache, which improved performance by an order of magnitude (less than 2 seconds average response times vs. 2 minutes or more without Memcache).
Other App Engine technologies we use heavily include AppStats for performance tuning, URL Fetch for the Spring Remoting described above, and the fantastic Maven GAE plugin that we use for packaging and automated deployments. As we continue to push our platform up to the cloud, we hope to utilize more of App Engine’s cool features. If you’d like to learn more about Elastic Path, how we are migrating our Java platform to run on the cloud, and how you might be able to migrate your application to App Engine, drop by our booth in the App Engine section of the Developer Sandbox. See you there!
Come see Elastic Path Software in the Developer Sandbox at Google I/O on May 10-11.
Eddie Chan is an ecommerce developer at Elastic Path Software in beautiful Vancouver, Canada. He and his brilliant team work closely with Google and are currently focused on migrating existing online stores to App Engine.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Designing large applications for Google App Engine 2013
Seo Master present to you: 
By Amy Unruh, Developer, Author, Consultant
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
Mojo Helpdesk from Metadot is an RDBMS-based Rails application for ticket tracking and management that can handle millions of tickets. We are migrating this application to run on Google App Engine (GAE), Java, and Google Web Toolkit (GWT). We were motivated to make this move because of the application’s need for scalability in data management and request handling, the benefits from access to GAE’s services and administrative tools, and GWT’s support for easy development of a rich application front-end.
In this post, we focus on GAE and share some techniques that have been useful in the migration process.
Task failure management
Our application makes heavy use of the Task Queue service, and must detect and manage tasks that are being retried multiple times but aren’t succeeding. To do this, we extended
This allows permanent task failure to be reliably exposed as an application-level event, and handled appropriately. (Similar techniques could be used to extend the new official Deferred API).
Appengine-mapreduce
Mojo Helpdesk needs to run many types of batch jobs, and
Supporting transaction semantics
The Datastore supports transactions only on entities in the same entity group. Often, operations on multiple entities must be performed atomically, but grouping is infeasible due to the contention that would result. We make heavy use of transactional tasks to circumvent this restriction. (If a task is launched within a transaction, it will be run if and only if the transaction commits). A group of activities performed in this manner – the initiating method and its transactional tasks – can be viewed as a “transactional unit” with shared semantics.
We have made this concept explicit by creating a framework to support definition, invocation, and automatic logging of transactional units. (The
Entity Design
To support join-like functionality, we can exploit multi-valued Entity properties (list properties) and the query support they provide. For example, a
These patterns have helped us build an app whose components run efficiently and robustly, interacting in a loosely coupled manner.
Come see Mojo Helpdesk in the Developer Sandbox at Google I/O on May 10-11.
Amy (@amygdala) has recently co-authored (with Daniel Guermeur) a book on Google App Engine and GWT application development. She has worked at several startups, in academia, and in industrial R&D labs; consults and does technical training and course development in web technologies; and is a contributor to the @thinkupapp open source project.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Amy Unruh, Developer, Author, Consultant
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
Mojo Helpdesk from Metadot is an RDBMS-based Rails application for ticket tracking and management that can handle millions of tickets. We are migrating this application to run on Google App Engine (GAE), Java, and Google Web Toolkit (GWT). We were motivated to make this move because of the application’s need for scalability in data management and request handling, the benefits from access to GAE’s services and administrative tools, and GWT’s support for easy development of a rich application front-end.
In this post, we focus on GAE and share some techniques that have been useful in the migration process.
Task failure management
Our application makes heavy use of the Task Queue service, and must detect and manage tasks that are being retried multiple times but aren’t succeeding. To do this, we extended
Deferred, which allows easy task definition and deployment. We defined a new Task abstraction, which implements an extended Deferrable and requires that every Task implement an onFailure method. Our extension of Deferred then terminates a Task permanently if it exceeds a threshold on retries, and calls its onFailure method.This allows permanent task failure to be reliably exposed as an application-level event, and handled appropriately. (Similar techniques could be used to extend the new official Deferred API).
 |
| From the existing Mojo Helpdesk: a view of a user’s assigned tickets. |
Appengine-mapreduce
Mojo Helpdesk needs to run many types of batch jobs, and
appengine-mapreduce is of great utility. However, we often want to map over a filtered subset of Datastore entities, and our map implementations are JDO-based (to enforce consistent application semantics), so we don’t need low-level Entities prefetched.
So, we made two extensions to the mapper libraries. First, we support the specification of filters on the mapper’s Datastore sharding and fetch queries, so that a job need not iterate over all the entities of a Kind. Second, our mapper fetch does a keys-only Datastore query; only the keys are provided to the map method, then the full data objects are obtained via JDO. These changes let us run large JDO-based mapreduce jobs with much greater efficiency.Supporting transaction semantics
The Datastore supports transactions only on entities in the same entity group. Often, operations on multiple entities must be performed atomically, but grouping is infeasible due to the contention that would result. We make heavy use of transactional tasks to circumvent this restriction. (If a task is launched within a transaction, it will be run if and only if the transaction commits). A group of activities performed in this manner – the initiating method and its transactional tasks – can be viewed as a “transactional unit” with shared semantics.
We have made this concept explicit by creating a framework to support definition, invocation, and automatic logging of transactional units. (The
Task abstraction above is used to identify cases where a transactional task does not succeed). All Datastore-related application actions – both in RPC methods and "offline" activities like mapreduce – use this framework. This approach has helped to make our application robust, by enforcing application-wide consistency in transaction semantics, and in the process, standardizing the events and logging which feed the app’s workflow systems. |
| From the existing Mojo Helpdesk: a view of the unassigned tickets for a work group. |
Entity Design
To support join-like functionality, we can exploit multi-valued Entity properties (list properties) and the query support they provide. For example, a
Ticket includes a list of associated Tag IDs, and Tag objects include a list of Ticket IDs they’re used with. This lets us very efficiently fetch, for example, all Tickets tagged with a conjunction of keywords, or any Tags that a set of tickets has in common. (We have found the use of "index entities" to be effective in this context). We also store derived counts and categorizations in order to sidestep Datastore restrictions on query formulation.These patterns have helped us build an app whose components run efficiently and robustly, interacting in a loosely coupled manner.
Come see Mojo Helpdesk in the Developer Sandbox at Google I/O on May 10-11.
Amy (@amygdala) has recently co-authored (with Daniel Guermeur) a book on Google App Engine and GWT application development. She has worked at several startups, in academia, and in industrial R&D labs; consults and does technical training and course development in web technologies; and is a contributor to the @thinkupapp open source project.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Using Google BigQuery to learn from GitHub data 2013
Seo Master present to you: 
By Ilya Grigorik, Web Performance Engineer
Open-source developers all over the world contribute to millions of projects every day: writing and reviewing code, filing and discussing bug reports, updating documentation and project wikis, and so forth. The data generated from this activity can reveal interesting trends across many industries, including popularity of programming languages over time, defect rates, contribution metrics, and popularity of specific frameworks and libraries.
The challenge in extracting these trends is gathering the data. Each project has its own distributed workflow, code repositories, and conventions. Having hosted dozens of my own projects on GitHub, I've long wanted to analyze the developer activity from the 2.6M+ public projects hosted on GitHub. Hence, earlier this year GitHub Archive was born!
GitHub Archive is a project to record the public GitHub timeline, archive it, and make it easily accessible for further analysis. Each day it archives over 120,000 public activities, ranging from new commits and fork events to opening and closing tickets, each with detailed metadata.
Once I collected the data, I needed a tool to analyze it, and that is when I found Google BigQuery. Based on the research behind Dremel, a popular internal tool at Google for analyzing web-scale datasets, BigQuery allowed me to easily import the entire dataset and use a familiar SQL like syntax to comb through the gigabytes of data in seconds. Plus the tool will scale to terabyte datasets, so there is plenty of room to grow!
The best news is that thanks to collaboration from the GitHub and BigQuery teams, the GitHub dataset is now public and available for you to slice and dice in any way you like. No need to worry about data gathering or database schemas: BigQuery will do all the heavy lifting, and you can just compose your queries to be executed in realtime.
Here's a real-world example. What are the most popular programming languages on GitHub over the past month?
If you are curious for more, sign up for BigQuery and follow the instructions on githubarchive.org to access the GitHub dataset. You can use the free 100GB query quota to run your analysis and perhaps even win some of the prizes from the GitHub Data Challenge!
Ilya Grigorik is a Web Performance Engineer and Advocate at Google, an open-source evangelist, and an analytics geek. You can find him on GitHub under igrigorik, and blogging about web performance at igvita.com.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Ilya Grigorik, Web Performance Engineer
Open-source developers all over the world contribute to millions of projects every day: writing and reviewing code, filing and discussing bug reports, updating documentation and project wikis, and so forth. The data generated from this activity can reveal interesting trends across many industries, including popularity of programming languages over time, defect rates, contribution metrics, and popularity of specific frameworks and libraries.
The challenge in extracting these trends is gathering the data. Each project has its own distributed workflow, code repositories, and conventions. Having hosted dozens of my own projects on GitHub, I've long wanted to analyze the developer activity from the 2.6M+ public projects hosted on GitHub. Hence, earlier this year GitHub Archive was born!
GitHub Archive is a project to record the public GitHub timeline, archive it, and make it easily accessible for further analysis. Each day it archives over 120,000 public activities, ranging from new commits and fork events to opening and closing tickets, each with detailed metadata.
Once I collected the data, I needed a tool to analyze it, and that is when I found Google BigQuery. Based on the research behind Dremel, a popular internal tool at Google for analyzing web-scale datasets, BigQuery allowed me to easily import the entire dataset and use a familiar SQL like syntax to comb through the gigabytes of data in seconds. Plus the tool will scale to terabyte datasets, so there is plenty of room to grow!
The best news is that thanks to collaboration from the GitHub and BigQuery teams, the GitHub dataset is now public and available for you to slice and dice in any way you like. No need to worry about data gathering or database schemas: BigQuery will do all the heavy lifting, and you can just compose your queries to be executed in realtime.
Here's a real-world example. What are the most popular programming languages on GitHub over the past month?
If you are curious for more, sign up for BigQuery and follow the instructions on githubarchive.org to access the GitHub dataset. You can use the free 100GB query quota to run your analysis and perhaps even win some of the prizes from the GitHub Data Challenge!
Ilya Grigorik is a Web Performance Engineer and Advocate at Google, an open-source evangelist, and an analytics geek. You can find him on GitHub under igrigorik, and blogging about web performance at igvita.com.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Google BigQuery brings Big Data analytics to all businesses 2013
Seo Master present to you: 
By Ju-kay Kwek, Product Manager, BigQuery
BigQuery enables businesses and developers to gain real-time business insights from massive amounts of data without any upfront hardware or software investments. Imagine a big pharmaceutical company optimizing daily marketing spend using worldwide sales and advertisement data. Or think of a small online retailer that makes product recommendations based on user clicks. Today, we are making BigQuery publicly available, an important milestone in our effort to bring Big Data analytics to all businesses via the cloud.
Since announcing BigQuery in limited preview last November, many businesses and developers have started using it for real-time Big Data analytics in the cloud. Claritics, a social and mobile analytics company, built a web application for game developers to gain real-time insights into user behavior. Crystalloids, an Amsterdam-based analytics firm, built a cloud-based application to help a resort network analyze customer reservations, optimize marketing and maximize revenue. This just scratches the surface of use cases for BigQuery.
BigQuery is accessible via a simple UI or REST interface. It lets you take advantage of Google’s massive compute power, store as much data as needed and pay only for what you use. Your data is protected with multiple layers of security, replicated across multiple data centers and can be easily exported.
Developers and businesses can sign up for BigQuery online and query up to 100 GB of data per month for free. See our introductory pricing plan for storing and querying datasets of up to 2 TB. If you need more than that, contact a sales representative.
We hope you will be able to gain real-time business insights using BigQuery. Share your BigQuery use cases and feedback in our user forums or on our +Google Enterprise page.
Ju-kay Kwek is the Product Management Lead for Google's Cloud Big Data initiative. In this role, he focuses on creating services that enable businesses and developers to harness Google's unparalleled data processing infrastructure and algorithms to tackle Big Data needs.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Ju-kay Kwek, Product Manager, BigQuery
BigQuery enables businesses and developers to gain real-time business insights from massive amounts of data without any upfront hardware or software investments. Imagine a big pharmaceutical company optimizing daily marketing spend using worldwide sales and advertisement data. Or think of a small online retailer that makes product recommendations based on user clicks. Today, we are making BigQuery publicly available, an important milestone in our effort to bring Big Data analytics to all businesses via the cloud.
Since announcing BigQuery in limited preview last November, many businesses and developers have started using it for real-time Big Data analytics in the cloud. Claritics, a social and mobile analytics company, built a web application for game developers to gain real-time insights into user behavior. Crystalloids, an Amsterdam-based analytics firm, built a cloud-based application to help a resort network analyze customer reservations, optimize marketing and maximize revenue. This just scratches the surface of use cases for BigQuery.
BigQuery is accessible via a simple UI or REST interface. It lets you take advantage of Google’s massive compute power, store as much data as needed and pay only for what you use. Your data is protected with multiple layers of security, replicated across multiple data centers and can be easily exported.
Developers and businesses can sign up for BigQuery online and query up to 100 GB of data per month for free. See our introductory pricing plan for storing and querying datasets of up to 2 TB. If you need more than that, contact a sales representative.
We hope you will be able to gain real-time business insights using BigQuery. Share your BigQuery use cases and feedback in our user forums or on our +Google Enterprise page.
Ju-kay Kwek is the Product Management Lead for Google's Cloud Big Data initiative. In this role, he focuses on creating services that enable businesses and developers to harness Google's unparalleled data processing infrastructure and algorithms to tackle Big Data needs.
Posted by Scott Knaster, Editor
2013, By: Seo Master