... or Why Pipelining Is Not That Easy
Golang Concurrency Patterns for brave and smart.
By @kachayev
| App configuration in environment variables: for and against | |
| For (some of these as per the 12 factor principles) | |
| 1) they are are easy to change between deploys without changing any code | |
| 2) unlike config files, there is little chance of them being checked | |
| into the code repo accidentally | |
| 3) unlike custom config files, or other config mechanisms such as Java |
... or Why Pipelining Is Not That Easy
Golang Concurrency Patterns for brave and smart.
By @kachayev
Use case: You have repository A with remote location rA, and repository B (which may or may not have remote location rB). You want to do one of two things:
NB: Check out git subtree/git submodule and this Stack Overflow question before going through the steps below. This gist is just a record of how I solved this problem on my own one day.
Before starting, make sure your local and remote repositories are up-to-date with all changes you need. The following steps use the general idea of changing the remote origin and renaming the local master branch of one of the repos in order to combine the two master branches.
| location ~* ^/s3/(.*) { | |
| set $bucket '<REPLACE WITH YOUR S3 BUCKET NAME>'; | |
| set $aws_access '<REPLACE WITH YOUR AWS ACCESS KEY>'; | |
| set $aws_secret '<REPLACE WITH YOUR AWS SECRET KEY>'; | |
| set $url_full "$1"; | |
| set_by_lua $now "return ngx.cookie_time(ngx.time())"; | |
| set $string_to_sign "$request_method\n\n\n\nx-amz-date:${now}\n/$bucket/$url_full"; | |
| set_hmac_sha1 $aws_signature $aws_secret $string_to_sign; | |
| set_encode_base64 $aws_signature $aws_signature; |
Hello!
This is a commentary and discussion from walking through what happens on startup in [https://github.com/circleci/frontend], looking at this SHA in December 2014: [https://github.com/circleci/frontend/commit/273558250040ce197e44e683d5528381f36c4eea].
The first part is a literal walkthrough, where I'm tracing my reading of how the code works. This is a way to check my understanding, since of course I don't have all of your context. And it's also a way to echo back to you how someone else might experience this code without that context. The second part is about asking questions, making suggestions, and exploring some paths for making it even more awesome. I also mixed in a few asides in the walkthrough part where I jump ahead a bit.
Doing this with colleagues has worked well for me as a way to do in-depth code reviews about more abstract design and architectural questions. The goal of the the first part is to clarify we're all looking at the same thing, which creates the space and shared understa
There are three easy to make mistakes in go. I present them here in the way they are often found in the wild, not in the way that is easiest to understand.
All three of these mistakes have been made in Kubernetes code, getting past code review at least once each that I know of.
What do these lines do? Make predictions and then scroll down.
func print(pi *int) { fmt.Println(*pi) }I'm be using DreamCompute as my OpenStack provider, but there are dozens to choose from. I assume you already have Ansible and the OpenStack CLI tools installed.
With the proliferation of OpenStack public clouds offering free and intro tiers, it's becoming very easy to effectively run a simple application for free or nearly free. Also with the emergence of Ansible, you don't need to learn and deploy complicated tools to do configuration management.
| #!/bin/bash | |
| # -------------------------------- | |
| # Totally Simple Web Server (TSWS) | |
| # -------------------------------- | |
| # | |
| # (c) 2015 Dave Fletcher | |
| # All Rights Reserved | |
| # | |
| # This is free and unencumbered software released into the public domain. |