Skip to content

Instantly share code, notes, and snippets.

Avatar
💭
💉💉💉😷

Edward Muller freeformz

💭
💉💉💉😷
View GitHub Profile
View redis.go.md

Connecting in Go

Use the redigo or redis package in your application.

$ go get github.com/garyburd/redigo/redis 
$ # OR
$ go get gopkg.in/redis.v5
View main_test.go
package main
import (
"context"
"fmt"
"testing"
"github.com/pressly/chi"
)
View USA, CA, San Francisco.md

Restaurants

View keybase.md

Keybase proof

I hereby claim:

  • I am freeformz on github.
  • I am freeformz (https://keybase.io/freeformz) on keybase.
  • I have a public key whose fingerprint is 8275 DE1C B8C3 BDA3 4463 0307 4CFC 26B0 A8B0 8656

To claim this, I am signing this object:

View issue #1.md

Glide didn't save all deps of github.com/mattes/migrate when it was glide get github.com/mattes/migrate'd.

!!
 !!    'GOVERSION' isn't set, defaulting to 'go1.6'
 !!
 !!    Run 'heroku config:set GOVERSION=goX.Y' to set the Go version to use
 !!    for future builds
 !!
-----> Installing go1.6.2... done
View response.json
{"responseStatus":"500 INTERNAL_SERVER_ERROR","responseDetails":{"Error_Reason":"Error executing setEmailPrefForward: null object"}}
View gist:a1f4064438c8125ab6af
$ go test -cpu 1,4 -bench Pipe -benchmem .
PASS
BenchmarkPipeline 50 25605141 ns/op 45.76 MB/s 3263675 B/op 32618 allocs/op
BenchmarkPipeline-4 2000 1311399 ns/op 30.85 MB/s 163586 B/op 1582 allocs/op
$ git checkout remove_front_buff
Switched to branch 'remove_front_buff'
$ go test -cpu 1,4 -bench Pipe -benchmem .
PASS
BenchmarkPipeline 100 13675065 ns/op 110.69 MB/s 3564797 B/op 36274 allocs/op
View abort.md

@sdboyer

You're right - they are not. Which is why I never said they were "required," or "needed." Necessity is not at issue; the question is whether or not they have supplemental information that makes it easier to determine compatibility.

It certainly makes it quicker, but I'd argue less accurate and more prone to error than analyzing the code to determine what's actually compatible (API wise).

...well, this weirds me out, because this is pretty close to what I'm arguing for.

I want authors of packages to use descriptive version tags/branches (semver would be a nice standard as @davecheney pointed out) for what they are developing and to specify the specific versions of their deps (e.g. vendor.json, Godeps.json). The specific versions are the only ones the author has tested with / believes to work with their package. The range argument, to me anyway, relays: "I think versions ~>1.2 works with my package, have fun resolving the ambiguity and have fun figur

View gist:f5587afb54db973aa248
FROM heroku/cedar:14
RUN useradd -d /app -m app
USER app
WORKDIR /app
ENV HOME /app
ENV RUBY_ENGINE 2.2.1
ENV BUNDLER_VERSION 1.7.12
ENV NODE_ENGINE 0.10.38
View nonstdlib
#!/bin/bash
# Display the packages that your code imports / depends on that
# are not in the go std lib.
result=()
#my deps
# NOTE: Requires jq
mine=($(go list -json | jq '.Imports + .Deps | .[]' | sort -u | sed -e 's/"//g'))