Adding Shurikens


Recently I felt the need to increase the amount of visitor feedback on this blog. I really liked's "claps", where visitors can click to give claps (more than one if they want) for articles. No log in or social media connections are required, which makes it low effort on the visitors part.

Since I am no longer using Wordpress and a continuously running server to host this blog, I couldn't just use that to implement this feature. I am now using a static site generator and hosting on Netlify, and this cannot store any state (we need to keep track of how many clicks each page gets). So I decided to learn more about cloud computing and create a backend/API in AWS.

Continuing with the Ninja theme, rather than likes, +1's, thumb ups or claps, this blog has "shurikens" (Ninja stars).

+1's, likes, thumb's up and claps have been done before, this blog uses shurikens!

+1's, likes, thumb's up and claps have been done before, this blog uses shurikens!

You can see the backend code at The front-end is embedded in the code that generates this blog, which can be found at Files of interest in the blog repository include:

You can see the final result in this .gif below (or just look at this webpage!):

Demo of the shurikens.

Demo of the shurikens.

AWS Infrastructure

AWS services are used to provide an API and persistent database for the static site front-end to talk to. AWS Lambda is used to implement the API which means that no cost is incurred when the API is in use (i.e., I don't have to have a server running 24/7). Below are some interesting stats on the services I used:

Amazon Lambda

  • 1M free requests per month
  • 3.2Ms of compute time per month

Amazon DynamoDB Free Tier

  • 25GB of storage
  • 25 units of write capacity
  • 25 units of read capacity (enough for 200M requests/month)


The great NPM library serverless was used to create all of the above infrastructure. serverless allows you to create things such as Lambda-based APIs backed with a DynamoDB database in a really easy fashion, without having to delve to much into the cloud infrastructure design. It automatically creates the services, roles, permissions, and connections.

Runtime: Node.js 8.10

Serverless Settings:

  • IAM User: serverless
  • Access Type: Programmatic Access
  • Permissions: AdministratorAccess (policy directly attached to user)
  • Region: us-east-1

Serverless is given the AWS credentials to the serverless user with (using the default profile):

$ serverless config credentials --provider aws --key <key> --secret <secret_key>

Service can be deployed with:

$ serverless deploy -v


TravisCI is used to build and deploy the backend. The AWS credentials are stored in secret TravisCI environment variables called AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.

The settings page for the CICD setup on TravisCI.

The settings page for the CICD setup on TravisCI.

Disqus Reaction Removal

Adding these shurikens also meant I no longer had any need for the "Disqus reactions". These reactions where a piece of functionality the Disqus commenting system let you enable which would allow viewers to choose between 6 or so basic emoji (upvote, funny, love, e.t.c). I had always found this a tad tacky and untidy, but until now was the only way viewers could quickly react to content. Now that the shurikens have been added, I have disabled the Disqus reactions.

Saying goodbye to the Disqus reactions.

Saying goodbye to the Disqus reactions.

What Could Be Improved

  • If any part of the page URL changes (including the domain name), the shuriken count will be reset. It would be nice to be able to track page URL changes and keep the count state.
  • There is no authentication process for the public API, anyone could use it, which could cause increase AWS costs (we will see if this becomes an issue).
  • Have separate dev and prod deploys of the shuriken backend, currently I am just using dev.

February 2019 Updates

January 2019 Updates

Happy New Year 2019

Happy new year! Image from

Happy new year! Image from

Statistics for 2018

This is the first year I have used Google Analytics to gather these statistics. Even though I have been using Google Analytics for many years, in previous years I just relied on the statistics presented in the Wordpress admin dashboard. This is no longer possible as I am now using Hugo to power this site. This also means that the reported numbers are different, in fact, Wordpress seemed to always report higher numbers than Google Analytics. The stats for 2017 on this page are also from Google Analytics so that a fair comparison can be made. See the Happy New Year 2018 post for the Wordpress sourced 2017 stats.


Page Views83k116k
Number of users per week for the 2018 year. Image from Google Analytics.

Number of users per week for the 2018 year. Image from Google Analytics.

A User is a unique person who visited this website at least once.

Ranked by number of page views:

Altium Tricks And Standards10.5kAltium Tricks And Standards11.0k
Altium Bugs And Things To Watch Out For4.9kAltium Bugs And Things To Watch Out For5.8k
Home Page3.9kLinux Serial Ports Using C/C++4.6k
A Function Pointer Based State Machine2.3kHow To Use SocketCAN With The Command-Line In Linux4.4k
Component Packages2.2kHow To Use SocketCAN With C In Linux4.4k
Altium Scripting And Using The API2.0kHomepage4.2k
Altium Keyboard Shortcuts1.7kA Function Pointer Based State Machine3.3k
UART Protocol1.4kAltium Scripting And Using The API2.7k
PCB Design1.3kAdding A Custom App To A Yocto Build2.5k
How To Unbrick A PICkit 31.2lAltium Keyboard Shortcuts2.3k


5 most popular acquisition methods by number of users:

Organic Search34.4kOrganic Search53.6k

5 most popular referrers by number of users:


Plans For This Year

  • Utilize Hugo to it’s fullest capabilities. Although the migration from Wordpress to Hugo is complete, I feel like I have not yet explored all of the possibilities that Hugo allows. This includes sitemaps, RSS feeds, automatic thumbnail creation, better shortcodes, e.t.c.
  • Find a way to reliably detect dead links as they occur, along with an easy way of fixing them.
  • Move all of the GitHub repos into my own personal account, as there is no real need for a “organization” on GitHub, at it just leads to extra work and confusion on where repos are.
  • Remove all the excess images in the blog repository. As a result of the Wordpress migration, there are many copies of a single image, each at a slightly different pixel size (I’m assuming they were created as part of a page load speed optimization in Wordpress). These are un-needed as Hugo can resize images at build time to correctly fit the container on the page. These extra images are just using up repo space.
  • And of course, as always, add more content!

December 2018 Updates