DEV Community: Anna R Dunster

Deploying a Next.js Website to a Virtual Private Server

Anna R Dunster — Mon, 25 Sep 2023 01:40:37 +0000

Originally published September 14, 2023 on my personal site.

When I initially began writing this article, after spending a week or so working on the functionality and writing for my renovated Next.js website, I assumed I would be able to deploy it to my existing hosting provider, Bluehost. Bluehost is a web hosting service that is primarily focused on supporting WordPress sites, and as such the tools and processes for deploying other types of applications are obscure and often poorly documented. After several hours of digging, a conversation with their tech support, and a trial run of using the output: 'export' option in Next.js, I concluded that either I'd have to live with substandard features, quadruple my monthly cost with Bluehost, or select a new service provider. I opted to select a new service provider.

A Word About Digital Ocean

My initial research lead me to Digital Ocean, which seemed like a good choice throughout the initial deployment to the VPS. Everything was reasonably smooth and straightforward, and easy to provision. However, when I then moved to the process of preparing to change the DNS over for my domain name, and investigating what I would need to do to swap my email over, I came across some very concerning information that lead me to rethink this decision. Unfortunately, entire blocks of Digital Ocean's available IP ranges are blacklisted by multiple spam prevention lists due to the convenience of setting up a mail server on their VPSs. (If you're curious about your VPS's specific IP, you can check sites such as UCEPROTECT, who runs one of the biggest blacklists that gets used by many organizations, or multirbl which checks the IP against a broad array of blacklists to see if it is listed.) From my reading, it seems that even if you do not serve email through their IP addresses, simply associating your domain with Digital Ocean can cause your domain to get blacklisted from some providers. This doesn't seem worth the risk to me, and for this reason I do not recommend using Digital Ocean as your VPS provider. However, I am leaving the tutorial available as it should apply equally well to any VPS hosting provider.

Setting Up The Virtual Private Server

When you first set up an account with a VPS provider, they should walk you through setting up your first virtual private server. For this tutorial, we'll be using a minimal VPS with largely default features.

VPS Creation Steps

These steps and screenshots demonstrate the process via Digital Ocean. Other providers will have similar options depending on the specifics of their service.

Select your region and datacenter. Here I have selected San Fransisco and left the datacenter dropdown on default.
Select an image for the VPS. For easy deployment, we will want one that already comes with Node.js installed on it. This is as easy as searching for Node.js in the "Marketplace" tab of the image selection section.
Select the size you would like for the VPS. Here we are just using the default smallest size, which comes with the Basic Plan's Shared CPU, 10GB of SSD storage, 512MB of RAM, and a total transfer bandwidth of 500GB. If you know you have higher requirements, feel free to adjust the details here.
Choose an authentication method. Using an SSH key is strongly suggested. The rest of this tutorial assumes you have set up SSH rather than opting to use a password based login.
Select any additional services such as metrics and backup that you want on your server. These are entirely up to your needs on the server.
Finalize details. Here you can adjust how many instances of the VPS you want to deploy, and give your VPS a name and tags. You can also select which project to add it to if you have more than one project set up.

Deploying The Site On The VPS

There are a few things we will want to take care of here. First, we need to get the code onto the VPS, all the npm dependencies installed, and the website built. Then, we will need to swap the configuration of pm2 (which comes pre-installed) to run the Next.js server instead of its default Node server. We will run these commands in the terminal via ssh.

`ssh` into your virtual machine using the root account.

From the terminal, run:



ssh root@your.ip.here

Or, to select a specific SSH private key file:



ssh -i ~/.ssh/custom_rsa root@your.ip.here

On successful login, your terminal will update to show root@name-of-vps as the user, and display some welcome messaging from the operating system (including active IP addresses) and possibly your hosting provider. The first thing you will want to do is apply any updates, especially security updates, by running apt update followed by apt upgrade (You may see an alert about how many packages are available to update). Your provider may mirror the packages, which makes this process faster, but it still may take a few minutes depending on how many packages need to be installed or upgraded.

Pick a location to clone your Next.js app into.

This is entirely up to you, but for a bit of guidance, the Filesystem Hierarchy Standard specifies /srv as the location for "Site-specific data served by this system, such as data and scripts for web servers, data offered by FTP servers, and repositories for version control systems (appeared in FHS-2.3 in 2004)." Another common location for content that is served to the web is /var/www/. However, neither are strictly required by the NGINX setup this image comes with.

One word of caution: never use / or /root for this. You don't want your web server files to live in the same place as your user logins and other sensitive data.

Clone your repository.

If the repository is private, you need to set up access to clone the repository into this VPS. Assuming the repository is hosted on GitHub, creating a personal access token and cloning via HTTPS is one way to get the required access without setting up personal SSH keys on the VPS. Using a fine-grained access token even allows you to restrict the token specifically to the repository you are working with. Remember to select the "Contents" permission from the list of possible permissions for this repository if you go this route.

Install dependencies and build the project.

Change directory into the newly cloned repository, then run:



npm ci

Followed by:



npm run build

Install may take a few minutes, and due to the low CPU and memory available on the low cost VPS, build also takes a few minutes.

Turn off the `hello` app.

NOTE:
Make sure you have the right user when working with pm2. It's easy to miss an important piece of information here: by default, the pm2 process belongs to the nodejs user. If you run pm2 again as root, you'll end up with two instances running. Be sure to either log in as the nodejs user (instructions to find the login data are in the welcome message), or use sudo -u nodejs before any pm2 commands to avoid this.

If you don't do this before you start your Next.js server, Next.js will attempt to start on the same port and quit with an error rather than starting successfully. Alternatively, if you want to keep hello or another app running on port 3000, you can start your Next.js server in the next step by adding a specific port, instead. If you're logged in as the root user, use:



sudo -u nodejs pm2 delete hello

Run the server.

In order to run the server and set up automatic restart when the VPS reboots, this VPS uses the pm2 (Process Manager) command. From the directory where you cloned and built your project (and assuming you are using the default commands in package.json), we'll run Next.js start with this command to give it a name of next-js in the pm2 interface:



sudo -u nodejs pm2 start npm --name "next-js" -- start

For variations on pm2 commands you might want to use here, this Stackoverflow answer goes into more detail.

Save your `pm2` configuration.

Verify that pm2 is running the correct processes:



sudo -u nodejs pm2 list

Then save the active list:



sudo -u nodejs pm2 save

If Next.js shows an error in the information returned from pm2, for example if you tried to start it before removing hello and it quit with the port error, you can restart it (assuming you named it "next-js" as shown in the previous step):



sudo -u nodejs pm2 restart "next-js"

Edit NGINX configuration.

NOTE:
For more detail on what you might want to change in NGINX config, a good place to start is NGINX's Pitfalls and Common Mistakes article.

If you reload your site at your IP address now, you will already see your Next.js app, as it runs internally on the same port that the hello script was using. However, there are additional things to edit in the config file. To edit the config (for the default server, which comes as the hello app in this image) using nano, run (replacing nano with your favorite command line text editor if desired):



nano /etc/nginx/sites-available/default

There are several things to particularly pay attention to in this file.

The root and asset location directives should be updated to match the location of your static files and assets to let NGINX serve your static files. You can proxy everything to Next.js, however letting NGINX serve them directly when possible will be faster. See more info from NGINX.

Configure the root directive to match the Next.js public directory (in this example we cloned the your_site repo to the /srv folder):



root /srv/your_site/public

Configure the location directive for the images directory to point to the images directory in the Next.js repository, using the try_files directive:



location /images {
  try_files $uri $uri/ @proxy;
}

Then ensure you have your root directory configured to use your proxy setup also:



location / {
  try_files $uri @proxy
}

Then set up the named location for proxy configuration:



location @proxy {
  # proxy config here
}

The proxy configuration itself likely may be reused from the hello app with few or no changes.

To test that it is working correctly, you can load your site and verify a) everything that is present loads as expected, and b) that you get the correct 404 page from Next.js, and not a 500 error, if you attempt to view a image that does not exist.

Finally, the server_name field, which should be updated to your domain address or an appropriate wildcard.

Once you have finished any configuration updates, verify that the configuration file's syntax is correct with sudo nginx -t, then use sudo systemctl restart nginx to restart the NGINX server.

Congratulations! Your content is now available on your VPS.

Possible Additional Steps

There are some more things you may want to do on your VPS once the site is up and running, such as configuring the firewall and other security, setting up non-root users for everyday use, or configuring NGINX logging. We won't be covering the details here, but you may find these pages useful:

Configure NGINX Access and Error Logs (Note this page is documentation for NGINX +, so double check if any particular feature you want to use is supported by the base version before use.)
How To Secure Your Anonymous VPS on bitlaunch.io
How to set up continuous deployment of a website on a VPS using GitHub Actions

Building a Dungeon Generator, Part 1. Introduction

Anna R Dunster — Wed, 29 Dec 2021 02:25:59 +0000

(Originally published on my blog on December 19, 2021)

Over the summer, myself and a few friends hatched an idea to work on a project together to practice programming. A bit of brainstorming later and we settled on a game idea that is sort of a hybrid roguelike / Legend of Zelda style game, and started hashing out some details; finally we had enough of a working name to put together a Unity project and a github repo, and started banging out some code. (I am sure Project Dungeon will not be the final name of this project.... I hope....)

Layout Generation

Ajesh Jhalli and Denver S collaborated to design and implement the layout generator part of the code, which produces layouts like these based on input variables.

With twenty rooms:

Seven rooms:

Thirty-seven rooms:

The blue room is considered the "starting room" and the red room is considered the "boss room". This data at this stage isn't interactable in any way, but shows a proof of concept in the code to build the layout, correctly assign doors, and pathfind from a randomized starting room to the most distant dead end room in the dungeon, which we then assign as a boss room.

Originally this was implemented using Random, but after watching a few Game Developer Conference talks on using "random" functions vs using a seed and hashing, I convinced my co-developers that we should use hashing to create noise, instead of random number generators, to determine our "random" generation. This way, every dungeon generated from the same seed will have the same layout, monster placement, and so on. This will allow different players to start in the same world if they choose, and also increase the reproducibility of behavior for testing and bug hunting.

Ajesh adapted the C++ function that Squirrel Eiserloh shows at 46:33 in his GDC talk, Math for Game Developers: Noise-Based RNG into C# for us, and swapped our implementation over to use the new function. It works great! There will be some interesting challenges to solve in the future using this (for one, if we have one world seed used to generate all hashes, how do we handle changing the dungeon layouts when a character dies and we want to generate new ones?), but I think overall it is the correct choice. Besides, it's fun to generate a layout, mess with the seed, generate a new layout, then switch back to the first one and see the first layout again!

Tilemap generation

I volunteered to handle the tilemap generation end of things, the actual generating of the rooms described by the layout generator as in-game objects. I figured I would be best positioned to do this as I'm also planning to handle the majority of the art assets as well.

Following parts of this video tutorial series on generating procedural dungeons in Unity by Sunny Valley Studio, and using this 32x32 dungeon tileset by Stealthix for prototyping, I got the code into a situation where I could paint tiles into a tilemap programmatically:

But then I basically ran into a wall. I was thinking I would have to generate each room as an object and create a prefab or something to pass back to an array of rooms for the game engine to pick from as needed, and I just didn't know enough about Unity. I had no idea how to do that. Honestly, I still don't. Most of my time on this project in the past couple months has been spent on other things, like setting up SpriteLibraryAssets and animations, and trying to get a better handle on how the different parts of Unity work together and interact in general.

But... Saturday I had a different idea.

What if we use each floor of the dungeon as its own tilemap? This idea will probably come with optimization challenges, especially if we go for larger dungeons. But I can see a path to making this work! And any working prototype is better than none. Let's do this!

Next up in part 2: adapting the Room Generator code to take floor and wall tilemaps, room dimensions, and starting coordinates as arguments. Also work on assigning wall tiles manually, since trying to do it with a rule tile ... didn't turn out good, and probably even less so once I switch to using the assets I created that are 3 units deep for the complete height of a wall on-screen. Oh, yeah, and at some point I'll need to finish figuring out the doors and room transitions to be able to generate them with code. I'm sure it's doable.

Adding Cypress to an existing Angular project

Anna R Dunster — Wed, 29 Dec 2021 02:14:54 +0000

(Originally published on my blog December 23, 2021)

When I set up my Angular13 single-page application (SPA) at work, I initially considered setting up Selenium for end to end testing, but due to the steep learning curve I was experiencing with the stack in general (and some other projected hurdles such as figuring out how to mock data that would be accessed through the window.external property in the live environment), I kept putting it off.

But, in the past month I encountered a situation in which the tests that I have written for this project did not actually catch a dependency error that caused the page not to load when the template was accessed at runtime. I suspect this is because I am not using the TestBed for the majority of my unit tests, since TestBed has a high overhead and slows down my couple thousand test cases dramatically.

I also recently read some articles (particularly From Zero to Tests on Corgibytes) that got me rethinking my test structure. Most of my tests currently are simply unit tests, possibly a few integration tests - mostly, does this function do what we expect when given the inputs we expect it to get (or handle it gracefully if we give it bad inputs)? I definitely don't have any tests that address DOM rendering. So, I had a stretch of downtime where I don't have anyone waiting on any specific projects and figured it would be a great time to set something up.

Why Cypress?
You may have noticed that I mentioned Selenium to begin with, but this article is about Cypress. Going back to Corgibytes, this time to Integration Tests Can Be Fun!, I didn't really care for the idea of setting up a black box that was hard to understand to handle my higher level tests. Plus, I've heard good things about Cypress from other sources, and it looks like it is relatively easy to set up, compared to Selenium.

Getting Started

The first thing I did after deciding to set up Cypress was hop over to their website and start watching the introduction video. This video suggests to install Cypress in any project with npm install -D cypress. I'm sure this would work, but I am also aware that Angular has its own package addition process, and sure enough, double checking for an Angular-specific install path lead me to End-to-End testing with Cypress - Testing Angular, which gives the Angular CLI command ng add @cypress/schematic instead.

NOTE:
If, like me, the first thing you do after installing Cypress is run it with npm run cypress:open, you may be confused by the immediate error message of "Warning: Cypress could not verify that this server is running." Don't worry about this for now if you're following the tutorials. Later in, they go over running your development server alongside Cypress for testing.

From there I hopped into the introductory tutorials that Cypress provides to get started. This is my first experience with a browser automation suite, and I have to say, it's pretty fun to enter commands in text, hop back over to the browser window and see it executing them! Definitely excited to push forward and get to a state where I could test my actual application.

So, the next step was to ensure that Cypress actually could test against it. The Cypress tutorials direct the user to enter a localhost address into cy.visit(), but the Angular CLI ng add command we used earlier already set up a default localhost address that's different from the one mentioned in Cypress's tutorials... and matches the one available from ng serve. If you have customized ng serve, I don't know if this will hold true, but in my case the address Cypress was looking for is a match. (If you want to customize the localhost address, the Cypress tutorial goes over configuring this in Step 3 of Testing Your App.)

Angular also provides a basic test file with a couple of contains() assertions when you use ng add to include Cypress in your project. In my case, since this is an existing project with actual content, neither passed. I'm not sure whether they're valid for the empty new app that Angular's CLI generates when creating a new application; I suspect they might be.

My case is a bit unusual in that a user should never actually see this page; users access individual pages by URLs that are stored in the software that they show up in. The only time a user would end up at the root of the application is if somehow the stored link in the software didn't match any valid route. Nonetheless, it's useful to ensure that the page loads and renders, since if it doesn't, none of the rest of the application will either! I ended up just writing a few basic test cases against the minimal content and links that I have at the root of my application for proof of concept.

I also took one of the user-facing pages that was fairly simple and worked up an initial-state test for that, too, as proof of concept. I added data-cy="whatever" tags to the important elements, and had Cypress check that the ones that should exist on page load, do; and the ones that should be hidden on page load, are.

Setting up the Mock Environment

Most developers at this stage are going to be starting to test their login flow and look at building stubs for server requests. For my application, though, the software that the pages get loaded in handles all of that, my code doesn't have anything to do with authenticating a user. So what I needed to do next was figure out how to stub the entire interface that lives on window.external when the pages are live in the production environment.

What Didn't Work

First I decided to try using the custom commands feature to add a command to apply the mock I've been using for my unit tests to window.external. There was an immediate hurdle involving Typescript and parsing the commands file: as soon as I copied the example namespace declaration from the comment at the top of commands.ts and adapted it to name my custom command, I got Argument of type 'mockWindow' is not assignable to parameter of type 'keyof Chainable<any>'.ts(2345) from my linter. I tried a few things and got other errors, then ended up following along with Adding Custom Commands to Cypress Typescript. I created an index.d.ts file in ./support to hold my modified namespace declaration, and added ./support to the tsconfig.json in the cypress folder, which resolved the type errors.

// index.d.ts
declare namespace Cypress {
  interface Chainable {
    mockExternal(): Chainable<Element>
  }
}

Unfortunately, then the part of the custom command where I import the mock caused a huge error, the first part of which looked like this:

Error: Webpack Compilation Error
./node_modules/@angular/router/fesm2015/router.mjs
Module not found: Error: Can't resolve '@angular/common' in 'C:\Users\adunster\Documents\repos\HtmlApp\node_modules\@angular\router\fesm2015'
resolve '@angular/common' in 'C:\Users\adunster\Documents\repos\HtmlApp\node_modules\@angular\router\fesm2015'
  Parsed request is a module
  using description file: C:\Users\adunster\Documents\repos\HtmlApp\node_modules\@angular\router\package.json (relative path: ./fesm2015)
    Field 'browser' doesn't contain a valid alias configuration
    resolve as module
// ...

I tried getting around this by duplicating my mock to a file in cypress's directory and editing out any references that imported anything in my Angular project such as types or mocks. Only then I did I find out that nothing I assigned to a property of window.external was actually showing up in the browser.

How did I fix it?

My ultimate solution was to skip using Cypress commands entirely, and change program behavior based on environment variables. I'll probably refine this to a more specific npm script, maybe with an additional environment.ts file (as opposed the development environment in general) in the future. For now, the code that assigns the .external property in my Angular service changed from:

function _external (): any {
  return window.external
}

To:

function _external (): any {
  if (environment.production) {
    return window.external
  } else {
    return new MockCEMRWindow().external
  }
}

Now, as I develop my specific Cypress tests, I can mock data into the functions in the MockCEMRWindow.external property to produce the results I need to test. It's not ideal, but for the moment it will do what I need it to do, and actually is something I'd meant to do for a while for manual testing in a browser window running the development environment. I'm sure I will want to dig further into cy.stub() and cy.spy() when I get the chance, too.

Running the Tests Automatically

I'm sure there's a lot of room for growth in automating our deployment processes, but for now, the way building and deploying to production is currently set up is through the npm scripts in the root package.json. After completing code and testing on a feature or bug fix, the code gets merged into the fresh branch, and then we run an npm script that will cause the production server to pull the fresh branch, run the Karma/Jasmine unit tests, and then run build it if the tests don't fail. (It's similar for the non-production server we use for semi-live testing on real data, only usually on the current development branch instead of fresh.)

Unfortunately, it looks like this will be neither simple nor straightforward to set up for this situation (especially given that all of these have to live inside a pushd command since we are using UNC paths), so this will be an adventure for another week. But Cypress has some direction here in their Continuous Integration documentation if you're looking for where to head next.

Conclusion

After getting my feet wet with Cypress and seeing a few of the things it can do, I'm actually really genuinely excited about it. It looks like a great tool and I can't wait to use it to help guarantee the resiliency of my code!

It isn't too hard to get the basics set up on an existing project, although there are a few tricks you may have to deal with depending on your environment. Their tutorials are great, though, and their documentation is clear and easy to follow.

I think if I were building a page that works through more typical API calls and HTTP requests it would be a lot easier to set up appropriate mocks and stubs, or at least have a lot more clear direction. Still, even with the unique challenges of my environment, the basic setup has not been difficult at all. Don't be afraid to just install it and get started!

Consequences (The Game)

Anna R Dunster — Wed, 29 Dec 2021 02:10:08 +0000

(Originally published on my blog on January 21, 2021)

I had an interesting idea today when I received something I'd ordered, which happened to be a birthday present for my niece. The present is a Mad Libs book, and the idea was: that would be easy to write code for - and I bet my niece and her brothers would enjoy messing with it, too. (Plus it saves the books!)

A little research later (to see how careful I needed to be with naming the script...) and I discovered that the game Mad Libs is actually significantly based on an older game called Consequences, and in fact the same code could work for either style of game, based on content templates. So here I'm going to organize my ideas for the code, and then I'll get to programming!

Technology Decisions

For all the enjoyment I've been getting out of C++ lately, and all that writing in Python now makes me feel strangely insecure ;), this project is relatively uncomplicated, and at a high level of abstraction, and simply doesn't need the level of control that C++ gives. Plus, I already know where to find most of the tools I need to make it work in Python.

Initially I thought maybe I'd just write a command line script, and I might still make it able to run as a command line script if needed, but it's a better exercise if I stretch myself a bit and craft it with a GUI, and easier for a user to get into, too. For the GUI, mostly for licensing practicalities, I'll use PySide2. (For more information about the licensing and other differences, Machine Koder wrote an article covering the main points.)

Content files will be written with JSON, since it's a nice, easy, human readable (and human editable) format that should be simple to work with, unless I get into the thick of writing code and have trouble getting it to do what I want.

Finally, I'll set the program up to run as a package in a self-contained venv to avoid dependency issues and keep users' system installs clean. Plus it's good practice (and a good practice).

Content Files

At this point in ideation I can see basically 3 fields of information that a content file would need to have to work. First, a title, although that's not critical. Second, the base text that user entered words will be applied into, with properly named "blanks" to be filled in. Third, a dictionary of the values to fill, each corresponding to a named blank:

# 1:
title = "Breakfast"
# 2:
text = "{name1} {verb1} to a/an {adjective1} {noun1} of {noun_plural1}."
# 3:
values = {name1: "", verb1: "", adjective1: "", noun1: "", noun_plural1: ""}

Possibly not in that order (it might make more sense to a content producer to have the dictionary above the text, for example), although order shouldn't actually matter if I call each field by name.

NOTE:

I was thinking about using .gitignore to hide all "content" files, since initially I'll be populating it with content from the book I purchased for her, but I think it makes more sense to have a separation between public and private content - public content can be shared with anybody, and makes it easier to get into and start messing with the game, whereas private content can be things that shouldn't be shared publicly, because of copyright or whatever other concerns.

As a side note, I want to also save user generated output files, probably just as a text file based on the content filename + a timestamp. Alternatively, as a JSON including the original title and a "By: " field input by the user. If I go this route, I could also save the dictionary of values used, to allow editing or fine tuning a particular output for maximum entertainment. ;)

Ideally, there'd be a way for a user to create a content file through the GUI, but that's a more complicated proposition that I don't intend to include immediately. Writing a JSON file with the necessary fields isn't too difficult.

Game Loop

When the program starts, the user should be presented with a "Welcome" string, and the list of available content by title (possibly organized by subdirectory). Clicking on a title, then a select button will bring up a dialog in which the user enters each requested value, then a button at the bottom to "Generate" the text. Selecting Generate will produce a text file saved to an output directory, and display the contents on the screen, at which point the game will offer the user to "Select new" or "Exit" - or possibly to "View saved" as well. Select new should return the user to the initial screen, while view saved would be an additional dialog to view the list of generated files and select one to view.

Possible problems

What happens if the user doesn't fill in all the blanks? One could go two ways here: one, by not allowing the user to proceed without filling blanks (which could be annoying), or two, the option I prefer: if a value isn't filled in, just supply the name of the value (in the example above, if someone declined to fill in adjective1, then the text would just output with adjective1.) This would work especially well with the idea of saving the values, and actually could allow content producers to be more specific in their directions: noun1 could be pre-supplied with "noun related to food", or something like that, and if the user chooses not to fill it in, that would be the value used.

Another issue that's less simple to fix is badly formed content. Too many possible values, such that not all of them get used, is not a big deal programmatically, although disappointing to the user when their favorite verb ever doesn't make it into the final text. But what if they format the content incorrectly, such that either the JSON can't be read at all, or the base text doesn't have the input values correctly indicated, or asks for an input value that isn't listed in the dictionary? Some kind of error handling and display is vital to this situation, preferably with helpful hints about what went wrong.

Conclusion

Writing all this out has given me a pretty solid place to start in developing the software of this game. I anticipate the hardest part will be getting PySide2 working as intended, since I haven't done very much GUI work at this point, possibly followed in difficulty by correctly packaging the program to work as intended, although I've made that work a few times.

After writing this post, I immediately dove into implementing the project. You can see my results in this Consequences github repository.

Thinking About Switching to Sphinx / ReST

Anna R Dunster — Thu, 05 Nov 2020 23:54:09 +0000

That’s it, I’m tired of WordPress.

There’s just too much bloat, too much going on, too many layers of stuff to have the level of control that I want. The interface is clunky and slow and constantly wants me to update a variety of things which are of questionable import to my site anyway. The website itself is slow, and to get it the way I want it I’d have to dig way further into the available themes, or try to build one from scratch.

If I’m going to build it from scratch, why not use a technology that actually interests me?

At my internship at MousePaw Media I recently started using Sphinx and reStructuredText to write documentation files for the project I’m working on. Pretty simple, and pretty cool (although in this case I’m fortunate enough that the web site is all set up - all I have to do is write docs in .rst. So I thought it’d be a good option to try for my personal page, too.

So now I’m researching the best way to go about this. Sphinx, by itself, is designed around building software documentation. That’s a little bit different than a blog (although I suppose it doesn’t entirely have to be) There are a few decent options for extending Sphinx to a more blog-like setup, though.

Reinout van Rees

Reinout has built some tools to assist Sphinx in converting .rst source files into a blog format, including tagging, and made them public. On the plus side, it’s software designed to do basically what I’m thinking of doing. On the down side, there is no quick pip install feature, and it’s very specifically designed for Reinout’s own website. So, if I want to use that code, I’d have to dig through it and borrow and adapt the pieces I want, while building the rest to my own personal specifications. This might be worth the effort if the other options don’t measure up, but isn’t a very attractive option to begin with.

Tinkerer

Tinkerer is a blogging tool built on Sphinx. It has support for a handful of useful blogging tools, such as Discus, localization, RSS feeds, and more. It does have documentation that should make it fairly straightforward to use. On the down side, it hasn’t been updated since 2017. That may not be a problem, as long as it all works fine; I don’t need a lot of fancy, new, language features, I just need to generate static HTML from templates plus source files. Definitely an option.

ABlog

Similarly to Tinkerer, ABlog is built in Python, as an extension for Sphinx, for the purpose of easily converting a project into a fully functional blog. It also supports Discus and RSS feeds if I ever decide to use either of them (which I’m not sure if I will, but it’s nice to have options). The tagging and category functions look pretty handy and usable. And it has current development - the last release was just a few days ago.

Conclusion

These all seem like decent tools that do the job they were meant to do. The sites using them are functional. But overall, ABlog seems to have the most (and most recent) documentation and tutorials available. I’m going to start there, get a trial page working, and then migrate my WordPress site over. Next post will probably be about what I have to learn to make that happen....

DEV Community: Anna R Dunster

Deploying a Next.js Website to a Virtual Private Server

A Word About Digital Ocean

Setting Up The Virtual Private Server

VPS Creation Steps

Deploying The Site On The VPS

ssh into your virtual machine using the root account.

Pick a location to clone your Next.js app into.

Clone your repository.

Install dependencies and build the project.

Turn off the hello app.

Run the server.

Save your pm2 configuration.

Edit NGINX configuration.

Possible Additional Steps

Building a Dungeon Generator, Part 1. Introduction

Layout Generation

Tilemap generation

Adding Cypress to an existing Angular project

Getting Started

Setting up the Mock Environment

What Didn't Work

How did I fix it?

Running the Tests Automatically

Conclusion

Consequences (The Game)

Technology Decisions

Content Files

Game Loop

Possible problems

Conclusion

Thinking About Switching to Sphinx / ReST

Reinout van Rees

Tinkerer

ABlog

Conclusion

`ssh` into your virtual machine using the root account.

Turn off the `hello` app.

Save your `pm2` configuration.