Time is really good at folding in upon itself. I thought that I would be working on node.js for about an hour, and the next thing that I knew, I was in the second hour working to restore some of the work I had previously lost. Of course, this restoration will need to continue for me to have the code to the place it was before and have myself at the starting gate I would prefer.
That is where things are.  Beginning in order to begin. I anticipated that these types of struggles would rear their assorted heads, and in coding, this is going to be a regular thing. Today I managed to spin up a new server for node.js to handle the actual live bots and the traffic they will generate. This was mostly the easy part.
Access was the other thing I had to optimise because I only had a root user, and for this sort of thing root is not the user I want to be working with. I needed a non-privileged account to execute from. I had also learned that having open login prompts to systems is not the best thing. Now I use SSH keys and this resolves some of the heartburn from the previous adventure I experienced.
Whilst operating in two challenges a key discovery I have made is that updating everything as in the paperwork that is resident in just about any activity known to man can absorb its own chunk of time. I have been coerced into scheduling these extra pieces of my agenda in place to keep me from running into too many overages.

learn to love the keys

SSH keys should become part of your normal mode of operation if they are not already. They will become integral in your system security as well as a lifesaver in remembering many pesky logins or averting the risk of having said credentials leeched by an outside entity.
I have learned a good bit about these in the past few days and you can find the same information here. I would suggest that you read them and get familiar with them. Use keys on your own systems, and they are also good for GitHub and GitLab.
After all, it can become a good and wise thing to pick up on what all of the cool kids are doing. Especially in things like this, where we are all learning the culture and the ways that things work.
In my other challenge and project, Project Rei I have also given Rei her own SSH key so that when she begins to operate as a service, the mechanism is in place and all I will need to do in the future is simply replace the key instead of having to write a whole sequence on the fly to accommodate it.  I feel it is better to get all of that out of the way now and treat her as a normal user, as that is what I am creating her to be.

working with node

One thing that concerns me is the current mismatch of versioning that I have, and  I will very likely correct that tomorrow. I have a newer version on my coding system than I do on the server, and I think it would be prudent to upgrade the server binaries for node.js as well as npm to the newest version. After all, that is why people code these things, to be used, abused,  but not to be ignored.
I also realised that I might be rambling a little bit, so I should take a moment and explain for those that did not follow the link I just posted that NPM stands for the Node Package Manager. It's a program like PIP is in Python, or APT in Debian (or YUM in godforsaken RedHat) that handles the loading of packages for use by node.js. Now that we have that explanation out of the way.
With this, I began to recode one of my bots that got burnt out in the Chinese house fire I was a bit hostile about on the New Year. Of course, this is where I learned another new thing, two things actually, and they are as follows:

  1. Never git commit your bot key to a public repo. Even if it is "private". There are things like sniffers that you don't want that data on.
  2. love the .gitignore file.

on bot keys

The best way to handle this that I know about at the moment is the way suggested in the Idiot's Guide and it involves creating a config.json file (which also means you just got your tippy toes wet with a little JSON, too!), placing your super secret bot key within that, then calling it into the functioning script. Perhaps I will add that snippet of code, edited of course, here so you can see it. At the moment I am not on a machine that has that code on it.

.gitignore

This does exactly what it declares on the tin. It allows git to ignore a file, a directory, or types of files in your clone. This is even simpler than the addendum that I described before. It is simply a file with single line items in it. You can see more on how to put that together here. Because I also get a kick out of being helpful, here is a page of templates for the .gitignore file.
Even if this doesn't seem like a lot to accomplish, it was a few hours of reading, studying, and executing, which is entirely the point of all this madness.
A madness we shall engage in again in a few hours.