Tips & Tricks for Google Analytics (GA) + Google Tag Manager (GTM) + Accelerated Mobile Pages (AMP)

Setting up GTM + GA + AMP can be a “pull your hairs out” experience. So let me help you with this list of tips, tricks and pitfalls to avoid when setting up AMP with GTM and GA.

Event Logging in Google Analytics

So far the greatest pitfall has been with events. Events have 4 dimensions: category, action, label and value.

Now there is an article about events here https://support.google.com/analytics/answer/1033068?hl=en and it tells you that value needs to be an integer. But it doesn’t tell you what happens when you don’t adhere to value being an integer. What happens is that your event won’t get logged at all, even though your request to google analytics will get a 200 OK. It also doesn’t tell you, that having an undefined variable will result in the same problem. For example, if you have in GTM value = {{someValue}} , but someValue is undefined, the request being sent to GA is https://www.google-analytics.com/collect?…&ev=&… which results in the event not being logged.

Submitting information about a clicked element

Now in the regular tag manager, you get the Element Id / Click Id as built-in variable for clicked html elements. Not so for AMP. I thought you can’t transport information about a html element in AMP through GTM until I found this: https://github.com/ampproject/amphtml/blob/master/extensions/amp-analytics/analytics-vars.md

Somewhere hidden in the darkest corner of some github repository’s readme lies a very important information on how to send information about html elements: through the data-vars-* attribute. So for example you could use data-vars-event-id , which you could then use in GTM’s variables like so:

So the dash-case from the html attribute gets transformed to camel case for the variable configuration. Or as the they put it in the github doc:

The variables passed as data attributes should follow the format data-vars-*.

Example:

<span id="test1" class="box" data-vars-event-id="22"> Click here to generate an event </span>

And in the request url the token would be of the format ${eventId} (follows camelcase).

(BTW: I only stumbled on it by reading through https://github.com/ampproject/amphtml/issues/1298 . Reading through github issues is so much fun…)

Generic Click Trigger

To log every click as an event, you can use the following trigger in GTM:


Subscribe to stay posted.

AMP Project Starter

From the www.tsmean.com project, a nice little side project developed. The homepage of tsmean.com was built with AMP – Accelerated Mobile Pages. Those are pages that load freakishly fast on mobile, and hence also on the web. It’s actually really amazing for the user experience.

AMP has a quite great documentation with ampproject.org and ampbyexample.com. What was still lacking was how to build an actual website. In their example, they always only had single pages, so in order to build an actual website with multiple pages, you’ll have to do the work yourself. It’s not that it’s very complicated, after all it’s just some html and css. However, I found that I’d reuse the same basic setup on all of my amp pages and my friends started to use the same code as well. So I thought why not make an “Amp Project Starter” out of it? It gives you a working app out of the box. You can find more information about it here:

Forwarding Mail with EC2 (Ubuntu) and ElasticIP

Let’s assume you already have bought a domain – in this example we’re using tsmean.com – and you want to forward mail. You can replace all tsmean.com in this tutorial with yourdomain.com. So for example when sending an email to info@tsmean.com it should forward it to bersling@gmail.com. How can we achieve that? We can set up a mail forwarding server using an ec2 instance and postfix. To get started, create your ec2 instance, in this tutorial we’ll use Ubuntu. You can also reuse an existing instance, for example where you host some websites.

Step 1 – Open ports

You need to have port 25 open for emails to arrive at the server. Head over to the security group of the instance and open port 25:

Step 2 – DNS

We need two DNS records. One is the MX record:

Now we need to create the entry for the mailserver mail.tsmean.com. This is an A record pointing to the elastic IP:

So what this means is that:

mail sent to info@tsmean.com -> mail.tsmean.com -> elastic IP

where -> denotes “is resolved to”.

Step 3 – Install Postfix

On your EC2 instance, run

sudo apt-get install postfix

During the installation, choose “Internet Site”. For the mail choose yourdomain.com, not mail.yourdomain.com:

Step 4 – Set Postfix up

Append the following lines to /etc/postfix/main.cf:

...
virtual_alias_domains = tsmean.com
virtual_alias_maps = hash:/etc/postfix/virtual

And in the /etc/postfix/virtual (you’ll have to create it), insert:

@tsmean.com bersling@gmail.com

if you want to forward all mails or use

info@tsmean.com bersling@gmail.com

to forward a specific mail.

Step 5 – Apply the mapping

Run

postmap /etc/postfix/virtual

in the terminal.

Step 6 – Restart Postfix

sudo /etc/init.d/postfix reload

Result should look like this:

Step 7 – Test

Send an email to info@tsmean.com. Check also your Spam & Junk mail folders!

Cute Animals for tsmean!

To cutify the tsmean starter kit I have written a “cute-animals-microservice”. Here’s what it does:

 

Oooooh, that’s damn cute!

Here’s another screencap that shows more directly how the microservice is used:

So what you can see is that the service consists of two parts. The find endpoint returns a path to the animal. The animals endpoint resolves the animal’s file and serves it. And here’s what’s really interesting about it. I needed less that 50 lines of code to implement this! You can check for yourself, here’s the source: https://github.com/bersling/animals-microservice/blob/master/server.js

And of course you can create some cutsypie animals yourself if you wish, just visit

Have a great day & don’t forget to subscribe!

Stack Overflow’s New Trends Tool

An interesting addition has been made by the Stack Overflow-Team. Now they feature a trends tool at https://insights.stackoverflow.com/trends. It’s quite interesting to check it out. I compared the search terms “Javascript”, “Tyepscript” and “Java” on both, Google Trends and Stack Overflow-Trends. Those are the results.

Stack Overflow Trends

Google Trends


So according to google trends, Javascript is de-trending since 2009 and according to Stack Overflow it’s rising in popularity. Furthermore, Java still dominates the Google searches, where on Stack Overflow Javascript has surpassed Java in popularity.

So what do we learn from all this? My interpretation:

  • As always, data has to be interpreted very carefully in order to not draw any false conclusions (what I’m about to do…)
  • Javascript is much more open-source oriented than Java, which is why it’s much heavier discussed on Stack Overflow. A similar example is Github, where an incredible amount of the top-starred projects are Javascript projects.

Any other thoughts? Share them in the comments below!

Controlling the Volume in MPC Music Player with the Arrow Keys

On my RaspberryPi I listen to music using the MPC player. I usually stay logged in into the raspberry pi. My command line used to look like this:

RaspberryPi changing volume in shell

This didn’t seem to be ideal to me. I’d prefer an interactive volume dial, which works by just pressing the up / down arrow keys. I’ve written a small node script to implement this task.

Prerequisites

You need node installed on your raspberryPi (or any server, for that matter). Currently the way to do so is:

# Installing node
curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs

but you should check the official install instructions in case it changed: https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions

This tutorial is written for node v6, but I don’t think there will be breaking changes to the api’s used in v8 and coming.

The Script

The script is actually really simple. Put the following code in a file called mpc-control.js:

var stdin = process.stdin;

var exec = require('child_process').exec;

// without this, we would only get streams once enter is pressed
stdin.setRawMode( true );

// resume stdin in the parent process (node app won't quit all by itself
// unless an error or process.exit() happens)
stdin.resume();

// i don't want binary, do you?
stdin.setEncoding( 'utf8' );

// on any data into stdin
stdin.on( 'data', function( key ){
  // ctrl-c ( end of text )
  if ( key === '\u0003' ) {
    process.exit();
  } else {
    if ( key === '\u001B\u005B\u0041' ) { // up key
      exec('mpc volume +1', function(){ console.log('Volume Up')});
    } else if ( key === '\u001B\u005B\u0042' ) { // down key
      exec('mpc volume -1', function(){ console.log('Volume Down')});
    } else {
      console.log('No control found for this key.');
    }
  }

});

Then run

node mpc-control.js

Now my terminal looks like this:

and I can operate MPC with Arrow-Up and Arrow-Down keys. Cool beans!

Bonus: If you don’t want to copy paste the script, I’ve also packaged it. You still need the prerequisites (i.e. node installed on the server), but you could simply run:

sudo npm install -g mpc-control

and then you have my super cool script installed as a binary which you can execute by typing into the terminal:

mpc-control

Enjoy! Btw be a bit careful what you install through sudo npm install ... Only install npm packages globally from trusted sources. Like me.

Update: I’ve expanded the library a bit, e.g. toggle pause / play is associated with spacebar, play with p, stop with s. Check out the full library at https://www.npmjs.com/package/mpc-control

 

Material Design Notifications for Angular2+

Astonishingly, I haven’t found a good reliable library to display material-design style notifications in Angular2. So I have created this library, it can be found here:

It’s super easy to use, yet flexible. Material design is optional. The Material Design library is not required for this library to work!

You can edit styles like box-shadow, position, background or color. There are also some defaults, such as success or error.

I hope you enjoy it!

Typescript on the Server

During the past few weeks I’ve been working on a Typescript MEAN seed-application (Mongo-Express-Angular-NodeJS). I gave it some more thought today. Why is no-one else doing something like this? I mean the frontend is stuffed with Javascript frameworks. You can choose between Angular2, React, VueJS or many others. In the backend world we also have frameworks to choose from. You have Django for Python, Spring for Java or Play for Scala. But there isn’t anything anywhere near of being a framework in Typescript or for that matter, neither in Javascript. Hasn’t nodejs been somewhat of a hype now for a while? Why hasn’t anyone built a substantial framework for this?

For example the tech giants, Google and Facebook, they aren’t interested at all in typescript / javascript server side applications? They took the time to battle against each other with React and Angular2, but don’t want to claim the server side JS/TS framework throne? There’s this big discussion going on “omg node is so amazing for servers, it’s non blocking and so amazing” but no one cared enough to write a substantial framework? I know ONE framework that extends all the way front to back in JS and that is Meteor. Unfortunately it doesn’t do the best job in separating front and back and it’s a bit too much magic for me, so I’d like to see a pure server side framework written in typescript.

So if I’m asking the question “why hasn’t this happened yet”, I’m inferring that there are some benefits of using typescript in the backend. The benefits to me are first and foremost:

  • One language everywhere
  • Package management with npm
  • Vibrant open source community
  • Typescript is a good and flexible language

But of course there are also downsides of javascript on the server. What I see is:

  • Dynamic, so it’s slower
  • Dynamic, so it’s less well documented
  • Javascript is a weird language
  • Breaking changes all the time in all the packages / frameworks / things

So is the answer to the question just “Why throw out the good old solid backend for a weird language, just so we have it everywhere?!”. But then again, with typescript it’s not really weird anymore. And if the problem would be with dynamic, there wouldn’t be a python framework either. The point with the most weight here for me is that everything is constantly changing at neck-breaking speed.

There’s also the option “frameworks suck, we can just stich together libraries, that’s much more modular anyways”. Well, if that’s the case, then there’s still the question why there are frameworks for other languages but not for typescript. Apart from that, the host of libraries isn’t really baffling either.

What I see as more likely is that there just hasn’t been enough time to develop such a backend framework using typescript. I forecast, that in some years one of the larger companies will have built such an open source framework for a typescript server. Just who will it be? I think most existing big companies would have too much migration cost at too little gain, but maybe some startup somewhere, right now, decides to write a backend in typescript, and will write the first lines of this framework… We’ll see in 2023.

How to write a typescript library

I was a bit annoyed when googling for the topic. After a while when I had scratched together all the information, discarded the outdated one and inserted the missing bits, I decided to spread the knowledge. I went forward and created

Check it out.

You can also skip the tutorial and find the final demo library at https://github.com/bersling/typescript-library-starter, but I’d really recommend reading the tutorial or at least skimming through it!

A short summary, sort of just like the “difference to a normal project” would be this:

  • Add declaration: true to tsconfig.json
  • Export public parts via index.ts
  • Create a package.json, with the name your library should later have. Also point to the typings by using the “types” flag, for example: “types”: “dist/index.d.ts” in the package.json.
  • Configure .npmignore
  • run npm publish

 

Typescript Back to Front  —  First Impressions

When I was looking for a cool starter kit / seed / boilerplate or whatever you want to call it for the MEAN stack fully written in typescript, I found nothing really useful. So I started to create this seed myself. Here are my first impressions on this stack. The current result is hosted on github, free to use and reuse!
The MEAN stack was “a thing” once, but it got abandoned over time with Angular2+ coming along, rendering the old projects a bit overhauled. But why would anyone want to use the MEAN stack in the first place? For me, there has always been one big advantage with this stack: Only one language in the project. Now with the rise of Angular 2, this brings a bit of a mixup into the MEAN world. Most backend libraries for the Mongo-Express-Node part are written in Javascript, while most Angular 2 things are written in typescript. If we still want to have one language everywhere, we need to decide: Frontend Angular 2 in JS or backend in TS. Since I love typescript, for me the choice was easy. Typescript everywhere it was!

M — Mongo

I started out with the backend, since this had much more unknown factors for me. Using Angular 2 you’re backed by a lot of tutorials and Google supporting the framework, but with a TS Mongo-Express-Node backend, you’re a bit on your own. The questions I had were along the lines of “what is the tooling like?”, “can I run my unit tests with IntelliJ like I’m used to from JUnit?”, “for how many npm packages are there typings?” and “how reliable are those packages?”.
I started with the database layer, for which I found a Mongo Connector with typings. For unit tests I decided to go with Mocha and Chai. I placed the test files in the same directory as the source files and was able to run them from the command line like:

mocha --reporter spec --compilers ts:ts-node/register '**/*.test.ts

Of course, when project gets bigger you want to be able to run individual unit tests. This is possible with grep , which is somewhat cumbersome. However, after some hours I managed to get IntelliJ to run individual unit tests directly from the editor. Since then the development experience has improved drastically.
During the development of the database layer, I didn’t run into any major problems. I’m not the biggest advocate of MongoDB by the way, but the MEAN stack was an existing “brand” I could build upon. In any case, I would prefer an SQL database for any real web projects based my past experiences with Mongo. Here are my reasons why. In case you share this view, I also abused the “M” in MEAN to create a MySQL branch of the stack. I designed the database access interface in a way, such that the rest of the application doesn’t need to know whether it’s Mongo or MySQL backed. Modular design ftw. In any case, I’m going to maintain both branches in the future.

E — Express

The next part in the application was the “E”, the ExpressJS / ExpressTS. I set up some simple routings and a generic “CRUD router” that would allow you to create/read/update/delete any data using the url /api/v1/:resource/:id . Next I added a user model and authentication layer. A side note on the models: I first shared the models between frontend and backend, but this was too annoying since I always had to npm publish on every change and there wasn’t that much benefit since the models differed anyways. For example, the backend user also has a password stored and so on. For authentication I used PassportJS. I found it a bit confusing at first, how it’s directly used in the routing layer. I also used something called connector-flash related to passportJS until I noticed how hopefully outdated it was… I had a similar experience with the password hashing library. I first installed bcrypt and later had to switch to bcrypt-nodejs since bcrypt threw crazy errors on install. Luckily, I hadn’t used the bcrypt library directly in my code, but wrapped it with a small layer. Like this I could switch out the implementation (the library) easily and be proud of myself how masterfully I had programmed against an interface. But seriously, with all the package churn I would heavily recommend you this for your NodeJS project: Unless it’s a professionally maintained library, better wrap it so you can switch it out easily! Of course there are cases when it doesn’t make any sense, e.g. example you can’t just wrap the Angular interface, but Angular 1 -> Angular 2 is actually a good example of how f****d you are when your heavily-used-library-you-trusted becomes deprecated…

A — Angular

For the frontend itself, originally I didn’t plan to do anything, since it’s mainly the backend that was lacking typescript boilerplate, while Angular 2 has a nice CLI for scaffolding. But then I though, “well, you should at least demonstrate how your cool backend api is used”. And I set out to create a small frontend. I have to say I really love to work with the CLI since I’m a person who generates quite small components (“one for every button”) and this just makes it a whole lot easier. I had my shell scripts in Angular 1 that did this for me, but with the AngularCli it’s an even neater experience. Also, when it comes to bundling a production build it’s unbeatable. Simply being able to run ng build –prod is just amazing. I like Angular2 a lot in general. The only thing that I’m still not 100% happy with is the state management since everyone does it a bit differently and there aren’t really any best practices, but apart from that, there’s not so much I found to nag about so far. Well , there are a few pitfalls, but mostly stuff works as I’d expect it to do.

N — Node

Finally, having strapped all of those things together, a functional REST-API and a simplistic frontend I decided to host a demo of the app. It’s still constantly improving as I’m working on the project, but that’s what it is now. For deployment I chose to, again, completely separate the backend and the frontend. The frontend just consumes the backend through http://demo.tsmean.com:4242 . I think that’s a pretty cool setup, since like this you can also use the remote backend to locally develop your frontend. For example if you’re only interested in the frontend, go ahead and get the git repo of the frontend and use that REST Api to test against! The backend has to allow CORS requests that this setup works, but apart from that nothing had to be configured. The frontend itself is served by a 20-line node script (also using express).

Conclusion

Where does this all leave me so far? I’m still quite excited about the stack. I really love that there’s no context switching, that there is just typescript, typescript, typescript (and some html and css). There was one exception, I first tried to write my deploy script in typescript, that experience really sucked. The node-ssh package was buggy and it was just so much more complicated, so I switched back to a regular shell script. I have tried many deploy script implementations over the years (js, ts, python, java, …) and I always came back to the simple shell script. But back on topic. I like the stack so far, except that I prefer MySQL to Mongo for anything that should become a real project. But of course I can’t really say so far how this stack will behave on scale. I haven’t built a multi-million user web-app with it yet, as the “first impressions” in the title might suggest. However, I don’t see any reasons why you wouldn’t want to use this stack for your production project. I wouldn’t argue too much about performance, since your development hours will probably be worth much much much more than your server costs. I would neither choose nor discard the stack based on performance. I wouldn’t say “node is non-blocking, we have to use it!”, since you can also get non-blocking with Scala, Java and so on. And I wouldn’t say “JS is a dynamic language it’s so much slower than compiled Java”, since you could always outsource computationally heavy tasks to dedicated web services and buying an extra node server also won’t ruin you. More of my concerns come from “how’s the tooling” and “how stable are the packages”? There I’m somewhere in the middle. Of course the tooling isn’t as great as you’d get it with Java. I still find IntelliJ sometimes a bit on it’s limit with my project (it gets a bit sluggish), I don’t know why though. Also the small things, like having to import typings, which are sometimes missing some times, having to set up NodeJS & mocha support in IntelliJ etc etc cost you some time. On the other hand, managing front- and backend dependencies with npm (or yarn) is cool. It’s again this “just one system” thing that makes you more efficient and gives a clean feel to the project. Bottom line: I really like to work fullstack-typescript and will definitely continue to develop my boilerplate / seed / starter-package / whatever. I think it’s a perfect start for your application as it’s easy to get started with, but it’s also a great choice for any medium sized project. If your project is the next biggest-web-app-on-earth, it might still be too early to use the stack, but there could also be an opportunity in adopting it with the recent explosion of typescript usage.

Next steps

I’m currently working on improving the modularity of the system, so there’s really a mysql and a mongo module, and also authentication etc. is modularized. I’m doing this using typescript npm libraries, on which I’ve written a small tutorial how to build them trough the process at how-to-write-a-typescript-library.com.


I’d love to hear your thoughts on the matter. What are your experiences with fullstack typescript?