Explore the world with updated apps for iPhone: Check in with Latitude and use Places in 30 languages

We’re happy to announce updates for two iPhone apps that help you connect the people you care about with the places you love: Google Latitude with check-ins and Google Places in 30 languages.

Check in with Google Latitude for iPhone
After adding check-ins to Google Latitude for Android-powered devices, we’re happy to announce that you can now start checking in at places with the updated Latitude app for iPhone.

With Google Latitude, you can see where your Latitude friends are on a map and choose to continuously share where you are. Now, you can also choose to check in at specific places, such as your favorite restaurant or a park, to add more context to your location. You’ll be able to not only let friends know that you’re just around the corner but also let them know the actual coffee shop that you’re at in case they want to join you. If Latitude is set to continuously update your location, you’ll also be automatically checked out when you leave. This way, friends aren’t left guessing if you’re still there or not before heading over to join you for a latte.

Tap the “Check in” button to start checking in at nearby places. Keep checking in every time you visit your favorite places to start gaining special status there. You’ll not only progress to become a Regular, VIP, and then Guru at your favorite places, but if you’re near Austin, Texas, gaining status lets you unlock check-in offers at over 60 places.

Just like with sharing your location, you can control your Latitude check-in privacy. Checking in is 100% opt-in, and you can choose to share any check-in with your friends on Latitude, publicly on the web and your Google profile, or just yourself.

To start checking in with Latitude on your iPhone, update the Latitude app from the App Store. The app requires iOS 4 and above, and it’s available for iPhone 3GS, iPhone 4, iPad, and iPod touch (3rd/4th generation). However, background location updating is only available on the iPhone 3GS, iPhone 4, and iPad 3G.

Google Places in 30 languages
Best ever! Me gusta! Mi piace! Ich liebe es! Wherever you are and whatever language you speak, we want to give you the best personalized place recommendations when you use Google Places with Hotpot. Update the Google Places app from the App Store to rate on the go and get personalized recommendations for places in 30 languages.

You’ll also have one more way to personalize your experience: saved places. Sign in with your Google Account using the info icon in the top left corner. Then, tap the new “Saved” icon on the app’s main screen to see all the places that you’ve saved or starred from the app,google.com/hotpot or maps.google.com.

Updates will appear in the App Store in supported countries throughout today. Get the latest version of Google Places from the App Store and start discovering great new places wherever you are!

Enomaly chooses Google App Engine for SpotCloud.com


SpotCloud.com is the realization of a dream originating more than 7 years ago when we first started Enomaly. SpotCloud was born from a desire to change the way cloud computing is bought and sold for the better by overcoming the inefficiencies (including large capital commitments and low utilization rates) that beset the traditional models. SpotCloud is the first multi-supplier, multi-buyer model of cloud computing, all built on Google App Engine.

SpotCloud is the first marketplace where service providers can sell their unutilized or under-utilized IaaS cloud services, and where buyers can shop competitively for these services on the basis of quality, price, and geography across a federated global pool of capacity with a single, consistent set of access and management mechanisms.

SpotCloud provides its users with the following main services:

  • VM image repository & VM image provisioning services
  • REST API for cloud service users, with management and monitoring functionality
  • REST API for cloud service providers
  • REST client to access service provider API endpoints
  • Single-point unified access & authentication to all underlying cloud services
  • Federated management portal, providing management & monitoring over all connected cloud services
  • Cloud service quality, reliability, and performance measurement instrumentation and rating
  • Runtime management service (to enable time-limited instances)
  • Billing, payment, and settlement services

Why Google App Engine?

We realized early on that a traditional data center infrastructure — even one built on our own ECP technology — was not a fit for a platform which needs to be global from day one. We also had a strong preference for Python, given that large parts of our existing IaaS software stack is built using it. Cost was also very important: SpotCloud needs to manage potentially very large Virtual Machines, delivering them to a globally distributed group of providers and managing them in near-real time across this extended footprint. With Google App Engine we have the power, flexibility, and global breadth of the Google infrastructure at our disposal. This was a key selling feature for us. Also the cost was practically impossible to beat.

How App Engine powers SpotCloud

As you can see from the list of services provided by SpotCloud, most of our application actually runs in the background. This is made possible by App Engine task queues and cron jobs. We need to poll for stage changes across hundreds (soon thousands) of service providers — we need a near-real-time view of instance states, available virtual hardware profiles, cloud utilization data, etc. These things are triggered by cron schedules. Each of these tasks goes into a queue. We’re able to execute these tasks to allow us to keep our view of service provider resources up to date without interrupting the front-end UI and API workflows.

Another challenge is executing tasks at a particular point in the future. Running instances deployed out to a provider through SpotCloud may expire, and renewal may or may not be allowed depending on the seller’s settings. So we need a way to terminate them if their time is up. We can use the task queue API to execute this in the future. We’re able to ensure our data is consistent by adding tasks to the queue in a transactional way.

Buyers upload the appliances they want to provision to the market. So we obviously have a big storage requirement. App Engine’s data store allows us to do this in a highly performant, cost-effective manner. SpotCloud can then distribute these appliances out to providers on demand. We’re able to do this because of the low-cost bandwidth Google provides.

We’re big fans of Django at Enomaly, and we use it in SpotCloud. We’ve been able to loosely couple Django with the App Engine data store, along with other App Engine components and services like urlfetch. This means that we’re not “locked-in” with App Engine. The App Engine API is structured in such a way that we’re able to extend any web framework we want with App Engine components that help us scale.

SpotCloud Success

Since announcing the SpotCloud private beta at the end of last year, we’ve been overwhelmed by the amount of interest we’ve gathered, and have had large numbers of service providers from all over the globe join our beta. We now have more than 10,000 servers from 40+ countries represented in the marketplace.

Since we opened the marketplace to buyers and sellers early in 2011, the market has been off to a roaring start — as noted by The Economist, ComputerWorld, and many others. Google App Engine has performed up to our (high!) expectations, serving an ever-increasing transaction rate in the market without a hiccup. We’re looking forward, as the market ramps up even further, to seeing if we can make App Engine break a sweat! Sign up today as a cloud capacity buyer or seller at www.spotcloud.com.

Dev Tip of the Week: How to search by driving time with AJAX v7, REST, and Spatial Data Services

The recently released Query API within the Bing Spatial Data Services makes it easy to build applications that enable searching for locations by area, by property, and by ID. A common scenario is the ‘Locator’ application, in which end-users enter an address, and find the locations that are nearest to them. We can easily cater for this in Bing Maps by geocoding the end-user’s address with the Locations API, and then finding nearby locations with the Query API to Query by Area.  Using a spatial filter, we can find the locations that sit within a specified radius of the given location, and present the results ordered by distance ‘as the crow flies’.

But what about those cases in which geography or other considerations mean that the closest location by straight line measurement will actually take much longer to drive to than one of the other locations? For example, if you are in the Upper West Side of Manhattan, NY, the nearest location by straight line distance might be across the Hudson River in New Jersey. But actually getting there will require you to drive or walk quite some distance in order to cross a bridge over the river.

It would be much quicker to make your way to a location in Manhattan that might be a bit further by straight-line distance, but doesn’t require you to cross any rivers.

So how can we help our users identify the locations that will take the least amount of time to get to? We can reorder our results by driving time before we present them to our end user. By using the Query API to obtain a set of locations in the vicinity of our user, then using the Routes API to determine how long it will take to drive to each of our nearby locations, we can guide our user to our locations which will be quickest for them to get to.

Reordering Results by Driving Time

The key step here will be the reordering of our results so that they are presented in order of least driving time, and doing this without making separate Routes API requests for each location. We achieve this by constructing a multi-point route request, going from the search origin (our user’s location) to each of the locations in our Query API result set and back. The Routes API supports up to 25 waypoints per route request, so we could use this technique to determine the driving distances for up to 12 locations in a single request. We can use the resulting drive time (or drive distance) of each leg of our route to reorder our locations before presenting them.

Sample Application

Included below is code for a basic application that combines the Bing Maps AJAX Control v7, the Query API, and the REST Locations and Routes APIs, to enable a fully client-side locator scenario in which we present our results based on driving time.

At a high-level, the application will:

  • Capture a user address, and geocode it via the Locations API
  • Take the latitude and longitude from our geocoded location, and use the Query API with a spatial filter to find the nearest 5 Fourth Coffee Shops to the user address
  • Generate one multi-point route request that goes from our geocoded location to each Fourth Coffee Shop and back
  • Reorder our results based on the driving distance from the geocoded location to each Fourth Coffee Shop
  • Present the reordered results to the end user on a map using the Bing Maps AJAX Control v7

To optimize performance, we limit the result set to 5 locations, but to reduce the chances that there are other stores that might be closer by driving time than the 5 that are presented, we could also consider retrieving 10 results from the Query API, reordering them by drive time, then presenting only the top 5 from our reordered result set.

Here is the code. To view and use the code, developers will need to obtain a key and insert that key into the placeholder within the code sample.