DEV Community: Ian

Capitalizing Words in Javascript

Ian — Mon, 18 Jan 2021 12:24:06 +0000

I was looking for a solution on capitalizing all words in a string in Javascript this morning to use as the title of a page, I found a bunch of solutions, some included regex, some included looping through every character, some required a whole function.

I wanted something much cleaner and thought I'd share with everyone my solution

For this example I will be using the string "my awesome title"

"my awesome title".split(' ').map(i => {
    return i[0].toUpperCase() + i.substr(1);
}).join(' ');

So what is happening? First we split the string into an array by a space, we then iterate over it returning the first character of the string as uppercase, and the rest of the string starting at position 1. We then join it all back together with a space.

You can easily turn this into a function

capitalizeWords(words) {
    return words.split(' ').map(i => {
        return i[0].toUpperCase() + i.substr(1);
    }).join(' ');
}

Or if you are writing in VueJS like I needed to you can created a computed property, you will need to change the this.$route.params.category to what you want and split it by the appropriate character, for my requirement it was split by a dash

computed: {
    title: () => {
        this.$route.params.category.split('-').map((i) => {
            return i[0].toUpperCase() + i.substr(1)
        }).join(' ')
    }
}

There seems to be quite a few ways to do this, but I found this way to be cleaner than requiring regex, if you want to do it with regex, I found this blog had an example

Scrolling to a specific element on a page

Ian — Tue, 07 Jul 2020 06:41:57 +0000

I recently needed to scroll to various elements on a page via Javascript. I wanted to specifically see if there was a better way to do it than manually finding the offset as below

document.getElementsByClassName('series-list')[0].scrollTop = document.getElementsByClassName('breakpoint')[0].offsetTop;

And I found out about Element.scrollIntoView, amazingly all major browsers support it, despite it being a working draft.

So you can simply do

document.getElementsByClassName('series-list')[0].scrollIntoView()

As with Javascript there are numerous ways to accomplish the same thing but I never knew this existed and thought it was worth the share.

mdn

What note taking apps do you use?

Ian — Mon, 04 May 2020 09:59:09 +0000

I've been looking for a note taking app that supports speech to text along with notes and lists.

What are you currently using?

Building an Idle game Part 3 - Authentication

Ian — Thu, 26 Mar 2020 15:42:04 +0000

Welcome to my series on how to go about building an Idle game. This third episode focuses on authentication both in Vue and Node.

Authentication is a fun subject, there are a million ways to authenticate a user from the more basic user / password combination, to OAuth, OpenID and others. For our game we will be using KeyCloak, it is an "Open source Identity and Access Management" application. For a lot of apps this may be overboard, but our use case requires it, so we will be taking advantage of it.

Why not use just a user/pass combo?

This is a great question and originally we did do this. However we have several applications that require a central authentication portal. Keycloak provides this, but not only this it also allows for very easy integration of social logins, access control and more.

What if I don't want to use KeyCloak?

That is fine. As we develop the authentication you will notice we use JWT tokens, so most of the code can be easily changed to remove the need for KeyCloak.

Getting started

Make sure you have KeyCloak running before you start, there is a standalone version or a docker image, by default it runs on port 8080 and on http://localhost/auth.

Environment Variables

The first new bit of tech we are going to go over is environment variables. Almost all languages have this concept to some degree - even frontend frameworks like React. The idea is that this .env file is specific to the user/server and is not shared, it is also ignored in git to prevent commiting the file. This file will contain all the applications secrets. For our app we use 4 variables

AUTH_REALM=divinity-world
AUTH_URL=http://localhost:8080/auth
AUTH_CLIENT_ID=game
AUTH_REDIRECT_URI=https://localhost:8081/play

The AUTH_REALM is the realm you created in KeyCloak, the URL being the url to auth, the AUTH_CLIENT_ID is the client id, by default Keycloak creates an account client and a few others, I created my own game. And lastly the AUTH_REDIRECT_URI is where you get redirected after authentication.

JWKS and JWT's

There are 2 parts to authentication on the server side, the first part being the need to get the signing key from the server and the second being verification of the token, for this we use two libraries.

npm install jsonwebtoken
npm install jwks-rsa

Let's head into cluster/child.js now and declare those as constants


const jwt = require('jsonwebtoken');
const jwksClient = require('jwks-rsa');

After this we need to create the jwks client, this is generated based on the .env variables above

const jwksUri = `${process.env.AUTH_URL}/realms/${process.env.AUTH_REALM}/protocol/openid-connect/certs`;

const jwks = jwksClient({
    strictSsl: true, // Default value
    jwksUri: jwksUri
});

const kid = 'OHNidHJInGLWbWHanztSf8A8GDfnJVATENxKjchqvc0';

The last variable kid is the client id in Keycloak.

Next is actually protecting the socket from unauthorized requests

...
io.on('connection', (socket) => {

    let token = socket.handshake.query.token;

    try {
        jwks.getSigningKey(kid, (err, key) => {
            const signingKey = key.getPublicKey();


            jwt.verify(token, signingKey, {
                azp: 'game',
                issuer: `${process.env.AUTH_URL}/realms/${process.env.AUTH_REALM}`,
                algorithms: ['RS256']
            }, function (err, decoded) {
                if (!err)
                    console.log("User authorized", decoded);
            });
        });
    } catch (e) {
        socket.disconnect()
    }

    ...

}

This little chunk gets the token from the query, we then attempt to get the signing key from Keycloak, once we have that we then verify the token against the azp and issuer. Is anything goes wrong, we kick them out of the socket.

The frontend

The frontend doesn't require much code at all as we pull in two packages, one that handles the logic of tokens such as refreshing them. For this we use vue-keycloak-js and also vue-socket.io which handles the logic of binding events to components. All of this lives inside main.js in the client side.

Vue.use(VueKeyCloak, {
    config: {
        authRealm: 'divinity-world',
        authUrl: 'http://localhost:8080/auth',
        authClientId: 'game',
        redirectUri: "http://localhost:8081/play"
    },
    onReady: (keycloak) => {
        console.log({keycloak});


        Vue.use(new VueSocketIO({
            debug: true,
            connection: 'http://localhost:3994?token=' + keycloak.token,
        }));

        new Vue({
            router,
            render: h => h(App)
        }).$mount('#app')
    }
});

An improvement on this would be to also use environment variables in Vue, you may need to change the config depending on your realms.

By wrapping the app in Vue Keycloak, if the user is not authenticated it will always redirect to the login page so it's quite seamless when it comes to integrating it into other applications.

Building an Idle game Part 2 - The code

Ian — Sat, 21 Mar 2020 16:19:01 +0000

If you missed Part 1 you can find that over here. It is recommended to read that first to understand the theory behind some of the choices made in this part.

So we have now covered the theory of how the tick system will work for skills, now it is time to actually implement it. I'm going to go through the core parts, the UI will be in the repository however I won't show that in this part.

The entry point

Our entry point is server.js so let's check out what is in there

const cluster = require('cluster');

if(cluster.isMaster)
{
    require("./cluster/master");
} else {
    require("./cluster/child");
}

For now all it needs to do is handle clustering, we are building this in now as the project I am working on uses it, you are welcome to remove it, though you may need to tweak some things in cluster/master.js and cluster/child.js.

Cluster master process

cluster/master.js contains a bit more logic but it's pretty boilerplate as far as clustering seems to go, we fork it depending on the cores and setup a message handler

const cluster = require('cluster');
const cores = require('os').cpus().length;

console.log("Master process running");

for (let i = 0; i < cores; i++) {
    cluster.fork();
}

function messageHandler(message) {
    switch(message.cmd) {
        case 'disconnect user':
            return eachWorker((worker) => {
                worker.send(message);
            });
    }
}
function eachWorker(callback) {
    for (const id in cluster.workers) {
        callback(cluster.workers[id]);
    }
}

for (const id in cluster.workers) {
    cluster.workers[id].on('message', messageHandler);
}

cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
});

Cluster child process

child.js is quite a clutter at the moment so we will dissect it piece by piece.

let tasks = {};

const taskFiles = fs.readdirSync('./skills').filter(
    file => file.endsWith('.js')
);

for (const file of taskFiles) {
    const task = require(`../skills/${file}`);
    tasks[task.name] = task;
    console.log(`Loaded task ${task.name}`)
}

Here we are loading in all our skills so they can be used when needed, no need to manually find them, so whatever files ending in .js that are in /skills will get loaded up.

The next part of child.js is the socket, so let's jump into what happens when the login event is emitted from the client.

First we disconnect the user from all the other clusters so that no duplicate sessions are held for things like timers. We send an event to the master process, which in turn sends it to all workers.

        process.send({
            cmd: 'disconnect user',
            data: {
                user: credentials.username
            }
        });

Next is adding the user to the online array and actually loading the user in. We also join a private room so that we can emit events into that room for that user later on

let username = credentials.username;

usersOnline.push(username);

socket.join(`private user ${username}`);

user = new User(username, socket, client, tasks);
await user.load();

Now that we have loaded the user we need to let the client know about it, so we send the activeAction along with the username

socket.emit('login', {
    username: username,
    currentTask: user.data.activeAction
});

The final part of login is emitting the config which contains information such as locations for resources, items, monsters. We cache this in local storage on the client side and in future we will also include versioning. There are multiple benefits of this.

You don't need a separate config for the front and backend, just the backend
You can change what config is sent at any point just by pushing a change to the database
It prevents data mining, if you have secret items or achievements which should only be cached if the user has found them, this prevents spoilers for when no one have met an achievement or found an item
Save bandwidth, no need to download a config file everytime (Our current solution does this)

socket.emit('config', config);

// Send the signal to end the loading screen and now we're ready to play
socket.emit('ready to play');

We listen to three other events, start task, stop task and disconnect, these just call a method on the User.

socket.on('start task', (task) => {
    user.startTask(task);
});

socket.on('stop task', () => {
    user.stopTask();
});

socket.on('disconnect', () => {
    if(user instanceof User)
    {
        user.clearTimers();
        delete usersOnline[id];
        user = null;
    }
});

The last bit I want to explain of this file is subscribing to redis and handling disconnects. Redis is a key part of the application, it's sort of the glue that holds a bunch of things together such as pub/sub

So we first create the client for subscriptions and subscribe to stream. Every message received on this stream will be parsed and sent through socket.io, this is handy for external applications sending events inwards, handling cross server communication and, handling our own internal events

let sub = redis.createClient();

sub.subscribe('stream');

sub.on('message', function (channel, message) {
    let m = JSON.parse(message);

    io.to(m.channel).emit(m.event, m.data)
});

process.on('message', (message) => {
    if(message.cmd === 'disconnect user') {
        if(users.includes(message.data.username)) {
            users[message.data.username].methods.clearTimers();
        }
    }
});

The tick system!

It's finally time to explore the tick system, probably the most exciting part of this article. All our logic is held in the User class, for better or worse.

The class is initialised when a user connects as you can read above. I have changed, refactored, changed, deleted and changed some more, so I do believe there is some dead or redundant code. I'll be going through it again later on as we expand it to refactor and optimise.

startTask() is the entry point to starting a task, this is always called when we start a task, be it from the client, or internally.

startTask(task) {
    this.stopTask();
    this.data.activeAction = task[0];
    this.data.activeSkill = task[1];
    this.currentAction = this.config[task[1]][task[0]];
    this.save();
    this.executeTask();
}

We attempt to stop any running tasks, we then set the activeAction and activeSkill then proceed to save() to Redis, then execute the task.

executeTask() is where most of the logic is handled in regards to tasks and timing.

    executeTask() {
        let activeAction = this.data.activeAction;
        let activeSkill = this.data.activeSkill;

        if(!this.config[activeSkill][activeAction])
            return;

        let currentAction = this.config[activeSkill][activeAction];

        // Check if task exists
        if (this.tasks.hasOwnProperty(activeSkill)) {
            this.clearTimer('resource');

            let timer = this.getTaskTimer();

            this.socket.emit('startProgressBar', {activeAction, timer});

            this.timers['resource'] = setTimeout(() => {
                this.tasks[activeSkill].execute(
                    currentAction,
                    this.socket,
                    this.data
                );
                this.executeTask()
            }, timer)
        }
    }

Basic validation is the first step to make here then calculate the timer, getTaskTimer() simply returns a number from a config file. For this purpose think of it as 5000. So after five seconds we execute the task and then call the same function so that the progress bar gets started again.

I found it a little hard to wrap my head around, until I actually built it and it all made sense. I toyed with setInterval but ultimately found that setTimeout fit our needs much better given we want to be able to change timers on the fly, imagine an enchantment that gives a 30% to speed up the next action by 50%, you need to be able to do this easily and setInterval I found didn't work as well.

That concludes the tick system at least, it's pretty basic once it has been split up. We do have some other methods for clearing timers and setting timers.

Overall it was fun to make, the frontend was much harder than the logic on the backend mainly due to dealing with animations. Most of all I got to experiment on all aspects of this from how the tick system would work to figuring out how to get the frontend syncing up correctly.

I will be continuing the series and implementing SQL next along with authentication, I hope to have one part out a week, though some pieces may take two or three weeks depending on what is happening during the week

Building an Idle game Part 1 - Theory

Ian — Wed, 11 Mar 2020 21:24:46 +0000

I want to build a Idle RPG game, I'm pretty new to Node so it's going to be an adventure, a bit of trial an error, it should be fun :). This is a multi part series, in which by the end, you will be able to build your own game. I am taking inspiration from the likes of https://idlescape.com, https://melvoridle.com/, https://pendoria.net/.

Tick based systems are pretty interesting, I've never made one before, only theorized a few possibilities. After recently joining a project that uses a tick system, I decided to look into it more from scratch to get more of an understanding of it. What better use than building a real world example.

So where do you start with a tick system?

We need to start by describing what the system will do, we will be using Woodcutting as an example as it doesn't contain so much logic. It should be straightforward, you chop, you gain xp and gain logs. We will go over combat and other skills later.

Woodcutting

There are a few things that needs to happen for this skill - and for several others.

The timer for skill must be dynamic, so that we can change the time depending on the level of the skill or any buffs active
The skill can generate items and experience so it needs to update the user both locally in Node and in a database somewhere
It needs to be able to emit events to the client such as xp, progress bar movement, messages etc.

Queues

My first thought was thinking that it would be best to separate out each skill into a "job" and put it into a Queue. This would elevate much of the processing onto a separate server elsewhere. Initially it sounded great, but when it came to implementation it became quite convoluted, especially when it came to communicating from inside the job to the outside.

Latency also becomes a factor, as everything needs to happen fast so the next action can take place.

So I went with putting everything inside a setInterval() and left it at that. It reduces the complexity so much that avoiding queues for this is the best thing to do.

Conclusion

Sometimes the straightforward answer can be the right one.

So now we have an outline of what a skill will possess and a rough idea of how the tick system will work.

Part 2 will cover the actual code behind the tick system along with the Github repos which contains some other scaffold such as Vue frontend.