jdickey

After copying these from repo to repo for lo! these many projects, I decided to create a Single Source of Truth for project labels going forward.

These are an expansion of and, in a couple of cases, a slight modification of, the standard labels that GitHub creates for each new repo (and they themselves update from time to time). Particularly, I

• draw a distinction between a feature (new functionality not previously extant in a project) and an enhancement to an existing feature; and
• include a non-empty Description for each label. GitHub have recently changed their project defaults to do this, but older projects don't have that, even for "standard" labels;
• add generic tooling and vendor labels, as well as labels for docker and hanami as examples of tool-specific labels used in multiple projects. If a new project will never use Hanami or Docker, then I may not add the label to that project, and I may then add other, appropriate, tool-specific labels instead (e.g., for react in a

jdickey

Interactors, Action Classes, and Errors; Oh, My!

Contents

• Contents
• Why Are We Here?
• Hanami Controller-Action Parameter Data Validation
• New Kids on the Block: Interactors
• Error Data
• #call Me Only If You're Valid

jdickey

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sunday 1 July 2018 00:50 SGT (GMT+8)

This is to serve notice that my GPG (GNU Privacy Guard) key has changed with effect from today, Sunday 1 July 2018, following my (revised) standard protocol for key expiration. My new key will remain valid until 1 January 2019. I recommend that other users of GNU Privacy Guard enact such policies and keep revocation certificates for their current keys in offline storage, such as on a thumb drive that is labelled and physically secured separately from their systems.

jdickey

# Define ENV variables for development environment
DATABASE_URL='postgres://postgres:@db:5432/yourapp_development'
SERVE_STATIC_ASSETS="true"
WEB_SESSIONS_SECRET="d31b874186058eb00e17d9cde98e3745408b10666112a401a05a0d7ab392d30c"

jdickey

# Semi-automatic setup of Docker-running Droplet from within Droplet itself
#
# Last updated 2017-01-19 at 14:50 (SGT; GMT+8) by @jdickey
#
# ##### Section 1 of 10: Variables used within this script. #####
#
# **NOTE** that several of these **must** be changed, namely
# * DOCKER_PASSWD
# * DOCKER_USER
# * GITHUB_USER

jdickey

What We're Trying to Do

Referencing this earlier Gist, of course.

The following are from a series of Ansible Playbooks, associated files, and wrapper shell functions which I have been using for some months for multiple projects, all hosted on DigitalOcean. Until approximately 0130 Singapore time on Wednesday 17 January 2017 (GMT+8; 1730 GMT or 0930 PDT on 16 January), these scripts had been working quite well. The basic workflow is straightforward:

1. In the new_droplet.yml Playbook,
   1. Create a new Droplet, with specified values for name, image, region, size, and other values including ssh_key_ids, which is set to the (single) DigitalOcean SSH key ID for the DO user owning the Droplet to be created;
   2. Tag the newly-created Droplet so that it is uniquely identifiable using the Ansible digital_ocean.py dynamic-inventory script;
2. In the provision_droplet.yml Pla

jdickey

#!/bin/bash

# This is a fork of https://gist.github.com/mcemce/a6ee9b4ab07df9972883 with
# additional variable-based configuration and status hand-holding added by
# myself (@jdickey). Thanks to @mcemce for helping me out of a jam.

# Docker VM name. 'dev' is a recommended name for a development VM; you'll want
# to name a production VM something else.
OUR_DOCKER_VM=dev
echo "Docker will install a machine named $OUR_DOCKER_VM within VMware."

jdickey

The Tools

1. Pundit Authorisation; experimenting with this pull request linked to from the official Pundit README;
2. ActiveInteraction domain service objects ("DSOs");
3. RSpec 2.99.1

The Project

The project repo is on Github; what's under scrutiny here is on the pundit-1 branch.

jdickey

I've been trying to use Ansible to create and set up a Droplet based on your docker-16-04 image. Creating the droplet using the Ansible digital_ocean module works as expected, but I can't access the Droplet afterwards, as I get an error from ssh.

I can't believe that I'm the first or only customer to try to set things up like this. I've been knocking my head against any information source I can find for two weeks now. Perhaps you can advise?

I've attached my Playbooks and command output as listed below. The dynamic-inventory script referenced as digital_ocean.py is that supplied in the Ansible repo.

1. Command Output 1 - Create Droplet.log - output from running the new_droplet Playbook (see Item 3);
2. Command Output 2 - Attempted Provisioning of Droplet.md — output from running the playbook Playbook (see Item 4);
3. new_droplet.yml - Ansible Playbook tasked with creating and tagging a new Droplet
4. playbook.ym

jdickey

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Friday 30 June 2017 12:30 SGT (GMT+8)

This is to serve notice that my GPG (GNU Privacy Guard) key has changed with effect from today, Friday 30 June 2017, following my (revised) standard protocol for key expiration. My new key will remain valid until 31 December 2017. I recommend that other users of GNU Privacy Guard enact such policies and keep revocation certificates for their current keys in offline storage, such as on a thumb drive that is labelled and physically secured separately from their systems.

My old key will continue to work for use in sending me secured messages until it expires later today, Friday 30 June 2017 (and for verifying previously-signed messages thereafter); however, you should be using the new key. To anyone who has signed my old key, I’d greatly appreciate your signing the new one (after satisfying yourself of its provenance and legitimacy, of course).

This message is signed by