This gist is no longer valid. Please see Compass-Rails for instructions on how to install.
# Guide | |
# Configure the essential configurations below and do the following: | |
# | |
# Repository Creation: | |
# cap deploy:repository:create | |
# git add . | |
# git commit -am "initial commit" | |
# git push origin master | |
# | |
# Initial Deployment: |
The following guide will walk you through creating a bitcoin full node within GKE (Google Container Engine).
By default Bitcoin ABC is used, however this can be swapped for any other node quite easily.
If you wish to run another version of bitcoind, just change the image reference in bitcoin-deployment.yml
. There are tons of images available on the Docker Hub. Better yet, build your own. =)
The source for the included image is available at: https://github.com/zquestz/docker-bitcoin
image: docker.mydomain.com/build/kube-go-make | |
variables: | |
DOCKER_TAG: docker.mydomain.com/myapp/home:$CI_COMMIT_REF_SLUG | |
DOCKER_HOST: tcp://localhost:2375 | |
DOCKER_DRIVER: overlay | |
PROD_RSYNC_HOST: myprodserver.com | |
DOMAIN: mydomain.com | |
CHART_DIR: chart |
// semantic-ui-form.js | |
import React from 'react'; | |
import PropTypes from 'prop-types'; | |
import { Form, Input } from 'semantic-ui-react'; | |
export default function semanticFormField ({ input, type, label, placeholder, meta: { touched, error, warning }, as: As = Input, ...props }) { | |
function handleChange (e, { value }) { | |
return input.onChange(value); | |
} |
import React, { Component } from 'react'; | |
import DateTimePicker from 'material-ui-datetimepicker'; | |
import DatePickerDialog from 'material-ui/DatePicker/DatePickerDialog' | |
import TimePickerDialog from 'material-ui/TimePicker/TimePickerDialog'; | |
import { Field } from 'redux-form'; | |
const renderMyDateTimeInput = ({ input, meta: { touched, error } }) => ( | |
// for more customisation, see https://github.com/dmtrKovalenko/material-ui-datetimepicker |
This guide was written because I don't particularly enjoy deploying Phoenix (or Elixir for that matter) applications. It's not easy. Primarily, I don't have a lot of money to spend on a nice, fancy VPS so compiling my Phoenix apps on my VPS often isn't an option. For that, we have Distillery releases. However, that requires me to either have a separate server for staging to use as a build server, or to keep a particular version of Erlang installed on my VPS, neither of which sound like great options to me and they all have the possibilities of version mismatches with ERTS. In addition to all this, theres a whole lot of configuration which needs to be done to setup a Phoenix app for deployment, and it's hard to remember.
For that reason, I wanted to use Docker so that all of my deployments would be automated and reproducable. In addition, Docker would allow me to have reproducable builds for my releases. I could build my releases on any machine that I wanted in a contai
apiVersion: v1 | |
kind: PersistentVolumeClaim | |
metadata: | |
namespace: default | |
name: pv-default-100g-disk01 | |
annotations: | |
volume.beta.kubernetes.io/storage-class: default | |
spec: | |
accessModes: | |
- ReadWriteOnce |
// This is a basic Flutter widget test. | |
// | |
// To perform an interaction with a widget in your test, use the WidgetTester | |
// utility that Flutter provides. For example, you can send tap and scroll | |
// gestures. You can also use WidgetTester to find child widgets in the widget | |
// tree, read text, and verify that the values of widget properties are correct. | |
import 'dart:convert'; | |
import 'package:flutter/material.dart'; |
This code is extracted from one of my private projects as an example of how to implement encryption of PII in event streams using two keys: a master key for each "data subject" that is stored in Vault and never transported to the systems that process the PII, and a key unique to each event that is stored (itself encrypted) with the event.
To be clear, the key that is stored with the data is encrypted by another key that is not stored with the data. The idea is that each "data subject" has an encryption key that is stored in Vault (external). When you encrypt data, the library will:
- create a new AES 256 encryption key