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.

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.

Polymer in a corporate network

(a.k.a. The Things You Do For Money)

Working as a developer in a non-tech company can be challenging since usually the corporate IT infrastructure and regulations aren't designed for developer tasks but for day-to-day office business. So when I took over some new responsibilities at work and had the chance to finally include Polymer in some internal web projects (with the biggest stopping point of IE8 finally gone) I had some hurdles to overcome to make use of the full Polymer-related tool chain I've come to love for my private projects.

1. Microsoft Windows

The main OS in big corporations (at least in Austria) is still Microsoft Windows and usually you can't just install another OS on company hardware. However, as it turns out, all the tools needed are readily available on Windows, so it might be a unfair to list it among the problems. Consider this part mainly as a summary of what I use for developing with Polymer.

Node.js (with all web development tools being Node-based these days) is pretty well supported across all platforms. It comes with npm as package manager that lets you install other tools you will need like Bower or Gulp.

Git (for fetching Bower dependencies) has a Windows installation that also comes with a bash emulator, that is so much nicer to use than the Windows command prompt.

As for text editors you have a wide variety to choose from, personally I like Sublime Text but have also used Notepad++ quite frequently.

2. Group Policies

Having installation files available for Windows is nice, but you might not actually be allowed to install non-standard applications on your PC thanks to all settings and permissions being managed through Active Directory and Group Policies. If you are nice to your local IT department they might make an exception and give you local administrator rights or install custom applications for you, and luckily I have a very nice local IT department ;)

But in many cases not even the local IT department can help you, depending themselves on a global team that manages all permissions, and then you will have to start looking at portable solutions that you can simply put anywhere you want without having to install anything.

Here's one possible approach to put your whole development environment on an USB stick.

1. Download the latest version of PortableGit and "install" = extract it to any location you want.
2. Create a usr/local/bin folder in the same location
3. Download the latest node.exe (from win-x64 or win-x86), which is all that Node.js needs to run, and put it in usr/local/bin folder you just created.
4. Download the latest npm release and extract it into usr/local/bin/node_modules/npm/
5. Copy npm and npm.cmd from usr/local/bin/node_modules/npm/bin/ to usr/local/bin

Your final folder structure should look something like this:

When you run git-bash now you can already use npm to install Bower and any other node modules you may want to use with npm install -g bower

With the default settings PortableGit still has some issues though, the biggest one being that it is not truly portable with some global config settings being written to $HOME which defaults to C:/Users/YourUser

To solve this issue you will need to create a /home/YourUser folder in your PortableGit location. To prevent messing around with the default config scripts (which will be overwritten when updating PortableGit) you can create a batch file to temporarily (so we don't mess up other applications that need the %HOME% environment variable) set HOME to that folder before starting git-bash.

setlocal
set HOME=%~dp0home\%USERNAME%
git-bash.exe
endlocal

You can have different settings for different usernames that way, or if you prefer hard-code the username in the batch file so it will always refer to the same home folder.

Some bower commands (especially bower init) and probably others sometimes have problems with Mintty that the current version of git-bash uses as terminal emulator, so sometimes you might have to use bash.exe directly. You can use another batch file for that.

setlocal
set HOME=%~dp0home\%USERNAME%
bin\bash.exe -login -i
endlocal

3. Corporate Firewall

With all of this set up, you might already have stumbled across another problem in the previous step when trying to run npm install -g bower since the corporate firewall most likely blocked that request.

git, bower and npm all observe the http_proxy and https_proxy environment variables so once you know which proxy to use (easiest by looking at the Internet options IE) you can set those with

export http_proxy=http://company-proxy:port
export https_proxy=http://company-proxy:port

And so you don't have to do this every time you should create a .bashrc file in your /home/YourUser folder and put the commands in that file, which will be executed everytime you start bash.

Hint: since Windows gets easily confused with dot-files the easiest way to do this is via git-bash like this:

cd ~
touch .bashrc
notepad .bashrc

And with this I'm all set to bring Polymer goodness to the company, let's see where this journey takes me. I'll expect some more blogposts along the way :)

Polymer Quicktip - Attributes vs. Properties

A recurring problem that people starting with Polymer 1.0 or migrating from earlier version seem to have is the new property name to attribute name mapping.

This issue imho comes mainly from the fact that the element docs generated via iron-component-page only list the JS property names, but in many/most cases you will use the HTML attribute names in your markup that aren't listed anywhere.

Example from the google-signin element:

If you try to include this element in your page like this

<google-signin clientId="MY_CLIENT_ID"></google-signin>

it won't work because the clientId attribute will be mapped to a clientid property that doesn't exist and clientId will stay undefined.

The correct way to use the element would be:

<google-signin client-id="MY_CLIENT_ID"></google-signin>

So if you encounter issues with properties not getting the value you intended make sure your attribute names are correct.

Essentially the attribute name is converted to lower case first, and then dashes are converted to camelcase, SoMeThInG becomes something and SoMeThInG-ElSe becomes somethingElse.

For those interested, here's the part of the Polymer library that takes care of translation between attribute names and property names:
https://github.com/Polymer/polymer/blob/master/src/lib/case-map.html

And if you are really curious you can have a look at Polymer.CaseMap._caseMap to see what mappings are being used on your site.

Polymer Quicktip - debounce

One of the more hidden features of Polymer is the possibility to "debounce" multiple requests into one function invocation.

This is useful if you have a compute- or time-heavy function that depends on several (published) properties and needs to be executed when those properties get a new value, e.g. if you need to create a new ajax call depending on several parameters.

Here a simple sample to demonstrate this behaviour.
First the element without debounce:
Including this element as <without-debounce property1="foo" property2="bar"></without-debounce> will trigger the function twice when the element is first loaded, and even if you change both properties at the same time you still get two function calls.

Here the same element with the debounce functionality added:
Using this element the console.log will only be called once when the element loads and also only once when properties get changed during a definable time (300ms in this case). This causes a small, but mostly ignorable delay before the actual execution of the function.

An element that uses this functionality is the iron-ajax element to prevent executing the actual request until all properties have "finalised".

I'm using the same behavior for the same reason in my discovery-api-elements.