Go関連のことを調べてみた2019年11月04日

Golang によるfirebase AuthenticationにおけるJWT解析

# 概要

以下のような形式のJWTを分解しclaims部分を抽出、そして、デコードしFirebaseにおけるユーザー情報を取得するライブラリをGolangで作成した。

“`bash
{base64エンコードしたhead１er}.{base64エンコードしたclaims}.{署名}
“`

発行者(今回は、Firebase)が鍵を使用して、JSONに署名することでトークンとして扱うことができる。また、鍵を使用して検証することで改善を検知できる。
claims部には、ユーザー名などの任意の情報を含めることができる。

git: [k-washi/jwt-decode](https://github.com/k-washi/jwt-decode)

# インストール

“`bash
go get -u github.com/k-washi/jwt-decode/jwtdecode
“`

# 使用例

以下のプログラムを次のようなコマンドで実行した結果、firebaseに格納されたユーザIDとメールアドレスが取得できる。

“`bash
> go run main.go
Us

[WIP] 準備 Go 基本的環境

Install everything/tools use Homebrew

“` sh
brew install go
brew install dep
“`

`dep` is a the dependency management tool for Go

> https://github.com/golang/dep

### Setup $GOPATH

Add the following content to `.zshrc`

“` bash
# Go development
export GOPATH=”${HOME}/path/to/root/go”
export GOROOT=”$(brew –prefix golang)/libexec”
export PATH=”$PATH:${GOPATH}/bin:${GOROOT}/bin”
test -d “${GOPATH}” || mkdir “${GOPATH}”
test -d “${GOPATH}/src/github.com” || mkdir -p “${GOPATH}/src/github.com

コールバック関数を使ってリソースリークを防ぐ

GoにはGCがあるのでメモリリークは基本発生しませんが、メモリ以外のリソースはリークします。
たとえばよくありそうなのがファイル閉じ忘れ。

https://play.golang.org/p/h7cOUtlLkIk

“`
package main

import (
“io/ioutil”
“log”
)

func main() {
f, err := ioutil.TempFile(“”, “tmp”)
if err != nil {
log.Panic(err)
}
// f.Closeしてない！
f.Write([]byte(“hoge”))
}
“`

f.Close()するのを忘れてるのでリークしちゃってます。
f.Close()忘れを防ぐために静的解析でチェックするというアプローチもあるかとは思うのですが、そもそも手動で解放するから忘れるのであって、自動で解放してくれる仕組みがあればclose忘れを完全に防げるはずです。
ということで今回は別の方法を考えてみました。

ioutil.TempFile()を直接使うのではなく、例えば次の例のようにラ

Dockerで立てるGoのgRPCサーバ(※後々追記します)

## 前提とか
– goの実行環境
– dockerの実行環境

## まずはGoを使ってgRPCサーバを立ててみる
##1. 必要なものをinstall
gRPCxGoは色々なところで書かれているので簡単に。

### GoのgRPCライブラリをinstall
“`
go get -u google.golang.org/grpc
“`
### Protocol Buffersをインストール
– IDL(インターフェイス定義言語)で書かれたファイルをコンパイルするのに必要。

“`
brew install protobuf
“`

## Protocol Buffersのプラグインをインストール
– IDLに書かれた定義をGo言語へ変換するのに必要。インターフェイスをGo言語で自動生成する。

“`
go get github.com/golang/protobuf/protoc-gen-go
“`
protoc-gen-goはPATHが通った場所に置く必要があるので、`.bash_profile`やらに、以下を記述してPATHを通してあげる。自分は`$GOPATH/b

[golang] gRPC の RESTful API を dockernize するにあたって苦労したところ

## TL;DR

– gRPC gateway 用と server 用で別のコンテナを立てて, オーケストレーションの方で組み合わせられるようにする

## 成果物

こちらの記事の内容を dockernize させていただきました
https://qiita.com/ryu3/items/b2882d4f45c7f8485030

コンテナ立てる

“`sh
$ docker-compose up api
Creating network “siiid-gke_default” with the default driver
Creating siiid-gke_api_gateway_1 … done
Creating siiid-gke_api_1 … done
Attaching to siiid-gke_api_1
api_1 | 2019/11/02 23:49:42 Received: nakata
“`

API叩く

“`sh
$ curl -vvv -X GET http://0.0.0.0:8765/v1/exa

[Go]設定ファイルと環境変数の両方をいい感じに使う

##TL;DR
– 基本の設定を設定ファイルから取得してから、環境変数で上書きできるようにしよう

## アプリケーションと設定
`The Twelve-Factor App`の[III. Config](https://12factor.net/ja/config)には以下のように書いてある
>アプリケーションの 設定 は、デプロイ（ステージング、本番、開発環境など）の間で異なり得る唯一のものである。設定には以下のものが含まれる。
– データベース、Memcached、他のバックエンドサービスなどのリソースへのハンドル
– Amazon S3やTwitterなどの外部サービスの認証情報
– デプロイされたホストの正規化されたホスト名など、デプロイごとの値
…
Twelve-Factor Appは設定を 環境変数 に格納する。

これをみたときに環境変数に設定を全て格納すれば良いのかとも思えるが、よく読むと

>なお、この“設定”の定義には、アプリケーション内部の設定は 含まない ことに注意する。内部の設定とは、Railsにおけるconfig/routes.rbや、Sprin

オブジェクト指向な人に捧ぐGO言語の特徴

# TL;DR

GO言語はOOP（オブジェクト指向）な思考回路で書くと割ととっちらかってしまうので、特徴的なところをピンポイントで抑えたいとおもいます。

# 多態性（ポリモーフィズム）はダックタイピングで実現

宣言的に親（あるいはインターフェイス）を記述しなくても、そのオブジェクトが実装条件を満たしていれば親（インターフェイス）として振舞うことができます。

こちらがインターフェイス。

“`go

type Hito interface {
walk() string
}
“`

`Hito`インターフェイスを満たすにはstructが`walk()`を持つように実装します。`Male`というstructを実装してみました。

“`go

type Male struct {
}

func (m Male) walk() string {
return “テクテク”
}
“`

`Male`は`Hito`インターフェイスを満たしているので`doWalk(h Hito)`に引数として渡せるようになります。

“`go

func main() {
male :=

Go言語でポリモーフィズムとその便利さを理解する

継承・カプセル化・ポリモーフィズムはオブジェクト指向の3大要素と呼ばれています。そのうち今回の記事で扱うポリモーフィズムは日本語では多様性などと訳されますが、どのような概念なのかがいまいち分かりずらく、実装例を見ても何の役に立つのか自分には長らくピンと来ませんでした。
本記事では、ポリモーフィズムとは何か、何が便利なのかをGo言語での実装例と共に紹介していきたいと思います。

##ポリモーフィズムとは？
ポリモーフィズムを一言で言うと、**「同じインターフェイスを操作しても、それを実装するインスタンスによって違う動きをさせる仕組み」**であると自分は理解しています。

オブジェクト指向の本として有名な「オブジェクト指向でなぜ作るのか」では
>類似したクラスに対するメッセージの送り方を共通化する仕組み

と説明されています。Javaで言うと、同じクラスのメソッドを呼び出しても、そのメソッドを持つ親クラスを継承する子クラスによって実際の動きは異なってくるというところでしょうか。ポリモーフィズムはメソッドの呼び出し側で楽をするための仕掛けです。

※言葉で聞いただけでピンと来なくても、実装例

gonum/matで単位行列を生成する

# コード

“`go
idSlice := make([]float64, n*n)
for i := 0; i < n; i++ { idSlice[i*(n+1)] = 1 } idMat := mat.NewDense(n, n, idSlice) ``` これでできる。 # サンプルコード `go get gonum.org/v1/gonum/mat`を実行して、コピペすれば動く。 ```go package main import ( "fmt" "gonum.org/v1/gonum/mat" ) func matPrint(X mat.Matrix) { fa := mat.Formatted(X, mat.Prefix(""), mat.Squeeze()) fmt.Printf("%v\n", fa) } func main() { n := 4 idSlice := make([]float64, n*n) for i := 0; i < n; i++ { idSlice[i*(n+1)] = 1 } idMat :=

GO言語でmapの値に構造体を使う時はポインタにすると良いらしい

# mapの値に構造体を入れたらエラーが・・・
先日、職場でこんな感じのコードを書いたらエラー。（コードはサンプルです）

“`go:umaimono.go
package main
import “fmt”

type Food struct {
ID int
Name string
Description string
}

func main(){
fmt.Println(MakeResult()[“うまいもの”])
}

func MakeResult() map[string]Food {
result := make(map[string]Food)
result[“うまいもの”] = Food{
ID: 1,
Name: “焼肉”,
}
result[“うまいもの”].Description = “すこぶるうまい”

return result
}

“`
これを実行すると `cannot assign to struct field result[“うまいもの”].Descripti

Goのディレクトリ構成(追記予定)

# Goのディレクトリ構成をきっちり知っておきたい

## /src 開発用のディレクトリ

– プロジェクトごとにsrc 以下にディレクトリをつくる。
– ソースコード管理プラットフォームごとに切るのがGoの思想的
– go install するとpkgに実行したパッケージをコンパイルしたものが作られる。
– go buildをmainパッケージで実行すると/binに実行可能なバイナリファイルが作られる。

## /bin 実行可能ファイル、バイナリ
– 環境変数PATHに設定することが推奨されている。’export PATH:=$GOPATH/bin’

## /pkg コンパイルされたファイル
– srcからコンパイルされた非アプリケーション実行ファイルの.aファイル

## tips
– githubからgo getするようなものは、実態としてはgit cloneとgo installである。

goとpythonで始めるgRPCの事始め

gRPCってなんだって思って調べてたら実装してしまっていたので備忘録として残します。

## ゴール

このようなディレクトリ構造でpythonクライアントとgoサーバー間でgRPCを実装していくことをゴールとします.

“`
$GOPATH/src/pygo-grpc/
├ client/
| ├ app.py
| ├ hello_pb2_grpc.py　　　　　(gRPC自動生成)
| └ hello_pb2.py　　　　　　　　(gRPC自動生成)
├ protos/
| └ hello.protc
└ server/
├ grpc-server/hello.pb.go　(gRPC自動生成)
└ server.go
“`
## プロトコルを定義

– `$GOPATH`の配下に新しいワーキングディレクトリを作成し、プロトコルを定義します。

“`
~ $ cd $GOPATH/src
src $ mkdir pygo-grpc;cd $_
pygo-grpc $ mkdir client protocs server serve

Golangらしいコードを書こう

# はじめに
この記事は未完成です。Golangらしいコードというのは文化のようなものだと考えているので、様々な方の意見を取り込みながら、この記事を充実させていきたいと考えています。よろしくお願いいたします。

# Goらしいコードの前に
全言語共通のルールについてまとめます。きれいなコードを学びたい方へのおすすめは[リーダブルコード](https://www.amazon.co.jp/%E3%83%AA%E3%83%BC%E3%83%80%E3%83%96%E3%83%AB%E3%82%B3%E3%83%BC%E3%83%89-%E2%80%95%E3%82%88%E3%82%8A%E8%89%AF%E3%81%84%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%9B%B8%E3%81%8F%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%81%A7%E5%AE%9F%E8%B7%B5%E7%9A%84%E3%81%AA%E3%83%86%E3%82%AF%E3%83%

今すぐ「レイヤードアーキテクチャ+DDD」を理解しよう。（golang）

# 今すぐ「レイヤードアーキテクチャ+DDD」を理解しよう。（golang）
とはいっても記事を読み終わるのに三時間くらいかかる気がします。
## 対象読者
– レイヤードアーキテクチャ+DDDの実装に困っている方
– バックエンドエンジニアを目指す学生
– APIサーバを開発したことがある方

## はじめに
アーキテクチャは学習コストが高いと言われています。その要因の一つとして考えられるのはアーキテクチャの概念を学んだとしても、アーキテクチャの細かい部分は実装者に左右されるので、ネット上にあるプログラムは概念とはズレがあるので混乱しやすいことだと思います。それに加えて他のサイトを参考にした時もやはり実装者による違いで混乱してしまうからです。
したがって、概念とズレがある部分はしっかり言及したうえで解説することが良いと思います。

## アーキテクチャを採用する意味
– レイヤ間が疎結合になるため、ユニットテストが行いやすいこと。
– 責務がはっきりしているので、保守性が高いこと。
– 途中からフレームワーク等を入れたとしても影響範囲が限定されるので外部の技術の変更が容易なこと。

Beego+MySQL+Docker+Heroku

# はじめに
普段は，docker-composeでgolangとMySQLを管理しています．
Herokuへのアプリのアップを試みました．（DBストレージw）
個人開発でDBストレージ消費するサービス運用って，素敵なサーバどうしたものか．．．

# 環境
ubuntu16
Herokuアカウント・クレジットカード登録済み．
ローカルではアプリ動きます．
Dockerfileにはマルチステージビルドを採用しています．
herokuへpushするimageは25MBくらいでした．（もっと小さくしたい）

“`:Dockerfile

FROM golang:1.12.12-alpine3.9 AS build

ENV GOPATH $GOPATH:/go
ENV PATH $PATH:$GOPATH/bin

RUN apk update && \
apk add –no-cache git ca-certificates tzdata && \
go get “github.com/go-sql-driver/mysql” && \
go get “github.co

Golang APIレイヤードアーキテクチャで組んでみた。

# 初めに
今回アーキテクチャを触れるきっかけは、Golangで成果物を作りたいと考えたときに、文法などの知識を知っていてもどのようにフォルダの構造を決めてどの実装から取りかかればいいかわからなかったことです。アーキテクチャを勉強することでどのpackageがどのpackageに依存しているのかを明確にすることができるとともに、どの実装から取りかかれば良いのかも依存関係から知ることができる。

##対象読者
* アーキテクチャってなんだろうという方
* Goで何か成果物を作りたいが最初何から実装すればいいかわからない方
* 他

# 実装内容
今回実装したのは、TodoリストのRESTAPIである。この記事を書いたのはGetAll()APIを実装した段階である。

# アーキテクチャ
今回はレイヤードアーキテクチャを採用しました。アーキテクチャを初めて触れるにあたり触れやすいと聞いたので採用しました。構造は以下の通り作成しました。矢印方向に依存しています。

![レイヤードアーキテクチャ.png](https://qiita-image-store.s3.ap-northeast-1

Goでマルチドキュメントのyamlを読み込む方法

Go言語でマルチドキュメントのyamlを取り扱いたい.
具体的にはkubernetesのマニフェストを読み込んでごにょごにょしたかった

## マルチドキュメントyaml

“`yaml
—
test: 1
sample: hoge
—
test: 2
sample: hogehoge
—
test: 3
foo: foo
“`

こういうハイフン区切りになっているyamlファイル

## 実際のコード

“`main.go
package main

import (
“fmt”
“gopkg.in/yaml.v2”
“os”
)

func main() {
f, err := os.Open(“test.yml”)
if err != nil {
return
}
defer f.Close()

dec := yaml.NewDecoder(f)

var tmp map[interface{}]interface{}
for(dec.Decode(&tmp)) == nil {
fmt.Printf(“%v\n”, tmp)

ノリと勢いで Go で Hello World する

# はじめに

タイトルのままです。

読み手の対象者は、
僕と同じで

– Go 言語って名前だけ知ってる
– 何ができるのか、とか、実際にコードを見たことはない
– でもなんか触ってみたい

そんな人です。

いつも通り、やりながら、書いていきます。

やることは、
[公式のなんかセットアップ系のページ](https://golang.org/doc/install)　をやります

## 実行環境

持病のローカルに色々入れてはいけない病が出ちゃうので、
docker 内でやります。

docker の alpine でやります。

“`
$ cat /proc/version
Linux version 4.9.184-linuxkit (root@a8c33e955a82) (gcc version 8.3.0 (Alpine 8.3.0) ) #1 SMP Tue Jul 2 22:58:16 UTC 2019
“`

## 1. install

知らないんだから、持ってないですw

“`
$ apk add go
fetch http://dl-cdn.alpine

Golangでベクトル演算を高速化しようとしてみた話

# はじめに

Goでスライスのベクトル演算などを書いてたときに、今までは

“`go
for i := 0; i

Goで指定日の0時ジャスト(00:00:00)を取得する処理とテスト

#概要
担当しているプロジェクトで当日の0時ジャストのタイミングを取得したいという要件があり、以下の記事を参考に実行しました。

[golangのtime.Timeの当日00:00:00を取得する方法とベンチマーク](https://qiita.com/ushio_s/items/3e270933641710bbd88e)

が、実装にあたり問題があったので0時ジャストを取得する方法を確認しつつ、時間処理で注意すべきことをまとめます。

# TL;DR

処理速度を求めないのであれば、以下のようにすればできます。処理速度を求めるのであればUnixTimeを使ったやり方がありますが、タイムゾーンの処理で問題が起こる可能性があるのでこの記事を読むことをお勧めします。あと、時間処理はテスト書いた方が良いです。

“`go
func (timeUtil *TimeUtilUsingDate) GetJust0AM(t time.Time) time.Time {

return time.Date(t.Year(),
t.Month(),
t.Day(),
0, 0, 0, 0