Google Genome project Continues world domination

Google has continues to invest in projects other than what advertisements to post when someone searches for LOLcats by throwing the weight of it’s giant stacks of cash at Harvard’s George Church.

Dr Church plans to spend $1 billion to tie DNA information to each person’s health history in an attempt to create a database for finding new medicines. His credentials are high as he helped develop the first direct genomic sequencing method in 1984.

It’s good to see the heavyweights of the tech industry to contribute to the overall science community. American science has been suffering in the last few years even as interest in technology has been on the upswing and this type of investment can only help in the long term. Unfortunately, share holders are only willing to go along with these kinds of investments for so long before they get antsy.

Source- http://www.gadgetell.com/tech/comment/google-invest-in-genome-project-continues-world-domination/

Read More..

5 more tips for using Google Buzz on your phone

Last week we shared some tips for getting the most out of Google Buzz for mobile. Were back with more ways to help you become a power buzz poster and find the most interesting buzz while youre on the go. Try these 5 tips for the Google Buzz for mobile web app (buzz.google.com) on your iPhone or Android 2.0+ device.

1. Post buzz with your voice.
You can post your public buzz simply by speaking it. From the Google Mobile App for iPhone or Quick Search Box on Android, select the voice search icon, say "post buzz" followed by the text youd like to post, and watch your words appear. Before your post is sent, youll be able to edit it or change its tagged location.

2. Filter the Nearby tab for a specific place.
From the Nearby tab, you can easily filter buzz by a specific place, such as a sushi restaurant youre about to walk by, to only see posts from that place. Open the menu showing nearby places, for example "Tartine Bakery and 20+ other locations nearby," and then select a specific place from the list. Now, youll see all the public buzz anyones ever posted from that place or you can quickly create a post that is tagged with the place. To go back, just open the same menu and select your current location shown with the blue dot. Youll once again see all the recently posted buzz around your location.

3. Search!
As youd expect from any Google product, Google Buzz for mobile has a powerful search feature that lets you search all public buzz for topics that interest you. Open the menu or just select the magnifying glass icon to see the search bar. You can also search specifically for nearby posts by checking the "Search nearby" box before submitting your search (its already checked if youre in the Nearby tab). Now you can find out what people around you are saying about the closest pizza spot or a traffic jam.

4. Post from your city-level location.
Tagging a post with your location is easy and adds context to your buzz posts. Sometimes, your post isnt about a specific place or youd rather not share your exact location. You can easily show your city-level location, so your post has a general city location tagged and will be browsable in the Nearby view and Maps Buzz layer. When posting, just select the ">" in the location box, scroll down, and select the city-level location option.

5. Refresh your location.
On the other hand, sometimes you really want your location to be exact. When you visit the Nearby tab or want to tag your post with a location, Google Buzz will try to get your location using your phones GPS. If youre not happy with the location accuracy, youre moving, or youre just stepping outside to get a GPS signal, hit the refresh icon to tell the Google Buzz web app to get your location again. You can also learn more about troubleshooting location problems.

Stay tuned for more tips! Visit our Help Center to learn more or tell us your feedback and questions in our Help Forum. You can also give us suggestions and vote on other people’s on the Mobile Product Ideas page.


Posted by Chris Nguyen, Product Marketing, Google Mobile

Read More..

My summer with the Google App Engine Team

Today’s post is contributed by our Summer 2011 team intern, Chris Bunch. Chris did some great work on our Logs and MapReduce APIs and is also the first “App Engine Triple Crown” winner for developing the Experimental Logs Reader API in Python, Java and Go simultaneously.

Four years ago, I was a brand-new Ph.D. student at the University of California, Santa Barbara and when our research group (the RACELab) heard about Google App Engine, we were intrigued. We thought it presented a new model that enabled apps to scale the right way without severely constricting the types of programs users would write.

But we wanted to experiment with the core functionality of App Engine: the APIs, the scheduler, etc., and so we built AppScale, an open-source implementation of the Google App Engine APIs that allows users to deploy applications written in Python, Java, and Go to the infrastructure of their choice.

Wherever possible, we implement support for the App Engine APIs with alternative open-source technologies. We’ve added support for nine different databases, database-agnostic transactions, a REST interface that users of any programming language can communicate with (via an App Engine app), and the ability to run high performance computing programs over the whole thing and talk to it from your App Engine app. And here’s my favorite part - it all deploys automatically! You don’t need to tell it what block size you want for the distributed file system, or the size of the read buffers: we configure the necessary services automatically. Since AppScale is completely open source, if you don’t like the defaults, change them!

After creating our own system to run Google App Engine apps, I wanted to see how Google does it. Therefore, I decided to become an intern on the App Engine team and see if I could give them (and by extension, the App Engine community) something amazing over the summer. I started off with some work on the MapReduce API, making the sample app much easier to use and prettier all around. I also made a YouTube video showing how it all works and how easy it is to run MapReduce jobs over App Engine.

I then looked at a recurring question that App Engine users encounter: “How can I get my logging information for my application to answer data analytic questions?” It was an excellent problem to tackle, as we have users who want to be able to determine application-specific queries that Google Analytics or the Admin Console don’t answer. Currently users have to use appcfg to grab all their application’s data to a remote machine and run some analysis script over it.

To solve this problem, I created the Logs API, which gives applications programmatic access to their logs from within App Engine itself. Applications can use it to query small numbers of logs within a single request, and they can utilize the Pipeline, MapReduce, or Backends APIs if they have lots of logs they want to analyze. Logs contain both request-level information (e.g., the URL accessed, the HTTP response code returned) as well as logging info generated by the application (the logging module in Python, the Logger class in Java, and the logging methods that Go’s appengine package provides). The Logs API is available for use as of App Engine 1.6.1 by programmers using the Python, Java, or Go runtimes, in both the production environment and the local SDK.

I had a great time putting the Logs API together, and had a unique experience interning with the App Engine team. Programming in Python, Java, and Go on a daily basis was an exciting new challenge, and I loved it! 

Interested in interning with the App Engine team? Check out google.com/students for more information on internships.

Read More..

TweetDeck and Google App Engine A Match Made in the Cloud

Im 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.

Were 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 didnt 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. Were already extending our mailing system to use App Engines 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 weve 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 doesnt have to mean everything runs on it. Its 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 weve 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 Tweetdecks install base grows. Thanks to App Engine and the cloud, theres nothing holding us back from tackling the needs of our user base.

Here is a video interview of Reza and the Tweetdeck team.

Guest Post by Reza Lotun @rlotun, TweetDeck

Read More..