I've been working on Google Apps and the Google Apps APIs since I joined Google less than two years ago and I recently got a review copy of one of the books available on this topic.
The book is called "Google Apps : Mastering Integration and Customization" and is published by Packt Publishing. It was only released a few months ago but it is actually the English version of a French book that came out one year ago. This can be noticed in some chapters that were not recently updated and, as you know, in a tech world that changes so quickly, it is pretty easy to stay a little behind. Also, a few screenshots are in French, but that is only minor nuisance.
The book is split into four parts, targeted to different audiences: senior executives, end users, system administrators and project managers respectively. Being a developer myself, I wish a bigger section for software developers was included, but the book is definitely not targeted at programmers.
The best audience for the book is composed of technical managers and executives that want to understand more about the cloud computing paradigm and its advantages in order to offer it or consider it for their internal IT department.
Part 1 (chapters 1-2) describes the basics of cloud computing and Google Apps in particular, and devotes a chapter to the reasons why Google can be trusted for what concerns data protection, reliability, and security in general. Chapter 2 is available for free and can be downloaded from the publisher's website.
Part 2 (chapters 3-6) covers the various Google Apps services, including Gmail, Calendar, Docs and Sites. Not all available services are described, but the Google Apps suite continues growing almost every day and it would be very hard to always stay on top of the news. Chapter 5 focuses on security features (e.g. Postini), while chapter 6 explores some of the possibilities for third-party developers to extend Google Apps, including the Google Apps Marketplace and App Engine for Business.
The third section of the book (chapters 7-11) explains how to manage a Google Apps domain and includes my personal favorite parts of the whole book, chapter 8. This chapter is devoted to setting up a Single Sign-On solution compatible with Google Apps, one of the most challenging tasks that many system administrators have to face when migrating to the cloud. I didn't find the rest of this section as interesting as chapter 8, as it covers the API, Chrome/ChromeOS and Android, and presents some Marketplace applications, but the authors didn't go deeper into the details (I guess for obvious space constraints).
The final part of the book (chapter 12-14) is devoted to implementing a proper migration strategy in order to jump into Google Apps. The three chapters respectively discuss the solution design, how to start with a pilot project and, eventually, how to perform the actual migration, including specific solutions for those coming from Microsoft Exchange or Lotus Notes.
In general, I'd recommend this book to those matching the target audience. If you are a system administrator or a project manager and don't know yet what this "cloud computing" thing is and why everyone is "moving to the cloud", this book can answer many of your questions. If you are a developer willing to integrate his application with Google Apps, this is probably not the best reference material you can get, but I'd strongly recommend you to get in touch with people in my team at Google (the Developer Relations team) and reach out to us on our forums.
An interesting developer event just ended and if you missed it (as I did), here is another opportunity to attend a great event in London.
Droidcon, the UK's largest Android-only developer conference, is coming to London on October 6-7 and two of my fellow Google Developer Relations team members, Nick Butcher and Richard Hyndman, are presenting on day 2.
Register before October 1st to save £25 on the ticket price, I'm sure that with a BarCamp-style conference on the first day and 5 topics (Development, Design, Business, Enteprise, Gaming) on the second you'll find plenty of amazing content on different aspects of Android development.
Now that I told the story of my hiring process, I can finally talk about what I've been doing in my 12 months at Google.
I spent the first four weeks in Mountain View for training and to meet my team, or at least part of it, as we also have members all over the world, from New York to Zurich, from Hyderabad to Sydney. As expected, I felt like drinking from the firehose with lots of new things and technologies to learn and I was totally overwhelmed at the end of the month when I went to Google I/O, for the first time and as a Googler!
I moved to London right after Google I/O and the first challenge was to find a place to stay. The company helped me and eventually I found a nice small apartment one train stop away from the office, very convenient and very expensive!
I was settled so I had more time to spend on my job and start my first 20% project, something I was looking forward to do since I joined Google. My project was to extend the open-source library called JetS3t to natively support Google Storage for Developers, which was announced only a few weeks earlier at Google I/O.
That was my first 20% project, my main job was (and still is) to empower developers that want to use the Google Apps APIs. In order to do so, I write code for the client libraries in many languages, interact with the community on forums, support customers with their coding questions or present at public event on Google technologies.
In September I went to Madrid to present at the DevFest, then in October I did the same in Munich, Moscow and Prague for the Google Developer Days and at the end of November I presented at the Dublin GTUG.
While not flying around to meet external developers, I was spending more and more time coding and I eventually found myself leading the Google API Client Library for .NET project (yes, we do .NET development at Google!).
Fast forward to the new year, which started with two trips to Mountain View to meet my team and plan the new activities, including the super-secret projects you are hoping to read about and that I'm not going to disclose!
Exactly one year ago I started working for Google so it's about time to look back at how this new life has been doing so far.
I came to Google after a very long hiring process. It's not usually like that, but it took 11 months for me to get from the first contact with the recruiter to the job offer.
Everything started on June 2009, when a Google recruiter saw my submission on the job site and sent me an email offering to schedule the first of a series of phone interviews for a Developer Programs Engineer position in Mountain View.
In my opinion, the phone interview went terribly bad, but apparently the interviewer disagreed with me and I was asked to setup a second phone interview with another Googler. I did that at the beginning of July and this time I was quite positive about the results.
And I was right, everything was going well and I was invited to fly to a Google office for the onsite interviews.
Actually, I thought everything was going well, but instead something went wrong. The position was filled by someone else and there was no open headcount for me so I had to wait and wait and wait...
I was on hold till December 2009, when the recruiter finally contacted me again for a new opportunity for the same position in London or Dublin. My preference was still for Mountain View, but you don't say no to Google, do you?
This time things moved faster and I went to Dublin for the onsite interviews right after Christmas, only to find one of the coldest winters in ages and have 3 out of my 4 flights cancelled due to the snow. I eventually made it to Dublin and went through 7 interviews, from 11.30am to 5.30pm!
I went back home tired but enthusiastic and I kept my fingers crossed for days, waiting for the response from the hiring committee. It took less than I was expecting to get the answer, and I'm here now, so you may easily guess what that answer was like
Well, I guess I'll talk about my first year at Google in the next post...
One of the side projects I worked on at the end of last year is the Google Developer Advocate Team page, a web application that provides bios for all members of my team and allows to track the public events we are going to attend.
We'll probably end up open-sourcing the code but I've already got questions about the technologies adopted so I decided to write this post to explain some of the design choices.
The application is written in Java and runs on App Engine, which provides scalability and simple deployment and administration.
One of the main requirements when designing the application was that it had to seamlessly integrate into our existing workflow in order to be as easy as possible for Google advocates to insert their events. Internally we use Google Calendar to track our trips and speaking opportunities so it was straightforward to use the Calendar Data API to fetch data from a shared calendar.
Advocates' profiles are stored in a Google Spreadsheet which we can internally update using a simple web form. The public page uses the Spreadsheets Data API to get the relevant pieces of information and display them.
Want to see your face in the Google Developer Advocates page? We are hiring!
It's always hard to find some time to write about my job at Google but I really want to tell you what my team and I have done last week as that makes me proud of them and the entire company.
I work in the Developer Relations team for Google Apps APIs and one of our tasks is to write and maintain the GData client libraries for the various languages supported, mainly Java, Python, .NET and PHP.
This obviously includes fixing bugs in the libraries and once in a while we plan a fix-it day, during which each team member ignores other tasks and focuses on fixing bugs. This is quite normal, but last week we decided to go one step further.
Instead of having a fix-it day we organized a fix-it week and added some Christmas spirit to it by setting an extra incentive: for each bug fixed 10$ (5$ from our manager and 5$ from Google) would have been donated to charity!
And since we all love games, we also put a special "prize" for the team member who fixed the highest number of bugs: that guy had to pick the non-profit organization that would get the money.
Those rules made everyone interested in fixing as many bugs as possible (i.e. more charity) but also created an healthy competition among us to be the one to choose the target organization.
At the end of the week, 31 bugs were fixed and 310$ were donated to Save the Children.
Many people believe that Google's motto "Don't be evil" is just a slogan, do you know of other companies where something like that could happen?
Merry Christmas everyone!
In the last two weeks I've been travelling around Europe to present at the Google Developer Days in Munich, Moscow and Prague (three amazing cities!).
The series of events was a great success with more than 3000 participants and lots of interest and good questions.
In the three cities I gave similar talks on the Google Apps APIs and how to integrate an application on the Google Apps Marketplace, here are the slides I used:
My talk in Prague was also filmed and is available on Youtube:
Google announced a lot of cool stuff at Google I/O, including Google TV, Android Froyo and App Engine for Business but it was another project that caught my attention and it is Google Storage for Developers.
Cloud storage is a huge business and many successful online services such as Dropbox, SlideShare or Twitter already use Amazon S3 for their storage needs. The idea is simple: you store your files on Google's infrastructure and access them from anywhere, paying only for what you use.
Google Storage is a RESTful service so it is possible to interact with it through the standard HTTP methods (GET, POST, PUT and DELETE) as explained in the Developer's Guide but it is much easier to rely on the client libraries which hide the complexities of the raw protocol.
A Python library can be downloaded from the project website but Google Storage also understands Amazon S3 protocol so that any existing tool for S3 can work with Google Storage with minor (if any) modifications.
Among all the toolkits for Amazon S3, JetS3t is probably the best known and most widely adopted. It is an open-source Java suite that officially added support for Google Storage in the recently released version 0.8.0.
JetS3t is released under the Apache License 2.0, so it is free for commercial or non-commercial use and can be modified as needed. Its source code can be downloaded from the project page on BitBucket where you can also find the instructions on how to build it or contribute to the project.
Using JetS3t to write a Java application that interacts with Google Storage is very easy. It is possible to connect to the service, create buckets and upload/download objects with less than 10 lines of code:
// Google Storage login credentials are required to manage GS accouponunts. GSCredentials credentials = new GSCredentials(ACCESS_KEY, SECRET_KEY); // To communicate with Google Storage use the GoogleStorageService. GoogleStorageService service = new GoogleStorageService(credentials); // To store data in GS you must first create a bucket, a container for objects. GSBucket bucket = service.createBucket("jets3t-test-bucket"); // Create a GSObject based on a local file File localFile = new File("my_file.txt"); GSObject localObject = new GSObject(localFile); // Upload the object to our test bucket in GS. localObject = service.putObject("jets3t-test-bucket", localObject); // Download the data object we just uploaded GSObject remoteObject = service.getObject("jets3t-test-bucket", "my_file.txt");
The GoogleStorageService exposes all the methods to manipulate the cloud filesystem and only takes a set of credentials to be instantiated. Besides the basic set of commands presented in the code snippet above, there are other methods to manage Access Control Lists or to copy/move/rename objects.
The source code distribution also includes a complete code sample that covers all the functionalities described in the Google Storage Developer's Guide.
Are you already thinking about the next big thing that can be built on top of this service?
It's time again for a series of Google events in Europe, where you can learn about the newest technologies and have the chance to ask questions to Google engineers.
Google Developer Days 2010 will be held in Europe in November according to the following calendar:
Registration for these three events will open on September 22nd so save the date because the available seats usually run out very quickly!
Next week we'll be also having a different event in Spain, the Madrid DevFest 2010. Unfortunately, registration for this event is already closed and there's no way to request extra seats, as it is full booked.
I just started my third week at Google as Developer Programs Engineer and I wanted to recap my experience so far.
You may have heard many stories on what working for Google is like, and many of them are actually true, but you won't know until you are inside, and that's exactly what happened to me.
When you start at Google, you have to attend the Noogler Orientation training sessions for one or more weeks, where you learn how things work (and a lot of secrets too!). In the meanwhile you have to understand how to move inside the huge internal documentation section and start a personal project.
One of the other advantages of working at Google is that you can attend to many Tech Talks on any kind of topics. Just to mention a few, in the two weeks I have been here I listened to Vint Cerf, the "Father of the Internet", and to Monty Widenius, the creator of MySQL.
What else? I'm having a lot of fun and eating too much. You already know about food at Google, don't you?