MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

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:

• 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.
  

You can also find all videos for Enterprise I/O 2010 sessions in this YouTube playlist.

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 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):

• 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.

In addition to the linked session titles where you'll find the videos and slides, you can also find all videos in this YouTube playlist for App Engine I/O 2010 sessions.

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 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.

By Bruce Johnson, Google Developer team2013, By: Seo Master

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:

• 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.

With these new features, we’re making it easier for businesses to take advantage of the core benefits of Google App Engine: easy development using languages you already know (Java and Python); simple administration, with no need to worry about hardware, patches or backups; and effortless scalability, automatically getting the capacity you need when you need it.

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.

By Sean Lynch, Google App Engine team2013, By: Seo Master

Seo Master present to you: By Andrew Jessup, Product Manager

Cross-posted from the Google Cloud Platform Blog

At Google I/O, we announced PHP as the latest supported runtime for Google App Engine in Limited Preview. PHP is one of the world's most popular programming languages, used by developers to power everything from simple web forms to complex enterprise applications.

Now PHP developers can take advantage of the scale, reliability and security features of App Engine. In addition, PHP runs well with other parts of Google Cloud Platform. Let's look at how this works.

Connecting to Google Cloud SQL from App Engine for PHP

Many PHP developers start with MySQL when choosing a database to store critical information, and a wide variety of products and frameworks such as WordPress make extensive use of MySQL’s rich feature set. Google Cloud SQL provides a reliable, managed database service that is MySQL 5.5 compatible and works well with App Engine.

To set up a Cloud SQL database, sign into Google Cloud Console - create a new project, choose Cloud SQL and create a new instance.



After you create the instance, it's automatically associated with your App Engine app.


You will notice Cloud SQL instances don’t need an IP address. Instead they can be accessed via a compound identifier made up of their project name and instance name, such as hello-php-gae:my-cloudsql-instance.

From within PHP, you can access Cloud SQL directly using the standard PHP MySQL libraries - mysql, mysqli or PDO_MySQL. Just specify your Cloud SQL database with its identifier, such as:

<?php

$db = new PDO(
  'mysql:unix_socket=/cloudsql/hello-php-gae:my-cloudsql-instance;dbname=demo_db;charset=utf8',
  'demo_user',
  'demo_password'
);

foreach($db->query('SELECT * FROM users') as $row) {
  echo $row['username'].' '.$row['first_name']; //etc...
}

Methods such as query() work just as you’d expect with any MySQL database. This example uses the popular PDO library, although other libraries such as mysql and mysqli work just as well.

Storing files with PHP and Google Cloud Storage

Reading and writing files is a common task in many PHP projects, whether you are reading stored application state, or generating formatted output (e.g., writing PDF files). The challenge is to find a storage system that is as scalable and secure as Google App Engine itself. Fortunately, we have exactly this in Google Cloud Storage (GCS).

The first step in setting up Google Cloud Storage is to create a bucket:


With the PHP runtime, we’ve implemented native support for GCS. In particular, we’ve made it possible for PHP’s native filesystem functions to read and write to a GCS bucket.

This code writes all prime numbers less than 2000 into a file on GCS:

<?php

$handle = fopen('gs://hello-php-gae-files/prime_numbers.txt','w');

fwrite($handle, "2");
for($i = 3; $i <= 2000; $i = $i + 2) {
  $j = 2;
  while($i % $j != 0) {
    if($j > sqrt($i)) {
      fwrite($handle, ", ".$i);
      break;
    }
    $j++;
  }
}

fclose($handle);

The same fopen() and fwrite() commands are used just as if you were writing to a local file. The difference is we’ve specified a Google Cloud Storage URL instead of a local filepath.

And this code reads the same file back into memory and pulls out the 100th prime number, using file_get_contents():

<?php

$primes = explode(",",
  file_get_contents('gs://hello-php-gae-files/prime_numbers.txt')
);

if(isset($primes[100]))
  echo "The 100th prime number is ".$primes[100];

And more features supported in PHP

Many of our most popular App Engine APIs are now supported in PHP, including our zero-configuration Memcache, Task Queues for asynchronous processing, Users API, Mail API and more. The standard features you’d expect from App Engine, including SSL support, Page Speed Service, versioning and traffic splitting are all available as well.

Open today in Limited Preview

Today we’re making App Engine for PHP available in Limited Preview. Read more about the runtime in our online documentation, download an early developer SDK, and sign up to deploy applications at https://cloud.google.com/appengine/php.


Andrew Jessup is a Product Manager at Google, working on languages and runtimes for Google App Engine.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Urs Hölzle, Senior Vice President, Technical Infrastructure, and Google Fellow

Cross-posted from the Google Cloud Platform Blog

Watch the video of the Cloud track kickoff.

Over the last fourteen years we have been developing some of the best infrastructure in the world to power Google’s global-scale services. With Google Cloud Platform, our goal is to open that infrastructure and make it available to any business or developer anywhere. Today, we are introducing improvements to the platform and making Google Compute Engine available for anyone to use.

Google Compute Engine - now available for everyone

Google Compute Engine provides a fast, consistently high-performance environment for running virtual machines. Later today, you’ll be able to go online to cloud.google.com and start using Compute Engine.

In addition, we’re introducing new Compute Engine features:

• Sub-hour billing charges for instances in one-minute increments with a ten-minute minimum, so you don’t pay for compute minutes that you don’t use
• Shared-core instances provide smaller instance shapes for low-intensity workloads
• Advanced Routing features help you create gateways and VPN servers, and enable you to build applications that span your local network and Google’s cloud
• Large persistent disks support up to 10 terabytes per volume, which translates to 10X the industry standard

We’ve also completed ISO 27001:2005 international security certification for Compute Engine, Google App Engine, and Google Cloud Storage.

Google App Engine adds the PHP runtime

App Engine 1.8.0 is now available and includes a Limited Preview of the PHP runtime - your top requested feature. We’re bringing one of the most popular web programming languages to App Engine so that you can run open source apps like WordPress. It also offers deep integration with other parts of Cloud Platform including Google Cloud SQL and Cloud Storage.

We’ve also heard that we need to make building modularized applications on App Engine easier. We are introducing the ability to partition apps into components with separate scaling, deployments, versioning and performance settings.

Introducing Google Cloud Datastore

Google Cloud Datastore is a fully managed and schemaless solution for storing non-relational data. Based on the popular App Engine High Replication Datastore, Cloud Datastore is a standalone service that features automatic scalability and high availability while still providing powerful capabilities such as ACID transactions, SQL-like queries, indexes and more.

Over the last year we have continued our focus on feature enhancement and developer experience across App Engine, Compute Engine, Google BigQuery, Cloud Storage and Cloud SQL. We also introduced Google Cloud Endpoints and Google Cloud Console.

With these improvements, we have seen increased usage with over 3 million applications and over 300,000 unique developers using Cloud Platform in a given month. Our developers inspire us everyday, and we can’t wait to see what you build next.


Urs Hölzle is Senior Vice President of Technical Infrastructure and Google Fellow. As one of Google's first ten employees and its first VP of Engineering, he has shaped much of Google's development processes and infrastructure.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Scott Knaster, Google Developers Blog Editor

Google App Engine has a well-deserved reputation for regularly adding cool new features and other improvements. This week the team launched full-text search, which has been a hotly desired feature since the earliest days of App Engine. The new App Engine Search API enables you to search documents using lots of options, including searching specific fields and creating results snippets. At Google, it’s always fun to build new frontiers in search.

The App Engine Search API is a powerful tool indeed, but it probably couldn't defend you against an aggressive chimp that likes to gather and throw stones. The chimp in question, Santino, has apparently been gathering stones for years and then throwing them at intruders. Scientists have debated whether Santino is actually planning for upcoming tantrums when collecting stones. After years of close observation, researchers still disagree on whether Santino is a premeditated stone-thrower. But there is plenty of fascinating evidence, such as Santino stashing his stones beneath piles of hay where nobody will see them. Cat out of the bag, Santino?

Finally, we direct you to this remixed video of a different, stone-free interspecies confrontation. It's weird and funny, and it has special effects – what more could you want? It's a perfect way to spend a minute and ten seconds of your Friday or weekend.


Each week we publish Fridaygram, a post with cool Google and non-Google stuff you might have missed during the week. Fridaygram items aren't necessarily related to developer topics; they’re just interesting to us nerds. As for moving from App Engine Search to Santino the plotting chimp, we’re just trying to maintain our practice of tortured transitions.

2013, By: Seo Master

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

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

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:

• 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.

In addition, when we take App Engine out of preview in the second half of this year, we will provide a 99.95% uptime service level agreement, operational and developer support, offline billing, and a new Terms of Service agreement geared towards businesses. We will also introduce a new pricing structure for App Engine based on more transparent usage-based pricing.

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 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:

1. Security of data - No matter which system you use for governance, compliance, and access controls, you want that data to be safe.
2. 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.
3. 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 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

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

Seo Master present to you: By Dion Almaer, Google Developer Programs

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 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:

• Increased security
• Easier deployments and operations
• Scalability
• Cost-effectiveness
• Built-in monitoring

We can only undergo this migration because App Engine supports enterprise-grade Java applications, and because Elastic Path is very flexible.

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 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 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).


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.


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 Master present to you: By Sriram Saroop, Product Manager

We are pleased to announce the latest release of Google Plugin for Eclipse (GPE 2.6) with improved tooling for Cloud SQL and Google APIs. GPE 2.6 introduces the following features:

• Tooling for using Java Persistence API (JPA) to access Cloud SQL
• Importing the latest Google APIs into your GPE project

Tooling for using Java Persistence API (JPA) to access Cloud SQL

Object-Relational Mapping (ORM) frameworks are very popular in the Java community for accessing relational databases. The Eclipse Web Tools Platform offers a robust set of tools to configure and use JPA with an implementation of your choice. With the new Google Plugin for Eclipse (GPE) 2.6, you can now take advantage of these tools with Cloud SQL and Google App Engine. In any GPE project, JPA can now be enabled and configured as a project facet. The screenshot below shows the JPA facet configuration for a GPE project.



Importing the latest Google APIs into your GPE project

With GPE 2.6, you now have access to all the latest Google APIs at the click of a button within Eclipse. You can now download the latest Google APIs Java client library with the required dependencies to access Google APIs right within your App Engine project using GPE. Update notifications for API version changes will appear in your App Engine project, so you can easily keep your client libraries updated all the time. The screenshot below shows the GPE UI for adding a Google API to a GPE project.



The next time we update the App Engine Engine SDK, you will be happy to see an update notification within Eclipse prompting you to update to the latest SDK.

Please go ahead and install GPE 2.6 by following the instructions here. You can start using the ORM tooling for Cloud SQL and the latest Google APIs for your App Engine projects. We always love to hear your feedback and the GPE group is a great place to share your thoughts.


Sriram Saroop is the Product Manager for the Google Plugin for Eclipse and the Google Admin APIs. He has been a software engineer in his previous life and he is now working toward creating an awesome developer experience for Google products.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you: By Dion Almaer, Google Developer Programs



We had the pleasure to talk to some of the Google App Engine team to discuss the recent launch that Dick uses the tagline as "Your apps, our servers". We get to chat with tech lead on the project Kevin Gibbs, product manager Pete Koomen, and Guido van Rossum. I don't think we need to introduce Guido!

The podcast starts out answering why Google App Engine was created, and why Python was chosen as the first language. We then hear about the work that goes into making a language hardened for the platform itself.

Of all of the APIs that we expose in the App Engine back-end, we feel that the Database API is probably the most foreign for the majority of developers. Many are used to the relational model for datastores, and our datastore is different. Kevin talks about these differences, and the ramifications that come with a schema-less store. We then delve into the practicalities of having libraries such as SQL Alchemy support GQL which is a functional subset of SQL.

What about lock-in? This was one of the big questions that came out of the community when we launched App Engine. You can see how open the team is to other solutions, and how they like seeing work such as AppDrop that shows how you can do this. The choice to make the SDK itself fully open source says a lot.

Guido discussed how the Python runtime is indeed the full language, but how some libraries are not there. He talks about the reasons behind the choices, which are mainly related to security. As time goes on more libraries that developers really need will make it into the system, often with equivalent implementations. Although a traditional file system doesn't make sense in the cloud, we could very well see a virtual file system implemented.

We go on to discuss a lot more, including:

• What restrictions are there for serving your applications?
• What Web frameworks are available?
• Can you develop Web services as well as Web applications? How about gadget and widget?
• What kind of traffic can be expect with the free accounts?
• Can I run these applications on my domain, and integrate with Google Apps?

If you want to see more of the team and play with App Engine, come by a hackathon when it get to your neck of the woods, or hear more at Google I/O.

You can download the episode directly, or subscribe to the show (click here for iTunes one-click subscribe).2013, By: Seo Master

Seo Master present to you:

Mike

Fred

By Mike Johnston and Fred Cheng, co-founders, Simperium

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.


We originally created Simplenote both as a learning exercise and to address what we thought were shortcomings in the original Notes app for the iPhone (Marker Felt font, no ability to search, etc.) The very first version of Simplenote didn't even have syncing!

We've certainly come a long way since then. The Simplenote backend now synchronizes data across devices, the web, and third-party apps while also handling in-app purchases, sharing, and basic metrics. About a year ago, we were accepted to the Y Combinator startup accelerator with something like 20,000 users. Today, with hundreds of thousands of users, we're currently serving 15 million requests daily and providing access to over 500 gigabytes (!) worth of text notes.


Google App Engine is at the heart of it. We made a decision early on to use App Engine so we wouldn't have to worry about scaling, or deploying more servers, or systems administration of any kind. Being able to instantly deploy new versions of code has allowed us to iterate quickly based on feedback we get from our users, and easily test new features in our web app, like the newly added Markdown support.

We consider our syncing capabilities to be core features of Simplenote. They are, in and of themselves, largely responsible for attracting and retaining many of our users. Our goal is to give other developers access to great syncing, too. The next version of our backend is named after our company, Simperium. As a general-purpose, realtime syncing platform intended for third-party use, Simperium's architecture is much more expansive than the Simplenote backend. Yet App Engine still plays a key role. It powers the Simplenote API that is used by dozens of great third-party apps like Notational Velocity. And it continues to power auxiliary systems, like processing payments with Stripe, while bridging effectively with externally hosted systems, like our solution for storing notes as files in the wonderful Dropbox.

We suspected we might outgrow App Engine, but we haven't. Instead, our use of it has evolved along with our needs. Code we wrote for App Engine a year ago continues to hum along today, providing important functionality even as new systems spring up around it.

In fact, we still come up with entirely new ways to use App Engine as well. Just last week we launched an internal system that uses APIs from Twitter, Amazon Web Services, Assistly, and HipChat to pump important business data into our private chat rooms. This was a breeze to write and deploy using App Engine. Such is the mark of a versatile and trustworthy tool: it's the first thing you reach for in your tool belt.


Come see Simperium in the Developer Sandbox at Google I/O on May 10-11.

Mike Johnston was a senior designer and programmer at Irrational Games where he worked on numerous games and prototypes for PC and Xbox 360. Before that he built security software at Entrust.

Fred Cheng hails from Cantaloupe Systems, a venture-backed startup, where he built their infrastructure for wirelessly tracking tens of thousands of vending machines.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you: By Chukwuemeka Afigbo, Program Manager, Sub-Saharan Africa

Cross-posted from the Google Africa Blog

Creating applications and services that use Google platforms to make the internet more relevant to Africans is a big part of Google’s vision in Africa. This is why we are always excited whenever we come across individuals or companies whose efforts are in line with this vision. Here are a few of the interesting applications we have seen in recent months.

Battabox, co founded by Christian Purefoy and Yemisi Ilo, is an online social television platform developed in Nigeria that aims to provide everything Nigerian from music, film, street-life to news, comedy and cooking using the YouTube platform. Crowdsourcing videos is an important part of the Battabox strategy and they were able to achieve this using YouTube Direct running on Google App Engine integrated into their website. They also provided an Android App that enables users to upload videos directly from their Android phones.




Chukwuemeka Afigbo is a Program Manager in the Sub-Saharan Africa Outreach Team. He is an avid football (soccer) fan.

Posted by Scott Knaster, Editor

2013, By: Seo Master