HomeGorseAn open-source recommender system service written in Go. DocumentationLive Demo Multi-sourceRecommend items from Popular, latest, user-based, item-based and collaborative filtering.
最近のGo Modulesプラクティス ~ ghqユーザーの場合も添えて | おそらくはそれさえも平凡な日々
最近Go Modulesを使っていて、だいたいプラクティスが定まってきたのでまとめてみる。 個人的な結論 Go Modulesは積極的に使っていけばいい 幾つか課題はある $GOPATH から出る必要もない $GO111MODULE を適宜設定すればよい どうせ次のGo 1.13からはどこに置こうが関係なくなる 2つのモード $GOPATH/src にプロジェクトを置いていると、今(Go 1.12)の標準動作はGOPATHモードになる。これは、$GOPATH/src 以下からサードパーティパッケージを読み込むこれまでのGoと同様の動作になるということ。 それ以外の場所では go mod コマンドを使ってGo Modulesを利用することができる。これをmodule-awareモードという。go.mod と go.sum を使って依存ライブラリを管理する方式になる。これらのファイルはgo m
モノレポ（mono repository）内でgoのmoduleを相対パスで利用する方法 - 寝ても覚めてもこんぴうた
goの依存管理ツールはいろいろありますが、最新はGo Modules(mod)を利用することが多くなってきたと思います。 dep(vendor)を利用した依存解決の場合にはgopath配下にあればある程度柔軟に相対的に依存を解決できましたが、 modは普通に利用するとリポジトリにコミットをした状態を期待しているような振る舞いをします。 モノレポで以下のように複数のモジュールを管理している場合には、modでは利用しづらいように思えましたが、 参照しているモジュールをコミットした状態ではなくとも参照したいという要望があったので解決してみました。 project ├ a_module │ ├ go.mod │ └ main.go ├ b_module │ ├ go.mod │ └ hoge │ └ say.go ... 各モジュールをmod化する 各モジュールをmod化します。 mod init
Go 言語のプロジェクト構成 - fugafuga.write
Go のプロジェクトのディレクトリ構成などについて プロジェクト構成 プロジェクトディレクトリをgo_workとする。 go_work ├── bin -> go install 時にバイナリが格納される ├── pkg -> 依存パッケージのオブジェクトファイル格納場所 └── src -> ソースコード格納場所 上記3つのディレクトリがあることが前提。 環境変数$GOPATHにプロジェクトディレクトリを指定することで、依存パッケージの解決が自動的に行われる。 % cd go_work % export GOPATH=`pwd` パッケージについて Go のパッケージは、Ruby で言うところの gem にあたる。 パッケージは自分で作ったり、Git などでリポジトリが公開されていれば、それをgo get コマンドでコピーして利用できる。 パッケージの作成 gosample というパッケ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - mitchellh/mapstructure: Go library for decoding generic map values into native Go structures and vice versa.
