If someone asked me the question "what layout should I use for my Go code repository?", I'd start by asking back "what are you building: an executable, or a library?"
Create a directory named however you want your final executable to be called (e.g. "mycommand"), change into that directory, and create the following files:
VMWare Fusion 13 is now released. Read Vagrant and VMWare Fusion 13 Player on Apple M1 Pro for the latest.
This document summarizes notes taken while to make the VMWare Tech preview work on Apple M1 Pro, it originated
package main | |
import ( | |
"fmt" | |
"sync" | |
"github.com/aws/aws-sdk-go/aws" | |
"github.com/aws/aws-sdk-go/aws/awserr" | |
"github.com/aws/aws-sdk-go/aws/session" | |
"github.com/aws/aws-sdk-go/service/s3" |
HackerNews discussed this with many alternative solutions: https://news.ycombinator.com/item?id=24893615
I already have my own domain name: mydomain.com
. I wanted to be able to run some webapps on my Raspberry Pi 4B running
perpetually at home in headless mode (just needs 5W power and wireless internet). I wanted to be able to access these apps from public Internet. Dynamic DNS wasn't an option because my ISP blocks all incoming traffic. ngrok
would work but the free plan is too restrictive.
I bought a cheap 2GB RAM, 20GB disk VM + a 25GB volume on Hetzner for about 4 EUR/month. Hetzner gave me a static IP for it. I haven't purchased a floating IP yet.
This is a collection of the things I believe about software development. I have worked for years building backend and data processing systems, so read the below within that context.
Agree? Disagree? Feel free to let me know at @JanStette.
Keep it simple, stupid. You ain't gonna need it.
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:
# LVDB - LLOOGG Memory DB | |
# Copyriht (C) 2009 Salvatore Sanfilippo <[email protected]> | |
# All Rights Reserved | |
# TODO | |
# - cron with cleanup of timedout clients, automatic dump | |
# - the dump should use array startsearch to write it line by line | |
# and may just use gets to read element by element and load the whole state. | |
# - 'help','stopserver','saveandstopserver','save','load','reset','keys' commands. | |
# - ttl with milliseconds resolution 'ttl a 1000'. Check ttl in dump! |