Abdalsamad amusameh

Mistakes to Avoid: Docker Antipatterns

Whichever route you take to implementing containers, you’ll want to steer clear of common pitfalls that can undermine the efficiency of your Docker stack.

Don’t run too many processes inside a single container

The beauty of containers—and an advantage of containers over virtual machines—is that it is easy to make multiple containers interact with one another in order to compose a complete application. There is no need to run a full application inside a single container. Instead, break your application down as much as possible into discrete services, and distribute services across multiple containers. This maximizes flexibility and reliability.

Don’t install operating systems inside Docker containers

It is possible to install a complete Linux operating system inside a container. In most cases, however, this is not necessary. If your goal is to host just a single application or part of an application in the container, you need to install only the essential

I really liked @tjvantoll article Handling Failed HTTP Responses With fetch(). The one thing I found annoying with it, though, is that response.statusText always returns the generic error message associated with the error code. Most APIs, however, will generally return some kind of useful, more human friendly message in the body.

Here's a modification that will capture this message. The key is that rather than throwing an error, you just throw the response and then process it in the catch block to extract the message in the body:

fetch("/api/foo")
  .then( response => {
    if (!response.ok) { throw response }
    return response.json()  //we only get here if there is no error
 })

I have a project that's been happily chugging along on Travis for a while. Its .travis.yml looks something like

script:
  - node_modules/ember-cli/bin/ember test

I wanted to add a second parallel build that did something very different. I didn't want to run ember test with a different Ember version or some other flag. I wanted to run a completely different command. Specifically, I wanted to run LicenseFinder's audit.

Travis has great docs on customizing parallel builds, but nothing describes how to do two completely different commands.

What is your folder-structure preference for a large-scale Node.js project?

0: Starting from Rails

This is the reference point. All the other options are based off this.

|-- app
|   |-- controllers
|   |   |-- admin

	/**
	* This gist was inspired from https://gist.github.com/homam/8646090 which I wanted to work when uploading an image from
	* a base64 string.
	* Updated to use Promise (bluebird)
	* Web: https://mayneweb.com
	*
	* @param {string} base64 Data
	* @return {string} Image url
	*/
	const imageUpload = async (base64) => {

	const AWS = require("aws-sdk"); // from AWS SDK
	const fs = require("fs"); // from node.js
	const path = require("path"); // from node.js

	// configuration
	const config = {
	s3BucketName: 'your.s3.bucket.name',
	folderPath: '../dist' // path relative script's location
	};

	// Demo at http://codepen.io/jondaiello/full/YWRbOx/
	/* This mixin is for generating CSS arrows on a box */
	@mixin box-arrow($arrowDirection, $arrowColor, $arrowSize: 10px) {
	position: relative;
	z-index: 10;

	&::after {
	content: '';
	width: 0;
	height: 0;

	#!/bin/bash

	for file in $(git diff --cached --name-only \| grep -E '\.(js\|jsx)$')
	do
	git show ":$file" \| node_modules/.bin/eslint --stdin --stdin-filename "$file" # we only want to lint the staged changes, not any un-staged changes
	if [ $? -ne 0 ]; then
	echo "ESLint failed on staged file '$file'. Please check your code and try again. You can run ESLint manually via npm run eslint."
	exit 1 # exit with failure status
	fi
	done

	var AWS = require('aws-sdk'),
	fs = require('fs');

	// For dev purposes only
	AWS.config.update({ accessKeyId: '...', secretAccessKey: '...' });

	// Read in the file, convert it to base64, store to S3
	fs.readFile('del.txt', function (err, data) {
	if (err) { throw err; }