概要

Goのdepで既にインストール済の依存パッケージに関して、既に指定されているブランチとは別のブランチを参照させるようにする方法についてです。
例えば、既にmasterブランチを参照する設定になっていたとして、一時的に開発中のfeature/sugoiブランチを参照させたい場合には以下のような手順で参照先のブランチを変えることができます。

Gopkg.tomlで指定済のbranch名を変更する

Gopkg.tomlの該当パッケージのbranch名指定（branch=xxxxx）を変更する。

変更前

仮にmasterブランチを参照している状態だとする。

[[constraint]]
  name = "github.com/hogehoge/fuga"
  branch = "master"

変更前

branchの指定を、参照させたいブランチ（ここではfeature/sugoi）に変更する。
なお参照させたいブランチは、githubからダウンロード可能な状態（githubにpush済）である必要がある。

[[constraint]]
  name = "github.com/hogehoge/fuga"
  branch = "feature/sugoi"

dep ensureを実行

Gopkg.tomlの記述内容を変更した状態でdep ensureを実行する。

dep ensure

これで、依存モジュールがGopkg.tomlで指定したブランチのものに更新される。

元に戻したいとき

Gopkg.tomlを元の内容に戻し、再度dep ensureを実行すればよい。

前書き

Python、R、Fortran90、C#、Processing、等々さわってきた結論として、

CとFortranからは逃れられない定めにあると悟りました

Goで土台を築くことに……

そして、後輩たちに布教するんだ……ふへっ

学ぶ上で用意した物

Go Tour
https://go-tour-jp.appspot.com/

スターティングGo言語
https://www.amazon.co.jp/dp/B01FH3KRTI/

本題

Go Tourのforまで学んで思ったことについて

導入

@yoskeoka 氏が WindowsにGo言語をインストールする方法まとめ

とまとめてくださっているので、導入には苦労しませんでした

と言うのも、入れろ入れろと煩く言われたウイルス対策ソフトの影響で、

挙動が不安定になり、

hello.go

package main

import "fmt"

func main() {
  fmt.Printf("Hello world\n")
}

の go run や go build に数分かかる、フリーズしかける、など

酷い目に遭いました

うーん、初歩的!

気に入っている所

import.go

//----------------
import (
    "fmt"
    "time"
)
//----------------

importを枠内に書くので見やすい

()で囲むところもポイントが高い

type.go

//----------------------------
func add(x int, y int) int {
    return x + y
}
//-----------------------------

型を変数の後ろで定義する所が最初は違和感だったけれど、

xが整数と素直に読める事を考えると、素晴らしい!になった(小並感)

while.go

//-------while--------------------------
func main() {
    sum := 1
    for sum < 1000 {
        sum += sum
    }
//-------infinite-----------------------
func main() {
    for {
    }
}
//---------------------------------------

whileを利用した所、infiniteを利用した所など、

非常に分かりやすくて、すこすこのすこ!

ぐぬぬ……な所

func.go

//----------------------------------------
func swap(x, y string) (string, string) {
    return y, x
}
//----------------------------------------

戻り値の型の定義が、引数の隣なので忘れそうで怖い

loop.go

//----------------------------------------
func main() {
    sum := 0
    var i int = 0
    for ; i < 10; i++ {
        sum += i
    }
    fmt.Println(sum)
}
//----------------------------------------

暗示的な型には:=を、明示的な型にはvarを利用するのですが、

for文の変数に対して型を明示的するやり方が分からない件について

上の書き方で、var i int を var i float64 に変えると、

mismatched types int and float64

と返ってきたので、一応成功していそうです

態々そんなのする必要ある?は禁句

本日のまとめ

この言語、個人的にすこすこのすこてぃっしゅ!

明日はMethods and interface に突入したいね!

EC2にインストール

利用できるバージョンの確認

# amazon-linux-extras list | grep golang
 29  golang1.11=latest        enabled      \

インストール

amazon-linux-extras install golang1.11

GOPATHの追記

export GOPATH="$HOME/go"
export PATH=$PATH:$GOPATH/bin

インストール確認

# go version
go version go1.13.4 linux/amd64

実現したい機能

Shift-JIS EUC-JP ISO-2022-JP等の文字コードであるstringをGo内部で扱えるよう UTF-8 にデコードする。

実装

文字コードが既に分かっている場合の変換は以下の手順で実現できる。

• 入力stringのcharsetに応じたdecoderを取得
• decoderを用いてstringをUTF-8にdecode

package main

import (
    "errors"
    "fmt"
    "golang.org/x/net/html/charset"
    "golang.org/x/text/transform"
)

// Converts the specified charset to UTF-8.
func Decode(src []byte, charSet string) (string, error) {
    e, _ := charset.Lookup(charSet)
    if e == nil {
        return string(src), errors.New(fmt.Sprintf("invalid charset [%s]", charSet))
    }
    decodeStr, _, err := transform.Bytes(
        e.NewDecoder(),
        src,
    )
    if err != nil {
        return string(src), err
    }
    return string(decodeStr), nil
}

使い方

func TestDecode(t *testing.T) {
    t.Run("SJIS -> UTF-8", func(t *testing.T) {
        src := <SJIS byte slice>
        // encodingの指定は"sjis"や"Shift_JIS"でも可
        decoded, err := Decode(src, "shift_jis")
        fmt.Println(decoded)
    })
}

その他

今回のソースコードは以下に置いておきます。
https://github.com/tomtwinkle/go-encoding-decoder

比較コミュニケーションサイト Versus
https://versus-web.net

Twitter で技術マウント合戦している人たちが面白かったので
AWS と Go の勉強がてら、テーマを持ち寄ってコミュニケーションできる簡単な掲示板サイトを作ってみたので作業工程など記録してみる。

構成

インフラ

• ECS
• Lambda
• DynamoDB
• API Gateway
• Route 53

バックエンド

• Go

フロントエンド

• Nuxt (SSR)

Go と Fargate 辺りを使ってみたかったのでこんな構成になりました。

作業工程

タスク管理

タスク管理ツールとして Trello を使用した。

こんな感じに5カラムで管理してみた。
Doc としてドキュメント管理にも使用してみたが、シンプルでサクサク動くし、個人開発規模ならすごく使いやすいと思った。

デザイン

Figma を使用。

こんな感じに遷移図作ったり

色管理もしつつ、わりとしっかりめに使ってみたつもり（デザイナーの方からするとまだまだだろう）
このくらいやっておくと開発時だいぶ楽。

開発

Go

Lambda で採用。ディレクトリ構成は以下の通り。

.
├── posts-function
│   └── posts
│       ├── bin
│       ├── cmd
│       └── internal
│           ├── actions
│           ├── handler
│           ├── models
│           └── repositories
└── threads-function
    └── threads
        ├── bin
        ├── cmd
        └── internal
            ├── actions
            ├── handler
            ├── models
            └── repositories
                └── mock

AWS SAM を使用することで、コマンドで Go の Lambda 関数を作成することができる。
ディレクトリ構成は golang-standards を参考にした。
どの粒度で Lambda 関数を作成するか迷ったが、リソース単位で分割することにし、以下のようにハンドリングしてみた。

handler.go

package handler

import (
    "context"

    "posts/internal/actions"

    "github.com/aws/aws-lambda-go/events"
)

var routes = map[string]actions.ActionFactory{
    "GET":  actions.NewPostsGetter,
    "POST": actions.NewPostsPoster,
}

// CORS compatible
var headers = map[string]string{
    "Content-Type":                "application/json",
    "Access-Control-Allow-Origin": "*",
}

func Handler(ctx context.Context, request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    factory := routes[request.HTTPMethod]
    action := factory()
    jsonData, err := action.Run(request)
    if err != nil {
        return events.APIGatewayProxyResponse{}, err
    }

    return events.APIGatewayProxyResponse{
        Body:       string(jsonData),
        StatusCode: 200,
        Headers:    headers,
    }, nil
}

HTTP メソッドで振り分けるだけなのでルーティングは楽。関数を分ければ当然デプロイも分けられるので、この辺の粒度は規模を見つつといった感じになりそう。（ちなみに他プロジェクトではマイクロサービス粒度で分けていた）

Nuxt

フロントエンドで採用。
基本的に初期表示速度的な意味で SSR をすべきと思っているので今回も SSR を採用。
難しいことをしていないのであまり特筆する点がないのだが
バリデーションに vuelidate を使用してみてとても使いやすかったのでおすすめしたい。
人気の VeeValidate と比較すると、vuelidate はテンプレートとアプリケーションロジックが分離しているので、バリデーション時の処理を細く設定したい要件があるときに使いやすい。

所感

AWS と Go がほぼ初見だったためだいぶ苦労した。
Node なら Lambda 上のコードを AWS コンソールから見れるため、とっつきやすさもあるが、Go の場合それができず、デプロイ周りを整えるまで一苦労だった。
新しく何かを作るときは未知の技術は１種類にすべき、みたいな話をどっかで聞いたけどその通りだと思った。
しかし今回の技術スタックはだいぶ耳にすることも多くなってきたので、試してみるのは一興だと思う。