Write 日報 Every Day

先月から毎日日報を書くことにした。毎日コードを書いてコミットし続けるのは大変だけど、通勤時間に本を読んだり仕事のなかで学ぶことはあるから、せめて日報にそれを記録しようと思った。

日報はDropbox内にmarkdown形式で書いている。~/Dropbox/Documents/日報/2017-11-01.mdみたいなパスに保存している。

## 学んだこと

## 思ったこと

みたいなフォーマットで書いている。日報を書くハードルを下げるためにnippoというスクリプトを書いた。

毎日記録することで少しずつ前進している実感が湧いてきた。

net/httpによるHTTPメソッドを含んだルーティングの実装

最近GoによるWebアプリケーション開発を学び始めたので間違っている箇所があればコメントください。

ServeMux型によるルーティング

http.Handle関数を使うとパスに対するルーティングを登録することができる。http.Handler型は実際にリクエストを処理するオブジェクトで、下のように実装すると/foodsへのリクエストを*FoodsHandler型が処理することになる。

http.Handle("/foods", &handlers.FoodsHandler{})

http.Handle関数によって登録されたルーティングはhttp.DefaultServeMuxという*ServeMux型の変数が保持することになる。

type ServeMux struct {
    mu    sync.RWMutex
    m     map[string]muxEntry
    hosts bool
}

type muxEntry struct {
    h       Handler
    pattern string
}

登録されたルーティングはフィールドmで保持される。サーバーはmから一致するパスを探し、対応するHandlerを呼び出す。

見たところ、ServeMux型ではGET, POST等のHTTPメソッドを考慮していない。RESTful APIを実装するにはHTTPメソッドを考慮する必要があるため、ServeMux型によるルーティングでは不十分だと分かる。そこで、ルーティングを自前で実装する。

Handlerによるルーティング

http.Handle関数の代わりにhttp.ListenAndServe関数に渡すhttp.Handlerによってルーティングを実装する。

http.ListenAndServe(":8080", handler)

http.DefaultServeMuxを使う場合はhandlerの代わりにnilを渡すが、自前のハンドラーを使う場合はここに渡す。

type RoutesHandler struct {
    routes map[string]map[string]http.Handler
}

func (h *RoutesHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    paths, ok := h.routes[r.Method]
    if !ok {
        w.WriteHeader(http.StatusNotFound)
        return
    }

    handler, ok := paths[r.URL.Path]
    if !ok {
        w.WriteHeader(http.StatusNotFound)
        return
    }

    handler.ServeHTTP(w, r)
}

*ServeMux型とは違い、map[string]map[string]http.Handler型のフィールドroutesでHTTPメソッドを含むルーティングを管理するようにした。ServeHTTP関数を実装することでhttp.Handler型のインターフェイスを満たしている。内部でroutesから一致するハンドラーを呼び出す。

func (h *RoutesHandler) GET(path string, handler http.Handler) {
    h.register("GET", path, handler)
}

func (h *RoutesHandler) POST(path string, handler http.Handler) {
    h.register("POST", path, handler)
}

func (h *RoutesHandler) register(method, path string, handler http.Handler) {
    if h.routes == nil {
        h.routes = make(map[string]map[string]http.Handler)
    }

    _, ok := h.routes[method]
    if !ok {
        h.routes[method] = make(map[string]http.Handler)
    }

    h.routes[method][path] = handler
}

こうした関数を定義し、ルーティングを登録できるようにする。

routesHandler := &handlers.RoutesHandler{}
routesHandler.GET("/foods", &handlers.FoodsHandler{})

http.ListenAndServe(":8080", routesHandler)

GoのためのDockerfile

base image

library/golangで公式イメージが用意されている。ユースケースに合わせていくつかの種類が用意されている。

  • golang:<version>: 何が必要なのか分かっていない場合はこれを使った方がよさそう。
  • golang:alpine: Alpine Linuxをベースとしているため非常に軽い。イメージサイズを小さくしたい場合に推奨されている。
  • golang:onbuild: ネット上ではよく紹介されているが、公式では非推奨とされている。

ディレクトリレイアウト

$ docker run -i -t --rm golang:1.9 /bin/bash
root@xxxxxxxxx:/go# pwd
/go
root@xxxxxxxxx:/go# ls
bin src
root@xxxxxxxxx:/go# env | grep GO
GOLANG_VERSION=1.9
GOPATH=/go

GOPATH/goに設定されているので、/go/src/以下にWORKDIRを設定していく。

Dockerfile

FROM golang:1.9
WORKDIR /go/src/github.com/naoty/golang-sample
COPY . .
RUN go install github.com/naoty/golang-sample
ENTRYPOINT ["golang-sample"]

go install .../go/bin/以下にバイナリがビルドされる。PATH/go/binも含まれているため、そのままビルドされたバイナリを指定するだけでOK。

参考

Goでちょっとしたツールを作った

Go言語のレベルアップを目的としてちょっとしたツールを2つ作った。

license

MITライセンスファイル(LICENSE)を作成するとき、いつもMIT License | Choose a Licenseからコピペしていた。さすがに毎回同じことをするのは面倒になってきたのでテンプレートからテキストを生成するだけのコマンドラインツールを書いた。text/templateを使ったことがなかったのでちょうどいい練習になった。

brewery

Goで書いたコマンドラインツールはnaoty/homebrew-miscからHomebrewでインストールできるようにしている。その準備をするためにformulaを作るとき、brew create <url> --tap naoty/miscを実行していた。しかし、この方法だと/usr/local/Homebrew/Library/Taps/naoty/homebrew-misc/以下にformulaが作成されてしまい、その後ワークスペースにコピペする作業が発生していた。

そこで、formulaをテンプレートから生成して標準出力に出力するだけのコマンドラインツールを作った。SHA256もちゃんと計算してくれるので便利。今後はformulaを書く作業が捗りそう。

学び

  • text/templateの使い方。Webアプリケーションを開発するのであれば、同じようなパッケージであるhtml/templateが確実に必要になるので、覚えておきたかった。
  • https://github.com/jteeuwen/go-bindataによってテンプレートをバイナリに含めること。これもテンプレートを使う以上シングルバイナリにして配布を簡単にするために必要になるだろう。
  • golang/depの使い方。おおかたの仕様についてはstableになったとのことなので、今から使い方に慣れておきたい。dep ensureのバリエーションとGopkg.tomlの書き方をもう少し把握したい。

近況

5月

  • 結婚式を挙げ、新婚旅行にいった。

6月

  • 30歳になった。
  • 仕事が忙しくなりはじめる。最近はRailsでサーバーサイドを書いている。
  • 結婚式の準備などの忙しさから解放されたため、個人開発を少しずつ始める。ElectronでTodoアプリを作り始め、Webpack, React, Redux, TypeScriptなどモダンなWebフロントエンドの技術スタックについて学んだ。

7月

  • 仕事の忙しさがピークに至る。

8月

  • 仕事がだいたい落ち着く。
  • お盆休みは海いったりバーベキューしたり、ここ10年で最も充実した夏だった。
  • 個人開発では、RailsでモダンなWebフロントエンド環境を導入するための知見を学んだ。具体的にはwebpackerについて学んだ。http://naoty.hatenablog.com/entry/2017/08/17/201249
  • また、GraphQLにも興味をもちRailsで試してみたりした。引き続き学んでいきたい。
  • ある日、思い立ってこのブログのスタイルを書いた。なるべく文章が読みやすいデザインを心がけた。 https://github.com/naoty/focus-theme

`bin/webpack`を読んだ

webpackerを理解するため、rails g webpacker:installで追加されるbin/webpackや設定の中身を読むことにした。

bin/webpack

newenv  = { "NODE_PATH" => NODE_MODULES_PATH.shellescape }
cmdline = ["yarn", "run", "webpack", "--", "--config", WEBPACK_CONFIG] + ARGV

Dir.chdir(APP_PATH) do
  exec newenv, *cmdline
end
  • bin/webpackでは実際にはyarn run webpack -- --config WEBPACK_CONFIGを実行している。
  • WEBPACK_CONFIGconfig/webpack/#{NODE_ENV}.jsとなっているため、config/webpack/development.jsなどとなる。

config/webpack/development.js

const sharedConfig = require('./shared.js')

module.exports = merge(sharedConfig, {
  // ...
})
  • config/webpack/shared.jsというファイルが環境ごとの設定ファイルでmergeされているようだ。

config/webpack/shared.js

const { env, settings, output, loaderDir } = require('./configuration.js')
  • settingsconfig/webpacker.ymlをロードしたオブジェクトを参照している。
    • settings.extensions: [.coffee, .erb, .js, .jsx, .ts, .vue, ...]
    • settings.source_path: app/javascript
    • settings.source_entry_path: packs
  • outputpathpublicPathというプロパティをもったオブジェクトを参照している。
    • path: public/packs
    • publicPath: ‘/packs’
      • ASSET_HOSTという環境変数を指定することでホストを変更できそう。
  • loadersDirconfig/webpack/loaders/を参照している。
const extensionGlob = `**/*{${settings.extensions.join(',')}}*`
const entryPath = join(settings.source_path, settings.source_entry_path)
const packPaths = sync(join(entryPath, extensionGlob))

module.exports = {
  entry: packPaths.reduce(
    // ...
  )
}
  • entryはwebpackによってbundleされる対象のファイルを設定する。
  • synchttps://github.com/isaacs/node-globからexportされている。同期的にglobサーチをしている。
  • ここでは、app/javascript/packs/**/*{.coffee,.erb,.js,.jsx}*のようなglobでファイルを検索し、マッチしたファイルのリストがpackPathsに代入されている。
  • つまり、app/javascript/packs/以下のsettings.extensionsで指定された拡張子をもつファイルがwebpackによってbundleされるということになる。
module.exports = {
  entry: packPaths.reduce(
    (map, entry) => {
      const localMap = map
      const namespace = relative(join(entryPath), dirname(entry))
      localMap[join(namespace, basename(entry, extname(entry)))] = resolve(entry)
      return localMap
    }, {}
  )
}
  • entryにオブジェクトが指定された場合、プロパティごとにbundleされるファイルが分割される。output.filename[name]と指定された箇所にプロパティ名が入る。
const { env, settings, output, loaderDir } = require('./configuration.js')

module.exports = {
  output: {
    filename: '[name].js',
    path: output.path,
    publicPath: output.publicPath
  }
}
  • outputはbundleされたファイルの出力先を設定する。
  • output.filenameでbundleされたファイル名を設定する。entryがオブジェクトで指定されているため、[name]にはオブジェクトの各プロパティ名が代入される。
  • output.pathは出力先のパスを設定する。上記の通りpublic/packsが設定されている。
  • output.publicPathは本番ビルド時のCSSやHTML内のURLを設定する。これは本番のみCDNを使う場合に便利。上述の通りこれは/packsが設定されているが、ASSET_HOSTという環境変数でこれを変更することができるようになっている。
module.exports = {
  module: {
    rules: sync(join(loadersDir, '*.js')).map(loader => require(loader))
  }
}
  • rulesはwebpackのモジュールを設定する。
  • config/webpack/loaders/*.jsにマッチするファイルを検索している。
  • マッチしたファイルをrequireしている。各ファイルは以下のようになっている。これによって、config/webpack/loaders/*.js内の設定を展開している。
module.exports = {
  test: /\.(jpg|jpeg|png|gif|svg|eot|ttf|woff|woff2)$/i,
  use: [{
    loader: 'file-loader',
    options: {
      publicPath,
      name: env.NODE_ENV === 'production' ? '[name]-[hash].[ext]' : '[name].[ext]'
    }
  }]
}
const webpack = require('webpack')
const ExtractTextPlugin = require('extract-text-webpack-plugin')
const ManifestPlugin = require('webpack-manifest-plugin')

module.exports = {
  plugins: [
    new webpack.EnvironmentPlugin(JSON.parse(JSON.stringify(env))),
    new ExtractTextPlugin(env.NODE_ENV === 'production' ? '[name]-[hash].css' : '[name].css'),
    new ManifestPlugin({
      publicPath: output.publicPath,
      writeToFileEmit: true
    })
  ]
}
= stylesheet_pack_tag "application" # load /packs/application-xxxxxxxx.css
{
  "application.css": "/packs/application-xxxxxxxx.css"
}
module.exports = {
  resolve: {
    extensions: settings.extensions,
    modules: [
      resolve(settings.source_path),
      'node_modules'
    ]
  }
}
  • resolveはモジュール解決方法を設定する。webpackはデフォルトではいい感じに設定されている。
  • resolve.extensionsはファイル名からモジュールを解決する際に自動的に付与する拡張子を設定する。
  • resolve.modulesはモジュールを解決する際に検索されるディレクトリを設定する。

github.com/rails/webpacker/lib/webpacker/helper.rb

#stylesheet_pack_tagマニフェストファイルからどのようにアセットを参照するかを確認する。

def stylesheet_pack_tag(*names, **options)
  unless Webpacker.dev_server.running? && Webpacker.dev_server.hot_module_replacing?
    stylesheet_link_tag(*sources_from_pack_manifest(names, type: :stylesheet), **options)
  end
end

def sources_from_pack_manifest(names, type:)
  names.map { |name| Webpacker.manifest.lookup(pack_name_with_extension(name, type: type)) }
end

def pack_name_with_extension(name, type:)
  "#{name}#{compute_asset_extname(name, type: type)}"
end
  • #sources_from_pack_manifestマニフェストからアセットのファイル名を解決しているようだ。
  • ActionView::Helpers::AssetUrlHelper#compute_asset_extnameはファイル名とtypeから適切な拡張子を返す。
  • Webpacker.manifestWebpacker::Manifestインスタンスを返す。

github.com/rails/webpacker/lib/webpacker/manifest.rb

def lookup(name)
  compile if compiling?
  find name
end

def find(name)
  data[name.to_s] || handle_missing_entry(name)
end

def data
  if env.development?
    refresh
  else
    @data ||= load
  end
end

def refresh
  @data = load
end

def load
  if config.public_manifest_path.exist?
    JSON.parse config.public_manifest_path.read
  else
    {}
  end
end
  • #lookupマニフェストファイルの中身にアクセスしている。
  • マニフェストファイルの中身はJSON.parseした結果をメモリに保持している。開発環境ではアクセス毎にJSON.parseし直している。