The server automatically checks for updates every fifteen minutes. This is of course, configurable. That's what this document explains.
The update server is GitHub. The nodeStorage repo as the official release version.
When there's a new version your server will automatically update itself, unless you've configured it not to. However it will not automatically restart. You can set it up so it does. See the section below.
You can configure the updates through config.json by specifying a top-level object named updates. It has three optional elements, enabled, fnameStorageJs and ctMinutesBetwChecks.
If enabled is false, it won't check for updates.
If you've changed the name of storage.js, set fnameStorageJs to the name of the file (that's the file it will update). I like to change the name so if I'm running more than one instance of the storage server on a system I can tell which is which when looking at a forever list.
Change ctMinutesBetwChecks if you want it to check more or less frequently.
You can set it so that your server automatically quits when there's been a change to a file you can specify. If you're running a utility like forever, it can then relaunch the server.
Turn the feature on with flWatchAppDateChange. And specify the file it should watch with fnameApp.
Here's an example of a config.json that has an updates object and automatically restarts when there's a change to the main JavaScript file.
If you want your 1999 server to be open for anyone to create a blog there, then you don't need to specify a whitelist. However if you want to limit who can set up a blog, you need a whitelist.
It's an array of Twitter screen names named userWhitelist that you add to your config.json file.
An example of a config.json with a userWhitelist specified.
If you want more flexibility in editing your whitelist, you can put it in a separate file accessible over HTTP. Here's an example of such a file.
Instead of putting the array directly in your config.json file, you would point to it using the urlUserWhitelist value.
The server reads the whitelist file once a minute, so you can change the whitelist without restarting the server. config.json is only read when the server starts up.
Here's an example of a config.json file that specifies a remote whitelist file.
1999.io is pretty much ready to go, now the question is -- how to roll it out.
First of all, what is it?
It's a blogging system. It's the blogging system I might have released in 2006 or so if I had stayed on the job instead of having my life take a sharp turn. Instead, we got WordPress from Matt, and Twitter/Medium from Ev. And Tumblr sold out to Yahoo, so that's not going anywhere. And Facebook is sort of a blogging system, but the posts don't have titles and can't have HTML markup, or links, so it's pretty limited.
Now I like all these guys, so this isn't personal, but I think WordPress is a pretty bad blogging system. It's command structure is designed to make sense to programmers. You have to be a programmer to modify a template. It's good for consultants, they love it because you need one to get a system up and in some cases to keep it running.
Twitter has that awful 140-char limit, and Medium is like a closed box with a few little windows here and there, so you can see some light, but neither really fully embraces the open web.
Bottom-line, the blogging world I left behind is actually considerably behind where we were when I took my leave.
First, I wanted a box at the top of the page where I can enter something new, start typing, and take it all the way to a finished post.
I wanted to be able to edit the template for my site, easily, giving me full control of how the pages look, without having to do any programming.
The server should be as easy to set up as possible. And it should get easier over time.
If I have a group project I want all the members of my group to be able to post to the blog. But one user retains ownership, control over the appearance and the server.
The server should be open source, so there can be a million servers if that's what the world wants. I don't want to try to capture the writing of others in my silo. I don't even want to host their stuff, if there's any way I can avoid it.
And I want to be able to continue to hack at the product, factoring, adding features, but retaining its simplicity and performance.
What's next
A new version of these instructions is on the 1999-project repo.
This version is maintained as an archive.
1999.io is a new blogging environment that's fast and easy, and has lots of features no other blogging software has. I'll write a FAQ that explains the feature set, but for now this is a doc that shows you how to set up a 1999 server on Ubuntu.
sudo apt-get update sudo apt-get install nodejs sudo apt-get install npm sudo apt-get install nodejs-legacy
We also install npm, a requirement to run Node apps.
nodejs-legacy makes it possible to run apps by saying node app.js instead of having to use nodejs, an oddity of Ubuntu.
sudo apt-get install git
I like to install git, because it makes it easy to install nodeStorage from GitHub.
nodeStorage is the name of the 1999 server software. It can be used for other apps. This doc shows you how to set it up for running 1999.
git clone https://github.com/scripting/nodestorage.git
Change into the nodestorage directory you created in the previous step.
cd nodestorage npm install
Launch your favorite Unix editor. I like nano because I'm a newbie, and it has a nice menu at the bottom of the screen if you don't know the commands.
nano config.json
Here's a template for config.json, copy the text, and paste it into nano in your terminal window.
Now I'm going to go through all the elements step by step, explaining what you have to do to set their values.
myPort -- enter the number of the port you want to use. Make sure that this port is open in your firewall, if you have one on this server.
websocketPort -- we use a technology called WebSockets to push updates back to the editing app, and to pages that people are reading. So you must specify a port for the WS server to run on, and as with the main HTTP port, above, it must be open in your firewall.
myDomain -- enter a domain name that points to this server. If you don't have one, you can enter the IP address of the machine, it will work as well as the domain name. Be sure to include the port you're using in the domain, as shown in the example.
where -- leave it as-is. It will store the public and private files in sub-folders of the nodestorage folder.
twitterConsumerKey and twitterConsumerSecret -- I'll explain how to set this up in the next section. For now, leave them as set in the example. The strings are nonsense, just placeholders.
Save the file by typing Control-O, then exit with Control-X.
node storage.js
Go to apps.twitter.com and click Create New App in the upper-right corner. A page with a form appears, asking for details of your app.
Give your app a name. If it's for your book club, you could call it The Hometown Book Club Blogs. If the name is already being used by someone, choose a different name. For my example I used "My test editor 2789". It was available.
The website URL will be the value for myDomain specified in your config.json file, as an HTTP url. From the example, it would be http://1999.bullmancuso.io:1999/
The callback URL for nodeStorage instances is the url of the app, as specified in the previous step, followed by "callbackFromTwitter" (don't include the quotes).
If it all worked, you should have a Twitter app set up. Click on the Test OAuth button in the upper-right corner of the page, and it will show you two values, consumer key and consumer secret.
In the terminal, press Control-C to quit nodeStorage.
Open config.json in your editor, and replace the placeholder values for twitterConsumerKey and twitterConsumerSecret with these values and save the file.
Go to the home page of your server. In the example above it would be http://1999.bullmancuso.io:1999/.
You should see a page a menu on the right edge of the menu bar entitled Sign on here.
From that menu choose Sign on Twitter...
You should get the Twitter authorization page. Authorize your app.
It should send you back to your home page, where you should see an edit box at the top and a few menus. Type some text in the box and click the Post button.
If it worked, you should see a new post below that. If you click on the wedge you'll see a menu of options for the post. If you click on the Eye icon next to the menu you should see a rendering of the page.
Pat yourself on the back. You are now a DevOps dudess or duderino. On your way to being a Full Stack Developer.