Création des Logiciels de gestion d'Entreprise, Création et référencement des sites web, Réseaux et Maintenance, Conception
Seo Master present to you: 
By Ron Zalkind, CTO and Co-Founder, CloudLock
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
At CloudLock, we're all about cloud data protection. When we decided to build CloudLock for Google Apps, we had three main challenges to solve:
Why App Engine?
After researching all the choices available to us, we concluded that Google App Engine was the right choice for us.
1. Data stays within the Google infrastructure - Since CloudLock classifies document sharing permissions to help companies control who has access to what and what is accessible to whom, the location of this highly sensitive data is paramount. Using Google App Engine lets us scan, analyze and present information to our customers natively within the Google infrastructure without any of the data leaving to a third party.
Google's datastore had the attributes we were looking for in a persistent storage solution. It offers a high replication option for high reliability, and since it is implemented on top of BigTable and Google's distributed file system, it runs on the same core infrastructure that powers other Google services like Gmail and Google Apps.
CloudLock customer Brian Bolt from Boise State University put it best, saying "Our security team appreciates the fact that the CloudLock solution is developed and hosted on the Google App Engine platform; and since CloudLock is powered by Google’s App Engine, our data never leaves Google’s Cloud Infrastructure."
2. Scaling with App Engine is easy - While being able to handle the largest Google Apps customers was a top concern, being able to do so on an ongoing basis was another issue we had to solve. Using the Google App Engine Task Queue service, CloudLock is able to analyze massive amounts of data continually. App Engine makes it very easy to start as many background tasks as needed to deal with bursts of load.
The Google Apps Marketplace
The Google Apps Marketplace gives Google Apps customers access to hundreds of applications to extend the capabilities of the core productivity suite. Installing an app from the marketplace is seamless, with a wizard-like interface that makes apps immediately available in a few clicks. The installation securely white-lists the app and grants access to specific domain resources such as Google Docs.
Google’s App Engine Users service allows application developers to easily integrate their app with Google’s account management system (Google account or Google Apps accounts) and OpenID for Single Sign-On. Using the Users service and the marketplace installation we were able to deliver an app that is very easy to install into a domain and gain secure access into the domain's data.
By choosing Google App Engine and the Google Apps Marketplace, we were able to create an application that keeps our customers’ data secure within the Google infrastructure, meets the scaling challenges of the largest Google Apps users, and is immediately and easily available to users.
CloudLock for Google Apps is available directly from the Google Apps Marketplace and runs on Google App Engine.
Update 7:50 AM: This blog post was modified to correctly represent App Engine's certification state. As of May 2011, App Engine is pursuing SAS70-II certification to align it with the other products in the Google Apps suite.
Come see CloudLock in the Developer Sandbox at Google I/O on May 10-11.
Ron Zalkind is the CTO and a Co-Founder of CloudLock, runs the Boston Google App Engine User Group, and has been known to roll up his sleeves and write code while blasting Jay-Z in his headphones.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Ron Zalkind, CTO and Co-Founder, CloudLock
This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.
At CloudLock, we're all about cloud data protection. When we decided to build CloudLock for Google Apps, we had three main challenges to solve:
- Security of data - No matter which system you use for governance, compliance, and access controls, you want that data to be safe.
- Enterprise scalability - By nature, many of the companies facing data governance and regulatory compliance requirements are larger organizations. Because of that, we needed to build CloudLock with the largest Google Apps customers in mind from day one.
- Low administrative overhead - We wanted to be able to make the most effective use of our development resources. With App Engine, we spend time building apps rather than managing infrastructure.
Why App Engine?
After researching all the choices available to us, we concluded that Google App Engine was the right choice for us.
1. Data stays within the Google infrastructure - Since CloudLock classifies document sharing permissions to help companies control who has access to what and what is accessible to whom, the location of this highly sensitive data is paramount. Using Google App Engine lets us scan, analyze and present information to our customers natively within the Google infrastructure without any of the data leaving to a third party.
Google's datastore had the attributes we were looking for in a persistent storage solution. It offers a high replication option for high reliability, and since it is implemented on top of BigTable and Google's distributed file system, it runs on the same core infrastructure that powers other Google services like Gmail and Google Apps.
CloudLock customer Brian Bolt from Boise State University put it best, saying "Our security team appreciates the fact that the CloudLock solution is developed and hosted on the Google App Engine platform; and since CloudLock is powered by Google’s App Engine, our data never leaves Google’s Cloud Infrastructure."
2. Scaling with App Engine is easy - While being able to handle the largest Google Apps customers was a top concern, being able to do so on an ongoing basis was another issue we had to solve. Using the Google App Engine Task Queue service, CloudLock is able to analyze massive amounts of data continually. App Engine makes it very easy to start as many background tasks as needed to deal with bursts of load.
The Google Apps Marketplace
The Google Apps Marketplace gives Google Apps customers access to hundreds of applications to extend the capabilities of the core productivity suite. Installing an app from the marketplace is seamless, with a wizard-like interface that makes apps immediately available in a few clicks. The installation securely white-lists the app and grants access to specific domain resources such as Google Docs.
Google’s App Engine Users service allows application developers to easily integrate their app with Google’s account management system (Google account or Google Apps accounts) and OpenID for Single Sign-On. Using the Users service and the marketplace installation we were able to deliver an app that is very easy to install into a domain and gain secure access into the domain's data.
By choosing Google App Engine and the Google Apps Marketplace, we were able to create an application that keeps our customers’ data secure within the Google infrastructure, meets the scaling challenges of the largest Google Apps users, and is immediately and easily available to users.
CloudLock for Google Apps is available directly from the Google Apps Marketplace and runs on Google App Engine.
Update 7:50 AM: This blog post was modified to correctly represent App Engine's certification state. As of May 2011, App Engine is pursuing SAS70-II certification to align it with the other products in the Google Apps suite.
Come see CloudLock in the Developer Sandbox at Google I/O on May 10-11.
Ron Zalkind is the CTO and a Co-Founder of CloudLock, runs the Boston Google App Engine User Group, and has been known to roll up his sleeves and write code while blasting Jay-Z in his headphones.
Posted by Scott Knaster, Editor
2013, By: Seo Master
Seo Master present to you:
2013, By: Seo Master
You walk into the bathroom, your bladder is throbbing. You throw open the lid of the toilet, bend down, and before you have time to react you’re new iPhone 5 has fallen from your jacket and floats in a new resting place in the toilet bowl. Suddenly, relieving yourself has taken a backseat to retrieving and attempting to salvage your phone. Regardless of the brand and model of smartphone, the urgency to save your expensive technology is the same. The next time you find yourself in this unfortunate situation, keep in mind the following tips to rescue and resuscitate your fallen phone.
This is essential to preserving the function of the phone since many electrical circuits in the phone will still function after immersion in water if they are unattached to a power source. You should also remove any covers or accessories from the phone. Taking out the SIM card is also a good idea since all of your contact data is stored here.
Extract the Phone Immediately
This should probably just go without saying since your instinctive reaction will likely be to thrust your hand into the toilet bowl and pull the phone out. If you already relieved yourself when the phone fell, your unfortunate situation just got a little more unfortunate -- and interesting. The plastic on most smart phones is pretty tight, but you should assume it is waterlogged and make haste to pull it out.Remove the Battery and Place on a Towel
How long the phone was immersed in water will determine the damage. Sometimes if the phone was not in the water for too long, there will not be much damage. Instead of immediately patting the phone dry after taking it out, remove the battery cover and battery and place them on the towel.This is essential to preserving the function of the phone since many electrical circuits in the phone will still function after immersion in water if they are unattached to a power source. You should also remove any covers or accessories from the phone. Taking out the SIM card is also a good idea since all of your contact data is stored here.
Dry the Phone Well
Even a little bit of water still inside the phone can ruin it. Damaging the circuitry and corroding other essential components is possible with the presence of just a little water. Keep the phone still on a flat surface and gently wipe it with an absorbent cloth or towel. Try not to shake or move the phone around too much since this could spread water around inside. Often this is the last step to resolving the crisis. Once dry, turn the phone on and see if it works.Vacuum Dry
This is an additional step that may not be necessary after towel drying. Holding a vacuum cleaner suction tube over the phone to remove residual moisture can effectively dry your phone in a short time. Always hold the vacuum away from the phone to prevent static electricity from building up. After vacuuming, wait a couple of hours to turn your phone on, even if it appears dry. This will ensure proper evaporation of all of the components of the phone to prevent an electrical short.Test the Phone
After drying your phone using whatever means you have available, the final step is to turn the phone on and test it. Waiting until the phone is completely dried out is a good idea before turning it on. Of course, if the phone doesn’t even turn on, you’ve completed the test and it has failed -- you either need a new battery, a charge, or need to consult a professional. Check the ports and crevasses for moisture, insert the battery, and power it on. Ensure the phone functions and that there are no strange noises. If all appears well, you’ve learned a valuable lesson and still have a functioning phone.Author Bio:
Ben Vaughn is a contributing writer for ACR Services. He writes on topics ranging from choosing a plumber and water conservation tips to saving your smartphone from a slow drowning death in the toilet.Seo Master present to you: 
By Webb Brown, Co-Founder of DayZipping
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 launched DayZipping in July 2010 to help people easily find day trip ideas. Before starting the project we conducted an extensive search to find the most suitable web technologies. When evaluating our options we had two priorities that eclipsed all others. First, we wanted to minimize page load times, because we believed our consumer engagement (photo views, rapid spatial searches, etc.) would be strongly impacted by site performance. Part of this requirement was offering a snappy desktop-like experience for certain sections of our site. Secondly, we wanted an environment that didn't hinder our ability to iterate quickly across our entire web platform.
Below are the key factors that lead us to believe that Google Web Toolkit (GWT) is the best tool for the job. Also, we have included evidence of how GWT features have helped us accomplish these goals:
Inherent GWT Efficiencies. The GWT project structure comes chock full of performance benefits that are practically free. Its compilation process significantly reduces code size by renaming variables and inlining method calls when possible. The bootstrapping project structure permits perfect caching of browser-specific implementations by generating deployment files based on the MD5 hash of file contents. The only cost for these performance improvements is the time spent compiling code when deploying production releases, which for us amounts to a marginal five to ten minutes per week.
Resource Bundling. GWT allows you to reduce round trip times by bundling css, image, and text resources into initial page requests. Browser-specific implementations and perfect cacheing mechanisms are all managed behind the scenes. We've used this to bundle many of our static images and in certain cases removed up to 20 fetch requests on a single page.
Code Splitting. The ability to seamlessly split deployed Javascript into logical chunks has greatly improved our user experience. Google released code splitting after we began development of DayZipping, so we were able to analyze results independent of large feature changes. Implementing code splitting reduced our initial fragment download by approximately 100K, which equated to a 40% decrease in size for most browsers. This change in initial download time decreased our bounce rate by approximately 20% on most pages.
Java Tools. The tools available for GWT development have allowed us to stay nimble despite amassing a substantial code base for a two person development team. Eclipse's refactoring tools have arguably played the largest role in our ability to quickly make changes across the project. Being able to make logical adjustments as well as renaming entire functions or classes without having to track down all references has saved us considerable time relative to a Javascript environment. Eclipse syntax recognition and code completion tools make touching dusty sections of our code more palatable. Having the power of a JUnit test suite gives us the confidence to deploy these changes as rapidly as we could imagine. During these rapid iterations, the GWT perfect caching mechanisms relieve the risk of users being stuck with stale content.
Last year our initial hypothesis of a strong negative correlation between page load times and user engagement received compelling support. We made GWT compiler flag changes that gave us an immediate ~10% performance improvement. (You can explore performance gains by experimenting with the various compiler flag options shown here and analyzing the results.) This particular enhancement drove a nearly 1 to 1 increase in user engagement, pushing average pageviews per visit above 11. These engagement improvements have directly impacted conversion rates, which as a consumer startup is arguably our most important operating metric.
GWT has met our initial requirements with high marks. We genuinely believe that we would have been unable to accomplish these tasks as effectively with any other framework. Come visit our exhibit at Google I/O to hear more about the details of our experience.
Come see DayZipping in the Developer Sandbox at Google I/O on May 10-11.
Webb Brown uses his background in investment banking and software development to do a little bit of everything at DayZipping. He spends his free time outdoors and traveling, all while trying to complete as many trips on DayZipping as possible.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Webb Brown, Co-Founder of DayZipping
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 launched DayZipping in July 2010 to help people easily find day trip ideas. Before starting the project we conducted an extensive search to find the most suitable web technologies. When evaluating our options we had two priorities that eclipsed all others. First, we wanted to minimize page load times, because we believed our consumer engagement (photo views, rapid spatial searches, etc.) would be strongly impacted by site performance. Part of this requirement was offering a snappy desktop-like experience for certain sections of our site. Secondly, we wanted an environment that didn't hinder our ability to iterate quickly across our entire web platform.
Below are the key factors that lead us to believe that Google Web Toolkit (GWT) is the best tool for the job. Also, we have included evidence of how GWT features have helped us accomplish these goals:
Inherent GWT Efficiencies. The GWT project structure comes chock full of performance benefits that are practically free. Its compilation process significantly reduces code size by renaming variables and inlining method calls when possible. The bootstrapping project structure permits perfect caching of browser-specific implementations by generating deployment files based on the MD5 hash of file contents. The only cost for these performance improvements is the time spent compiling code when deploying production releases, which for us amounts to a marginal five to ten minutes per week.
Resource Bundling. GWT allows you to reduce round trip times by bundling css, image, and text resources into initial page requests. Browser-specific implementations and perfect cacheing mechanisms are all managed behind the scenes. We've used this to bundle many of our static images and in certain cases removed up to 20 fetch requests on a single page.
Code Splitting. The ability to seamlessly split deployed Javascript into logical chunks has greatly improved our user experience. Google released code splitting after we began development of DayZipping, so we were able to analyze results independent of large feature changes. Implementing code splitting reduced our initial fragment download by approximately 100K, which equated to a 40% decrease in size for most browsers. This change in initial download time decreased our bounce rate by approximately 20% on most pages.
Java Tools. The tools available for GWT development have allowed us to stay nimble despite amassing a substantial code base for a two person development team. Eclipse's refactoring tools have arguably played the largest role in our ability to quickly make changes across the project. Being able to make logical adjustments as well as renaming entire functions or classes without having to track down all references has saved us considerable time relative to a Javascript environment. Eclipse syntax recognition and code completion tools make touching dusty sections of our code more palatable. Having the power of a JUnit test suite gives us the confidence to deploy these changes as rapidly as we could imagine. During these rapid iterations, the GWT perfect caching mechanisms relieve the risk of users being stuck with stale content.
Last year our initial hypothesis of a strong negative correlation between page load times and user engagement received compelling support. We made GWT compiler flag changes that gave us an immediate ~10% performance improvement. (You can explore performance gains by experimenting with the various compiler flag options shown here and analyzing the results.) This particular enhancement drove a nearly 1 to 1 increase in user engagement, pushing average pageviews per visit above 11. These engagement improvements have directly impacted conversion rates, which as a consumer startup is arguably our most important operating metric.
GWT has met our initial requirements with high marks. We genuinely believe that we would have been unable to accomplish these tasks as effectively with any other framework. Come visit our exhibit at Google I/O to hear more about the details of our experience.
Come see DayZipping in the Developer Sandbox at Google I/O on May 10-11.
Webb Brown uses his background in investment banking and software development to do a little bit of everything at DayZipping. He spends his free time outdoors and traveling, all while trying to complete as many trips on DayZipping as possible.
Posted by Scott Knaster, Editor
2013, By: Seo Master