Thursday, May 4, 2017

Doing more with your Google Location History

With the discontinuation of the Google Latitude API several years ago some nice third party tools to visualize your location history disappeared, which at that time triggered me to look into what can be done with Google Takeout data. The result was the location_history_json_converter (or latitude_json_converter as it was called back then) which thanks to several contributions from the open source community has turned out to be a rather useful and powerful tool to prepare your takeout data for further manipulation and visualization.
Since I've recently used the tool myself again for a travel report (more about this below) and I never actively promoted or explained the tool, I've decided to put together this blog post to tell you about the tool and some samples of what can be done with it.

Monday, March 13, 2017

Polymer in Production

When I was tasked with including new functionality into an existing, rather big internal web application, I found myself in a bit of a dilemma.

For my own personal projects and several other internal projects I did at work, I have grown to love web-components using Polymer because of the ease of development and the natural way to structure applications into (re-usable) parts.

The existing web application in question had been mainly developed with a once (and still) very popular library that shall not be named.

A full rewrite of the application was out of question due to time and budget restraints, but using Polymer would have a lot of benefits for the future as far as testability, maintainability and extensibility are concerned.

In this blog post I will go over some of the things I did and had to consider to make this work.

Wednesday, August 10, 2016

PolymerCubed

I've recently started using Microsoft SQL Server Analysis Services for reporting purposes at work, and while querying the cubes worked great, the visualization options were rather unsatisfactory, especially when it came to building web-based dashboards.

And while there are several vendors offering solutions in this area, I decided to give it a try myself and started creating a suite of Polymer elements.

Wednesday, May 25, 2016

I/O 2016

I/O 2016 is over again already, so it's time to sum up my thoughts about what I/O brought for developers and what announcements/updates you should check out.



Monday, April 18, 2016

Polymer and the [hidden] attribute

The hidden attribute is a "fairly new" convenience attribute (fairly new = not implemented in IE<=10) to hide page elements that are not relevant in the current context/state of the website.

It is especially useful in a Polymer web app, since you can use attribute binding to show/hide elements based on (computed) properties, without having to make your own display: none; styles.

There are several cases where you will have to be careful with this attribute though.

Tuesday, March 8, 2016

Polymer on Blogger

I've had some fun over the past few weeks to force Polymer to work on Blogger, or rather to force Blogger to work with Polymer, and here are my results, some of which might be more useful than others.

A quick disclaimer before we get started:
This post definitely falls more into the "because I can" category than in the "because you should" category, and would need some extensive testing and tweaking before being used out in the wild.

Thursday, February 11, 2016

I See... People

To get a better understanding of the new Google People API I created a small (of course Polymer-based) demo, since playing around with the API Explorer can be cumbersome.

https://scarygami.github.io/people-api-demo/

This demo will fetch one "page" of results from the people.connections.list method and display the raw JSON for each contact.

You can then click on "load full data" to fetch the rest of the contact information via people.get for each contact.



Source code for the demo is available if you want to play around some more.

The demo makes use of my discovery-api-elements element, that I should really get around to write a more detailed article about, since, if I may say so myself, this is an awesome way to easily access all of Google's discovery-based APIs and your own Google Cloud Endpoints.



Some takeaways from what I've seen so far in no particular order.

The "resourceNames" are interesting

If you want to fetch the data for a Google(+) account, instead of just using the numeric ID, you will have to use people/ID
This is easy enough to get used to, but makes you wonder what other resources they might have planned to include in this API.

The data structure is confusing to look at

To be fair JSON isn't really meant for human consumption, but to be able to work with it programmatically you first have to understand it.

Each person has one or more sources where the data comes from.
In most cases there will be two:
  • CONTACT from your Gmail contact information
  • PROFILE from the public Google(+) profile.
{
  ...,
  "metadata": {
    "sources": [
      {
        "type": "CONTACT",
        "id": "gmail_id"
      },
      {
        "type": "PROFILE",
        "id": "gplus_id"
      }
    ],
    "objectType": "PERSON"
  },...
}

For each "type" of data (e.g. names, photos, urls, emails, phone numbers, ...) the response will have an array, and each item in this array comes with metadata to show which source the information comes from. While this makes perfect sense for easily parsing and displaying the information programmatically it results in a rather lengthy JSON response. This block here is only for two email addresses:

{
  ...,
  "emailAddresses": [
    {
      "metadata": {
        "primary": true,
        "source": {
          "type": "CONTACT",
          "id": "gmail_id"
        }
      },
      "value": "email1@gmail.com",
      "type": "other",
      "formattedType": "Other"
    },
    {
      "metadata": {
        "source": {
          "type": "CONTACT",
          "id": "gmail_id"
        }
      },
      "value": "email2@somewhere.com",
      "type": "other",
      "formattedType": "Other"
    }
  ],...
}

Google+ profile images are broken

A bug that will hopefully be fixed soon, but for now the profile photo URLs  that come from PROFILE give a 404. Interestingly profile photo URLs from CONTACT work, as do cover photo URLs.

No access to "private" profile data even if you are allowed to see it

That was one of the biggest problems with/complaints about the Google+ API's people.get method as well. Even if you are using authenticated calls you only get the public Google+ profile information which doesn't include the private/limited data you might see when visiting someone's Google+ profile. Unfortunately that hasn't changed with this API...

No Google+ contacts

The people.connections.list method only shows Gmail contacts, and none of your Google+ contacts even if the plus.login scope is included in authentication. So if you want to work with Google+ contacts you will still need to use the people.list method of the Google+ API. And then you might as well use the people.get method of the Google+ API to get the rest of the information as well. The one benefit you get with people.get in the new API, is that any private information that has been added via Google Contacts will be displayed along with the Google+ profile information.

No more GData!

And after all my complaints one positive thing to say as well. If you've been using the old GData Contacts API you should switch to this new API asap. I think everyone who has been forced to work with GData will be happy to never see it again ;)




So to summarize my thoughts:

Great replacement for the old Contacts API, not really adding much value when working with Google+ contacts.

Curious to see what further features (if any) are planned for this API.