inforno

Go言語用のObject mapper generatorを書いた

22 Jul 23 11:14 UTC

Go言語で構造体と構造体をマッピングする、いわゆるObject mapperを生成するCLIを書きました。

経緯

READMEに書いてる通りですが、いわゆるClean architectureなど多層構造のアプリケーションではどうしても似たようなオブジェクトを定義せざるを得ないことがあります。

特にキツい(?)のがgRPCを採用した場合ですね。 protocが吐く構造体は完全にprotobufに依存したものになっておりある程度層をまたいで同じオブジェクトを持っていくのは許容しよう、と割り切ってもこれをいわゆるドメイン層にそのままもっていくのは結構ハードルが高いのではないかと思います。

＃あと、gogo/protobuf 亡き今、protoc-gen-goが非標準命名規則でソースコードを出力するのもキモチワルイ。。。

WEB上にいっぱいあるGo + gRPCのクリーンアーキテクチャサンプル的なものでもここはかならず似たオブジェクトに詰め替えています。GoにはJavaにおけるDTOのような歴史はあまりないですし、アーキテクチャ上必要なことなんだから手で書くべき、という人もいますがとはいっても項目数が多くなってくるとつらいですよね。

これをある程度自動で詰め替えるライブラリはリフレクションを使ったものはそれなりにあるのですが、経験上

リフレクションを使ったものはデバッグがつらい
- 項目が多くなってきたときに、1つだけなんかマッピングされてない！というときになんでマッピングされてないの？というのがわかりづらい
性能が微妙
- いくらGoのリフレクションが早いといってもリフレクション使わないコードよりは当たり前だが遅い

ということで、コード生成してくれるタイプのものが欲しかったんですがいいのが無かったので書いた、という次第です。

できること

構造体と構造体をマッピングするインタフェースと実装を生成できます。マッピング定義はYAMLに記載、結構柔軟に定義できます。ネストしたものも再帰的にマッピングできます。

例: stringとtime.Timeをマッピングするものを登録しておけば自動的にこれらのフィールドを持つ構造体を変換可能

比較的にきれいな(自分的には)インタフェースを吐くので最悪、このツール使うのやめようとなってもインタフェースに対する実装を自分で書けばよいだけです。生成するソースはこんな感じ

 1package mapper
 2
 3import (
 4    pkg00002 "time"
 5
 6    pkg00001 "example.com/testmod/domain"
 7    pkg00000 "example.com/testmod/model"
 8)
 9
10type TodoMapperHelper interface {
11    ModelToEntity(*pkg00000.TodoModel, *pkg00001.Todo) error
12    EntityToModel(*pkg00001.Todo, *pkg00000.TodoModel) error
13}
14
15type TodoMapper interface {
16    ModelToEntity(*pkg00000.TodoModel) (*pkg00001.Todo, error)
17    EntityToModel(*pkg00001.Todo) (*pkg00000.TodoModel, error)
18}
19
20// ... (TodoMapper default implementation)

Goでの構造体のマッピング、結構どうにかしたいと思いつつとりあえず全部手でやってました、という人も多いと思うのでもしよければ使ってみてください。

Go言語でCommonMarkパーサを実装した、またCommonMarkについて

26 Apr 19 16:50 UTC

GoでCommonMarkのパーサを実装しました。

分かりやすいASTに変換＋拡張が容易、そこそこ速い実装になっています。

めちゃくちゃしんどかったです。

経緯

Go言語のMarkdownパーサといえばblackfridayですが、拡張するための機構がないのでさくっと自前でMarkdownパーサを書くか、と思い立ちました。

そこで「そういえばCommonMarkなんてもんがあったな」と思い出しせっかくならCommonMark準拠にするかとおもってCommonMarkの仕様を読み始めました。

え、なにこれは…

Markdownで出来ることなんてrestructuredTextなどほかのマークアップ言語に比べればわずかなものです。しかし、たかがそれだけを実装するために凄まじく複雑な仕様が定義されているのでした。

以下、CommonMarkに寄せられた声です。

commonmarkのlistの仕様複雑すぎて死んでいる
— tkr (@kgtkr) 2019年3月28日

う〜ん、CommonMark難しすぎる！w
— らぃと (@lightnet328) 2019年2月23日

質問：
CommonMarkのパーザの実装を試みていますが、仕様が絶望的です。どうしたらいいでしょうか？

回答：
もっとテキトーにパーザを実装して、そのパーザの動作を以て“新しいMarkdown方言”であると定めましょう！#Markdown #うわぁ #うわぁ #うわぁ
— ZR-TeXnobabbler🤔 (@zr_tex8r) 2018年11月1日

皆さんには是非 CommonMark Spec を読んで絶望してほしい．
— 画力・博士号・油田 (@bd_gfngfn) 2018年10月31日

しまいには、CommonMarkの中心人物自体が「えらいもん作ってしまった・・・」となっています。

Beyond Markdown

There are 17 principles governing emphasis , for example, and these rules still leave cases undecided. The rules for list items and HTML blocks are also very complex. All of these rules lead to unexpected results sometimes, and they make writing a parser for CommonMark a complex affair. I despair, at times, of getting to a spec that is worth calling 1.0.

私も仕様を読んだ段階で「これはヤバい」と感じたのですがここで引くのも悔しかったので作り切りました。

CommonMarkについて思うところ

正直なところ、これが世に広まるってどうなの、と思います。

そもそもなんでMarkdownが軽量マークアップ言語の中でこれだけ広く使われるようになったのかというと

書き手としての書きやすさ
実装者としての実装しやすさ

つまり、「書き手の適当さ」と「実装側の適当さ」がいい具合に噛み合ったからだと思っています。書き手はそれなりに適当に書けるし、実装するにしても仕様が適当なので、適当に実装してもMarkdown 対応であると言うことができました。

それによってあらゆる言語、さまざまなタイプの実装が生まれそれが至るところで使われることになり Markdownは広まっていったのです。

それに対して、CommonMarkはあまりに実装するのがしんどすぎます。さらにはそれだけしんどい思いをしても出来ること自体は少ないのです。テーブルさえ使えないのです。

その実装の難しさからCommonMark対応のパーサはいわゆるMarkdownパーサと比べるとわずかしかありません。 CommonMarkにかかわっている人の中には「それが何の問題ですか？」という人さえいます。「CとJSで参照実装提供してるじゃん。ブラウザはC動かないからJSも用意してある。それ以外の言語は C実装のバインディング作ればいいだけでしょ。実装なんて1個あればいいんだよ」なんて感じです。

CommonMarkはオリジナルのMarkdown作者から「Markdownの名前は使うな」と言われてCommonMarkという名前になったという経緯があります。

Markdownを冠していないのであれば、perlの神正規表現で実装されたオリジナルのMarkdown.plの動きにできるだけ寄せようとするのではなく、もっと仕様をシンプルにする方向に動いて欲しかったです。

CommonMarkパーサを実装したい人に向けて

とにかく、CommonMarkに準拠するのは難しい。ということでいるかいないかわからない、CommonMarkパーサをこれから書こうと言う人に気づきを共有しておきます。

いわゆるプログラミング言語やXML, JSONなどのパースとは全く別物です。そういうものはもともと「パースしやすいように」という視点で文法が作られてますが、CommonMarkはそんなことはありません。 pegベースのパーサもあるので無理じゃないですがいわゆるLL,LRやLALRのような方法では厳しいです。
Markdownはいうなれば「行志向」なので業単位を基本としましょう。
「lazy continuation」はかなり曲者です。
仕様策定者自身が Beyond Markdown で述べている部分は間違いなくしんどいです。特に強調は自分で考えるのは諦めましょう。素直に参照実装と同じアルゴリズムで実装するより他にspec testを通すのは難しいです。
タブが本来のタブの意味でつかわれる点に注意。つまりタブ文字の位置によりタブは 1文字分、2文字分、3文字分、4文字分、いずれの文字幅にもなりえます。
とにかく折れない心が大事です。CommonMarkとMarkdownは別物です。覚悟してかかりましょう。

batの中にbashスクリフﾟトを埋め込む方法

14 Feb 17 16:25 UTC

相変わらずメインのマシンはWindowsなのですが、batファイルのもろもろがいつまでも覚えられず、bashスクリプトで書きたいなあ、ということでbatファイルにbashスクリプトを埋め込むことにしました。 Cでつくった自作用ツールがあるため、Windowsにはかならずmsys2をいれているのでbashは絶対あるんですよね。

その他の言語を埋め込む方法は

Windowsでshebangもどき、またはバッチにスクリプトを埋め込む方法

が詳しいです。

シェルスクリプトをバッチファイルに埋め込む

以下のようにすると、バッチファイルにシェルスクリプト(bashスクリプト)を埋め込むことにできます。拡張子 .bat で保存すると cmd.exe からもmsys2の bash.exe からも起動できます。

1:rem () { <<'#__CO__'
2@bash  "%~f0" %* & exit /b
3#__CO__
4}
5
6echo 以下普通にシェルスクリプト

仕組みはバッチファイルのコメントやら、bashのヒアドキュメントやら、: コマンドやらをうまく利用して埋め込んでいます。

Go1.8のpluginパッケージでGopherLuaに共有ライブラリロードを実装してみた

16 Dec 16 12:10 UTC

Go Advent Calendar 2016 16日目です。去年に引き続き今年も3つカレンダーがあり相変わらずの人気ですね。

さて、Go1.8では待望？のShared Libraryのロードが可能になります。 pluginパッケージを使います。

Go1.8beta1ではLinuxとMacOSがサポートされていたのですが、MacOSで問題が見つかりbeta2ではLinuxのみで利用可能な機能となります。

Advent Calendar 2の qt-luigiさんのネタと被ってしまったのですが実戦的に使ってみました、ということで許してください。

プラグインの作成とコンパイル

マニュアルページにあるとおり、以下のようになります。

 1package main
 2
 3// // No C code needed.
 4import "C"
 5
 6import "fmt"
 7
 8var V int
 9
10func F() { fmt.Printf("Hello, number %d\n", V) }

ポイントは

Cのコードはないが、 import "C" が必要
package は main

という２点です。コンパイルは

1$ go build -buildmode=plugin -o plugin.so plugin.go

でOK。簡単ですね。これで plugin.so が生成されます。

プラグインのロード

これまたマニュアルページどおりですが

 1p, err := plugin.Open("plugin.so")
 2if err != nil {
 3    panic(err)
 4}
 5v, err := p.Lookup("V")
 6if err != nil {
 7    panic(err)
 8}
 9f, err := p.Lookup("F")
10if err != nil {
11    panic(err)
12}
13*v.(*int) = 7
14f.(func())() // prints "Hello, number 7"

のように非常に直感的に使えます。

GopherLuaで使ってみた

拙作のPure GoによるLua実装 GopherLua ですが(何気にstarいっぱいでうれしいですね)、当然ながらC言語実装のように共有ライブラリをロードできませんでした。

そのため、必要なライブラリはすべて事前に組み込んでおく必要がありました。そこでGo1.8で共有ライブラリロードを実装できるのか、実装できるだろうけどちゃんと動くのか、と思い試してみました。

こちらは feature-exp-go1.8pluginsブランチで実際に動かせます。プラグイン部分のコミットは 571b031 です。

まずプラグイン側から。Luaのお作法通りです。

 1package main
 2
 3import (
 4    "C"
 5    "github.com/yuin/gopher-lua"
 6)
 7
 8func Add(L *lua.LState) int {
 9    v1 := L.CheckInt(1)
10    v2 := L.CheckInt(2)
11    L.Push(lua.LNumber(v1 + v2))
12    return 1
13}
14
15func LuaOpenPlugin(L *lua.LState) int {
16    L.Push(
17        L.SetFuncs(L.NewTable(), map[string]lua.LGFunction{
18            "add": Add,
19        }))
20    return 1
21}

C実装のLuaでは luaopen_共有ライブラリファイル名 が実行されるのですがそこはGoの命名規則に合わせました。違いはそれくらいですね。

こいつをコンパイルして・・・

1$ cd /home/yuin/tmp/plugin
2$ go build -buildmode=plugin -o plugin.so plugin.go

こうじゃ

1$ glua
2> package.cpath = package.cpath .. ";" .. "/home/yuin/tmp/plugin/?.so"
3> adder = require("plugin")
4> print(adder.add(1, 2))
53

おおおおおおおおおおおおお

普通に動きますね。素晴らしい。ちなみに、「ロードする側」と「ロードされる側(すなわちプラグイン)」のバージョンが違うと以下のようにエラーになります。この判定が結構厳しいので（プラグインが参照していない部分の更新でもダメっぽい）、事前にプラグインをコンパイルしておいて配布、は難しいのではないでしょうか。

1<string>:1: plugin.Open: plugin was built with a different version of package github.com/yuin/gopher-lua

package.loadlib も実装しました。

1$ glua
2> print(package.loadlib("/home/yuin/tmp/plugin/notfound", "foo"))
3nil plugin.Open(/home/yuin/tmp/plugin/notfound): realpath failed    open
4> print(package.loadlib("/home/yuin/tmp/plugin/plugin.so", "foo"))
5nil plugin: symbol foo not found in plugin plugin/unnamed-16c3f13f46f4b66b64ad316d78cd61078d12ac64  init
6> print(package.loadlib("/home/yuin/tmp/plugin/plugin.so", "LuaOpenPlugin"))
7function: 0xc4200c9840
8>

完璧ですね。

pluginパッケージ、使えそうですが・・・

少なくとも、Linuxでは plugin パッケージは使えそうです。ただし、本体と共有ライブラリのコンパイル時、完全にバージョンを合わせる必要があるところが難しそう。

Goの大きなメリットである単一バイナリ配布や、クロスコンパイルと相性は悪いですがうまく使っていければいいなと思います。

Go+Luaのチャットボットフレームワークを作った

28 Jul 16 11:32 UTC

たまには実用的なものをつくろうと思って、Go+Luaで置くだけで動くチャットボットを作ってみました。Slack, IRC, Hipchatをサポートしています。

チャットボットといえばHubotだと思いますが、もっとさくっと動かしたいという方におすすめです。置けばうごきます。

特徴は以下です。

Goなので置けば動く
それでいてLuaでスクリプトを書ける
最初からマルチスレッド(複数goroutine)を考慮している
HTTP(S)サーバ機能があるのでWEBHOOKも一緒に作れる
定期ジョブも流せる

 1function main()
 2  local bot = golbot.newbot("Slack", { token = "xxxxx" })
 3
 4  bot:respond([[\s*(\d+)\s*\+\s*(\d+)\s*]], function(m, e) -- 3
 5    bot:say(e.target, tostring(tonumber(m[2]) + tonumber(m[3])))
 6  end)
 7
 8  bot:serve(function(msg)
 9    if msg.type == "say" then
10      bot:say(msg.channel, msg.message)
11      respond(msg, true)
12    end
13  end)
14end

こんな感じのよくあるAPIです。特徴的なのがworkerの仕組みで

 1function main()
 2  bot:respond([[deploy]], function(m, e)
 3    bot:say(e.target, "accepted")
 4    goworker({target=e.target, type="deploy"})
 5  end)
 6
 7  bot:serve(function(msg)
 8    if msg.type == "say" then
 9      bot:say(msg.target, msg.message)
10    end
11  end)
12end
13
14function worker(msg)
15  if msg.type == "deploy" then
16    do_deploy()
17    notifymain({type="say", target=msg.target, message="your deployment has been completed"})
18  end
19end

このように goworker でLuaからGoroutineをつくって重い処理などをWorkerで実行することができます。Workerからは notifymain でメインGroutineにメッセージをおくることができます。

HTTPサーバ機能では以下のような関数を定義するだけで簡単にWEBHOOKが作れます。

 1function http(r)
 2  if r.method == "POST" and r.URL.path == "/webhook" then
 3    local data = assert(json.decode(r:readbody()))
 4    local message = data.item.message.message
 5    local user = data.item.message.from.name
 6    local room = data.item.room.name
 7
 8    local ret = {
 9      message = "hello! from webhook",
10      message_format = "html"
11    }
12
13    return 200, headers, json.encode(ret)
14  end
15  return 400, headers, json.encode({result="not found"})
16end

定期ジョブは以下のような感じ。

 1function main()
 2  golbot.newbot("Null", { 
 3    http = "0.0.0.0:6669" ,
 4    crons = {
 5      { "0 * * * * * ", "job1"}
 6    }
 7  }):serve(function() end)
 8end
 9
10function job1()
11  print "hello!"
12end

チャットボットのためだけにNode.jsとnpmはちょっと・・・という場合にぜひ。