IT Lesson

One of the big focuses of this blog (and the team behind it) has been providing compelling examples of how integration with Google Apps APIs can make a product richer and more engaging. As a part of this effort, earlier today we announced Au-to-do, a sample application built using Google APIs.

Au-to-do is a sample implementation of a ticket tracker, built using a combination of Google App Engine, Google Cloud Storage, and Google Prediction APIs.

In addition to providing a demonstration of the power of building on Google App Engine, Au-to-do also provides an example of improving the user experience by integrating with Google Apps. Users of Au-to-do can automatically have tasks created using the Google Tasks API whenever they are assigned a ticket. These tasks have a deep link back to the ticket in Au-to-do. This helps users maintain a single todo list, using a tool that’s already part of the Google Apps workflow.

We’re going to continue work on Au-to-do, and provide additional integrations with Google Apps (and other Google APIs) in the following months.

To learn more, read the full announcement or jump right to the getting started guide.

Dan Holevoet   profile Dan joined the Google Developer Relations team in 2007. When not playing Starcraft, he works on Google Apps, with a focus on the Calendar and Contacts APIs. Hes previously worked on iGoogle, OpenSocial, Gmail contextual gadgets, and the Google Apps Marketplace.

When a file of a common type is uploaded to Google Drive, it is automatically indexed so users can easily search for it in their Drive files. Google Drive also tries to recognize objects and landmarks in images uploaded to Drive.

For instance, if a user uploaded a list of customers as an HTML, XML, PDF or text file he could easily find it later by searching for one of its customer’s name that is written inside the file. Users could also upload a picture of their favorite green robot, then search for “Android” and Google Drive would find it in their Drive:

Searching for “Android” finds images containing the Android logo.

Metadata such as the file’s title and description are always indexed so users can always find a file by name. However, Google Drive does not automatically index the content of less common or custom file types. For example if your application uploads or creates files using the custom MIME-type custom/mime.type, then Drive would not try to read and index the content of these files and your users would not be able to find them by searching for something that’s inside these files.

To have Google Drive index the content of such files you have to use one of the following two options available when uploading files through the Google Drive API.

useContentAsIndexableText URL parameter

We recently added a way for you to indicate that the file you are uploading is using a readable text format. In the case where your file data format is text based — for instance if you are using XML or JSON — you can simply set the useContentAsIndexableText URL parameter to true when uploading the file’s content to Drive. When this flag is set Google Drive will try to read the content of the file as text and index it.

indexableText attribute

There is a more flexible approach which is to set the indexableText attribute on the File Metadata. You can set the value of the indexableText attribute which is a hidden — write-only — attribute that we will index for search. This is very useful if you are using a shortcut file — in which case there is no content uploaded to Google Drive — or if you are using a non-text or binary file format which Google Drive won’t be able to read.

Have a look at our Google Drive API references or watch our latest Google Developer Live video about the topic to learn more.

Nicolas Garnier Google+ | Twitter Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate for Google Drive and Google Apps. Nicolas is also the lead engineer for the OAuth 2.0 Playground.

What’s the difference between reality and theory? In theory, there is no difference. But reality often imposes unanticipated constraints on developers. These may come in the form of bandwidth restrictions, memory limits, timeouts, or other requirements of the systems that interact with your application.

My team recently built an application that helps us analyze the scheduling and usage of conference rooms at Google. We use the new Calendar API v3 on Google App Engine to read the rooms’ schedules, which we combine with actual occupancy data to calculate utilization and other metrics.

As you might imagine, Google has a lot of conference rooms (I believe the last official count was “more than twelve.”) And many of the rooms seem to be booked fairly solid. That means we need to read a lot of data from Calendar. So much, in fact, that our queries time out if we try to read an entire calendar at once. But the API team anticipated “Google scale” use and designed a mechanism that allows us to retrieve data in batches.

The idea is simple. When you create a request, you specify the page size: the maximum number of results you’d like Calendar to return in one batch. Calendar returns the data you requested, along with an opaque page token, which you can think of as a bookmark. To retrieve the next batch of data, you ask the API for the next page token and include the new token in your next request. The page token keeps track of the results you’ve already seen, so Calendar can send the next batch each time. You repeat this process until you’ve exhausted all the results.

Here’s how we did this in Java:

public void getRoomEvents(String roomEmail) throws IOException {
    // Create a request to list this room’s events (see code, below)
    Calendar.Events.List listRequest = getListRequest(roomEmail);
    do {
      // Retrieve one page of events
      Events events = executeListRequest(listRequest);
      List eventList = events.getItems();

      // Process each event
      for (Event event : eventList) {
        processEvent(event);
      }

      // Update the page token
      listRequest.setPageToken(events.getNextPageToken());

    // Stop when all results have been retrieved
    } while (listRequest.getPageToken() != null);
  }

  // Create a request to list the events for a room
  private Calendar.Events.List getListRequest(String roomEmail)
        throws IOException {
    return calendarClient.events().list(roomEmail)
        .setMaxResults(1000) // Limit each response to 1000 events
        .setPageToken(null)  // Start with the first page of results
        // Return an individual event for each instance occurrence of a
        // recurring event
        .setSingleEvents(true); 
  }

We call getRoomEvents() for each room, using the room’s email address to identify it to Calendar. (You can retrieve events from your own calendar by substituting your own email address.) Then getListRequest() creates a request that we will send to Calendar. The request asks for a list of up to 1000 events from the room’s calendar.

The remainder of getRoomEvents() is a loop that executes the request, processes the results, and updates the page token in preparation for the next request. The loop continues, retrieving and processing each subsequent page of results, until the entire list has been returned. The call to getNextPageToken() indicates the end of the results by returning a null value.

By paginating our requests we avoid timeouts and reduce memory requirements. As an added benefit, each request completes fairly quickly, which means it’s also quick to retry if an error should occur. And finally, a multithreaded application may be able to process one or more pages of results while it retrieves the next, speeding execution. These advantages have led developers at Google to adopt pagination as a best practice. Look for it in our APIs when you need to exchange large amounts of data, and consider adding it to your own services.

If you have questions about our services or APIs, or if you want to see what other developers are doing with Google Calendar, check the discussions and documentation in the Google Apps Calendar API forum.

Adam Liss profile Adam is an engineer who believes that "technical" shouldnt necessarily mean "difficult." He enjoys building infrastructure and tools that make Googlers more productive. Before joining Google in 2010, he built network-security appliances and one of the first wireless application delivery platforms.

We are announcing the deprecation of SWF export functionality for presentations from the Google Documents List API. We are taking this action due to the limited demand for this feature, and in order to focus engineering efforts on other aspects of the API.

Clients currently making the following request to the API are affected by this change.

https://docs.google.com/feeds/download/presentations/Export?docID=1234&exportFormat=swf

We recommend clients currently using SWF exports switch to PDF exports, using the appropriate exportFormat value.

https://docs.google.com/feeds/download/presentations/Export?docID=1234&exportFormat=pdf

We are disabling SWF exports in the coming weeks. Clients attempting to export presentations as SWF after the exports are disabled will receive an HTTP 400 response.

For more information on exporting presentations, see the Google Documents List API documentation. If you have any questions, feel free to reach out in the forums.

Vic Fryzel   profile | twitter | blog Vic is a Google engineer and open source software developer in the United States. His interests are generally in the artificial intelligence domain, specifically regarding neural networks and machine learning. Hes an amateur robotics and embedded systems engineer, and also maintains a significant interest in the security of software systems and engineering processes behind large software projects.

1. To make an actual presentation (e.g. using PowerPoint for what it was meant to be used for)
2. To make printables for your classroom (e.g. the "teacher" way to use PowerPoint! lol!)

"The 30-minute masters originated from a discussion between Cammy Bean and myself (Clive Shepherd) at the Boston eLearning Guild Annual Gathering earlier this year. We set out to develop a curriculum that could teach subject experts and generalist trainers the essentials of instructional design in just 30 minutes (The 30-minute masters will be presented at DevLearn 2007) ...more "

• Module I: Prepare
  1. Set a realistic goal.
  2. Consider the content from the learners point of view.
• Module II: Inform
  3. Hook learners in emotionally.
  4. Present your material clearly, simply and in a logical order.
  5. Illuminate your material with imagery.
  6. Consider using audio.
• Module III: Consolidate
  7. Put your material into context with examples, cases and stories.
  8. Engage users with challenging interactions.
  9. End with a call to action.

(Click here to view the full course curriculum. Still under construction using a Wiki!)

REFLECTION TIME!
If you have time, please check out Father Guido Sarduccis Five Minute University, too. A great laugh with some great points! Anyone that has been through formal education would probably be able to relate to it. Interestingly and seriously, according to the authors anyone can build their own 30-minute masters course based in whole or in part on these materials provided on this site. If you wish you can even sell this course to others, but you should give KUDOS and recognition to the masterminds. Though, keep in mind it is still under construction.

One might be able to go through the Masters curriculum in 30-minutes, but I suppose it would take a longer time to be able to apply the lessons learned effectively (Process + Knowledge = Skills?). But overall it is a great idea and with such experts constructing or nurturing the curriculum it will be interesting to follow the progress. Since they are using a Wiki, we can also contribute.

Yes, I remember when I got my first job in the area of e-learning (2001). I was entitled Instructional Designer without any training. They asked me to read a few books, and get my hands dirty with a huge project. I struggled and suffered, but looking back at it, I realized that Learning-by-Doing (with guidance) is simply the best (at least for skills development, if possible) :)

Link to site & full report (PDF, 27 pages, 695K)
"The online enrollment projections have been realized, and there is no evidence that enrollments have reached a plateau. Online enrollments continue to grow at rates faster than for the overall student body, and schools expect the rate of growth to further increase:

• Over 1.9 million students were studying online in the fall of 2003.
• Schools expect the number of online students to grow to over 2.6 million by the fall of 2004.
• Schools expect online enrollment growth to accelerate ? the expected average growth rate for online students for 2004 is 24.8%, up from 19.8% in 2003.

Are students as satisfied with online courses as they are with face-to-face instruction?

• 40.7% of schools offering online courses agree that students are at least as satisfied? with their online courses, 56.2% are neutral and only 3.1% disagree.
• Medium and large schools strongly agree (with less than 3% disagreeing).
• The smallest schools (under 1,500 enrollments) are the least positive, but even they have only 5.4% disagreeing compared to 32.9% agreeing.
• Doctoral/Research, Masters, and Associates schools are very positive, Specialized and Baccalaureate schools only slightly less so."

Read the summary (at least) or the full report . This report is excellent (27 pages), and gives us insight to the e-learning or online education state and progress in U.S. higher education.

• Link to Maps-of-War
• Link to History-of-Religion

MAPS-OF-WAR?
Maps-of-War is a multimedia site dedicated to producing diverse, creative visuals that enhance our understanding of war and its history.

HISTORY-OF-RELIGION?
How has the geography of religion evolved over the centuries, and where has it sparked wars? This animated map gives you a brief history of the worlds most well-known religions: Christianity, Islam, Hinduism, Buddhism, and Judaism. Selected periods of inter-religious bloodshed are also highlighted. Here is 5,000 years of religion in 90 animated seconds:

OTHER MAPS?

• Leadership-and-War
  Which Presidents have led the United States into its deadliest wars?
• Imperial-History
  Who has controlled the Middle East over the course of history?
• Iraqi-Pressure-Vault
  From a geographic standpoint, Iraq is caught between a rock and a hard place...
• Signs-of-Occupation
  Before / after satellite photos of Saddams palace in Baghdad, Iraq...
• Shiite-vs-Sunni
  The pieces of the puzzle are slowly aligning themselves as Iraqs sectarian divide widens...
• CIA-Secret-Prisons
  Anatomy of a secret prison...
• Recapture - of - Fallujah
  In November of 2004, American forces launched Operation Phantom Fury to recapture Fallujah...

In addition, I would not be surprised if more animated maps will be added in the near future.

DOWNLOAD?
Every Maps-of-War animation is available for download so that you can play it on your own computer, even without an internet connection. Maps are provided in Flash SWF Format (.swf).

These Maps-of-War animations are also excellent tools to engage (or motivate) students into thinking and kick-start discussions in your face-to-face or online sessions (as long as they are related in one way or the other to the subject or topic you are teaching/facilitating). Finally, these visual maps should also facilitate great discussions on whether they are really accurate or not :)

Click here to view full article

• Gotcha # 1: Where?s the Data? Can you get it? (Define your reports up front & get quality data)
• Gotcha #2: Extensive Customizations (Risk of Extensive Customizations such as 1. Lengthens the implementation by months or more, 2. Often costs more than they are really worth in terms of business value 3. Makes upgrading difficult if not impossible without "re-doing" the work).
• Gotcha #3: Lengthy Projects (The most effective way to deliver value from your investment is to get the system up and running as soon as possible)
• Gotcha #4: Conflicting Requirements (Pleasing Everyone Pleases No One).

"Producing a clear project plan and ensuring tight control of the requirements will help you avoid most, if not all, of these issues."