DEV Community: allen-woods

How to Patch and Run DieHarder on Alpine Linux

allen-woods — Wed, 09 Dec 2020 15:27:05 +0000

I am neither a cryptographer nor a security engineer, so when it came time to consider cryptographic best practices for my project I innocently searched for entropy test utilities. A few skimmed lists later, I had set my sites on one that I kept hearing good things about -- something called dieharder.

Nakatomi Tower as a CLI? A Digital John McClane? I had to track it down and learn more.

DieHarder DOA?

DieHarder is a CLI entropy testing utility written by Robert G. Brown at Duke University. It implements several rigorous tests that can measure a system's performance calculating random data. To vastly oversimplify, it goes far beyond /dev/urandom. "Perfect," I thought. "I'll just grab that and include it as a nice-to-have."

Unfortunately, when I followed the installation instructions the compilation failed. Trying to find a solution only pulled up threads dedicated to CentOS or Ubuntu that were years out of date. So, I decided to solve how to compile it on Alpine myself.

Sed to the Rescue

Luckily, the necessary changes are brief and can be made using the built-in stream editor sed. The addition of a missing typedef and a missing define of a constant are all that it takes to make the compilation succeed; aside from renaming a required dependency.

Without further ado, here's how to install, patch, compile, and run this utility on Alpine!

#!/bin/sh

# Install static packages.
apk add \
  apk-tools-static \
  busybox-static

# Install packages needed to compile DieHarder.
apk.static -U add \
  chrpath \
  gsl \
  gsl-dev \
  haveged \
  libtool \
  make \
  rng-tools \
  rpm-dev \
  build-base

# Create a valid build tree for RPM.
mkdir -pm 0700 \
~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

# Point to the 'rpmbuild' path in the macro file.
echo '%_topdir %(echo $HOME)/rpmbuild' >> ~/.rpmmacros

# Create a path of your choice to install into.
mkdir -pm 0700 /your/install/path
chown root:root /your/install/path

# Download the latest version of dieharder.
wget -c \
http://webhome.phy.duke.edu/~rgb/General/dieharder/dieharder.tgz -O - | \
tar -xz -C /your/install/path/

# Set current directory to the top level of the build
# extracted from the tarball.
cd /your/install/path/*

# Generate makefiles and compilation resources.
./autogen.sh

# ---- Patch dieharder.spec file.

# Patch line 16 to point to 'gsl-dev' package.
sed -i \
'16s/.*/chrpath gsl-dev/' \
./dieharder.spec

# Patch line 129 to prevent 'macro expanded' error.
sed -i '129s/.*/# /' ./dieharder.spec

# ---- Patch libdieharder.h file.

# Insert new line to define 'M_PI' constant.
sed -i \
'66i #define M_PI    3.14159265358979323846' \
./include/dieharder/libdieharder.h

# Insert new line to create 'uint' typedef.
sed -i \
'262i typedef unsigned int uint;' \
./include/dieharder/libdieharder.h

# Compile dieharder.
make install

# Run all tests in dieharder.
dieharder -a

This has been tested using dieharder 3.31.1 running on Alpine 3.12 Stable inside a HashiCorp Vault 1.5.4 image built with docker-compose. Results may vary.

Hope this helps you in your cryptographic projects, and thanks for reading!

Why You Should Try Using GraphQL

allen-woods — Thu, 18 Apr 2019 16:30:47 +0000

Often when creating a full-stack application, a lot of time is consumed by back-end development — usually more than expected.

Querying for data must be specific, which typically means some excess or deficit of the data we need when interacting with a RESTful API. This can further impact user experience and app performance due to excess overhead introduced by inefficient requests when deployed at scale.

It would be great if we didn't have to delicately tip toe through our data or pull down heavy chunks just to retrieve or update specific information.

Luckily, a technology was designed for that very purpose and its name is GraphQL. Today we will review the potential it has for our next projects from the perspective of a curious novice.

Concise Questions Within Detailed Data

GraphQL is an open-source querying language developed by Facebook that was released in 2015. Its primary premise is to provide a way for client-side requests to ask concise questions about the data in your API.

Only What You Need

One of the best aspects of implementing GraphQL is that you can retrieve or update only the information you want to interact with while retaining freedom in how your data store is structured.

Data Typing

Another terrific addition to workflow is the stronger typing of data that is sent and received through GraphQL, complete with debugging tools that make development easier overall.

Database Agnostic

The fact that GraphQL can be used with both relational and non-relational databases, such as PostgreSQL and MongoDB, among others, is definitely a plus not to be overlooked.

Not a Middleware

In practice, GraphQL essentially acts as a form of translator for your database, whereby client-side communication is relayed through it rather than passed to your data store directly.

In the short term, this adds a layer of planning to a project that requires time to be allocated for design of requests themselves. However, the intuitive syntax affords a greater degree of freedom, faster turn around, and more accurate debugging when taking the long view.

To put it simply, the added value in workflow alone more than makes up for the time taken to implement it.

Let's take a closer look at the overview of how GraphQL is structured to get a better sense of what it does.

Services

All data returned through GraphQL are effectively requested values that correspond to keys that match specific fields. These keys and values exist on a special "root" object that is used to pass data to the client.

Services can be written in any language, allowing for seamless integration on your server — even if your app has already been deployed.

The way that GraphQL interacts with data is through services, defined as blocks comprised of a data type that contains one or more fields. Those types and fields are then associated with callback functions that are used to process information. For example, the following structure:

type Query {
  opponent: Player
}

type Player {
  id: ID!
  name: String!
}

function Query_opponent(request) {
  return request.auth.player;
}

function Player_name(player) {
  return player.getName();
}

To run the above code, the request would take the following form:

{
    opponent {
        name
    }
}

While the syntax looks similar to JSON, it is important to note that the above GraphQL syntax is written in multi-line string format, typically surrounded by back-ticks (also known as "grave diacritics"), and must be parsed during translation by the included server runtime.

There are many topics involved in the definition and use of GraphQL and the rabbit holes can go rather deep.

For now, we are most interested in taking a broad overview of the main building blocks. Let's start with Queries and Mutations.

Queries and Mutations

Queries are GET requests written more intuitively and executed more dynamically using GraphQL. Conversely, Mutations are effectively POST, PUT, or PATCH requests.

To that end, all requests made through GraphQL are functionally no different from less efficient RESTful requests, in principle. However, GraphQL makes it possible to embed conditionals into requests themselves, as well as aggregate data more cohesively into a single return of data.

Here is an example of what a query and a mutation might look like in GraphQL:

{
  hero {
    name
    # Queries can have comments!
    friends {
      name
    }
  }
}

mutation CreateReviewForEpisode($ep: Episode!, $review: ReviewInput!) {
  createReview(episode: $ep, review: $review) {
    stars
    commentary
  }
}

Source: GraphQL Docs

Schemas and Types

A schema effectively operates as a rule set for GraphQL services, whereby returned data is validated using the master definition for a given service block.

Types are object types that you define to describe the properties of the data you expect to return from your server. These are the container objects used to reference a given service block where data fields are contained.

Here is an example of how you might write a schema of GraphQL object types:

schema {
  query: Query
  mutation: Mutation
}

query {
  hero {
    name
  }
  droid(id: "2000") {
    name
  }
}

Source: GraphQL Docs

Putting It Into Practice

The cursory nature of this overview is meant to give an impression of the possibilities made available by implementing GraphQL rather than an in-depth instructional walkthrough.

In order to provide a snapshot of what can be accomplished, let's skip ahead to an example of what all of the features look like when put into practice.

query Hero($episode: Episode, $withFriends: Boolean!) {
  hero(episode: $episode) {
    name
    friends @include(if: $withFriends) {
      name
    }
  }
}

query HeroForEpisode($ep: Episode!) {
  hero(episode: $ep) {
    name
    ... on Droid {
      primaryFunction
    }
    ... on Human {
      height
    }
  }
}

Sources:
GraphQL Docs - Directives
GraphQL Docs - Inline Fragments

A great example of how to use GraphQL in the context of MongoDB using the MERN stack can be found in this ongoing tutorial series by Code Realm on YouTube:

Conclusion

I hope that this overview has given you an idea of what GraphQL can do in your next project and that your RESTful APIs will be more relaxing.

I look forward to writing an in-depth walkthrough once I have had a chance to utilize this technology in my next app design.

How to Setup a Domain on VPS: From Registration to SSL Certification

allen-woods — Thu, 04 Apr 2019 18:29:04 +0000

There is Never a "Right" Time

This article is meant for those who have been thinking about hosting their first domain, but may be holding back. The right project will come along, the right moment will line up, but not yet.

After going through this process, I can tell you that there is no better time than right now to get started hosting your first domain.

"The best way to predict your future is to create it."
— Abraham Lincoln

This walkthrough is geared toward those who choose to do things manually and "learn by doing". If this is not your approach, you can still follow along using the easy one-click versions of what I discuss.

Disclaimer: This tutorial is written from a Mac user's perspective.

There are many different ways to achieve the same outcome, but for the purposes of this article we will be discussing domain name registration through Namecheap and VPS hosting through DigitalOcean.

Ready? Let's go!

What's In a Name

The hardest part of this entire process is unfortunately one I cannot help you with -- choosing your domain name. While I can't help you come up with the exact name itself, I can share the advice I have received to help make it easier for you.

Personal or Professional?

To start off on the right foot, we must be direct: what kind of programmer are you?

Are you career focused and want to build and maintain a selection of apps as a resume pitch toward landing a role?

Are you passionate about code and find yourself constantly diving into projects beyond your assignments or daily standups for the thrill of understanding and learning new things?

The difference comes down to commitment and time scale — both important factors that will guide how to choose your first domain name. For example, a personal site may adapt to changes within your career path while a professional site is more likely to represent a specific narrative within a set domain.

	Personal	Professional
Based on	Your legal name or nickname.	Distinctive, memorable identifier.
Best for	Developers who view tech as a chapter in their overall career path, rather than a passion.	Aspiring Engineers who are passionate about code itself.
Typical use	Resume pitch while job searching.	Showcasing an ongoing body of work to build an online presence and curated brand image representative of your passion for code.
Note	Can be used by passionate programmers to build an Asch phenomenon surrounding their online presence, but works best with distinctive legal names or nicknames.	Harder to come up with and often harder to register.

The ideal case would be to have both types of domains as a "catch all" approach, but I would recommend starting with what your passion level is and use that to pick one domain to start with.

Checking Availability

Many, many, many times I have had a perfect idea in my head for a domain name, only to find out that it isn't available. This used to mean encountering landing pages on the sites I went to check for, but I have recently discovered that just because a site appears to be unregistered does not mean that it's unregistered.

This brings me to our first axiom:

A registered domain is more expensive than an unregistered domain.

Unless you really intend to make back your investment and can afford to pay the asking price, try to purchase an unregistered domain whenever possible.

To make sure your site is actually available instead of privately parked, I recommend taking the following steps:

WHOIS (ICANN)
- Look to see if the domain is registered by anyone.
Namechk
- If the site is available, look to see how much reach that name would have across social media platforms.

Once you have settled on your passion level and your domain name of choice, it's time to commit and make the purchase.

If you have read this far, you know that you're ready. Let's do it!

Registration

The domain name broker I went through was Namecheap.com. I highly recommend them when registering a domain because of how incredibly straight forward and easy to follow the overall process is.

That said, there are some things we should go over in terms of what you need to purchase and what you don't need to purchase.

What to Purchase

You should only be paying for or selecting the following items when registering your domain:

Domain name itself.
WHOIS Guard

That last one is important. WHOIS Guard effectively protects your email, address, and legal name from WHOIS searches. Without this selected, your personal information would not be anonymized and would be publicly available.

When entering "webmaster" type emails later in this guide, you can use the special "WHOIS" protected email address you are provided by this service instead of an established webmaster email address to remain anonymous.

Namecheap does make an SSL certificate available to you that lasts for a period of one year, but this is not required in order to setup HTTPS on your domain. (I learned that the hard way so you don't have to.)

We will cover how to configure Certbot to generate an SSL certificate through Letsencrypt.org toward the end of this article.

You will not really need to setup anything more advanced than this to get started. Now that your domain name is newly registered, it may take up to 72 hours for the registration to be completed. In the mean time, let's set up our hosting!

Creating A Droplet on DigitalOcean

I researched many hosting providers before I committed to a decision. The primary providers that I ultimately chose from were:

I selected DigitalOcean because their name kept getting mentioned and recommended by other devs in threads on web-development subreddits and because their free documentation has so much depth.

I am very much a "learn by doing" type of person and the predominantly DIY nature of DigitalOcean's services felt like a right fit with what I wanted — to develop skills by doing things myself.

That said, this can feel daunting for one reason in particular.

Linux

It takes a certain kind of person to make it through this tutorial. To put that more succinctly, you have to feel slightly more excitement than fear when you open bash and only see this in your terminal:

That is not very much to go on. Luckily, there are tons of resources online regarding the use of Linux and the community is very welcoming and supportive.

This brings us to our second axiom:

The more dynamic your skill set is, the more valuable you are.

You don't need to already know Linux to follow along, but placing yourself in the position of having to learn it should be bundled into your desire to embark on this experience.

Being able to navigate and use Linux, as well as being able to say that you manage your own VPS, is better than not knowing those supportive technologies first-hand.

For now, I have journeyed long into these rabbit holes and done all the research for you. Onward, to the command line!

Commanding the Line (Ubuntu)

There are a lot of Linux distributions — known as "distros" — but we will be focusing on the server version of Ubuntu Linux for this walkthrough.

Linux is versioned in varying levels of granularity all the way down to a frequency of as often as nightly build changes. However, the version type that we want to use on our VPS is something called Long Term Support or LTS for short.

As of this writing, the current LTS release is Ubuntu Server 18.04, released in April of 2018. This is what we will select to have pre-installed on to our VPS.

LTS versions remain dependable for a period of up to two years, requiring far fewer updates to your server and less maintenance to perform. We should probably take this opportunity to go over our third axiom:

Always use the LTS version.

There are not just LTS versions of Linux, but NodeJS and other frameworks as well. Ideally, you should aim to identify and use an LTS versioned stack whenever possible to reduce pain points maintaining a project. Alternatively, you can create Docker containers for your applications.

If you would like to know more about Docker, please see the following article by one of my peers at Flatiron School Seattle:

Docker Basics by Matthew Brophy

This is a lot to go through before getting started, so let's take this a step at a time. To start things off, we need to do some things on your local machine first.

Using Secure Shell (SSH)

Everything we do regarding how we interact with our VPS should be encrypted to remain secure. To accomplish this, we use Secure Shell, or "SSH" to connect. In order to prepare, before even purchasing a VPS on DigitalOcean, we need to generate a new SSH key pair.

Open terminal on your computer and enter the following command:

ssh-keygen -f ~/your-domain-name-here-rsa -t rsa -b 4096

For more, see: SSH Keygen

Be sure to replace your-domain-name-here with the name of your newly registered site.

If you are prompted that creation of the new key will overwrite an existing key, cancel. Agreeing to overwrite an existing key is a permanent and destructive act that will erase the overwritten key forever.

Now that we have the keys we need to create our Droplet on DigitalOcean, let's start building our castle.

Choosing a Droplet Type

You should generally aim for the amount of hosting you need based on your comfort level, available time, budget, and the demands of your project(s).

I would also say that there should be some element of incentivized participation trough economic pressure, whereby increased use of the VPS is insured as a result of "having to pay for it."

In my case, I knew that I wanted to build apps that would use computationally more expensive functions for some things, as well as the need to stream data in real time to achieve some of the results I wanted to accomplish. To that end, I measured twice and cut once by getting their $20 a month option.

At the time of this writing, this is what DigitalOcean offers on their $20 VPS tier:

Select the Droplet configuration that meets your criteria. Follow the setup procedure, but once you see an option button titled "Add SSH Keys" appear on screen, wait until you have read the next step before continuing.

Navigate to: DigitalOcean Droplet Pricing

Binding SSH

Back in your bash terminal, go ahead and type the following command:

pbcopy < ~/.ssh/id_rsa.pub

This will copy your personal SSH key to the clipboard, so don't select and copy any text until you have attached this key to your Droplet.

Click the "Add SSH Keys" button on DigitalOcean and paste the key's text into the form that appears. You should see a very large hash of encrypted data when pasting the text if this is successful.

For more, see: How to Upload SSH Public Keys to a DigitalOcean Account

The reason we are binding the SSH key to our Droplet in this way is because it does three things that are very important.

It disables password authentication at time of creation for the Droplet.
It makes all use of the Droplet secure over SSH from the start.
It prevents email delivery of any login information related to our VPS.

This makes sure that people can't even attempt a password access on the VPS at the moment it becomes activated, much less before we are able to login.

By default without an SSH key attached, the VPS would have password authentication enabled, which is less secure and requires manual deactivation. It also would require us to add the SSH key in a far less easy manner, although DigitalOcean does allow you to add an SSH key from the browser while in the managing editor for the Droplet itself.

The Importance of IPv6

Make sure that you have selected the checkbox for "IPv6" on your VPS options. This will generate a longer IP address that will allow your server to be accessible once the older IPv4 standard is phased out years in the future.

Many technologies provided by DigitalOcean, as well as web technologies in general, benefit from the availability of an IPv6 connection, so it's a nice option to have activated.

At this point, we are ready to communicate with our VPS for the first time and get down to business. Be sure to copy down your IPv4 address from DigitalOcean and prepare to login to your server!

Becoming a Superuser

For the sake of clarity, I will be condensing the necessary commands into coherent blocks. For those unfamiliar to the syntax, all lines beginning with a # symbol are descriptive comments, not bash commands.

ssh root@<your_server_ipv4>
# Confirm "yes" to connect.

adduser <your_first_name>
# Type a strong password and skip everything else.

usermod -aG sudo <your_first_name>
ufw app list
# You should see OpenSSH listed.

ufw allow OpenSSH
ufw enable
# Type yes to confirm.

ufw status
# You should see OpenSSH and Open SSH (v6) ALLOW from Anywhere.

rsync --archive --chown=<your_first_name>:<your_first_name> ~/.ssh /home/<your_first_name>

In your bash terminal press Command+T to create a new parallel tab. Remain logged into the "root" user in the first terminal tab. This is important in case anything goes wrong during the configuration of your user account.

Inside the parallel tab, enter the following:

ssh <your_first_name>@<your_server_ipv4>

If you are logged into your user account in the second tab, you can now toggle back to your "root" session and continue. Enter the following in the "root" user tab:

sudo nano /etc/ssh/sshd_config
# Press the down arrow to scroll the editor until you see PermitRootLogin.
# Edit the line to read: PermitRootLogin no

# Press the down arrow to scroll the editor until you see PasswordAuthentication.
# Edit the line to read: PasswordAuthentication no

# Press Ctrl + X, then Y and Enter to save and exit the editor.

sudo systemctl restart ssh

Switch back to your user account tab and enter the following:

logout
ssh <your_first_name>@<your_server_ipv4>

If all has gone well up until this point with no snags, you can now safely logout of the "root" user terminal and close all terminal tabs.

To briefly summarize what we just did:

We gained access to our VPS.
We created a new user.
We gave our user account the same powers as "root" (sudo).
We raised the firewall against everything except for SSH logins.
We allowed our user account SSH access.
We removed the "root" user from being able to login again.

The reason we removed the "root" user is because most attacks on a server will come through the "root" login. By preventing this user from accessing the system, we add a layer of security to the system.

Now that our user account has been granted the same powers, we don't need "root" to be accessible anymore.

For more, see: Initial Server Setup with Ubuntu 18.04

Setting Up the Server

Now that our VPS is secured, it's time to get everything up to speed in terms of system updates and necessary software. Log in using your user account and enter the following commands:

sudo apt-get update
sudo apt-get upgrade
# Press Y and Enter to confirm.

sudo apt-get install curl imagemagick subversion wget lynx iperf rsync
# Press Y and Enter to confirm.

sudo apt-get install unrar unzip iptraf nmap tcpdump sysstat zip
# Press Y and Enter to confirm.

sudo apt remove cmdtest
# This might say cmdtest doesn't exist, but better to be sure.
# We remove this application to allow for installation of Yarn.

sudo nano ~/.bash_aliases
# Inside the editor, add this line (without leading # symbol):
# alias node=nodejs
# Press Ctrl + X, Y and Enter to save and exit the editor.

For more, see: How to Enable .bash_aliases

A Word About NodeJs on Ubuntu
The way that the alias for NodeJS works on Ubuntu Server, a separate alias called "nodejs" must be made to point to the NodeJS install on the VPS.

The workaround we have used in the last file edit process above is to use a new alias named "node" to point to the "nodejs" command, thereby patching the node command to be canonical with the local environment. |

The ground work is nearly complete for serving our first page over HTTP. We only have two more major installs to carry out.

Installing Nginx

If you are hosting a more advanced project using a stack, such as MERN or similar, you will need to do further reading on these topics in addition to this walkthrough. For now, we just want to serve a static page over HTTPS. This is our first time going through this process, so we will stick to the basics.

The HTTP server that our VPS uses is called "Nginx". The installation is the following series of commands:

sudo apt update
sudo apt install nginx
sudo ufw app list
# The output should show new options for Nginx Full, Nginx HTTP, and HTTPS.

sudo ufw allow 'Nginx HTTP'
sudo ufw status
# The output should show ALLOW from Anywhere for Nginx HTTP and Nginx HTTP (v6).

systemctl status nginx
# The output should include "Active: active (running)".

For more, see: How To Install Nginx on Ubuntu 18.04

Now that we have Nginx setup, we need to have something to serve and a way to serve it. Nginx is a tool, but it doesn't run by itself. We'll need to setup a server block for it to run, as well as upload our "hello world" to the server.

Uploading Your Hello World

It's time to place your first static page on the VPS itself. Follow this sequence in your VPS login terminal session:

sudo mkdir -p /var/www/yourdomainname.com/html
# Be sure to replace "yourdomainname" with your domain name.

sudo chown -R $<your_first_name>:$<your_first_name> /var/www/example.com/html
sudo chmod -R 755 /var/www/yourdomainname.com

Inside of a second terminal tab pointing to your local machine, enter the following command to transfer the local root folder to the VPS root folder being used by Nginx:

scp -r /local/root <your_user>@<your_ipv4>:/var/www/yourdomainname.com/html

For more, see: Copying a Directory with SCP

If this is successful, you should see your files uploading into the server. Great, your files are on the internet now. But using an IPv4 address to reach them isn't the most attractive option. Let's fix that.

Binding Your Domain to Your Host

By default, Namecheap will park your domain name on their nameservers. These addresses associate your registered domain as an idle "parking" page that shows a form letter message suggesting your domain could be for sale.

We need to change these nameservers to reflect our VPS on DigitalOcean, as well as bind our domain name to the IP of the VPS itself. Let's go through the steps needed to complete this.

Nameservers, IP and SSL

Log into your Namecheap account and click "Manage" on your domain name. Once inside of your dashboard, scroll down to "Nameservers" and enter the following addresses:

Nameservers
ns1.digitalocean.com
ns2.digitalocean.com
ns3.digitalocean.com

Scroll down until you find an option named "Parking Page" and disable it. This will unlink the domain from the template saying "this site might be for sale" that is automatically hosted by Namecheap.

Now the domain name will point to the nameservers on DigitalOcean where the actual data of your VPS will be located and served to your visitors. The second half of binding will be carried out on DigitalOcean. Log into your DigitalOcean account and add your domain to your dashboard.

Inside of this domain's management features, you will need to create the following records:

Type	Hostname	Value	TTL
CAA	www.yourdomain.com	authorization: letsencrypt.org [`issue`]	3600
AAAA	www.yourdomain.com	directs to IPv6	3600
A	www.yourdomain.com	directs to IPv4	3600
NS	www.yourdomain.com	directs to ns1.digitalocean.com	1800
NS	www.yourdomain.com	directs to ns2.digitalocean.com	1800
NS	www.yourdomain.com	directs to ns3.digitalocean.com	1800

Binding to your VPS occurs by choosing your Droplet in the dashboard of each record entry. The IPv6 and IPv4 addresses are entered for you automatically by entering the @ symbol in those fields on DigitalOcean. Additionally, the issue flag is a dropdown menu selection within the DigitalOcean dashboard when filling out this section.

What we have just done is complete the link between the domain we registered and our VPS, as well as enable SSL certification through Letsencrypt.org. But enabling the possibility of SSL certification is not the same as being certified. Let's configure and generate an SSL certificate for our "hello world".

SSL Certification

There are two steps to completing this process. Installation of Certbot, and generation of a SSL key pair. This proved to be the trickiest part for me during my experience setting this up on my VPS, but lucky for you I am able to set you off on the right path to make this as easy as possible.

Installing Certbot

Letsencrypt.org provides a utility for issuing and renewing SSL certificates using OpenSSL. From the VPS login session terminal, the installation process is as follows:

sudo apt-get update
sudo apt-get install software-properties-common
sudo add-apt-repository universe
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install python3-certbot-dns-digitalocean
sudo certbot --nginx
sudo certbot -a certbot-dns-digitalocean -i nginx -d "*.example.com" -d example.com --server https://acme-v02.api.letsencrypt.org/directory

For more, see: Nginx on Ubuntu 18.04 LTS

Now that Certbot is installed on the VPS, we must generate and use an SSL key pair to enable it. Follow these commands to complete our SSL certification:

sudo apt install python-certbot-nginx
sudo nano /etc/nginx/sites-available/yourdomainname.com
# Locate lines that begin with: server_name
# These lines should read: server_name yourdomain.com www.yourdomain.com;
# If this is not how it reads, update the lines to match.

sudo nginx -t
# The output should show no errors.

sudo systemctl reload nginx
sudo ufw status
# Output should show ALLOW from Anywhere on OpenSSH and Nginx HTTP

sudo ufw allow 'Nginx Full'
sudo ufw delete allow 'Nginx HTTP'
sudo ufw status
# Confirm that Nginx HTTP has been disabled from the ALLOW from Anywhere list.

If all has gone well, the following command will be the last step in the process:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

For more, see: How To Secure Nginx with Let's Encrypt on Ubuntu 18.04

Conclusion

This has been quite the journey. If you have paced yourself and made it through this process, give yourself a standing ovation because this really is a rather "involved" undertaking.

The main point of this article is to show how important it is to set yourself ambitious but obtainable goals. Yes, it was difficult and complicated, but the achievement of having accomplished something that pushed you past your prior perception of your personal limits makes it all worth it.

I hope that anyone reading this from a novice perspective comes away from this walkthrough with a greater sense of confidence and the beginning of a whole new set of skills. I had no experience in this, just as you might not have. Yet, here we are.

There is no telling how far you will go from here, but the odds are good it will be very far. You have already begun to master an important concept that a famous quote sums up nicely:

Whether you believe you can do a thing or not, you're right.
— Henry Ford

Happy hosting!

If you have questions, I will do my best to answer in the comments.
You can visit my own humble "hello world" of a random doodle at The Supertask.

Defining Private Members in JavaScript Classes: How and Why

allen-woods — Thu, 21 Mar 2019 22:09:40 +0000

Context

One of the more important concepts in Object Oriented Programming is the use of private properties and methods, collectively referred to as private members from here on.

The basic idea is that any data that is critical data to an application should be made private to prevent catastrophic faults or exploits that would otherwise be possible if those private members were accessible.

While it is possible to achieve truly private members using technologies such as webpack or ES6 modules, I will be discussing how you can achieve a very similar result using closures, Symbol(), and WeakMap().

For more details on this subject that go beyond the scope of this article, please give the inspiration for this article, by Axel Rauschmayer a read.

Naming Convention

When researching how to accomplish private members on classes in vanilla JavaScript, I found several articles and Stackoverflow threads suggesting the use of a common naming convention that places underscores at the beginning of variable names to indicate a "private" status.

class NamingConventionClass {
  constructor() {
    this._hidden = "Can you see me?";
  }
};

The problem with this approach is that it is a way to indicate to other programmers whether a member is intended to be private or not. In short, something that is "_hidden" through naming convention is still visible.

let peekaboo = new NamingConventionClass();
console.log(peekaboo._hidden + '...Yes I can.');

// outputs 'Can you see me? ...Yes I can.'

This is a problem if the intention is to keep certain members on our class objects inaccessible from the outside. Anybody using inspect in their browser could manipulate variables with undesirable results that could have real consequences beyond DOM manipulation.

We need some sort of private container to place our private members into without losing track of either where they are or what instance they belong to.

Enter the WeakMap

The best solution provided by vanilla JavaScript that I have found (as of this writing) is the WeakMap class. A WeakMap is simply a collection of keys and values. Each key must be a reference to an object and each corresponding value can be any arbitrary data. Because each key, value pair is added at the same time, their indexes always correspond.

let myWeakMap = new WeakMap();

The main advantage of using WeakMaps as opposed to other options provided by the map API is that their references are held "weakly", allowing for garbage collection. This means that if the data referenced in the WeakMap is deleted, such as the destruction of a class instance, the allocation of the WeakMap will be removed from memory along with it.

One way to use WeakMaps to obfuscate private members from a class is to do something similar to the example provided in Axel's article, as follows:

let _variableOne = new WeakMap();
let _variableTwo = new WeakMap();

class WeakMapPrivateMembers {
  constructor(valueOne, valueTwo) {
    _variableOne.set(this, valueOne);
    _variableTwo.set(this, valueTwo);
  }
  combineValuesInString() {
    let v1 = _variableOne.get(this);
    let v2 = _variableTwo.get(this);
    return `${v1}, ${v2}`;
  }
};

const hideTwoVariables = new WeakMapPrivateMembers('foo', 'bar');
console.log(hideTwoVariables.combineValuesInString());

This approach has at least three major problems listed below.

WeakMaps are accessible in global namespace.
WeakMaps are inefficiently defined for each variable.
WeakMaps can still be accessed and overwritten.

We're making progress, but now we have a problem based on the scope that our data is being stored in. We need to redefine how our class is being instantiated in such a way that our WeakMap data can remain inaccessible.

Class as Closure

It turns out that you can wrap an entire class definition inside of an Immediately Invoked Function Expression, or IIFE (pronounced "iffy"). The basic syntax of how this would look is as follows:

const MyClosureClass = ((param1, param2, param3) => {

  // Define a variable inside the scope of the closure to keep it hidden.
  // This WeakMap will act as a repository for all instances of this class.

  const _wm = new WeakMap();

  return class MyClosureClass {
    constructor(param1, param2, param3) {
      // add this class instance's private members

      _wm.set(this, {
        property1: param1,
        property2: param2,
        property3: param3
      });
    }
    get privateMembers() {
      // return the object stored at object key of "this"

      return _wm.get(this);
    }
  };
})();

let myPrivacy = new MyClosureClass("something important");

console.log(myPrivacy.privateMembers);
// The above line will return 'something important'

console.log(myPrivacy.params);
// The above line will return undefined

console.log(_wm);
// The above line will return undefined as well

What this means is that our class can now be instantiated with incoming data that can only be obtained through sanctioned getter methods. Also, we can nest an object containing a more complex structure of private members we want to associate with the class instance.

We could take this a step further and apply transformations to the data before returning it, or simply use the privately stored value(s) to perform conditionals that dictate the return of safer values.

// (code abridged)

    // rewrite the getter method as a confirmation method
    hasPrivateMembers() {
      return !!_wm.get(this);
    }

// (code continued)

It is important to note that you should be writing a helper method in the scope of your closure to abstract the need to type _wm.get(this).params[privateMemberName] every time you want to access the private member privateMemberName, as shown below.

// Inside the scope of our closure...

const _self = function(objRef) {
  _wm.get(objRef);
}

Embedding Symbols to Introduce Entropy

If you really, really, really need something to be private, other options are more suitable for this -- securing data within your database with no client side visibility being chief among them.

However, if you want to take the privacy of client side data to a paranoid level, you can also nest your private members deeper by using a Symbol to point to them.

// (code abridged)
    constructor(param1, param2, param3) {
      _wm.set(this, {
        [Symbol('root')]: {
          property1: param1,
          property2: param2,
          property3: param3
        }
      });
    }
// (code continued)

The primary drawback to applying this emphatic level of privacy is that you need a rather convoluted helper method to access these private members. However, if you want to pursue this route to explore how it operates, the helper method would look something like this:

// Inside the scope of our closure...

const _self = function(objRef) {
  let obj = _wm.get(objRef)[
    Object.getOwnPropertySymbols( _wm.get(objRef) )[0]
  ];

  return obj;
}

Conclusion

If you don't want to rely on an entire framework to do the work for you, using a WeakMap and an IIFE wrapper to convert your classes into closures is a terrific solution to private members on classes as of this writing.

I hope that this article can help guide you in improving your design considerations when building OOJS applications that require both public and private members.

Here in its final form is a reference of our example class utilizing everything we have just discussed.

const MyClosureClass = ((param1, param2, param3) => {

  const _wm = new WeakMap();

  const _self = function(objRef) {
    let obj = _wm.get(objRef)[
      Object.getOwnPropertySymbols( _wm.get(this) )[0]
    ];
    return obj;
  };

  return class MyClosureClass {
    constructor(param1, param2, param3) {

      _wm.set(this, {
        [Symbol('root')]: {
          property1: param1,
          property2: param2,
          property3: param3
        }
      });
    }
    get privateMembers() {
      return _self(this);
    }

    getSpecificMember(memberName) {
      return _self(this)[memberName];
    }

    hasPrivateMembers() {
      return !!_self(this);
    }
  };
})();

JavaScript: A Primer for Rubyists

allen-woods — Thu, 07 Mar 2019 18:20:01 +0000

When I first began to learn Ruby at Flatiron, I brought my previous experience with JavaScript along for the journey in hopes of narrowing the gap between the two syntaxes. While understanding some key concepts of programming fundamentals was helpful, I soon found myself in the far reaches of a very alien landscape of implied abstraction that seemed to counter everything I had previously known.

Now that I have trekked these past 6 weeks from the southern shores of simple do and def, all the way to the northern highlands of Rails 5, I find myself ironically jarred by setting foot in the familiar territory of JavaScript again.

Herein I will endeavor to describe the fundamental differences between JavaScript and Ruby syntax from a Rubyist's perspective and offer my strategies for achieving better mental dexterity when alternating between these two languages.

Explicit Implications

At the ground level, the major disconnect between Ruby and JavaScript is that Ruby is considered to be "strongly typed," meaning data types relate to one another in very specific ways; while JavaScript is considered to be "weakly typed," meaning data types are much more mutable and can relate to one another in less specific ways.

Where Ruby allows for implied logic with explicit rules for its data types, JavaScript requires explicit logic with more implied rules for its data types.

A perfect example of the difference in the rule sets is how Ruby treats integers and floating point numbers as separate data types that must be converted to act on each other, while JavaScript simply has numbers that can be either integers or floating values.

This clearly means there is a lot more freedom in a programmer's range of motion when working with JavaScript, however, that same range of freedom can yield unexpected results when embracing it from the background of a Rubyist.

A perfect example of the divide in how logic is treated differently is the fact that unless a value is explicitly returned using the return bare word in JavaScript, functions have an undefined return value.

This flies in the face of Ruby conventions that favor implied returns at the final line of a method. But if one thing has become clear so far on my journey of learning to code, it is that repetition breeds knowledge and knowledge breeds skill. In other words, doing things in a standardized way helps cement concepts. To that end, I have found that using either a commented return above my last line or actually applying the return bare word to my last line in Ruby helps me stay grounded across both languages.

Do or Do Not, There Is No Pry

There are do loops in JavaScript that emulate behavior that is similar to the do blocks found in Ruby, but they have a very important difference.

The do blocks in Ruby do not trigger if either their condition isn't met or the iterator they are passed to is unable to fire at least once.
In JavaScript, do loops evaluate their condition only after executing their code.

This means that do loops always trigger at least once in JavaScript, as illustrated below.

The differences in how do behaves between these two languages presents the first challenge when navigating JavaScript syntax as a Rubyist. The muscle memory we develop in Ruby can insert itself all too easily when we're writing in JavaScript without us even catching it when it happens. Luckily, there is a strategy we can use in Ruby to help minimize this growing pain.

Curly Boys to the Rescue

Some situations will still require you to employ the do end syntax, such as embedding logic into .erb files. But for the most part, the best way I have found to develop cross-language muscle memory is to pass blocks in Ruby using curly braces whenever possible.

The added advantage to adopting this syntax is it leaves the possibility open for method chaining for those occasions where the rule of adhering to functional readability can be flexed to write logic as a single line.

The case for using curly braces over do end is strengthened by adding shorthand key: value hash notation into the mix. When used in combination, these conventions of syntax apply to not only JSON but also CSS, creating a much more unified vocabulary of muscle memory overall.

Perhaps the biggest difference when adjusting to JavaScript that ranks very near the least popular among Rubyists is the lack of native support for a utility resembling binding.pry or byebug.

While there are solutions for this as mentioned in this article by Kevin Kim that are functionally synonymous with pry in the context of JavaScript, problems that occur when developing front-end code tend to show up as nasty surprises in the browser the majority of the time.

These situations do not necessarily imply that a given project will be created on NodeJS or that a given bug will crop up when testing in Chrome. This means that despite having utilities available under NodeJS or Chrome's developer tools, there will be times where these may not apply.

Enter our hero: console.log()

It's Better Than Bad, It's Good

The simplest explanation of how console.log() works is that it is a utility function that prints a copy of its string argument to the console window of the browser. By interpolating variables into a string using template literals, an approximation of the same behavior as pry can be achieved; albeit not as user friendly.

It is important to note that depending on the scope of the function where console.log() is called, it may be impossible to render the output of the function in the console.

Because of this, it is best to be aware of how to use console.log(), but factor in the availability of debugging tools when deciding how to develop the front-end code of a project.

Template Literals

Thankfully, the learning curve for interpolating variables into strings is a lot more straight forward. The syntax is nearly identical, as shown here.

Fun fact: the type of the "back tick" character is something called a "diacritic" and the name of the back tick character itself is a "grave". As a way of remembering what type of string quotation allows for interpolation in JavaScript, you can use the mental association:

"Interpolating variables is 'gravely' important"

Inverted Instantiation

One of the most difficult aspects of transitioning to JavaScript from Ruby is the muscle memory involved in instantiating a class. While we have always written a call to Class.new in Ruby, now we have to come to terms with new Class(). It may seem like a small difference, but it can have quite an impact on the flow of a project.

Because the majority of the class instantiation I write in Ruby now occurs inside of Rails controllers, a strategy that I have found for standardizing between these two syntaxes is to completely abstract my #new action into a before_action helper method. This simultaneously declutters my code and allows me to mentally conceptualize these two situations as unique, evading crosstalk.

Exhibitionism in ES6

Now that we are taking how classes are instantiated into consideration, let's step back a moment and review how helper methods like before_action are defined. According to Rails convention, these methods are defined below the private bare word inside our controllers. What this means is that the helper methods are private to that controller instance when it is created during a server request. Things work very differently in JavaScript.

As of this writing, all properties and methods of all class instances are effectively (and natively) public in JavaScript.

Returning to the point that JavaScript implies how data types interact, this implied system of relationships also extends to function scope. By exploiting aspects of how function scope works in JavaScript, it is possible to approximate the same behavior as the private bare word in Rails, but with a lot more work and high level understanding involved.

Currently, the intricacies of available means of privatizing class properties and methods extends beyond the scope of my skillset and the topic is a very deep rabbit hole that exceeds the reach of this article. More information about this process can be found here by Chris Ferdinandi.

That said, it is important to understand that unlike working in Ruby, acting upon data in JavaScript does not always act upon data that already exists, but rather can create data through the expectation that data exists.

One prime example is assigning a value to an object property that does not exist, thereby creating and appending it to the object in the process.

This article is being published while the most recent standard of JavaScript is still ES6. However, the next iteration of the standard — currently referred to as ESNext — is anticipated for release some time in 2019 or soon after. With it will come native support for private class properties and methods that will remove the necessity of using closures to conceal class variables.

Let it Let

Unfortunately there is one elephant of syntax difference in the room that is large enough no amount of workflow adjustments in either language can hide it. This elephant is the diverse ways in which the structure of statements and the use of bare words differ between these two languages.

The purpose of this article is to provide tactics for reducing the impact of higher level differences when writing in JavaScript from a Rubyist's perspective.

Due to the breadth of the information regarding exact syntactical differences you will encounter, I recommend reading this excellent article by Edozié Izegbu to better prepare for these inevitable sticking points.

Conclusion

While my journey of learning to code is only just beginning, I hope that these strategies can help to guide or inspire you to begin standardizing how you approach writing in multiple languages.