Boot up with an Fedora Live USB stick.
- Run
vgsto check if there's any space:
$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
fedora 1 3 0 wz--n- <237.28g 0 08/16/17 by Sergey Grebenshchikov
This is a quick tutorial on how to test code using the GoMock mocking library and the standard library testing package testing.
GoMock is a mock framework for Go. It enjoys a somewhat official status as part of the github.com/golang organization, integrates well with the built-in testing package, and provides a flexible expectation API.
| const strategy = 'keycloak' | |
| export default function ({ app }) { | |
| const { $axios, $auth } = app | |
| if (!$auth.loggedIn || !$auth.strategies[strategy]) | |
| return | |
| const options = $auth.strategies.keycloak.options |
| import nanoid from 'nanoid'; | |
| console.log(nanoid()); |
| package main | |
| import ( | |
| "database/sql" | |
| "log" | |
| ) | |
| func main() { | |
| db, err := sql.Open("VENDOR_HERE", "YOUR_DSN_HERE") | |
| handleError(err) |
| package main | |
| import ( | |
| "context" | |
| "flag" | |
| "fmt" | |
| "log" | |
| "net/http" | |
| "os" | |
| "os/signal" |
For a brief user-level introduction to CMake, watch C++ Weekly, Episode 78, Intro to CMake by Jason Turner. LLVM’s CMake Primer provides a good high-level introduction to the CMake syntax. Go read it now.
After that, watch Mathieu Ropert’s CppCon 2017 talk Using Modern CMake Patterns to Enforce a Good Modular Design (slides). It provides a thorough explanation of what modern CMake is and why it is so much better than “old school” CMake. The modular design ideas in this talk are based on the book [Large-Scale C++ Software Design](https://www.amazon.de/Large-Scale-Soft
| version: "3" | |
| services: | |
| db: | |
| image: postgres:9.4 | |
| deploy: | |
| replicas: 1 | |
| volumes: | |
| - pgsql_data:/var/lib/postgresql/data:rw,Z | |
| environment: |
This gist is based on the information available at golang/dep, only slightly more terse and annotated with a few notes and links primarily for my own personal benefit. It's public in case this information is helpful to anyone else as well.
I initially advocated Glide for my team and then, more recently, vndr. I've also taken the approach of exerting direct control over what goes into vendor/ in my Dockerfiles, and also work from
isolated GOPATH environments on my system per project to ensure that dependencies are explicitly found under vendor/.
At the end of the day, vendoring (and committing vendor/) is about being in control of your dependencies and being able to achieve reproducible builds. While you can achieve this manually, things that are nice to have in a vendoring tool include: