One place for hosting & domains

      Projects

      How To Probe the Depths of Nautically-Themed Open-Source Projects Using Moby Dick


      Introduction

      Despite being a commercial failure after its first publication, Herman Melville’s allegorical adventure novel Moby-Dick; or, The Whale is today one of the most popular and influential novels in the American canon. Artists as diverse as William Faulkner, Ralph Ellison, and Bob Dylan have acknowledged the novel’s impact on their work, and one can spot references to it in films, television, music, and, of course, open-source projects.

      In this article, we will analyze several nautically-themed open-source projects and how they pay tribute to Moby-Dick.

      Warning: While it isn’t necessary that you read Moby-Dick prior to reading this article, this article does contain a few spoilers. If you haven’t read the novel but would like to, you may want to hold off from reading this article until you’ve finished it.

      Prerequisites

      To follow along with this tutorial, you’ll need:

      • Familiarity with 19th-century literature.
      • An appreciation for nautical puns.
      • An adventurous disposition. For example, whenever you find yourself growing grim about the mouth, you account it high time to get to sea as soon as you can.

      Docker

      Docker logo

      Docker is an open-source program that performs operating system-level virtualization, also known as containerization. The influence of Moby-Dick is obvious with this project: Docker’s logo and mascot is a whale affectionately known as Moby Dock. However, there are some substantial differences between Moby Dick and Moby Dock.

      First, Moby Dock’s species isn’t immediately obvious. It’s clear from the beginning of the novel that Moby Dick is a sperm whale, and while it’s possible that Moby Dock is a sperm whale as well, there are several clues that suggest otherwise:

      • The head: Sperm whales have distinctively large, block-shaped heads. Moby Dock, however, has a flat forehead with a snout that slopes smoothly downward to its jaw, which is more suggestive of a right whale or bowhead whale.
      • The blowhole: Moby Dock is always seen from its left side. As any whaler worth their salt knows, a sperm whale’s blowhole always skews slightly to the left side of its head. No blowhole is visible in any known images of Moby Dock, another clue that it isn’t a sperm whale.
      • The fins: Moby Dock doesn’t seem to have any pectoral fins. All sperm whales are born with pectoral fins, adding another strike to the “Moby Dock is a sperm whale” theory. That said, all whales have pectoral fins, so this begs the question of whether or not Moby Dock is a whale at all.

      Another important difference between these Mobys is that Moby Dock is helpfully carrying a few stacks of containers; Moby Dick would never be so accommodating. In fact, one can easily imagine Moby Dick going out of his way to knock over such a neatly organized pile of shipping containers. Perhaps Moby Dock is meant to be seen as a warmer, friendlier cousin of Moby Dick. After all, it’s probably bad marketing to associate one’s product with a ferocious leviathan bent on destroying everything in its path.

      OpenFaaS

      OpenFaaS logo

      OpenFaaS is an open-source project that aims to make serverless functions simple through the use of Docker containers, allowing users to run complex infrastructures with far greater flexibility and without the fear of vendor lock-in.

      The OpenFaaS logo focuses entirely on a whale’s tail, which is significant because Melville dedicates an entire chapter to describing the tails of sperm whales. In it, Ishmael reveals his deep appreciation of whales’ tails:

      Such is the subtle elasticity of [the tail], that whether wielded in sport, or in earnest, or in anger, whatever be the mood it be in, its flexions are invariably marked by exceeding grace. Therein no fairy’s arm can transcend it.

      The OpenFaaS whale is shown to be peaking its flukes, presumably as it is about to dive. In the same chapter, Ishmael opines that “excepting the sublime breach…this peaking of the whale’s flukes is perhaps the grandest sight to be seen in all animated nature.” Perhaps the OpenFaaS team chose a whale’s tail as their logo to convey the grace and power that OpenFaaS brings to managing functions. It could even be that the whale is “diving in” to the realm of functions as a service.

      Because OpenFaaS is closely related to Docker, it’s obvious why the project’s logo also features a whale. However, are these supposed to be the same whale? Let us not forget that Moby Dick was believed to be “ubiquitous”, with sailors swearing up and down that they had encountered him “in opposite latitudes at one and the same instant of time.” This may be a clue that Moby Dock and the OpenFaaS whale are indeed one and the same.

      Perhaps in choosing this logo the OpenFaaS team was trying to signal their hope that the framework would become ubiquitous in future software projects. Interestingly, while an omnipresent whale may strike fear in the hearts of whalers, software is generally seen as safer and more secure if it’s widely used. The OpenFaaS team should be thankful that coders are generally less superstitious than whalers.

      Kubernetes

      Kubernetes logo

      Kubernetes is an open-source container orchestration system that helps to automate the deployment, scaling, and management of applications. The name “Kubernetes” comes from the Greek word “κυβερνήτης,” which translates to English as “captain” or “helmsman.” Appropriately, its logo consists of a ship’s wheel, or helm, conveying the control and steadiness required to manage complex container orchestration with ease.

      Curiously, the Pequod doesn’t have a wheel; instead, it has a tiller made out of a whale’s jawbone. This is seen by some readers as underscoring the shared histories of Captain Ahab and the ship, as Ahab lost his leg to the great white whale and replaced it with a whalebone prosthesis.

      Though a helm or tiller can convey steadiness and control, as the Kubernetes logo designers intended, Moby-Dick shows us the deeper questions that the project maintainers might have brushed aside. Who is at the helm when it comes to Kubernetes? Even more, who is at the helm in our everyday lives? Do we drive software, or does software drive us? Of all these things the helm is the symbol.

      MySQL

      MySQL logo

      MySQL is the world’s most widely deployed open-source database management system (DBMS). MySQL’s logo features the outline of a dolphin, affectionately known as Sakila.

      While dolphins aren’t prominently featured in the plot of Moby-Dick, Melville discusses them at length in one of the books famous pseudoscientific asides. In Chapter 32, “Cetology,” Ishmael refers to dolphins as “Huzza Porpoises,” so called because sailors see them as an omen of good luck:

      Their appearance is generally hailed with delight by the mariner…. If you yourself can withstand three cheers at beholding these vivacious fish, then heaven help ye; the spirit of godly gamesomeness is not in ye.

      Mayhaps the MySQL developers chose a dolphin to represent their DBMS to impart this same sense of hopeful joy to those who use it. By associating the database with a dolphin, they hope users will see it as being similarly fast, agile, and fun-loving. After all, who doesn’t have fun running correlated subqueries?

      MariaDB

      MariaDB logo

      MariaDB is a community-supported fork of MySQL, as indicated by its similarly nautical logo. Both the MariaDB and MySQL logos include the respective RDBMS’s name and feature an aquatic animal: in MariaDB’s case, this animal is a pinniped.

      Interestingly, there’s some confusion about what kind of animal is depicted in the MariaDB logo. According to the project’s trademarks page, the animal in the logo is a sea lion. However, some members of the MariaDB community see it as a seal. MariaDB’s official sources are fairly consistent in referring to their mascot as a sea lion, though not always. Certainly, the mascot’s shape does seem to more closely resemble that of a sea lion, but it’s also missing the telltale ears which would distinguish it as such.

      The idea that human perception is inherently biased and unreliable runs as a theme throughout the novel. Perhaps by keeping the pinniped’s species vague, the MariaDB team is making a Melvillian comment on how truth isn’t always obvious and, in some cases, can never be known for certain. Is it a seal or a sea lion? Is Moby Dick real or imagined? Is Vim or Emacs the superior text editor? Riddles like these abound throughout the world we live in, which, like a magician’s glass, to each and every man in turn but mirrors back his own mysterious self. Great pains, small gains for those who ask the world to solve them.

      Of course, it’s also possible that the logo is simply meant to represent a sea lion. Perhaps when the MariaDB team asked the designer to draw ears, they responded “I would prefer not to.”

      Conclusion

      Clearly, Melville’s influence extends far beyond the realm of literature, and well into the world of open-source technology. As this article has highlighted, these five projects (and likely many more) pay homage to his great whaling tale through subtle references in their names and logos, as well as how they challenge our perceptions of truth and human nature.

      We hope that by reading this article, you’ll go on to create your own Melville-inspired, nautically-themed, open-source project. Here are a few ideas to help you get started:

      • Ishmael: an application that turns any server process into an orphan process.
      • Starbuck: An uptime monitor that swears it will keep everything under control, but in the end just gives up and lets the system crash.
      • Stubb: A program that purports to do lots of important work, but really just takes credit for work done by other applications.

      Note: Some readers may be wondering why this article hasn’t yet mentioned DigitalOcean’s own Sammy the Shark. The simple reason is that Sammy has little in common with the sharks depicted in Moby-Dick. Throughout the novel, sharks are depicted as ravenous beasts dominated by instinct. Melville’s sharks eat anything and everything in their path, and are violent, dangerous creatures who pose a serious risk to the crew of the Pequod (though not as great a risk as whales, apparently).

      Clearly, Melville never encountered a shark like Sammy. After all, Sammy is a vegetarian, and a very friendly one at that!





      Source link

      How to Use Node.js and Github Webhooks to Keep Remote Projects in Sync


      Introduction

      When working on a project with multiple developers, it can be frustrating when one person pushes to a repository and then another begins making changes on an outdated version of the code. Mistakes like these cost time, which makes it worthwhile to set up a script to keep your repositories in sync. You can also apply this method in a production environment to push hotfixes and other changes quickly.

      While other solutions exist to complete this specific task, writing your own script is a flexible option that leaves room for customization in the future.

      GitHub lets you configure webhooks for your repositories, which are events that send HTTP requests when events happen. For example, you can use a webhook to notify you when someone creates a pull request or pushes new code.

      In this guide you will develop a Node.js server that listens for a GitHub webhook notification whenever you or someone else pushes code to GitHub. This script will automatically update a repository on a remote server with the most recent version of the code, eliminating the need to log in to a server to pull new commits.

      Prerequisites

      To complete this tutorial, you will need:

      • One Ubuntu 16.04 server set up by following the Ubuntu 16.04 initial server setup guide, including a non-root user with sudo privileges and a firewall.
      • Git installed on your local machine. You can follow the tutorial Contributing to Open Source: Getting Started with Git to install and set up Git on your computer.
      • Node.js and npm installed on the remote server using the official PPA, as explained explained in How To Install Node.js on Ubuntu 16.04. Installing the distro-stable version is sufficient as it provides us with the recommended version without any additional configuration.
      • A repository on Github that contains your project code. If you don’t have a project in mind, feel free to fork this example which we’ll use in the rest of the tutorial.

      Step 1 — Setting Up a Webhook

      We’ll start by configuring a webhook for your repository. This step is important because without it, Github doesn’t know what events to send when things happen, or where to send them. We’ll create the webhook first, and then create the server that will respond to its requests.

      Sign in to your GitHub account and navigate to the repository you wish to monitor. Click on the Settings tab in the top menu bar on your repository’s page, then click Webhooks in the left navigation menu. Click Add Webhook in the right corner and enter your account password if prompted. You’ll see a page that looks like this:

      Webhooks Page

      • In the Payload URL field, enter http://your_server_ip:8080. This is the address and port of the Node.js server we’ll write soon.
      • Change the Content type to application/json. The script we will write will expect JSON data and won’t be able to understand other data types.
      • For Secret, enter a secret password for this webhook. You’ll use this secret in your Node.js server to validate requests and make sure they came from GitHub.
      • For Which events would you like to trigger this webhook, select just the push event. We only need the push event since that is when code is updated and needs to be synced to our server.
      • Select the Active checkbox.
      • Review the fields and click Add webhook to create it.

      The ping will fail at first, but rest assured your webhook is now configured. Now let’s get the repository cloned to the server.

      Step 2 — Cloning the Repository to the Server

      Our script can update a repository, but it cannot handle setting up the repository initially, so we’ll do that now. Log in to your server:

      Ensure you're in your home directory. Then use Git to clone your repository. Be sure to replace sammy with your GitHub username and hello_hapi with the name of your Github project.

      • cd
      • git clone https://github.com/sammy/hello_hapi.git

      This will create a new directory containing your project. You'll use this directory in the next step.

      With your project cloned, you can create the webhook script.

      Step 3 — Creating the Webhook Script

      Let's create our server to listen for those webhook requests from GitHub. We'll write a Node.js script that launches a web server on port 8080. The server will listen for requests from the webhook, verify the secret we specified, and pull the latest version of the code from GitHub.

      Navigate to your home directory:

      Create a new directory for your webhook script called NodeWebhooks:

      Then navigate to the new directory:

      Create a new file called webhook.js inside of the NodeWebhooks directory.

      Add these two lines to the script:

      webhook.js

      var secret = "your_secret_here";
      var repo = "/home/sammy/hello_hapi";
      

      The first line defines a variable to hold the secret you created in Step 1 which verifies that requests come from GitHub. The second line defines a variable that holds the full path to the repository you want to update on your local disk. This should point to the repository you checked out in Step 2.

      Next, add these lines which import the http and crypto libaries into the script. We'll use these to create our web server and hash the secret so we can compare it with what we receive from GitHub:

      webhook.js

      let http = require('http');
      let crypto = require('crypto');
      

      Next, include the child_process library so you can execute shell commands from your script:

      webhook.js

      const exec = require('child_process').exec;
      

      Next, add this code to define a new web server that handles GitHub webhook requests and pulls down the new version of the code if it's an authentic request:

      webhook.js

      http.createServer(function (req, res) {
          req.on('data', function(chunk) {
              let sig = "sha1=" + crypto.createHmac('sha1', secret).update(chunk.toString()).digest('hex');
      
              if (req.headers['x-hub-signature'] == sig) {
                  exec('cd ' + repo + ' && git pull');
              }
          });
      
          res.end();
      }).listen(8080);
      

      The http.createServer() function starts a web server on port 8080 which listens for incoming requests from Github. For security purposes, we validate that the secret included in the request matches the one we specified when creating the webhook in Step 1. The secret is passed in the x-hub-signature header as an SHA1-hashed string, so we hash our secret and compare it to what GitHub sends us.

      If the request is authentic, we execute a shell command to update our local repository using git pull.

      The completed script looks like this:

      webhook.js

      const secret = "your_secret_here";
      const repo = "~/your_repo_path_here/";
      
      const http = require('http');
      const crypto = require('crypto');
      const exec = require('child_process').exec;
      
      http.createServer(function (req, res) {
          req.on('data', function(chunk) {
              let sig = "sha1=" + crypto.createHmac('sha1', secret).update(chunk.toString()).digest('hex');
      
              if (req.headers['x-hub-signature'] == sig) {
                  exec('cd ' + repo + ' && git pull');
              }
          });
      
          res.end();
      }).listen(8080);
      

      If you followed the initial server setup guide, you will need to allow this web server to communicate with the outside web by allowing traffic on port 8080:

      Now that our script is in place, let's make sure that it is working properly.

      Step 4 - Testing the Webhook

      We can test our webhook by using node to run it in the command line. Start the script and leave the process open in your terminal:

      • cd ~/NodeWebhooks
      • nodejs webhook.js

      Return to your project's page on Github.com. Click on the Settings tab in the top menu bar on your repository's page, followed by clicking Webhooks in the left navigation menu. Click Edit next to the webhook you set up in Step 1. Scroll down until you see the Recent Deliveries section, as shown in the following image:

      Edit Webhook

      Press the three dots to the far right to reveal the Redeliver button. With the node server running, click Redeliver to send the request again. Once you confirm you want to send the request, you'll see a successful response. This is indicated by a 200 OK response code after redelivering the ping.

      We can now move on to making sure our script runs in the background and starts at boot. Use CTRL+C stops the node webhook server.

      Step 5 — Installing the Webhook as a Systemd Service

      systemd is the task manager Ubuntu uses to control services. We will set up a service that will allow us to start our webhook script at boot and use systemd commands to manage it like we would with any other service.

      Start by creating a new service file:

      • sudo nano /etc/systemd/system/webhook.service

      Add the following configuration to the service file which tells systemd how to run the script. This tells Systemd where to find our node script and describes our service.

      Make sure to replace sammy with your username.

      /etc/systemd/system/webhook.service

      [Unit]
      Description=Github webhook
      After=network.target
      
      [Service]
      Environment=NODE_PORT=8080
      Type=simple
      User=sammy
      ExecStart=/usr/bin/nodejs /home/sammy/NodeWebhooks/webhook.js
      Restart=on-failure
      
      [Install]
      WantedBy=multi-user.target
      

      Enable the new service so it starts when the system boots:

      • sudo systemctl enable webhook.service

      Now start the service:

      • sudo systemctl start webhook

      Ensure the service is started:

      • sudo systemctl status webhook

      You'll see the following output indicating that the service is active:

      Output

      ● webhook.service - Github webhook Loaded: loaded (/etc/systemd/system/webhook.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-08-17 19:28:41 UTC; 6s ago Main PID: 9912 (nodejs) Tasks: 6 Memory: 7.6M CPU: 95ms CGroup: /system.slice/webhook.service └─9912 /usr/bin/nodejs /home/sammy/NodeWebhooks/webhook.js

      You are now able to push new commits to your repository and see the changes on your server.

      From your desktop machine, clone the repository:

      • git clone https://github.com/sammy/hello_hapi.git

      Make a change to one of the files in the repository. Then commit the file and push your code to GitHub.

      • git add index.js
      • git commit -m "Update index file"
      • git push origin master

      The webhook will fire and your changes will appear on your server.

      Conclusion

      You have set up a Node.js script which will automatically deploy new commits to a remote repository. You can use this process to set up additional repositories that you'd like to monitor. You could even configure it to deploy a website or application to production when you push your repository.



      Source link