A Tech Blog

Table.Fish - Going Viral.

Sun, 05 Apr 2020 12:46:37 GMT

Of all the weird domain names I have bought over the years, Table.Fish is an unlikely late bloomer. Originally purchased to be the home of a restaurant table booking app, it was quickly shelved and lay dormant for over a year. It’s now home to my newest passion project: a virtual table quiz platform.

It’s a simple concept, the quizmaster hosts a live stream on youtube with the questions. Players can submit their answers through our app.

Table.fish is growing rapidly in a world where pandemic has shut down mass gatherings and public events. This is a story about how we have managed to build a platform in days that can handle hundreds of users simultaneously, let scorers mark over 10,000 answers in minutes, and most importantly, raise over €2,500 for charity.

A long long time ago…

In mid march 2020, before the total lockdown we have now, when working from home was recommended Chris (my Exante co-founder) invited me to join a virtual quiz. He wanted to host 10 teams, submitting answers over whatsapp and calculating scores in excel. Managing it was a nightmare. Sending in answers was a pain. It took him ages to score answers. But people still sent him ‘entry fees’, just like a real life table quiz. I thought we could do much better…

By the following quiz, I had a firebase application up and running. It let you submit answers through a form, and it displayed them on an admin page with some buttons to mark each answer correct or incorrect. The scoreboard could then be displayed to each user, which updated as scores came in. I was happy.

(Yes, above image is a photo of a screen…It’s all I could find without spinning up an old version. You get the idea.)

3…2…1…

Next quiz (Friday, 20th March) we had a few more teams but were operating off a default cloudfront domain. Friends and family started to sign up. We had 28 teams in total. Assuming about 4 people on a team, that’s over a hundred people on the second outing! And our “pay what you want” model was working. Over €200 was contributed after the quiz.

The ‘show’ went well. Some minor bugs. A couple teams accidentally submitting answers early. An easy fix with a confirmation dialog. A missing scoresheet. hmm. Ok, I’ll investigate.

I spent a weekend on it and by the next quiz on Tuesday, we had a domain name, much nicer UX, better game controls for the quiz master and a little more functionality for scoring. It felt good to have real users on my system, but also terrifying to think about what would happen if it broke…

Double Trouble.

The next quiz blew us away. We had nearly twice the teams join us. Most of them we didn’t know. and with that growth came some growing pains.

It turns out you can’t trust user input. Even if you think you’re being careful. One team managed to set their team name to ‘undefined’. It shouldn’t have been possible, but it happened. The result was our scoring page threw an error and completely crashed after the first round. Thankfully I was able to push a frantic update mid-quiz to handle the error.
I thought I was out of the woods. Sadly not by a long shot. As soon as the scoring page came back, our scorers started experiencing massive lag. I had set up the paging slightly wrong. Each new score sheet appeared after the last, but didn’t replace it. Corrected score sheets were invisible to the scorer, but still in the DOM, taking up memory. Another live fix was necessary. This time, I only had the time to implement a crude drop down to let scorers skip ahead to a page in multiples of 10. Now they could proceed with frequent refreshes and at least keep up with the incoming answer sheets.
My heart rate must have been over 200 at this stage. I had just returned to the living room where my wife and her family were doing the quiz. I sat down, opened a beer, ready to enjoy the second half of the quiz. Then it ALL went haywire.
The answer sheets stopped loading for players. The admin panel stopped updating the game state. The scoring stopped updating. uhh…I ran back upstairs.
We had hit the free usage limit on firebase. 80,000 database reads. I was kicking myself. Firstly, why didn’t I see this coming? Secondly, how could the system be making 80,000 reads? That’s madness!
Thankfully the fix for this one simply involved a credit card.

By the end of the show we had made 180,000 db reads. Something was up!

What’s up doc?

Simply answer: The scoreboard was inefficient.

Less simple answer: The scoreboard was embarrassingly inefficient, I’m almost too ashamed to share it.

The first (and quickest, at the time) solution that occurred to me was to create a scoreboard component, get every user in the game, get every answer sheet for each of those users, then display them in a table. I obviously didn’t think about it very hard. This approach resulted in the scoreboard being generated fresh for every user that viewed it.

For a rough estimate: 80 users reading 80 other users with 8 answer sheets and 8 rounds. 80 * 80 * 8 * 8 = 409,600

The actual number is much smaller because the scoreboard for the first round requires less reads in total. But you get the idea.

Quite frankly, if this was a university assignment I would have barely passed. Thankfully that is all behind me and the real world is much more forgiving.

My updated solution is to only re-calculate the scoreboard once after each round is fully scored, and store the result somewhere that can be accessed in a single database read by all users. This reduces the db reads dramatically.

Conclusion

Table.fish is far from finished. As a tech challenge, I haven’t even addressed the scoring, which will make a whole post in itself. As a product, the user base keeps growing and the contributions keep coming. We’re on an exponential curve right now and it doesn’t seem to be slowing.

There’s a lot to do…

The Case for Self Hosting Your Blog

Fri, 15 Feb 2019 10:51:37 GMT

We are currently witnessing an internet paradigm shift - in reverse.

In The Beginning

Once upon a time in the heyday of chain mail, RSS and web rings, before bloggers were bloggers, when people hosted everything on their own servers, content was king.

The internet was weird and wonderful and useful.

Then we all collectively¹ decided that owning our own content was for losers and posting on a centralized system with likes, shares, and reblogs was clearly the superior approach.

The Kapitalist Kontent Killers

Pretty soon, the realities of the capitalistic internet kicked in. The content that we created was pilfered from our control, peddled to the highest bidder, and plastered in advertisements. Anything that didn’t titillate, tickle or trigger was quickly hidden by algorithmic feeds and timelines.

In 2012, while all this content commercialism was steaming along, a little startup called Medium was born. It offered a simple interface and slick experience for writer and reader alike.

When I discovered it in 2014, I was enamoured. After attempting to build my own blogging platform which coincidentally, also launched in 2012, (without success) I saw what I might have achieved with a bit more experience, knowledge and luck.

For many people, Medium seemed like a viable escape from the grip of content killers. Without the effort of coding it yourself, hosting and managing wordpress or whatever else. Medium was cool, man. And you could be cool too.

But of course, it was not to last. As I have come to learn, the cool kids are never really your friends. Once again, the platform bloated and profits became the goal at the expense of user experience. Now, practically every article on the homepage is a “member feature story”, costing you $5 a month to read - (The first 3 are free, yipee!) - if you can bear to read at all…

But whatever, right? I am not my platform. My articles are still free. I can survive.

Maybe not. There are reports of articles becoming monetised without consent. Biased discovery means getting any attention through the platform is next to impossible. About 99% of my traffic comes from Twitter, Reddit and occasionally Hacker News. That’s no way to build an audience.

And I’m not the only one to identify that. In 2019, many writers are losing faith in third party services.

Everything Old is New Again.

Hosting used to be expensive, unreliable and complicated. Now, with services like bluehost, dreamhost and even namecheap offering out-of-the-box wordpress, hosting your own content is easier and cheaper than ever.

For those with tech chops, github pages offers completely free static hosting. In combination with a static site generator like gatsby or hugo, you have the ultimate in flexibility and efficiency without sacrificing control of your content.

In 2019, the tools available to independent bloggers / writers have (sort of²) caught up with platforms that no longer offer meaningful features.

The catch

This all sounds great, but people moved to third party platforms for a reason. So what are we missing out on?

Discovery is up to you. Platforms don’t do much, but they don’t do nothing. If you’re not actively sharing your content and building an audience externally, you may as well be locked in a dark room whispering to yourself.
Interaction is difficult. Without the platform to handle user accounts, nobody can leave a comment. “But Wordpress has comments” I hear you moan. Yes. It does. And nobody but bots uses it. You could use a third party service like disqus, I don’t think usage would be high. Personally, I’m just hoping people will tweet me to discuss.
Interaction (Again) with meaningful light feedback features like ‘like’ and ‘applause’ buttons is impossible without using a third party service.
Retention of your readers is going to be tricky. With algorithmic feeds, they will be spoon fed the content they appear to like better. It’s a game you can play to get people coming back. But on a self hosted blog, your only option is a mailing list or other social media / content discovery services, like twitter, reddit etc.

The Conclusion

This is one of my more popular posts from last year. Over 5 thousand views, not massive but I’m proud. Less than 4% of those views came from the platform.

This bothered me, but not enough to actually do anything. Then, out of curiosity, I tried exporting my posts. Here’s what I got:

That is a HTML file. It looks ok if you open it in your browser. But the content is a single line of mangled HTML tags, arbitrary css and nonsense. This was enough to make me do something.

Migrating my old posts is a nightmare that involves copying and pasting text, downloading and reformatting images and basically re-writing my entire blog. Every new post I make on Medium would mean hours of work in the future.

Now, new posts are written in plaintext markdown files, with a simple directory structure: one folder per post. That folder contains all the images and assets used in the post. It is simple, maintainable and most of all, easy to migrate.

I hesitate to use the term “future proof” but it’s a step in the right direction.

In the end, Medium, you made my decision for me. Thank you. Next.

An argument could be made that we were all hoodwinked by the Mark Zuckerbergs of this world in this regard.
↩
I have many gripes with current blogging tools that I will cover in a later post. Wordpress is an over complicated disaster for simple blogging. Gatsby is complex, and while the final product is lovely, the setup is not.
↩

Vivisection of OpenTable widget.

Wed, 06 Feb 2019 12:46:37 GMT

You may be familiar with OpenTable, a service built around restaurant bookings. One of their main features is an embeddable widget that restaurants can insert in their website to let patrons reserve a table. Here’s what it looks like in the wild:

This widget was generated by the OpenTable widget builder page like so:

Try it yourself at: opentable

As you can see, we can change a few settings and then just copy the code into our own website. Pretty handy, but how does it work?

The loading script

The script we copy is simply a <script/> tag, which is used to load javascript. We can simply copy the URL into a browser window to see the code that would be loaded:

Yikes. It’s obviously been minified (as you would expect) but hope is not lost. Let’s copy this into a text editor and run some auto formatting:

Ok, that looks a bit more approachable. For reference, I’m using the Atom text editor with Atom-beautify for auto formatting.

First impressions

First thing to note here is the outer function syntax:

! function(i, n) {
  ...
}(window, document);

This is a self-executing anonymous function. That is, the function is called as soon as it is loaded (“self executing”), it doesn’t have a name or a variable reference (“anonymous”). This is a common approach for plugins and widgets, and was particularly common for jQuery plugins. In my experience, I have seen this mostly using the double bracket pair syntax: (function(){})() but this does the same thing.

The ! is simply a unary operation (a logical “not”) that forces javascript to execute the function. If the output of the function was stored in a variable, it would be negated, but since the function doesn’t return anything, and the result isn’t stored or used anywhere, it has no effect.

Next thing to note is that window and document are passed into the function and will be referenced by i and n respectively inside the function.

Let’s find and replace the occurrences of i and n for the sake of clarity…

Defaults and the Comma Operator

Looking at the internals of the function, we see that the widget starts by assigning stuff to the window, but it does this is a fairly interesting way, first by checking for an existing window.OT value using || , and if none exists (ie. if window.OT is undefined), the code after the || is executed.

Why would we bother checking for an existing window.OT value?

I assume this is to handle a website embedding the code in more than one place. This way we only ever execute the code after the || once.

So, after the ||…

Note: I have “folded” each function to highlight the comma operator syntax.

We see an empty object followed by a comma…weird.

Usually we would expect a comma to be inside a function declaration, an array or an object, right? In this case, the comma is used as an operator.

The comma operator evaluates each of its operands (from left to right) and returns the value of the last operand.
MDN

Based on that description, the empty object is “evaluated” [see note below], then a function is declared and assigned to OT.createNS [note 2], this function is then called a few times.

Note: Why the empty object? If each step is evaluated and only the last value is returned, what use is the empty object?

By playing around a bit, I have discovered that the empty object is necessary to avoid an error when assigning the OT.createNS function right after the || operator. Specifically: “Uncaught ReferenceError: Invalid left-hand side in assignment”.

The CreateNS function

This function gets called a few times, and as far as I can tell, it is simply used to set up the OT object with nested attributes. I think NS might stand for Name Space, but that’s a guess.

In short, it converts the string “OT.something.else.entirely” to an object.

It’s fairly straightforward, with the only interesting bit being the use of the void operator:

The void operator evaluates the given expression and then returns undefined.
MDN

The OT functions

The next few lines use the createNS function to ensure the OT object has an attribute of a certain name, and then assigns a function to each of these attributes. The functions are self explanatory:

createScriptTag, createCssTag, createOcTag, createIFrameTag, loadJQuery

The Modal

All of this extra work is building up to being able to inject a “modal” into the host page. The modal in question appears when you click the “find a table” button:

Modals are a fairly challenging (and controversial!) UI element. They have to sit over everything in your page, position themselves in the center of the screen, and go away when you need them to.

I try to avoid them if possible, as they also lead to accessibility issues and pose a challenge for screen readers.

All this leads to complex CSS and JS, which isn’t apparent in the code that we copied…so where is it?

Going even further down this rabbit hole, we can inspect the modal and discover that the contents actually come from an i-frame. That means the UI and elements are really a completely separate web page, loaded from a different server, simply placed over the host website.

The code we are vivisecting really only builds the src for the iframe, passing in the details of the specific restaurant.

From here, it is quite straightforward and well beyond the scope of this post. The modal i-frame is a fully functional web application (a react app if the class name “react-root” is to be believed).

Conclusion

We have seen some interesting patterns here — most of them (the comma operator usage for example) are fairly specific and probably the result of a preprocessor trying to produce a smaller JS. I’m not too sure what, how or why, but hopefully somebody can comment with an explanation.

The whole thing, however, boils down to a fairly simple approach:

Get the user to copy a <script> tag in the host page.
Use a self executing anonymous function in the <script> to…
Insert an <i-frame> tag close to the script tag, and…
Load your widget from your own server.

Thanks for reading!

Applications as Configurations.

Wed, 30 Jan 2019 12:00:00 GMT

Here’s a thought:

“Most software applications consist of the same basic functions in different configurations”.

Let’s play with that. Imagine a super-high-level language that could describe a software application tersely, but still capture the usefulness of the application.

✏️ Our app

Example 1

App: Twitter
  Allow user to: login
  Allow user to: send a tweet
  Allow user to: follow another user
  Allow user to: view a timeline of tweets

further examples here

Our app needs a name, we’ll use Twitter as an example.
login is pretty self explanatory and so common that we can assume it’s baked into the language. login becomes library.login indicating we will use provided library behaviour and not a custom implementation.
send a tweet is a unique instance of a very common action: take some user input (data: text, image, video, audio etc) and store it somewhere (write), so it can be returned (read) later. We can specify all that in more detail later. For now, let’s imagine send a tweet just references further configuration somewhere else, and becomes custom.tweet
follow another user again, a unique name for a common action: make a link, connection or relationship between two things, in this case, users of our app. In the case of twitter, the follower-to-followed relationship is many-to-one. The Facebook friend-to-friend relationship is one-to-one. On reddit, user-to-subreddit subscriptions are one-to-many. follow another user becomes custom.follow
view a timeline of tweets is a read action. It’s going to get some set of things, arrange them somehow and display them to the user. It will probably have nested actions, like liking, retweeting and replying but we’ll handle that later. It becomes custom.timeline

Ok, let’s iterate.

Example 2

App: Twitter
  Allow user to: library.login
  Allow user to: custom.tweet
  Allow user to: custom.follow
  Allow user to: custom.timeline

Each allow user to line corresponds to a function of the app, but may include multiple UI components. Library.login will obviously require a login page, a logout button somewhere else and other elements to update passwords and other information. custom.follow might appear in multiple places throughout the app.

🌇 Structure and views

It probably makes sense then to define the structure of the app separately, but with reference to the previously defined actions.

Example 3

App: Twitter
  Actions:
    #Allow the user do these...
    - library.login
    - custom.tweet
    - custom.follow
    - custom.timeline
  Views:
    # Allow the user to view these
    - library.landingPage
    - custom.home
    - custom.profile

Here I’ve split the app into Actions and Views. We’ll consider the first view in the list (library.landingPage) to be the default or index. Again, using library means it’s built in. Allowing us to use default boilerplate like this should help speed up development. We can always come back later and use a custom view instead.

🔗 Views and Actions

Mapping actions to parts of our application structure is not trivial. Some pages will have specific actions, and some actions will be reused in many views. Each view should define exactly the actions it needs.

Example 4

App: Twitter
  Actions:
    #Allow the user do these...
    - library.login
    - custom.tweet
    - custom.follow
    - custom.timeline
  Views:
    # Allow the user to view these
    - library.landingPage
        - library.login
    - custom.home
        - library.login.isUserloggedIn
        - custom.tweet
        - custom.timeline
    - custom.profile
        - library.login.isUserloggedIn
        - custom.follow

Now views have specific actions. We can now have functionality, with the added bonus that is totally clear what happens in each view.

Notice how library.login is used in each view. The library.login action is like a package with many nested functions. We should be able to use specific parts of an action like this — where we don’t need to let the user login on each page, but only check that they are logged in.

🗣️ Discussion

It is conceivable that a configuration like this could be used to generate all the necessary boilerplate for an application. At this point, the application could be generated for any platform too.

None of this is necessarily new. Meteor provides default app generation, boilerplate login functionality, and client-server comms. React has create-react-app which…creates a React app for you. The Vue CLI create command will scaffold your app. In fact, tools like Yeoman literally allows you to define a ‘generator’ and spit out a scaffolded application. Further, React Native takes a JavaScript project (basically a highly featured configuration) and generates native applications, similar to Cordova.

Code generation is not new. So what’s different here?

In the case of Yeoman, create-react-app and the VUE create command, once the scaffolding is generated, it’s all up to you. You are left with standard application code and development continues as normal. What I propose here is a tight coupling where the configuration becomes the application, not just a blueprint. That is, if you change the configuration at any time, the code will be updated to reflect that change. Write code that conflicts with the configuration, you get errors.

A developer should be able to look at the configuration and know that the application strictly conforms to that definition.

In the case of Meteor, with it’s highly functional login boilerplate and client-server comms (pub/sub), (which I think is wonderful, by the way) this goes a step further. User authentication and login is not a convenient package that happens to work quite well — it should be baked in to the very core of the system. With Meteor, the developer still needs to write templates that show/hide content or routes based on the users logged in state. This is silly. At best, it is inconvenient and leads to template overhead. At worst, it is a security risk when, though accident or inexperience, a developer does not handle authentication correctly.

It should be impossible to create insecure apps!

When a view is defined like this:

...
Views:
    - custom.home
        - library.login.isUserloggedIn
        ...

There should be nothing else to do. If the user isn’t properly authenticated, it isn’t accessible. That’s it. No fiddling with client side routers, entry events, or app-wide templates or anything else. The config is God. The config wins.

Finally, (for now) there are massive benefits when it comes to deployment and maintenance. Deterministic configurations should provide reliable deployments, and make dependency management easy. Imagine an app you built 5 years ago using library.login: you should be able to trust that a new deployment will include up-to-date authentication code — because your app will be generated using the standard configuration, it is always backwards compatible. Even if massive high level changes need to be made, as long as you use library.login.isUserloggedIn, your view will be protected on a higher level by the generated app code.

🎬 Conclusion

I know I am being incredibly idealistic here. I’m certain that there are edge cases and complications that make this completely impractical for some purposes. But this isn’t supposed to be a panacea. It’s supposed to work for the 90% of applications that need to make CRUD operations protected by user authentication.

But it’s fun to dream.

Mapping out my side projects

Fri, 07 Dec 2018 12:30:37 GMT

It turns out there’s a lot to learn by examining the cadence and variety of your side-projects…

Figure 1: Projects over time. Check out the original spreadsheet here.

I recently defended my PhD and in the process of preparing for the defence, I discovered that an old backup hard-drive was damaged beyond repair. Thankfully I had a further backup, but it got me thinking:

There’s a lot of stuff here that I probably will never look at again, but it’s important to me that I recognise it’s existence.

I hope I never have to look back at the PHP I wrote when I was learning, but I spent months cobbling together SQL queries and designing objectively terrible pages, and that process is important, at least to me.

Then I thought:

I’ve shared a lot of this stuff over the years, I wonder how many people have seen the stuff I’ve made?

The projects I could find hard data for include:

Original Music
6 Websites
3 Youtube Channels
3 Chrome Extensions
2 SAAS platforms
A physical product
and this blog.

Figure 2: Project data. Again, from the spreadsheet here here. Links included, where possible

Findings

I decided to go back as far as 2010, around about when I started my undergraduate degree, and when I started creating meaningful things that could be shared on the internet.

Relatively steady cadence

Figure 1 above shows pretty clearly that from 2012, I tended to start between 2 and 4 projects a year. There are some gaps (June 2015 — August 2016), and some times where I start a few projects close together (Early 2018), but overall, there’s never really a time where I don’t have a project to work on.

Blog posts come in spurts

The black bordered cells in Figure one indicate that at least 1 blog post was made that month. They tend to happen together, with large gaps in between. Obviously, I’ve begun to write more frequently lately. I think I also tend to write when I’m in need of a quick win: it’s a goal I can achieve in about a day or less and consider complete.

Newer projects are less viral

Left to right: oldest to newest. We should disregard Medium (where this post was originally published) here as new posts were added over time.

Obviously, older projects are going to have more views, but we would expect the decrease in lifetime views to be somewhat linear. In actual fact, my newer project don’t seem to get anything like the kind of exposure that my older projects got.

I think this might be due to my focus changing from viral content (“blogify 2” was designed to copy content from reddit and repost the links), to actual useful tools (“Blue Spots Parking” is an app to help disabled drivers find accessible parking spaces). Making useful tools that also gain viral traction is a sweet spot I have not yet managed to find.

But perhaps this is also a reflection on how social networks are becoming less effective. Reddit, Facebook and twitter have always been the main way I share my projects.

Views are not correlated to revenue.

These figures include prize money. “Reviewyour.Website”, “The Cub” and “Posture” have not received any prize money.

It’s safe to say that I won’t be quitting the day job any time soon, but I think making any money at all off a side-project is a massive success regardless of the magnitude. I have three main observations here:

The project with the most views still made no money. I actually didn’t even put ads on the “Blogify 2” site. I felt it was immoral to profit off it.
The physical product performed by far the best in terms of dollars-per-view. It was also the most challenging project though and probably took far more effort-per-view than any other project, if you could measure that.
Music is hard.

Conclusion

It’s probably about time to start something new. If I want to maximize the views, revenue and longevity, I should probably try to build a physical product that is a useful tool with a viral aspect, which has nothing to do with music.

Easy.

Zero Dependency HTML templating in 12 lines of Javascript

Mon, 12 Nov 2018 12:30:37 GMT

This is a piece of code I wrote for a previous blog post about writing a Custom Mocha Reporter. I wanted to generate HTML output from a template, but I didn’t need much functionality or an extra dependency. Turns out, it’s not that difficult.

Programmatically generating or producing HTML is not rocket science. The typical approach is:

Build a HTML template close to what you want.
Identify the variable parts of the template you want to change.
Write your code to get the replacement parts.
Use a templating engine to load the HTML and replace the variables with the replacement parts.

There are loads of templating engines out there. Mustache is one. Handlebars, doT and EJS also do the job. They all basically work the same, but they all represent an extra dependency that we don’t need. We’re not doing anything complex here, and I’d rather keep this package with zero dependencies. So build it ourselves.

Regular Expressions

Artists impression of a lake surrounded by red cabbage and carrots fields.

Regular expressions (regex) are a wonderful, powerful and complex concept that I wont get into in too much detail. Basically, a regular expression allows you to define an “expression”, or pattern, that can be used to find specific sequences in a body of text. A common use of regex is to find a substring, and replace it. Regex can also be used to validate data, ensuring it conforms to some structure (ie. phone numbers contain only numbers and are 10 digits long)

Replacing a String.

Regex are not unique to Javascript, and even within JS, there are multiple ways to utilise them. In our case, we’ll use the string.replace() method. (full documentation here)

str.replace(regexp|substr, newSubstr|function)

We’re going to take a string called template and find every occurrence of words surrounded by double squiggly brackets like so: {{word}} . Then we’re going to replace that word with a value we have generated — in the case of the Mocha reporter, we used the output of our tests, but it can be anything at all.

For example, say we have calculated the percent of tests that ran successfully as: runpercent , and in our template we have written `{{runpercent}}`. We could write:

template.replace(/{{run_precent}}/g, run_percent)

The regex literal is surrounded by forward slashes. The ‘g’ means search globally.

Replacing Multiple Strings

But we can do better. We can find any word surrounded by squigglies with the following regex: /{{.*?}}/g

. means any character except a newline.
* means match the previous thing 0 or more times.
? means make the previous thing ‘non-greedy’ — ie. The shortest possible match.

Finally, we’re not just going to replace every word in squigglies with just one value. If we pass a function as the second parameter to replace(), we can be much smarter…

let newContent = template.replace(/{{.*?}}/g, function(match){
  return replacements[match]
})

Here,Match is the word that is found by the regex. replacements is an object with keys for each of our template variables (the squigglies), and values for what we want to replace them with. Here’s an example:

// Example of replacements object
{
      "{{lastrun_date}}": new Date(),
      "{{run_percent}}": run_percent,
      "{{run_numerator}}": sum,
      "{{run_denominator}}": total
}

Wrapping it all up with the file reading/writing code in a nice little function (called updateBillboard in our reporter) and we have our templating engine in 12 lines of Javascript:

function updateBillboard(replacements){  
  content = fs.readFileSync(`template.html`, {encoding:'utf8'})
  let newContent = content.replace(/{{.*?}}/g,
    function(match){
      return replacements[match]
    })
  let output= `/output.html`
  if (!fs.existsSync(output_dir)){
    fs.mkdirSync(output_dir);
  }
  fs.writeFileSync(output, newContent)
  return output
}

Conclusion

Obviously, this isn’t going to be suitable for anything with complex templating needs. But, in my opinion, installing a whole extra package just to replace a few values in a file is overkill.