SearchJanitor.updateFTSStuffForGuestBookEntry(this);
SearchJanitorUtils.getTokensForIndexingOrQuery(...);
List searchResults = SearchJanitor.searchGuestBookEntries(searchString, pm);
StringBuffer queryBuffer = new StringBuffer();queryBuffer.append("SELECT FROM " + GuestBookEntry.class.getName() + " WHERE ");Set queryTokens = SearchJanitorUtils .getTokensForIndexingOrQuery(queryString, MAXIMUM_NUMBER_OF_WORDS_TO_SEARCH);List parametersForSearch = new ArrayList(queryTokens);StringBuffer declareParametersBuffer = new StringBuffer();int parameterCounter = 0;while (parameterCouter < queryTokens.size()) { queryBuffer.append("fts == param" + parameterCounter); declareParametersBuffer.append("String param" + parameterCounter); if (parameterCounter + 1 < queryTokens.size()) { queryBuffer.append(" && "); declareParametersBuffer.append(", "); } parameterCounter++;} Query query = pm.newQuery(queryBuffer.toString());query.declareParameters(declareParametersBuffer.toString());List result = (List) query .executeWithArray(parametersForSearch.toArray());
One of the many classes of application that App Engine facilitates building is online games, particularly collaborative ones. Games often start off small, but can see incredible growth rates as people convince their friends to join, and App Engine’s seamless scaling makes handling these sort of traffic spikes a breeze. Recently, we got together with Jay Kyburz, developer for the game Neptune’s Pride, and asked him a few questions about his game, and how App Engine has worked out for him.
Today we released version 1.3.3 of the App Engine SDK for both Java and Python. This is a minor release that includes changes and a few issue fixes for the datastore, administration console, and when deploying applications. For more information on all the changes, please read the 1.3.3 release notes for Java and Python.
Additionally, the Python SDK has a new experimental feature that gives you the option to use SQLite as the datastore stub backend. Using SQLite within the dev_appserver should speed up performance of your local datastore when testing on large datasets. (Note that this feature does not add SQL support to the App Engine SDK or service.) If you try out this feature, please give us your feedback on the App Engine Python users group.
1.3.3 is now available on the App Engine download page. As always, we welcome your feedback on the App Engine group.
Today marks a special day for us on the App Engine team. It was just forty-six years ago today that IBM announced the IBM System/360. As Wikipedia puts it, “It was the first family of computers designed to cover the complete range of applications, from small to large, both commercial and scientific.” One of the unique aspects of the S/360 was that customers could start with a small system while being confident that they could upgrade their system to scale to larger workloads without having to rewrite their application code.
We’ve come a long way since the days of 7.2MB disk drives and when systems with 256KB of main memory were considered large. Customers haven’t changed all that much though. Developers still want a platform which makes it easy to build, easy to manage and easy to scale their applications. That’s exactly what inspired us to build Google App Engine.
It was two years ago today that we launched App Engine to the first 10,000 developers. Those developers formed the start of today’s vibrant community of over 250 thousand developers. Each day your apps collectively serve over 250 million pageviews. Since it’s our Birthday we thought we’d share our traffic graph with you.
It all started on April 7, 2008 with the Python runtime. And, after a somewhat false start with the FORTRAN 77 runtime, we were able to successfully launch App Engine for Java, along with a number of other exciting features, on our first anniversary.
Those of you who have followed along closely know that we didn’t stop there. We’ve kept up the pace, launching a significant new feature almost every month since then. The datastore team has added everything from key-only queries, kindless queries, ancestor queries inside of transactions and query cursors to configurable datastore deadlines, opt-in eventual consistency and a whole new way of replicating data across data centers. Meanwhile the rest of the team hasn’t skipped a beat, delivering a number of new platform capabilities including Task Queues, XMPP support, incoming email and blobstore. We even affixed our own shipment of delete buttons to the Admin Console.
This is probably a good time to call out one of our recent favorites though. It’s an instrumentation library which provides great data and insights. It comes bundled with the SDK and can be easily enabled in your application. Of course we’re talking about Appstats. If you do one thing this week to celebrate our birthday and improve the performance of your app while helping to make the web faster, you should enable Appstats. You might be surprised what you learn about your own app or you might even win a t-shirt.
Of course it’s often the little things that count: API fetch from blobstore, expanded URL fetch ports, DoS API, IPv6 support, removing the 1000 row result limit, Java unit testing framework, custom admin console pages, Java app pre-compilation, datastore stats, wildcard domains, per request statistics in HTTP response headers, SDK dataviewer and stable unique id for users to name a few. If you saw something in that list you didn’t know about, be sure to read 10 things you didn't know about App Engine, visit the ever growing list of great App Engine articles, and, while you prepare for Google I/O 2010, be sure to review the excellent and highly informative App Engine sessions from previous years. The Java developers among you are of course already reading the App Engine Persistence Blog.
We want to take this opportunity to thank you for your tremendous support. Hearing your feedback is really important to us. It helps us stay on course. Your feedback has also helped drive the list of things we’re working on.
We know many of you like the big features and the new APIs we’ve launched. We have graphs that show you’re using them. But, we often don’t get enough detailed feedback on how you’re using these APIs, whether they’re working really well, or whether there’s room for improvement. Let us know how we’re doing. We’d love to hear what your favorite APIs are and how you use them, especially if you’re doing something interesting you think others might like to hear about. Also, tell us about your favorite little feature. What’s that one thing that made your life easier?
Please don’t mind the crumbs as we enjoy some cupcakes.
Posted by Fred Sauer, App Engine Team
I'm Reza and work in London, UK for a startup called TweetDeck. Our vision is to develop the best tools to manage and filter real time information streams like Twitter, Facebook, LinkedIn and MySpace. We offer products like our TweetDeck desktop client built on Adobe AIR, and our iPhone application. We are happy to say that we use App Engine as key part in our backend.
We're a small startup, so early on we started to look for tools that would give us the biggest bang for our buck. Combined with the fact we love Python, we thought it might be worth taking a look at what Google App Engine had to offer. The first feature we started playing with was the mail sending facility.
It was easy! Sending mail was a single call-- no messing around. Combined with the fact that it was sent via tried-and-tested Google Mail servers, this meant that we had a simple mailing solution where we didn't have to deal with spam blacklists, mail retries or SPF records. We could really see App Engine being our sole email provider for transactional emails (new users and forgotten passwords), but also for newsletter-type mailing.
When we got started, our existing backend was hosted on Amazon EC2 and SimpleDB, and we knew that we needed a way for the two systems to communicate with each other. App Engine provides all the basic tools to define any sort of resources you want--but more importantly, it has the Python standard library. We implemented a small mail API, with authentication provided by an HMAC-SHA1 of the request information and a shared secret key. The API has been made extremely general: its JSON input format contains fields to send messages to blocks of email addresses that are either defined in the request itself, or which exist as a template in App Engine (templates are defined as strings in a Python module).
The whole setup currently works quite well. We're already extending our mailing system to use App Engine's task queues-- exposing a number of queues to break large mailing jobs into a series of subtasks, thus spreading mailing sending over a large period of time. We have plans to make an even tighter bridge between our EC2 systems and App Engine, which involves keeping our subscriber list entirely in App Engine, and adding and removing from that list as appropriate.
We also use App Engine for various other prototypes and smaller applications that are part of our product. We use it to serve our "TweetDeck Recommends" feed, and we've even developed small tools to apply TweetDeck fan badges on Twitter homepage backgrounds using the Imaging API! The lesson from us, of course, is that using something like App Engine doesn't have to mean everything runs on it. It's an extremely good platform for creating APIs or smaller parts of your application that do specific tasks, and do them well. Think of it as the UNIX metaphor applied to the Cloud.
We love that we've been able to grow the functionality that Tweetdeck provides by progressively using more of the cloud. App Engine provides the perfect platform to compose new services quickly, iterate on them in production, and scale with demand as Tweetdeck's install base grows. Thanks to App Engine and the cloud, there's nothing holding us back from tackling the needs of our user base.
Here is a video interview of Reza and the Tweetdeck team.
Use promo code NEXT1720 to save $300 off general admission
Follow