Showing posts with label guest post. Show all posts
Showing posts with label guest post. Show all posts

Monday, August 5, 2013

Getting started with Twilio on Google App Engine for PHP

Author Photo
This guest post was written by Keith Casey, Sr. Developer Evangelist for Twilio

Cross-posted from the Google Cloud Platform Blog


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.


Keith Casey currently serves as a Developer Evangelist for Twilio to get good tools to good developers so they can change how businesses communicate. In his spare time, he is a core contributor to web2project, works to build and support the Austin technology community, blogs occasionally at CaseySoftware.com and is completely fascinated by monkeys.

Posted by Ashleigh Rentz, Editor Emerita

Wednesday, July 31, 2013

How Safari Books Online uses Google BigQuery for business intelligence

This guest post was written by Daniel Peter, Senior Programmer Analyst at Safari Books Online.

Cross-posted from the Google Cloud Platform Blog

Safari Books Online is a subscription service for individuals and organizations to access a growing library of over 30,000 technology and business books and videos. Our customers browse and search the library from web browsers and mobile devices, generating powerful usage data which we can use to improve our service and increase profitability. We wanted to quickly and easily build dashboards, improve the effectiveness of our sales teams and enable ad-hoc queries to answer specific business questions. With billions of records, we found it challenging to get the answers to our questions fast enough with our existing MySQL databases.

Looking for alternative solutions to build our dashboards and enable interactive ad-hoc querying, we played with several technologies, including Hadoop. In the end, we decided to use Google BigQuery.

Here’s how we pipe data into BigQuery:



Our data starts in our CDN and server logs, gets packaged up into compressed files, and runs through our ETL server before finishing in BigQuery.

Here’s one of the dashboards we built using the data:



You can see that with the help of BigQuery, we can easily categorize our books. This dashboard shows popular books by desktop and mobile, and with BigQuery, we are able to run quick queries to dive into other usage patterns as well.

BigQuery has been very valuable for our company, and we’re just scratching the surface of what is possible.

Check out the article for more details on how we manage our import jobs, transform our data, build our dashboards, detect abuse and improve our sales team's effectiveness.


Posted by Scott Knaster, Editor

Wednesday, November 28, 2012

Launching WordPress into the Google cloud

Author PhotoBy Artem Livshits, CEO of OblakSoft

This guest post was written by Artem Livshits, CEO of OblakSoft, which makes the ClouSE MySQL storage engine for cloud development. In this post, Artem describes his experience using Google Cloud Storage to store and serve a WordPress blog.


WordPress is popular blogging software used by over 60 million people. If you have a WordPress blog, you want to ensure that your server load is manageable and that your load times are fast. You also want your data to be protected in case your server fails. With that in mind, we at OblakSoft created the Cloud Storage Engine for MySQL (ClouSE). It stores all your WordPress data on Google Cloud Storage, taking the load off your server to improve reliability and speed, and to reduce hosting costs.

We’ve been very impressed with the performance of Google Cloud Storage. Because it’s built on Google’s infrastructure, storage objects are cached within Google’s global network and distributed globally without the need for a Content Distribution Network (CDN). This ensures content is delivered with the best possible performance.

Here is a high-level architectural diagram of a WordPress-powered website that uses Google Cloud Storage to store and serve content:


The website’s content management is done through WordPress, which uses a MySQL server to store the website’s data. It uses the WP2Cloud WordPress plugin we created to upload pictures (and other media files) to Google Cloud Storage. ClouSE makes the web server stateless by storing all data in Google Cloud Storage using the Google Cloud Storage API. Web pages (lightweight HTML) are served by WordPress, while media files are served by Google Cloud Storage directly.

WordPress is one example of a MySQL-based application that can take full advantage of Google Cloud Storage to:
  • Keep the data highly available and highly durable.
  • Serve media files in a highly scalable fashion.
  • Distribute media files across the globe for fast access.
This solution works with any hosting provider, so our users can keep their current hosting arrangement, and move their data to Google Cloud Storage using WP2Cloud and ClouSE. Users who are limited preview customers of Google Compute Engine can get started immediately using a fully configured WordPress image that we created.

We’re very excited about the potential of the Google Cloud Platform to power dynamic web server applications. Launch your own WordPress site in the cloud today - it’s easy and there’s minimal setup. We found it easy to make ClouSe work with Google Cloud Storage, and you can see how you can integrate Google Cloud Storage into your app as well.


Artem Livshits is the Founder, CEO and software architect at OblakSoft, a company focusing on technologies that simplify adoption of cloud computing. Previously Artem led the development of several server products from inception to maturity during his 12 years at Microsoft, including the source control system managing most of the Microsoft code base.

Posted by Scott Knaster, Editor

Tuesday, October 9, 2012

Streak brings CRM to the inbox with Google Cloud Platform

Author PhotoBy Aleem Mawani, Co-Founder of Streak

Cross-posted with the Google App Engine Blog

This guest post was written by Aleem Mawani, Co-Founder of Streak, a startup alum of Y Combinator, a Silicon Valley incubator. Streak is a CRM tool built into Gmail. In this post, Aleem shares his experience building and scaling their product using Google Cloud Platform.

Everyone relies on email to get work done – yet most people use separate applications from their email to help them with various business processes. Streak fixes this problem by letting you do sales, hiring, fundraising, bug tracking, product development, deal flow, project management and almost any other business process right inside Gmail. In this post, I want to illustrate how we have used Google Cloud Platform to build Streak quickly, scalably and with the ability to deeply analyze our data.



We use several Google technologies on the backend of Streak:

  • BigQuery to analyze our logs and power dashboards.

Our core learning is that you should use the best tool for the job. No one technology will be able to solve all your data storage and access needs. Instead, for each type of functionality, you should use a different service. In our case, we aggressively mirror our data in all the services mentioned above. For example, although the source of truth for our user data is in the App Engine Datastore, we mirror that data in the App Engine Search API so that we can provide full text search, Gmail style, to our users. We also mirror that same data in BigQuery so that we can power internal dashboards.

System Architecture




App Engine - We use App Engine for Java primarily to serve our application to the browser and mobile clients in addition to serving our API. App Engine is the source of truth for all our data, so we aggressively cache using Memcache. We also use Objectify to simplify access to the Datastore, which I highly recommend.

Google Cloud Storage - We mirror all of our Datastore data as well as all our log data in Cloud Storage, which acts as a conduit to other Google cloud services. It lets us archive the data as well as push it to BigQuery and the Prediction API.

BigQuery - Pushing the data into BigQuery allows us to run non-realtime queries that can help generate useful business metrics and slice user data to better understand how our product is getting used. Not only can we run complex queries over our Datastore data but also over all of our log data. This is incredibly powerful for analyzing the request patterns to App Engine. We can answer questions like:

  • Which requests cost us the most money?
  • What is the average response time for every URL on our site over the last 3 days?

BigQuery helps us monitor error rates in our application. We process all of our log data with debug statements, as well as something called an “error type” for any request that fails. If it’s a known error, we'll log something sensible, and we log the exception type if we haven’t seen it before. This is beneficial because we built a dashboard that queries BigQuery for the most recent errors in the last hour grouped by error type. Whenever we do a release, we can monitor error rates in the application really easily.



A Streak dashboard powered by BigQuery showing current usage statistics
In order to move the data into Cloud Storage from the Datastore and LogService, we developed an open source library called Mache. It’s a drop-in library that can be configured to automatically push data into BigQuery via Cloud Storage. The data can come from the Datastore or from LogService and is very configurable - feel free to contribute and give us feedback on it!

Google Cloud Platform also makes our application better for our users. We take advantage of the App Engine Search API and again mirror our data there. Users can then query their Streak data using the familiar Gmail full text search syntax, for example, “before:yesterday name:Foo”. Since we also push our data to the Prediction API, we can help users throughout our app by making smart suggestions. In Streak, we train models based on which emails users have categorized into different projects. Then, when users get a new email, we can suggest the most likely box that the email belongs to.

One issue that arises is how to keep all these mirrored data sets in sync. It works differently for each service based on the architecture of the service. Here’s a simple breakdown:




Having these technologies easily available to us has been a huge help for Streak. It makes our products better and helps us understand our users. Streak’s user base grew 30% every week for 4 consecutive months after launch, and we couldn’t have scaled this easily without Google Cloud Platform. To read more details on why Cloud Platform makes sense for our business, check out our case study and our post on the Google Enterprise blog.


Aleem Mawani is the co-founder of Streak.com, a CRM tool built into Gmail. Previously, Aleem worked on Google Drive and various ads products at Google. He has a degree from the University of Waterloo in Software engineering and an MBA from Harvard University.

Posted by Scott Knaster, Editor

Friday, September 28, 2012

How redBus uses BigQuery to master big data

Author Photo
By Pradeep Kumar, redBus

This guest post was written by Pradeep Kumar. Pradeep is a technical architect at redBus, an online travel agency in India that provides a unified online bus ticketing service. We recently published a business case study for redBus and wanted to dive into some more technical detail for the readers of the Google Developers Blog.


Our company has been providing Internet bus ticketing for India since 2006. There are more than 10,000 bus routes available for booking, and we have dozens of machines processing booking requests. Each step in the booking process produces a lot of data – on search terms, route availability, server health and more. We needed tools to to be able to process this data quickly and easily to determine whether decreases in customer bookings are the result of server problems or simply less demand.

While we typically use relational databases to store and analyze data, we knew we needed something more powerful if we wanted to analyze 500GB or more, so we started to look at open source frameworks like Hadoop and analysis platforms like Hive and Pig. We found that these frameworks require considerable in-house expertise and infrastructure investments and wouldn’t give us answers to our questions as fast as we wanted. We decided to try out Google BigQuery as a trusted tester, with hopes that it would give us the ability to perform quick iterative analysis without much up-front investment. Our initial tests went very well, so we started building our analysis tools on top of BigQuery.

BigQuery allows us to run SQL-like queries to understand the bus routes in highest demand and what types of searches users are performing. We’ve also used it to build internal dashboards that give us a snapshot of system health.


For more information on how we structured our immutable tables, pipelined our data into BigQuery for analysis using RabitMQ, and to see example SQL queries we’ve used, check out my article on developers.google.com.


Pradeep Kumar is a technical architect at redBus.

Posted by Scott Knaster, Editor

Friday, August 10, 2012

Behind the scenes: visualizing the evolution of the web

Deroy
Sergio

This guest post is by Sergio Alvarez, Vizzuality, and Deroy Peraza, Hyperakt, in collaboration with Min Li Chan, Chrome Team

At Google I/O this year, we launched a new version of The Evolution of the Web, a project visualizing the history and pace of innovation in web technologies and browsers. The Evolution of the Web traces how web technologies have evolved in the last two decades and highlights the web community’s continuous efforts to improve the web platform and enable developers to create new generations of immersive web experiences. In collaboration with the Google Chrome team, the team at Hyperakt designed the interactive visualization while Vizzuality built it using HTML5, SVG, and CSS3.


The visualization included 43 web technology "strands" across 7 browser timelines to represent major developments on the web platform. On hover or tap, each strand is highlighted to reveal intersections that tell the story of when browser support was implemented for each new web technology. To provide additional context, we developed a secondary visualization to illustrate the growth of Internet users and traffic.


In addition, this year's design includes the option for viewing the visualization in both day and night mode, making it ideal for large-screen projection.


For the teams working on this site, it was interesting to note that we used roughly 60% of the technologies highlighted in the timeline to build this visualization:
  • We used HTML5, SVG, and canvas to draw the visualization, alongside CSS3 transforms, rotation, and perspective for immersive animation and data interaction.
  • We used CSS3 to kick off the timeline with a 3D-like animation, as well as the panning and zooming functions, toggling between day and night modes.
  • Additionally, we took advantage of the D3 JavaScript library’s interaction and visual frameworks.
In working closely with the Chrome team, we tested multiple approaches to find the best way to bring to life initial design concepts and build a sleek, responsive visualization. In fact, during the project's development, the Vizzuality team came across an SVG rendering issue that prevented the animation from running smoothly. The Chrome team looked into this bug immediately and promptly enabled a fix the following day – a glimpse at the web evolving in real-time, if you will!

We're amazed at how much the web has advanced over the last several years, and the pace of development is only accelerating. Never in the web's history has it been as exciting to be a designer or web developer, and we hope that this visualization captures some of that spirit.


Deroy Peraza is a founding partner and creative director at Hyperakt, a New York City design firm that helps change-makers tell their stories. He was born in Havana, Cuba, and lives in Brooklyn with his wife Jenna and his son Luco.

Sergio Alvarez is co-founder and lead designer at Vizzuality and CartoDB, a NYC-based company working on data analysis and visualization on stories that matter, such as climate change or biodiversity loss. He is a good runner and loves to ride his long board.

Posted by Scott Knaster, Editor

Wednesday, September 28, 2011

Monetizing games with In-App Payments


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

Cross-posted with the Google Commerce Blog

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

Integrating In-App Payments

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

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

Pro tip: strive to reduce purchaser friction

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

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

General recommendations

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

Beau Harrington is Senior Development Director of Kabam

Posted by Scott Knaster, Editor

Tuesday, September 22, 2009

Lee Sargent and the Guest Post of Doom

After last week's marathon session of posting, I was both honored and relieved to discover that long time reader and super blogger and artist Lee Sargent of Quit Your Day Job fame had a guest post up his sleeve for me.

In fact, I think this is the first guest post I've ever had. I've written a few, but I've never had one.

Lee wrote an eloquent entry about what he looks for in a game (which he knew would be right up my alley), and it is like a walk down memory lane, even though I didn't go down the exact same path he did as a child.

Lee, I am forever in your debt my friend, and I thought you'd appreciate the title. It was probably better than referring to you as my favorite Eric Bana character ever.

--
When thinking about my favourite games I'm usually driven by two factors that your general game reviewer probably disregards for completely appropriate reasons given their goals. But as I maintain with any of these types of ranking exercises it's so much better to be personally subjective and so the following two factors play a large part for me:

* Nostalgia
* Social networking


Nostalgia is of course an incredibly powerful thing, especially in a marketing/retail environment. Nostalgia is what makes you generally interested in an A-Team film, despite the fact that upon detached and objective revisits to the A-Team television show you find yourself wondering how you ever could have found the show engaging on any level. Go on, watch an episode of the A-Team and tell me that it's a perfect show with great production value and logical well thought out plot lines and it's not just the 'idea' of the show that you remember and love.

Whilst not exactly the same but similar can be said for video games. As a very young man playing the very first Leisure Suit Larry command driven adventure game it was exciting because I could (mostly) beat the questionnaire that attempted to weed out people under 18, the game responded to commands driving a linear story and the game was generally pretty funny. I do want to point out that despite the adult nature of the game there was very little 'sexy' about it. I say that to qualify the next statement and to alleviate the growing impression that I'm some kind of video game smut addict. I recently sought out a copy of the original CGA (kids, you're just going to have to Wikipedia that one) and not the remade cartoon styled point and click monstrosity.

After several rounds of slowing the computer down enough so I could actually get the game to run like it wasn't an episode of The Flash (awww Dawson's Dad was a superhero) I managed to get into the game and enjoy it for about a minute. The graphics aren't great, the gameplay is not good and the command line is cumbersome and more than often frustrating. Of course the nostalgia gene still maintains in my head that Leisure Suit Larry is an awesome game that I do want to play again.

To sum up nostalgia, often instead of saying oh yeah I love that game, one probably should should just say oh yeah I remember that game.

The second criteria, social networking, fortunately has a much more tangible reason and legitimate worth behind it when ranking video games. Now before Facebook and Twitter showed up, the term social networking had a different connotation to it. It referred to your circle of friends, your relationships and the bonds formed between these. It doesn't take a social media expert to work out the natural progression into the Web 2.0 world and the weight the social networking aspect of games may weigh them more heavily.

So before online gaming, XBox Live and Wii networks really took off the only social networking in conjunction with gaming was to physically have someone else there with you playing the game in two or more player modes. This brings me to one of my favourite games, the Teenage Mutant Ninja Turtle arcade game. Is the game visually stunning? Well no not really, it looks like the cartoon series which is good but it's a side scroller at the end of the day and so fairly limited in the stun factor. The game play and storyline rank about as well as the graphics but the strongest point is that quite simply it was a big bag of fun that I shared with my friends. We would huddle around the machine and drop much coinage in there as we battled our way through Manhattan, eagerly discussed tactics and made predictions about what the next level would hold.

I have similar experiences with Sonic the Hedgehog, however not being a two player game we would take turns beating each level whilst the others would formulate strategies to get that blue hedgehog across the line.

Years later I would battle side by side with my wife as we fought our way through hordes of orcs and trolls whilst we struggled to build up experience points and learn new moves in the PS2 versions of The Lord of the Rings Two Towers and Return of the King (two of my favourite games on the PS2 by far). We would go on to become X-Men or Avengers and finally members of the Justice League, combining three things that I love; comic books, video games and my wife (who is an excellent gamer - yet rarely uses her powers).

But it is these games that really stand out to me and feature at the top of my own list of games, not because they necessarily are brilliantly written or constructed but because I could share the experience with others and I think it is these games that stand the test of time.

Remember Pong is still awesome when you are playing with a friend!

--

Danke Schoen, Mr. Sargent.