Forem: Audrey Hayes

Glossary of Software Development Terms

Audrey Hayes — Thu, 15 Oct 2020 10:10:56 +0000

Why a glossary?

When I first entered the field of software development, one of the biggest barriers to overcome was being unfamiliar with the many words seasoned developers used daily.

I'd like to help out newer generations of juniors by collating a list of helpful terms to be aware of when you are trying to land that first job.

Many of the terms listed below are, of course, highly dependant on the area of software development you work in as well as the particular lingo used in your workplace. I've attempted to keep them as general as possible.

Please shout out in the comments if you have suggestions of terms to add or alternative definitions for the ones I've already included!

Glossary

Build

'Building' is a fairly general term, and it can refer to anything that is needed to go from editable source material (source code, scripts, raw data files, etc.) to a shippable software product. Building can (and usually does) involve several steps, such as pre-processing, compiling, linking, converting data files, running automated tests, packaging, etc.

Build Pipeline

A pipeline is a set of automated processes that allow developers to reliably and efficiently compile, build and deploy their code to their production platforms. The pipeline process is often referred to as CI/CD (Continuous Integration/Continuous Development). The process is generally run automatically when deploying a piece of software (see 'Deploy' definition).

Compile

The act of taking a higher-level language (like TypeScript) and translating it into a language that a platform understands (such as JavaScript if you want your code to run on a browser platform)

Dependencies

Pieces of software external to your program that your program uses in order to run. There are 'dev dependencies', which are pieces of software (i.e. libraries, frameworks, packages) that are only used during the initial stages of writing source code (the development stage). A linting tool is an example of a dev dependency. They are generally removed during the build process in order to make a deployed program smaller. Dependencies required in order for the deployed program to run in production are kept.

Deploy

To take built artefacts (the results from 'building') and either copy them to a server, or execute them on a server.

Linting

The automated checking of source code for programmatic and stylistic errors.

Minification

The process of removing unnecessary spaces and line breaks while shortening variable and function names to optimise file size. It’s one of the main methods used to reduce load times and bandwidth usage on websites.

Module Bundler

A tool that takes pieces of code (i.e. Javascript) and its dependencies and bundles them into a single file, usually for use in the browser. Popular module bundlers are webpack, browserify, and rollup.

Package Manager

A package manager is a programming language’s tool to create project environments and easily import external dependencies. For example, npm is a package manager for node

Preprocessor

A program that translates input data into output data that is then used in another program (like a compiler). A preprocessor can also add functionality that doesn't natively exist in the output language.

A CSS preprocessor (like Sass) is a program that lets you generate CSS from the preprocessor's own unique syntax.

Release

Distributing software to the end user or consumer. In CI/CD (see 'Build' definition), a release is made any time a piece of software is updated. They are associated with a specific version number or name (see 'Versioning' definition).

Task Runner

A way of automating common tasks. Gulp is an example of a task runner.

Transpile

A specific term for taking source code written in one language and transforming into another language that has a similar level of abstraction. It can also mean translating from one version to another version in the same language (i.e. transpiling JavaScript version ES6 into ES5).

Versioning

The act of assigning unique version names or unique numbers to a release (see 'Release' definition). To make version descriptions more cohesive across the field of software development, there are versioning schemes widely used such as SemVer.

Watching

The act of a program 'watching' for changes in your source code and then taking some kind of action when a change is detected. Actions taken could be re-building your source code or reloading the browser to show new changes.

🔐 Intro to managing secrets using Mozilla SOPS 🔐

Audrey Hayes — Sat, 02 May 2020 16:38:46 +0000

It should go without saying that secrets, such as passwords and API keys, should never be committed to any repository hosting services such as Github or GitLab in plaintext.

But how to share secrets with your team and maintain version control?

The old classic: Vault

One solution is to provision a Vault server, which has built-in access control and secrets management.

You can then write scripts to automatically fetch a project's secrets according to the current environment using Vault's API and know that a lot of the work to secure access to those secrets is being done for you.

Potential drawbacks

However, the drawbacks to this approach are the additional overhead and cost to maintain Vault on a server (most likely on a Kubernetes cluster in the cloud).

For small organisations without a dedicated DevOps team, you also need to have at least one expert on hand to maintain and debug the vault in the event it goes down, or more likely is "sealed".

In fact, every time a node in the cluster is restarted by your cloud provider (which depending on your pricing options, can occur fairly regularly) it will automatically seal the vault and require someone to manually port-forward into the cluster to "unseal" it with the appropriate set of access keys.

Relying on a secrets management system that affects every project when something goes wrong is less than ideal.

SOPS for the win (with caveats 😉)

Mozilla SOPS (short for Secrets OPerationS) is a neat little tool for encrypting files in formats such as YAML, JSON and ENV.

For example, say you have a simple YAML file storing the following secret:

// values.yaml
super: secret

You can encrypt this file by running sops -e -i values.yaml, which will output something like this:

// values.yaml
super: ENC[AES256_GCM,data:PGCefhm7,iv:mjtXDC2EDTbjDurf0qAOS/OaUqgZs9RHAH6cTwjkXvc=,tag:CRtNcAZhOdv7G1tYfBIIOA==,type:str]

You can now keep values.yaml in your code repository in a much more human readable format that works will with version control (and makes git diffs much easier to handle).

In order to decrypt this file, SOPS needs the correct keys.

It pairs well with all the major cloud provider key management services so you can still reap the benefits of controlling access to the required keys to decrypt the files.

You can then rotate keys and create key groups based on which environment you'd like to decrypt the file in.

Pretty hand right?

I've read that this approach does not scale up well, which might be a major drawback for larger teams or projects.

Let me know in the comments if you've worked with SOPS and what your experience with it has been, good or bad!

Improving a static site's performance

Audrey Hayes — Sun, 19 Apr 2020 08:41:04 +0000

Introduction

I have a very simple one-page portfolio site that I built a couple of years ago when I was just starting to learn to code. I wanted to see if I could speed up the site's load time without losing too much of the site's simplicity (written in pure HTML & CSS).

Measuring the problem

I already know from simply visiting the site that the lack of minification, unoptimised images and unnecessary requests to third-party resources via inline script tags and stylesheets are major issues causing the site to load far too slowly.

But I still wanted some measured data to back up my own user experience on the site. So I audited the site using Google Chrome's Lighthouse report.

Ouch! I don't know if I've ever seen a performance score that low. The site definitely needs a facelift 😬.

Improving the site

I decided to port the site over to Gatsby so I could leverage all the image processing power that it offers. By writing one GraphQL query, I was able to use sharp to control the image sizes and render them fluidly directly from the local file system.

export const useBackground = () => {
    const result = useStaticQuery<BackgroundQuery>(graphql`
        query background {
            allFile(filter: { extension: { eq: "jpg" } }) {
                edges {
                    node {
                        base
                        childImageSharp {
                            fluid(fit: CONTAIN) {
                                aspectRatio
                                base64
                                originalName
                                sizes
                                src
                                srcSet
                            }
                        }
                    }
                }
            }
        }
    `);

    return {
        backgrounds: result.allFile.edges,
    };
};

Although migrating the site to Gatsby was a breeze, it took a bit of logic to pass in a background color prop to the card component so I could render the correct background image for each card.

This could probably be written more succinctly, but my goal was to complete this project in a day or less!

I set the backgroundColor prop as an enum of 'mint' | 'orange' | 'pink' | 'teal' | 'yellow' which I then filtered to match the name of the png file.

    const { backgrounds } = useBackground();

    const filteredBackground = backgrounds.filter(
        background =>
            background.node.childImageSharp.fluid.originalName.slice(0, -4) === backgroundColor
    );

Some additional improvements that I made:

used react-fontawesome to pull in brand icons with an npm package rather than rely on a CDN
moved the site to Netlify so I could deploy the site directly from the command line

Measuring the results

So how big were the performance gains made by these tweaks?

A pretty impressive return for an afternoon's work!

Check out the full Github repo