Création des Logiciels de gestion d'Entreprise, Création et référencement des sites web, Réseaux et Maintenance, Conception
seo Launching WordPress into the Google cloud 2013
Seo Master present to you: 
By 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:
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
2013, By: Seo Master
By Artem Livshits, CEO of OblakSoftThis 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.
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
2013, By: Seo Master
seo Streak brings CRM to the inbox with Google Cloud Platform 2013
Seo Master present to you: 
By 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.
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:
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.
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
2013, By: Seo Master
By Aleem Mawani, Co-Founder of StreakCross-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:
- App Engine to serve our app.
- App Engine Datastore to persist user data.
- Memcache to make operations fast.
- BigQuery to analyze our logs and power dashboards.
- App Engine Search API to let users sift through their data.
- Prediction API to machine learn over user data.
- Google Translate API to translate our app to over 40 languages.
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
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 |
.jpg){kind=link}
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
2013, By: Seo Master
seo Monetizing games with In-App Payments 2013
Seo Master present to you:
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:
Beau Harrington is Senior Development Director of Kabam
Posted by Scott Knaster, Editor 2013, By: Seo Master
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.
Beau Harrington is Senior Development Director of Kabam
Posted by Scott Knaster, Editor 2013, By: Seo Master
seo How redBus uses BigQuery to master big data 2013
Seo Master present to you: 
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
2013, By: Seo Master
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
2013, By: Seo Master