Let’s say you want to detect some grayscale colors:

A color is grayscale if the color’s red, green, blue (RGB) component values are exactly equal. A really common format for colors on the web is a 6 digit hexidecimal representation of the RGB component values: # + RRGGBB.

• #FFFFFF
• #000000
• #808080
• #FF0000
• #00FF00
• #0000FF

Knowing the above, detecting grayscale colors is simple:

function isGrayscale(color) {
  const { r, g, b } = parseColor(color);

  return r === g && r === b;
}

function parseColor(color) {
  const match = color.match(/#((?:[0-9A-F]{1,2}){3})/i);
  if (!match) {
    throw new Error('invalid color format');
  }
  const [r, g, b] = match[1]
    .repeat(2)
    .slice(-6)
    .match(/.{2}/g)
    .map(hex => parseInt(hex, 16));
  return {r, g, b};
}

Be aware that there are a boatload of valid formats for web colors. For production use you are better off using a library like d3-color to parse untrusted color values.

Anyway, the above code works great! I guess we are done. Hope you learned something! I should blog more often. See you next time!

Wait, what was that? You plugged some Bootstrap 4 gray colors into the function like isGrayscale('#adb5bd') and you got false? Well, I would indeed consider those Bootstrap grays to be “grayish” colors. However, those colors are not strictly grayscale colors according to the definition we agreed upon above. So yeah, it’s actually a good thing our function doesn’t match them. Closed as wontfix.

What? This blog post sucks? Okay, fine, there’s more we can do here. I’m no stranger to scope creep.

Classifying colors as “grayish”

A color is generally considered “grayish”, neutral, achromatic if all of its red, green, blue (RGB) component values are a close distance to each other. Makes sense: we know from earlier that a color is strictly grayscale if it has uniform RGB values. A distance of zero is about as close as you can get.

Let’s define our test cases. We can use those pesky Bootstrap 4 gray colors as colors we want to positively match.

• gray-100: #f8f9fa
• gray-200: #e9ecef
• gray-300: #dee2e6
• gray-400: #ced4da
• gray-500: #adb5bd
• gray-600: #6c757d
• gray-700: #495057
• gray-800: #343a40
• gray-900: #212529

As a sanity check let’s use ColorBrewer 2 as colors we want to negatively match.

Let’s visualize the RGB values of our test cases and check if we see the pattern we expect.

Okay, so we can clearly see the pattern we expect. The colors we want to match have equidistant RGB components. The ColorBrewer colors are off doing their own thing because they are clearly not gray colors.

If we want to classify these colors in code: we need a way to measure the degree to which the RGB components are close to each other. The range of the RGB components should measure this nicely.

const RANGE_LIMIT = 17;

function isGray(color) {
  const { r, g, b } = parseColor(color);
  const rgb = [r, g, b];
  return Math.max(...rgb) - Math.min(...rgb) <= RANGE_LIMIT;
}

This matches the original desired Bootstrap colors:

Similar “grayish” colors will be matched as well:

Great! Looks good to me so far. Now, how can we exhaustively prove that this function matches only the colors we want? The best way to spot check our function is probably to visualize what it considers to be “grayish”.

Checking our work

RGB is a nice and simple color model that is easy for machines to deal with. However, for our purposes here it would be nice to use a human-friendly color model. I will choose the hue, saturation, value (HSV) color model to make a simple 2D plot of the colors matched by our function.

HSV has some useful geometry for detecting and visualizing grayish colors. The HSV color model can be represented as a cylinder where the central vertical axis comprises neutral, achromatic, or gray colors. Those colors range, from top to bottom, white at value 1 and black at value 0.

By HSV_color_solid_cylinder.png: SharkDderivative work: SharkD  Talk - HSV_color_solid_cylinder.png, CC BY-SA 3.0, wiki

I’m not smart enough to do math in 3D: so let’s just chart 2D slices of this cylinder at different hues and see how far we get. We are mostly concerned with the interaction between saturation and value right now anyway. Let’s fix the hue to 210°. since all those Bootstrap grays tend to hover around that hue.

Great! Not perfect, but it’s definitely clear to me that we are on the right track.

Let’s check another hue to see what our function matches there. Let’s check the 120° hue.

Uhoh. Yeah, this isn’t working at all. Most all of these matched colors look downright green to me on all my devices. At best, it seems to be matching greens that look like olive drab.

If you are not familiar with color spaces: you might be wondering how #f0f7ff and #f0fff0 can have the same saturation (6) and value (100) yet #f0fff0 is disproportionately offensive. Due to the way color vision works, we are naturally more sensitive to colors in the greenish-yellow area of the color spectrum. So we need to use a perceptually uniform color model that accounts for this.

Perceiving colors in code

Let’s tighten up our terminology in the hopes of finding a good color model for our problem. Classifying colors as “grayish” can be more accurately stated as classifying:

• neutral colors
• colors with low colorfulness
• colors with low saturation
• achromatic colors, colors with a low chroma value

If we are looking for achromatic colors, we have the CIELCh_ab perceptual color model at our disposal. This is a cylindrical representation of the CIELAB color space with a channel for Lightness, Chroma, and hue. The chroma channel is what we will use to determine if a color is achromatic enough to be matched. #6c757d from our bootstrap colors has the highest chroma value at 6.05. Let’s use that as our threshold.

import { lch } from 'd3-color';

const CHROMA_THRESHOLD = 6.05;

function isGray(color) {
  let chroma = lch(color).c;
  return isNaN(chroma) || chroma <= CHROMA_THRESHOLD;
}

Let’s chart it at the 210° hue:

Let’s chart it at the 120° hue:

For completeness let’s try Let’s chart it at the 0° hue:

Let’s sample the edge case colors:

We are definitely getting somewhere. At this point I’m beginning to doubt my monitor calibration/eyes. Regardless, I’m gonna go ahead and judge that most people would struggle to classify the above colors as “gray”. If I asked people to name those colors I’m guessing they would say things like “pale blue”, “olive drab”, “dark blue”.

Here’s an example of me manually tweaking these colors in an LCh color picker until I personally would call them “gray”.

That is the best I could do in 10 minutes or so. I’m hesitant to tweak further as there are so many equipment and biological factors that could cause me to waste a ton of time with diminising returns. The limitations of human vision could certainly trip me up.

Anyway, the above exercise of manually finding the chroma threshold for those example colors was useful. Let’s encode my common sense judgement above into an algorithm.

Coding common sense

When determining a chroma threshold for our algorithm, we should consider these findings from above:

• Blue colors should be given lots of leeway. Blues with a low chroma look like “cool grays” to me.
• Orange colors should be given lots of leeway. Orange is a gateway to brown. Oranges with low chroma look like “warm grays” to me.
• Red colors should be judged somewhere in the middle.
• Green colors should be scrutinized closely.

Let’s slice up our 3D problem into 2D projections and apply some shader functions to our classifier curves to approximate our desired result.

function _clamp(x, min, max) {
  if (x < min) {
    x = min
  } else if (x > max) {
    x = max
  }
  return x
}

function _smoothstep(a, b, x) {
  const t = _clamp((x - a) / (b - a), 0.0, 1.0);
  return t * t * (3.0 - 2.0 * t);
}

const hueToleranceStopsV1 = [
  [0, 3.1], // red
  [20, 3.1], // orange
  [61.8, 8], // orange
  [66, 7.49], // orange
  [75, 6.8], // orange
  [100, 2], // yellow-green
  [180, 2], // green
  [240, 5.4], // blue
  [262, 14], // blue
  [263, 14], // blue
  [290, 6.5],
  [310, 3.1], // red
  [360, 3.1],
];

function _buildCurve(stops) {
  return function (value) {
    let a, b, from, to;
    for (const [x, y] of stops) {
      if (value >= x) {
        a = x;
        from = y;
      }
      if (value <= x) {
        b = x;
        to = y;
        break;
      }
    }
    if (a === b) {
      return to;
    }
    return _smoothstep(a, b, value) * (to - from) + from;
  }
}

const hueCurveLCh = _buildCurve(hueToleranceStopsV1);

function isGray(color) {
  const {l: lightness, c: chroma, h: hue} = lch(color);
  // black and white
  if ([0, 100].includes(lightness)) {
    return true;
  }
  // grayscale
  if (chroma === 0) {
    return true;
  }
  return chroma <= hueCurveLCh(hue)
}

Below is a visualization of hueCurveLCh:

Let’s dump all the edge case values this function matches. The following table shows the most chromatic colors matched for a given hue and lightness. These colors sit at the threshold of what this function considers “gray”.

Looking pretty good to me!

Color palettes classified as gray

Bootstrap grays ✅

• gray-100: #f8f9fa
• gray-200: #e9ecef
• gray-300: #dee2e6
• gray-400: #ced4da
• gray-500: #adb5bd
• gray-600: #6c757d
• gray-700: #495057
• gray-800: #343a40
• gray-900: #212529

PANTONE cool grays ✅

• 1C: #d9d9d6
• 2C: #d0d0ce
• 3C: #c8c9c7
• 4C: #bbbcbc
• 5C: #b1b3b3
• 6C: #a7a8a9
• 7C: #97999b
• 8C: #888b8d
• 9C: #75787b
• 10C: #63666a
• 11C: #53565a

PANTONE warm grays ✅

• 1C: #d7d2cb
• 2C: #cbc4bc
• 3C: #bfb8af
• 4C: #b6ada5
• 5C: #aca39a
• 6C: #a59c94
• 7C: #968c83
• 8C: #8c8279
• 9C: #83786f
• 10C: #796e65
• 11C: #6e6259

CSS Colors ✅

• black #000000
• silver #c0c0c0
• gray #808080
• white #ffffff
• dimgray #696969
• dimgrey #696969
• darkgray #a9a9a9
• darkgrey #a9a9a9
• grey #808080
• lightgray #d3d3d3
• lightgrey #d3d3d3
• aliceblue #f0f8ff
• gainsboro #dcdcdc
• ghostwhite #f8f8ff
• snow #fffafa
• whitesmoke #f5f5f5
• seashell #fff5ee
• linen #faf0e6

(I slightly disagree with aliceblue but gonna leave it for now)

Color palettes not classified as gray

A lot of these are blues with chroma values way above what I’m willing to match with the current implementation of the function. I could treat blues as special, but I’m gonna leave it be for now.

CSS “Slate Gray” ❌

I would like to match these guys eventually.

• lightslategray: #778899
• lightslategrey: #778899
• slategray: #708090
• slategrey: #708090

Light CSS Colors ❌

• azure #f0ffff
• ivory #fffff0
• floralwhite #fffaf0
• honeydew #f0fff0
• bisque #ffe4c4
• blanchedalmond #ffebcd
• burlywood #deb887
• cornsilk #fff8dc
• beige #f5f5dc
• antiquewhite #faebd7

Tailwind CSS “grays” ❌

Matching these made my blue hue edge cases kinda bogus looking. I tend to agree with my function above. These look like blue colors to me: not gray.

• 100: #F7FAFC ✅
• 200: #EDF2F7 ✅
• 300: #E2E8F0 ✅
• 400: #CBD5E0 ❌
• 500: #A0AEC0 ❌
• 600: #718096 ❌
• 700: #4A5568 ❌
• 800: #2D3748 ❌
• 900: #1A202C ❌

If you wanted to match these guys you would need to lax your tolerances for blue hues.

const hueToleranceStopsV2 = [
  [0, 3.1], // red
  [20, 3.1], // orange
  [61.8, 8], // orange
  [66, 7.49], // orange
  [75, 6.8], // orange
  [100, 2], // yellow-green
  [180, 2], // green
  [240, 5.4], // blue
  [262, 14], // blue
  [263, 14], // blue
  [290, 6.5],
  [310, 3.1], // red
  [360, 3.1],
];

Which looks like a much different curve:

What is this useful for?

You could use this as a post-processing step to classify things as “gray”.

roots/palette-webpack-plugin uses a simplified version of this technique to automatically sort colors in a color palette picker.

Further Reading

• David Briggs. “Dimensions of Colour”
• Alexei Boronine. “Color Spaces for Human Beings”
• Charlie Loyd. “On Rainbows”
• Perceptual Science Group @ MIT
  • Adelson, E.H. “Checkershadow Illusion”
  • Adelson, E.H. Lightness Perception and Lightness Illusions. (2000).

Hey austin. I have been interested into getting into coding, specifically back end coding. I was just wondering what would be the best way about getting started? And I need to buy a new laptop and was wondering what hardware would be best for me given all that. Also keep in mind all of this is on tha backdrop of zero program experience. Very novice at computers period really. Any advice you got would be much appreciated

In order to make learning to code fun and rewarding, I recommend first finding a problem that interests you. Learn how to code until you can solve your problem.

I began learning how to build websites in 2005. I was learning how to make basic flash animations and wanted to upload them to my own website like some of the other animators were doing. My success was measured by: “can people watch my little animations yet?” I learned how to successfully code and publish a website purely by trying to answer my own questions.

• “How do people get a domain name and how does that work?”
• “A website needs hosting, where do I get hosting?”
• “How do I make text show up on a web page?”
• “How do I change the color of the text on the page?”
• “How do I put a video on a web page?”

After I answered all of those questions (and a million more probably), I was successful in publishing my little flash animations to the web! People could watch the little clips I uploaded to the website. That only led to more questions.

• “How can I let people leave comments on my animations?”
• “How can I make blog posts on my website to let people know that I am working on more animations?”
• “How can I let other animators upload their own animations to my website without me having to manually publish them?”

By around 2008 or so I was able to do all the things I mentioned above. I was basically programming literate. I knew how to build simple database-backed web applications. Although discipline was indeed a factor in teaching myself programming, I attribute my success more to having clear end-goals. I wasn’t learning how to write a “for loop” was because someone told me it was important. I was learning how to write a “for loop” because I had an idea that I could use it to display a list of my videos without having to copy paste the list items 10 times.

The whole thing is very much like learning a spoken language. I took 5 years of spanish in school and never got anywhere close to fluent. I was consuming the class content as it was doled out and didn’t have any desire to go out and practice. You hear anecdotes all the time of people taking trips to Mexico or Spain or Costa Rica and coming back with twice the Spanish competency compared to when they left. It is obvious the success can be attributed to immersion as a motivating factor. You are far more likely to half-ass learning how to order at a restaurant out of a workbook compared to when you are in front of a real waiter at a foreign restaurant.

“What Can Programming Do?”

My little flash animation showcase website was my project that got me into programming. Yours should be something you care about as well. It doesn’t have to be a website, it could be a program that reads a spreadsheet and outputs some helpful text. It could be a program that tracks expiration dates on your groceries. It could be a program that tracks how often you have sex. You could write a program to calculate how much you need to save up month over month to buy something. You could build a goofy chat bot that says funny things when you chat to it. You could even just build your own to-do list app. It doesn’t matter if it’s a novel idea or that there is an existing solution, you are trying to learn.

My recommendation would be to think of a project that deals with numbers or text as data. At least to start with. Dealing with images, audio, and video isn’t rocket science, but introduces concepts that might confuse a truly novice programmer. If you truly aren’t familiar with what a “program” is, use an online tool like codeacademy and go through the first couple lessons, I recommend starting with JavaScript. This will teach you the very basics of what programming is. Hopefully this will jog your noggin and maybe you will see how you can write programs to crunch numbers or save text or remember dates or display text. But critical to my point: you should never stray far applying your knowledge. As soon as you know enough to be dangerous, you should try your hand at building something.

“What Language Should I Learn?”

I get this question a lot. My blind answer is usually JavaScript and web technologies. My reasoning is that coding JavaScript and building browser applications is very visually oriented and immediately produces results you can show people. It’s easy to produce a goofy little website and have people visit it. With people able to enjoy your work, you can get feedback and be inspired to add goofier and more complicated features.

However, it depends on what you are trying to do to. Do you want to build programs that read spreadsheets and do statistics, kind of like what an analyst would do in excel? You want to learn Python. Python is a programming language that could benefit most all office workers that crunch data or deal with computer systems.

It can get more complicated. For instance: you can build goofy websites using Python, JavaScript, AND web technologies. Although for a novice, focus on getting your feet on solid ground and feel free to mix and match once you know what you are doing.

Good resources:

• https://www.codecademy.com/
• code wars
• egghead.io
• mozilla

“What Should I Do?”

Go to meetups! So you have a basic idea of what programming is and perhaps you have done some reading online. Now it is time to collaborate with other people. If you go to school: see if your school has any coding meetups. Check Meetup.com for coding meetups in your area. Be a fly on the wall, listen to pros talk about stuff. Take notes. Ask people about things they have built. Ask people how they would build things you want to build. Talk to other newbies and ask what has been working for them.

Maybe take a class! If you need hands on instruction, go for it. You may have heard about coding bootcamps and stuff. I don’t have any recommendations on any specific programs to join but I would definitely recommend at least doing some online courses before paying for a bootcamp. My feeling is if you go in completely ignorant you are not going to get a lot out of it. You want to have an understanding of the basics so you can ask good questions and not fill your time tripping over pedestrian issues.

“What Equipment Do I Need?”

These days most any decent consumer computer is fine for entry-level programming. You need a full operating system though. Like Windows, Mac OSX, or Linux. Chromebooks and ipads and stuff like that won’t work.

If you are serious: I recommend using a Mac laptop. Any Mac laptop after 2014 should be fine. There are two main reasons I recommend a Mac:

• Someone might be nice enough to mentor you. If you have a Mac, you can use both Mac OSX and Windows. Use the same OS as your mentor so your time together is productive rather than spent fixing platform-specific issues.
• Using Mac OSX teaches unix concepts. If you learn how to set up a development environment on Mac OSX, those skills will kinda sorta translate to the linux world. If you learn how to set up a development environment on Windows, those skills are only valid for windows. (Footnote for a discerning reader: I am aware of the Windows 10 linux subsystem.)

Additional Tips

• Learn linux. If you don’t know what linux is: you should learn what linux is. Even just installing it on your computer to mess around with is a valuable learning experience if you are ignorant about computers.

Automatic responses

There are a couple tricks you need to know about to get the most out of the automatic responses:

• Separate multiple input phrases with commas. For example: hi, hello, yo
• You can add as many Slackbot responses as you’d like for each input phrase. Put each one on its own line. (A random response will be chosen if there are multiple responses.) For example: Well hi there!
  Hello yourself
  Yo yo yo

With all of these tricks in mind you can do things like I ask slackbot to make decisions:

Regex Input Phrases

This is all well and good, but it is not very flexible. For instance if you wanted Slackbot to respond to “yee”, ”yeeeeeeeee”, and everyting inbetween you would use a regex such as /yee{1,8}/. Since slackbot doesn’t read regex, you have to statically compile the regex permutations and then feed them to Slackbot. I went ahead and used the Genex perl module to do this. I explain how to install perl modules further down.

example: “yee”

perl -MRegexp::Genex=:all -le 'print join(",\n", strings(qr/yee{1,8}/, 20))'

Will yield the following:

yeeeeeeeee,
yeeeeeeee,
yeeeeeee,
yeeeeee,
yeeeee,
yeeee,
yeee,
yee

Note the strings method:

@list = strings( $regex, [ $max_length = 10 ] )
  Produce a list of strings that would match the regex.

example: “how good is x at y?”

They can get pretty complex:

perl -MRegexp::Genex=:all -le 'print join(",\n", strings(qr/How good is (Ridwan|Austin|Darren) at (perl|python|golang)\?/, 30))'

Will yield:

How good is Ridwan at perl?,
How good is Ridwan at python?,
How good is Ridwan at go?,
How good is Austin at perl?,
How good is Austin at python?,
How good is Austin at go?,
How good is Darren at perl?,
How good is Darren at python?,
How good is Darren at go?

example “aww yiss”

perl -MRegexp::Genex=:all -le 'print join(",\n", strings(qr/aww{1,9} yiss{1,9}/, 50))'

Will yeild this. So basically anyone can type awww yisss with an arbitrary combination of w’s or s’s and still get the desired automatic slackbot response.

How to Install Perl Modules

If you’ve never used perl before, you should check out CPAN and their install instructions.

If you are on Mac OSX, you already have perl and cpan in your path. So all you need to do is install cpanm.

cpan App::cpanminus

Which will give you a cpanm executable at ~/perl5/bin/cpanm. Now install the Genex module:

~/perl5/bin/cpanm Regexp::Genex

If that succeeded you can now play around with Genex and impress your friends.

See the Pen Smart Checkboxes by Austin Pray (@austinpray) on CodePen.

Source

• CodePen
• Gist

Problem

I had a friend last night ask me:

Anyone good at jQuery want to tell me if the following is a convoluted?

$('.gfield_checkbox input[value="none"]').change(function() {
  $(this).parents('.gfield_checkbox').find('input:checkbox').not(this).prop('checked', false).prop('disabled', $(this)[0].checked);
});

He had a group of checkboxes:

• option 1
• option 2
• option 3
• none of the above

He wanted them to behave such that:

1. When “none of the above” is checked: all the other options become unchecked and disabled.
2. When “none of the above” is unchecked: all the other options become enabled again.

There is nothing really wrong with the jquery one-liner my friend came up with. However I wanted a solution that didn’t rely on the user having to uncheck “none of the above” before being able to click another option. So:

1. When “none of the above” is checked: all of the other options become unchecked.
2. When an option other than “none of the above” is selected and “none of the above” is already checked: “none of the above” should be automatically unchecked.

Solution

Approach

Each time a checkbox in the group is checked:

1. Loop through all of the checked boxes and get their values.
2. If “none of the above” is among the values: decide which ones to uncheck based on the element that was just clicked.

Deciding when to uncheck

We loop through all of the checked boxes. For each element in the loop we evaluate this statement to determine if we should uncheck it:

or:

if (A^B) {
  // uncheck everything else
}

If you are unfamiliar with logical operators: XOR. In this case an exclusive OR saves us from:

or this confusing mess:

if ((!A && B) || (A && !B)) {
  // uncheck everything else
}

Conclusions

This probably is/should be a jQuery plugin.

These days your web project probably has a build step. Your build step takes your styles, scripts, and other assets and packages them for the browser. Maybe you are using gulp, grunt, or even make to orchestrate all your compilation steps. This post covers a couple methods for deploying projects with compiled assets and each method’s respective gotchas.

General Rules of Thumb

• Never commit compiled files to source control.
  1. Compiled files in a repo make it difficult to merge and rebase branches.
  2. Compiled files muddy the history and increase the file size of the repo.
  3. It just doesn’t make sense to put “binaries” in your source control unless you have some kind of specific vendoring strategy in mind.
• Deployments are completely automated and driven by your version control repository. Whether you are using something like Capistrano, a hand-rolled git deploy process or a PaaS that gives you git deploy options: you should have one codebase tracked in revision control and many deploys.
• Ideally Dev matches Production exactly. You should have a reproducible, portable development environment which exactly matches the environment your production app runs in. The most conventional way to do this is to use Vagrant. The new hotness is Docker.

Deployment Patterns

So at this point your source control drives your many deploys. Your build process outputs compiled files optimized for the browser. You are banned from checking any of these compiled files into source control. So how do the compiled files get to the proper place on the application server? It really depends on who or what is going to be running the build.

1. Locally Compile and Upload Assets

As a part of your deployment process on your local development machine:

• Build the project
• Copy compiled files to the remote destination

Where this falls apart:

• No single source of truth: When you have multiple people deploying and compiling there is a lack of “single source of truth”. This becomes a problem when working on a team or when you hand off a project. You run the risk of differences in a particular developer’s setup causing differences in the compiled output. Although this doesn’t happen often if you are diligent about locking down dependency versions: when it does it is extremely frustrating and expensive. It amounts to a ping-pong of intermittent issues based on who is actually deploying.
• Everyone Requires Credentials: Anyone who needs to deploy has to have access credentials for the server. This requires discipline and lots of work to keep credentials from floating around in the wild.
• Uploading is slow: uploading a bunch of files, especially over SCP, is generally pretty slow.
• Requires Discipline: You cannot run a deploy while there are uncommitted changes in your local source assets, intentional or not. You will have to stash any changes before deploying. In addition, you have to be on the exact branch your target stage relies on. Otherwise, the assets you upload will not match the application files in git. For instance:
  1. You are trying to deploy to “Staging” which pulls code from the “Develop” branch.
  2. You unknowingly find yourself with the master branch checked out while running the deploy.
  3. The deploy process will pull the latest code from the “Develop” branch.
  4. Your local machine will upload the compiled assets from the master branch.
  5. Uh oh! Now, among other things, your templates don’t match your JavaScript or your styles! You done goofed everything.

Recommendation:

If you are a lone developer with no project handoff in sight, there is probably nothing wrong with this pattern. It is crude but easy to setup. Also, if you do not have the ability to install dependencies on the remote box you might be forced to use this pattern.

2. Compile on the Application Server

As a part of your initial server provisioning process:

• Install build dependencies and runtimes. If, for instance, you are using gulp to build your project’s assets you would install Node.js and npm.

As a part of your deployment process trigger on the remote application server:

• Update, prune, rebuild project build dependencies. (example)
• Trigger the build

The application server becomes the single source of truth.

Where this falls apart:

• Everyone Requires Credentials
• Additional Dependencies Required on Application Server: most people prefer to keep their application servers as lean as possible. Having your application server “know” about the build process and its dependencies goes against this principle. Additional dependencies means additional provisioning time as well.
• Not Suitable for Resource Intensive Build Processes: If you have a super duper large build process this can steal resources from app for the duration of the build process. In all likelihood, your development machine is a quad core machine with 16GB of memory. Your application servers are probably single core nodes with 1GB of memory or less. A minute long build process on your dev machine could take 10 minutes on your lean application server.

Recommendation:

Generally for web projects this is a safe bet. The setup is cheap and simple. Due to the nature of web assets having to be consumed by a browser: building them is usually not a big deal. In my experience, the benefit of reproducible builds for team environments (especially remote teams) for little to no setup cost is greater than any hemming and hawing about additional dependencies being installed on the server.

3. Continuous Integration

Use something like Jenkins or a hosted solution like Travis. Your CI server watches your repo for new commits. When a commit happens the CI server:

• Runs any pre-deploy checks (tests, linters, etc.)
• Runs deploy
• compiles and uploads assets

So:

• Continuous integration server becomes the single source of truth
• Developers only need access to the source code to be able to contribute to a project. The CI server has all the privileged access under lock and key.
• Application server is as lean as possible, reduce server provisioning time.
• Discipline is enforced by CI server so when building human error is not a thing. You can make sure tests must pass and style guides must be followed before code makes it to production.

Where this falls apart:

This doesn’t fall apart unless your CI server falls apart. However, the upfront cost is significant. A CI server is definitely only worth it in the case of:

• Team environment
• Long-lived project or lots of projects/modules to subsidize the upfront cost
• Continuous development

Recommendation:

This is probably the most ideal deployment setup, but it is definitely only worth the effort in certain cases. Continuous integration requires continuous development. If you are working on a long-lived product in a team environment CI is pretty much required. I can’t imagine doing it any other way. For open source projects: Travis is free and it is awesome. Run your tests, linting or style guide against any and all contributions. Automatically build and update your docs.

Conclusion

There are lots of ways to skin this cat. The right solution depends heavily on the context of the project. The good news is: if you are doing something resembling any of the above you are probably on the right track.