(Cross-posted with the Google Enterprise blog)



Editor’s Note: Today’s guest post is from Ben Kamens, Lead Developer at Khan Academy, a not-for-profit that provides a free education available for anyone. ...
(Cross-posted with the Google Enterprise blog)



Editor’s Note: Today’s guest post is from Ben Kamens, Lead Developer at Khan Academy, a not-for-profit that provides a free education available for anyone.



Khan Academy has an audacious mission: to provide a free world class education to anyone anywhere. With less than fifty full-time employees at the company, our small team has to take special care to work on whatever’s most critical. So we’re building a culture that relentlessly focuses on shipping code that improves students’ lives. Our team of developers relies on three simple principles that guide all the work we do:


  1. Shipping beats perfection.

  2. Be open. Share your work.

  3. Anybody can fix anything.


Google Cloud Platform provides a flexible and reliable environment to put these principles into practice. With Google App Engine in particular, we get a big, enormous, whopper of a benefit — consistent Datastore performance no matter how big the product gets. Even if we have a query that returns 10 items from a set of 10,000, we can relax. We know that as our company grows over time, we’ll get the exact same speed when pulling 10 items from a set of 10,000,000,000.



Lots of people ask, “How will you know if Khan Academy is really successful?” My answer is always the same: we of course care about data, analytics, and metrics that demonstrate provable, real learning. But in the back of my mind I’m most persuaded by the personal stories that people send us literally every day. Those stories of real lives being changed for the better are the reason why we believe a free educational resource like Khan Academy simply must exist.







-Contributed by Ben Kamens, Lead Developer, Khan Academy


Labels: , ,

This post has been updated to more accurately reflect details of the encryption process.



We know that security is important to you and your customers. Our goal is to make securing your data as painless as possible. To help ...
This post has been updated to more accurately reflect details of the encryption process.



We know that security is important to you and your customers. Our goal is to make securing your data as painless as possible. To help, Google Cloud Storage now automatically encrypts all data before it is written to disk, at no additional charge. There is no setup or configuration required, no need to modify the way you access the service and no visible performance impact. The data is automatically and transparently decrypted when read by an authorized user.



If you require encryption for your data, this functionality frees you from the hassle and risk of managing your own encryption and decryption keys. We manage the cryptographic keys on your behalf using the same hardened key management systems that Google uses for our own encrypted data, including strict key access controls and auditing. Each Cloud Storage object’s data and metadata is encrypted under the 128-bit Advanced Encryption Standard (AES-128), and each encryption key is itself encrypted with a regularly rotated set of master keys. Of course, if you prefer to manage your own keys then you can still encrypt data yourself prior to writing it to Cloud Storage.



Server-side encryption is already active for all new data written to Cloud Storage, whether for creating new objects or overwriting existing objects. Older objects will be migrated and encrypted in the coming months.



This feature adds to the default encryption functionality already provided by Persistent Disks and Scratch Disks that come with Google Compute Engine. Together, this means that all data written to unstructured storage on the Google Cloud Platform is now encrypted automatically, with no additional effort required by developers. We’re happy to be taking this step in our commitment to evolve the security capabilities of our platform.



- Posted by Dave Barth, Product Manager
Labels: ,

Today’s updates to Google Cloud Platform bring lots of new enhancements complementing features we first shared at I/O. Check out the latest additions:

Today’s updates to Google Cloud Platform bring lots of new enhancements complementing features we first shared at I/O. Check out the latest additions:




Load balancing now available on Google Compute Engine

We’ve now added layer 3 load balancing to Compute Engine, which delivers Google-scale throughput and fault tolerance to manage Internet applications. Load balancing is critical in any highly scalable system, allowing you to automatically and intelligently route traffic across a collection of servers.



With the load balancing service, you can:


  • Load-balance ingress network TCP/UDP traffic over a specific set of Compute Engine virtual machines (VMs) within the same region

  • Ensure that only healthy VMs are used to serve Internet requests through the use of HTTP-based health checks

  • Easily handle spikes in load without pre-warming

  • Configure the load balancer via command line interface (CLI) and a programmatic RESTful API




This initial release provides Layer 3 support and we’ll continue to expand its capabilities on a regular basis. We’re pleased to offer the load balancing feature at no cost through the end of 2013, after which we’ll charge the rates outlined on our pricing page.



Improved developer experience for Google Cloud Datastore

Cloud development tools should enhance developer productivity, and that’s what we focused on with the latest update to Cloud Datastore.



Google Query Language (GQL) Support

Being able to search for data lies at the heart of all data-driven applications, and we’ve made that easier by adding GQL support — a SQL-like language for retrieving entities or keys from Cloud Datastore.



Metadata queries

You can now access Metadata Queries that allow you to retrieve statistics on their underlying data. This is useful when building your internal administration consoles, performing custom analysis or simply debugging an application.



Local SDK improvements

Part of providing great developer experiences is allowing developers to make changes in a fast, efficient and cost-effective way. That’s why we’ve made numerous enhancements to the command line tool.

Separately, we’ve also included support for those of you who use Microsoft Windows.



Getting started with Ruby

If there is one thing that developers are passionate about (us included) it’s languages. The initial release of Cloud Datastore included code snippets and samples for getting up and running with Java, Python and Node. With the latest release, we’ve included the same Cloud Datastore support for Ruby developers — allowing you to easily spin up Ruby applications that rely on a managed NoSQL datastore.



Updates to the PHP runtime in Google App Engine 1.8.3

We’ve been listening to feedback from early developers using the PHP runtime, so our latest App Engine release is dedicated to PHP. But there are still a few new goodies for those of you not using PHP, which you can find in the release notes.



Our integration with Google Cloud Storage for reading and writing files has proven to be popular, so we expanded this in 1.8.3. Our latest update includes:


  • improved support for working with directories in Google Cloud Storage — allowing you to call functions such as opendir() or writedir() directly on Cloud Storage buckets

  • support for functions related to stat()-ing files, such as is_readable() and is_file()

  • the ability to write metadata to Cloud Storage files

  • substantial performance improvements through memcache-backed optimistic read caching — this improves the performance of applications that need to read frequently from the same Cloud Storage file

  • numerous bug fixes




We’ve also improved support for task queues, including the ability to set headers on push tasks and to add tasks to queues efficiently in bulk using the new PushTask:addTasks() method.



We hope you enjoy the new Cloud Platform features!



-Posted by Greg DeMichillie, Director of Product Management

Today’s post comes from Keith Casey, Sr. Developer Evangelist at Twilio. In this post, Keith describes how to use Twilio with Google App Engine on the PHP runtime. You can follow Keith on Twitter at @caseysoftware or on Google+. ...
Today’s post comes from Keith Casey, Sr. Developer Evangelist at Twilio. In this post, Keith describes how to use Twilio with Google App Engine on the PHP runtime. You can follow Keith on Twitter at @caseysoftware or on Google+.



I’ve wanted to explore Google App Engine for years. Between its SLA, automatic scaling, and queuing system, it has always been compelling. Unfortunately, since my Python skills are somewhere between “Hello World” and “OMG What did I just do!?” I decided to save myself the embarrassment. When Google announced PHP support for App Engine, I was both ecstatic and intrigued about what might be possible. To get something running in just a few minutes, I decided to use our Twilio PHP helper.



When experimenting with a new Platform as a Service, there are nuances of which you should be aware like dealing with a virtualized file system and needing a separate service for email. However, the remaining nuances are usually pretty minimal and required only the “tweaking of my module” rather than a heavy “rebuilding of my app”.



Knowing that up front, let’s dig in.



Set up the PHP on App Engine environment



First, check out and follow Google’s Getting started with PHP on Google App Engine to set up your local environment. Their instructions will cover setting up the SDK, connecting to your account, and some details on debugging. It should set up your environment under http://localhost:8080/ which serves as the root of your application.



Upgrade your Twilio Helper library



Next, with respect to Twilio’s PHP Helper library, we’ve taken care of the nuances for you, the most important one of which involved falling back to PHP’s Streams when cUrl isn’t available. In your case, simply upgrade the library to v3.11+ or install it for the first time. You can use the library to send text messages and make phone calls exactly as you would in any other PHP environment:



<?php
// Include the Twilio PHP library
require "Services/Twilio.php";
 
// Set your AccountSid and AuthToken from www.twilio.com/user/account
$AccountSid = "ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";
$AuthToken = "YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY";
 
// Instantiate a new Twilio Rest Client
$client = new Services_Twilio($AccountSid, $AuthToken);
 
// Make an array of people we know, to send them a message:
$people = array(
    "+14158675309" => "Curious George",
    "+14158675310" => "Boots",
    "+14158675311" => "Virgil",
);
 
// Loop over all our friends:
foreach ($people as $number => $name) {
 
    $sms = $client->account->sms_messages->create(
        "YYY-YYY-YYYY",     // Change the 'From' number to a Twilio number you've purchased
        $number,            // the number we are sending to - Any phone number
        "Hey $name, Monkey Party at 6PM. Bring Bananas!"  // the sms body
    );
 
    echo "Sent message to $name";        // Display a confirmation message
}


If you’re interested in the the specific changes for our library, you can explore the relevant pull requests here and here. I also have an article called “Preparing your PHP for App Engine” in next month’s php|architect magazine.



URL Routing in PHP



Within App Engine, the entire routing system is powered by the app.yaml file. If you’re familiar with development using frameworks like Zend or Symfony, defining your routes will come naturally and may be marginally more difficult than copy/paste. If you’re only familiar with doing non-framework development in PHP, you’ll have to define a route for each and every PHP file the user accesses. In Google’s example “hello world” app, your app.yaml file should should begin with something like this:



application: examplehelloworld
version: 1
runtime: php
api_version: 1
threadsafe: true
 
handlers:
- url: .*
  script: main.php


The request handlers are the important part. If you’re using an MVC framework or OpenVBX, you’ll most likely have one primary element mapping your index.php file and a set of elements for static assets like JavaScript, CSS, and images.



Alternatively, if you’re not using a using a framework, app.yaml will map different URL patterns to individual PHP scripts, like this:

application: examplehelloworld
version: 1
runtime: php
api_version: 1
threadsafe: true
 
handlers:
- url: /images
  static_dir: images
 
- url: /send-sms
  script: send-sms.php
 
- url: /make-call
  script: make-call.php
 
- url: .*
  script: index.php


Within those individual PHP scripts, no changes are necessary, so our make-call.php is straightforward and identical to our quickstart:

<?php
 
require 'Services/Twilio.php';
include 'credentials.php';
 
$client = new Services_Twilio($AccountSid, $AuthToken);
 
$call = $client->account->calls->create(
    '1512-555-1212', // From this number
    '17035551212',   // Send to this number
    'http://twimlets.com/echo?Twiml=%3CResponse%3E%3CSay%3EHello%20Monkey!%3C%2FSay%3E%3C%2FResponse%3E&'
);
print $call->sid;


Also, the send-sms.php can be the same as our normal quickstart:

<?php
 
require 'Services/Twilio.php';
include 'credentials.php';
 
$client = new Services_Twilio($AccountSid, $AuthToken);
 
$call = $client->account->sms_messages->create(
    '1512-555-1212', // From this number
    '17035551212',   // Send to this number
    'Hello monkey!!'
);
print $call->sid;


Now you can access your scripts via http://localhost:8080/make-call.php and http://localhost:8080/send-sms.php respectively. If the file is one that doesn’t need to be accessible publicly, such as your credentials.php file, it shouldn’t have a listing.



Voila. You now have your first PHP application on Google App Engine!



I hope this is helpful as you test and deploy your PHP applications on Google App Engine. If you have any tips, feedback, suggestions, or just a good joke please let me know via email or Twitter: @CaseySoftware.



-Contributed by Keith Casey, Sr Developer Evangelist, Twilio