Google Plugin for Eclipse 2.5

Since Google added SQL support to App Engine in the form of Google Cloud SQL, the Google Plugin for Eclipse (GPE) team has been working hard on improving the developer experience for developing App Engine apps that can use a Cloud SQL instance as the backing database.

They are pleased to announce the availability of Google Plugin for Eclipse 2.5. GPE 2.5 simplifies app development by eliminating the need for manual tasks like copying Cloud JDBC drivers, setting classpaths, typing in JDBC URLs or filling in JVM arguments for connecting to local/remote database instances.

GPE 2.5 provides support for:

  • Configuring Cloud SQL/MySQL instances
  • Auto-completion for JDBC URLs
  • Creating database connections in Eclipse database development perspective
  • OAuth 2.0 for authentication.

Configuring Cloud SQL/MySQL instances
App Engine provides a local development environment in which you can develop and test your application before deploying to App Engine. With GPE 2.5, you now have the ability to configure your local development server to use a local MySQL instance or a Cloud SQL instance for testing. When you choose to deploy your app, it will use the configured Cloud SQL instance for App Engine.

Auto-completion for JDBC URLs
GPE 2.5 supports auto-completion for JDBC URLs, and quick-fix suggestions for incorrect JDBC URLs.

Creating database connections in Eclipse database development perspective
The Eclipse database development perspective can be used to configure database connections, browse the schema and execute SQL statements on your database.

Using GPE 2.5, database connections are automatically configured in the Eclipse database development perspective for the Development SQL instance and the App Engine SQL instance.

You can also choose to manually create a new database connection for a Cloud SQL instance. In GPE 2.5, we have added a new connection profile for Cloud SQL.

GPE 2.5 now uses OAuth 2.0 (earlier versions were using OAuth 1.0)  to securely access Google services (including Cloud SQL) from GPE. OAuth 2.0 is the latest version of the OAuth protocol focussing on simplicity of client development.

Can’t wait to get started?
Download GPE here and write your first App Engine and Cloud SQL application using GPE by following the instructions here.

Google hope GPE 2.5 will make cloud application development using App Engine and Cloud SQL a breeze. We always love to hear your feedback and the GPE group is a great place to share your thoughts.

Beautiful Google Earth Layers 2: Satellites database

Database of about 12,000 man-made objects in Earth orbit. These objects are tracked U.S. Strategic Command and includes various collector, retired satellites and rockets left over from the launch.

The database is updated in real time every 30 seconds, and detailed information about each object, including the owner, date of start-up and visualization of orbits can be viewed in Google Earth by clicking on the object.

Download .kml file

How does Google create and maintain/add location records for database?

The question “How does Google create and maintain/add location records for their “Google Places” database?” was asked recently at Quora. I am reproducing my answer here so that readers who are new to the blog can get some background information on Google Places from a high level view:

Google obtains records for their business listings from

  • the major list dealers like InfoUSA,
  • feeds from trusted sources like CityGrid,
  • scraping trusted structured websites like Superpages or BBB,
  • scraping less trusted and less structured directories,
  • user input via their MapMaker product and Community edit of unclaimed listings in Maps,
  • across the web in general,
  • and business claimed records via the Places Dashboard.

This data is essentially triangulated to create the Places search result.

Every time that they identify a unique PHONE/business/address/ combo they create what is known as a cluster into which all structured and unstructured known data about a business is placed.

The data that can be normalized is normalized and matched against the same field from all the sources. If there are discrepancies Google will resolve which is accurate by picking the data from the most trusted and most recent sources. Strong preference of trust is given to data from their own claiming process which requires direct post card verification. If a listing is unclaimed preference is given to verified lists like those of InfoUSA and then to trusted feeds and on down the chain of trust.

They do often end up with two clusters that are essentially identical or only differ in small details. They run a merge/purge that merges these two clusters into one. This system uses not just geographic signals but language similarities as well to decide if two listings should be merged. Errors and lack of granularity in this function can lead to merging of two unrelated businesses that are located physically close to one another and happen to be in the same line of work. If the system fails to merge two records, a business listing might lose rank as the cluster data is split between two records. At this point in time there is NO formal mechanism to unmerge two merged listings although there are some off-Google techniques that might accomplish it. This is known among the cognoscenti as a “Cluster-F**k”.

Here is an article that summarizes their clustering technology