By resources
sessions
list-sessions ls -- List sessions managed by server
new-session new -- Create a new session
// Package main is a sample macOS-app-bundling program to demonstrate how to | |
// automate the process described in this tutorial: | |
// | |
// https://medium.com/@mattholt/packaging-a-go-application-for-macos-f7084b00f6b5 | |
// | |
// Bundling the .app is the first thing it does, and creating the DMG is the | |
// second. Making the DMG is optional, and is only done if you provide | |
// the template DMG file, which you have to create beforehand. | |
// | |
// Example use: |
# Usage: | |
# aws cloudformation --region <region> create-stack --stack-name <stack name> --template-body file://vpc-fargate.yaml | |
# This template will: | |
# Create a VPC with: | |
# 2 Public Subnets | |
# 2 Private Subnets | |
# An Internet Gateway (with routes to it for Public Subnets) | |
# A NAT Gateway for outbound access (with routes from Private Subnets set to use it) | |
# |
/* | |
Took me a while to figure this out, this should never be so difficult IMHO. The dynamodb api could use more examples in its doc. | |
The documentation for doing this is scattered in a few places: | |
1. dynamodb api doc for golang: https://docs.aws.amazon.com/sdk-for-go/api/service/dynamodb/ | |
2. the Update Expression: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.UpdateExpressions.html | |
The structs belowed are abbreviated for the sake of the demo: adding a string to the questions slice in the dynamodb table. |
# aecho.py | |
from socket import * | |
import asyncio | |
loop = asyncio.get_event_loop() | |
async def echo_server(address): | |
sock = socket(AF_INET, SOCK_STREAM) | |
sock.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1) |
This document is a collection of concepts and strategies to make large Elm projects modular and extensible.
We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp
. You will probably merge
a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:
From a comment on StackOverflow:
Vendoring is the moving of all 3rd party items such as plugins, gems and even rails into the /vendor directory. This is one method for ensuring that all files are deployed to the production server the same as the dev environment.
The activity described above, on its own, is fine. It merely describes the deployment location for various resources in an application.
{ | |
"builders": [{ | |
"type": "amazon-ebs", | |
"access_key": "", | |
"secret_key": "", | |
"region": "us-east-1", | |
"source_ami": "ami-de0d9eb7", | |
"instance_type": "m1.large", | |
"ssh_username": "ubuntu", | |
"ami_name": "packer-jenkins {{.CreateTime}}" |
Thanks to Jacob Kaplan-Moss, Donald Stufft, David Reid, Allen Short, Zain Memon, and Chris Armstrong for review.
This is a guide for technical individuals to understand in what circumstances SSL communications are secure against an observer-in-the-middle (for all intents and purposes: the NSA).
#####EDIT: NB Ban is technically different from Purge. Banned objects remain in memory but banning is faster than purging. Read the Varnish 3 documentation here and here.
Purge may be a more appropriate action for your use-case; although the examples in the gist below work, it's not necessarily the best way of doing this.