こちらは Goクイズ Advent Calendar 2020 - Qiita の17日目の記事です。
今回はMethod values (メソッド値) の問題です。(前回のGo Language Specification輪読会で見付けたものです)
package main import "fmt" type I interface { M() int } type T struct { a int } func (t T) M() int { return t.a } func main() { var t *T = &T{a: 1} f1 := t.M var i I i = t f2 := i.M t.a = 2 fmt.Println(f1(), f2()) }
f1(), f2() の結果を問う、引っ掛け無しの問題となります。
さて、答えはどれでしょう？
1 11 22 2こちらは Goクイズ Advent Calendar 2020 - Qiita の10日目の記事です。
今回は、皆さん大好きなiotaの問題です。
package main import "fmt" const ( X = 0 A, B, C = iota, iota + 1, iota * 2 D, _, E _, F, _ G = iota + iota ) func main() { fmt.Println(D + E + F + G) }
さて、答えはどれでしょう？
こちらは Goクイズ Advent Calendar 2020 - Qiita の3日目の記事です。
序盤と言うこともあるのでシンプルな一問です。
package main import "fmt" func main() { var x = nil fmt.Println(x) }
結果はどちらでしょう？
<nil>Protocol Buffersのpackageの名前解決ルールを調べました。 このブログはproto3のドキュメントベースで書いています。
protobufでは、messageなどの定義名が衝突することを防ぐことを目的として、名前空間を分離できる package と言う機構が提供されています。
説明を簡略化するために、本家のドキュメントを引用します。
Packages
You can add an optional package specifier to a .proto file to prevent name clashes between protocol message types.
package foo.bar; message Open { ... }
You can then use the package specifier when defining fields of your message type:
message Foo { ... foo.bar.Open open = 1; ... }
From: Language Guide (proto3) | Protocol Buffers | Google Developers
上記のように、importした側のprotoで、 foo.bar.Open と言った形で別packageのmessageを参照することが出来ます。
protobufのPackage名ベースでの名前解決は、初めに innermost scope から検索を開始する形で行われます。例としては、 foo.bar package から X messageの検索を始め、foo.bar package 内に見付からなければ、次は foo package 内に無いか探しに行くといった感じです。
https://developers.google.com/protocol-buffers/docs/proto3#packages_and_name_resolution
続きを読む気になったので調べてみました。
tsconfig.jsonには、コメントが書けます。
tsc --init した時に生成されるtsconfig.jsonに、大量にコメントが付けられているので、すぐに気付くことと思います。
例)
{ "compilerOptions": { "target": "es5" /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', or 'ESNEXT'. */, "module": "commonjs" /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', 'es2020', or 'ESNext'. */, /* Strict Type-Checking Options */ "strict": true /* Enable all strict type-checking options. */, "noImplicitAny": true /* Raise error on expressions and declarations with an implied 'any' type. */ } }
これについて深く考えたことも無く、どこかでこれは JSON5 だと言う噂を見ていた*1のでそうだと思っていました。
ところが、試してみたところJSON5なら使えるはずの豊富な文法が全然使えなかったり、JSONとJSON5にかけていたformatOnSaveの設定が効かなかったので、違うということに気付きました。
tsconfig.jsonにPrettierかからんなーと思ったけど、そもそもtsconfig.jsonはJSONじゃなかった事を思い出した。
— syumai (@__syumai) 2020年3月29日
*1:.babelrcはJSON5らしい https://babeljs.io/docs/en/config-files#supported-file-extensions
Go 1.11でgo buildのtargetに
GOOS=jsGOARCH=wasmを指定できるようになって久しいですが、皆さんこちらお使いでしょうか？
Goが出力するWebAssemblyのファイルサイズが気になり、 これを計測するためのリポジトリ、go-wasm-sizesを作ったので、こちらと合わせて実際の計測結果を紹介します。
やっている事は単純で、
作業を行っているだけです。
package main import _ "fmt" func main() {}
また、比較対象として、何のpackageもimportしていないパターンも用意しました。
_で参照した場合、グローバル変数として定義されている構造体のメソッドとか、initで参照されているものは入るけど、code elimiminationでカットされてたりするはずなので、実際に使うともっと大きくなったりする印象あるけどwasm方式だとどうなんだろうか？ https://t.co/h8NEXLK9H2
— 渋川よしき (@shibu_jp) December 12, 2018
渋川さんからご指摘いただきましたが、今回の計測方法だとdead code eliminationされている可能性がありそうなので、こちらも考慮した上で別途検証したいです。
よく使いそうなpackageを適当に選んで紹介します。 計測対象にしている全packageのリストは、上記リポジトリのREADME.mdに記載があります。
※net/httpなどの子packageは、作業の簡略化のために / ではなく _ で連結した名前を設定しています。
1.30MB blank/blank.wasm # This package only contains func main(). 1.30MB math/math.wasm 1.30MB strconv/strconv.wasm 1.31MB io/io.wasm 1.34MB syscall_js/syscall_js.wasm 1.43MB time/time.wasm 1.44MB unicode/unicode.wasm 1.45MB strings/strings.wasm 1.45MB bytes/bytes.wasm 1.45MB path/path.wasm 1.46MB bufio/bufio.wasm 1.50MB os/os.wasm 1.98MB reflect/reflect.wasm 1.98MB sort/sort.wasm 2.00MB regexp/regexp.wasm 2.15MB fmt/fmt.wasm 2.16MB net_url/net_url.wasm 2.16MB context/context.wasm 2.37MB net/net.wasm 7.22MB net_http/net_http.wasm 11.32MB net_http_pprof/net_http_pprof.wasm
builtin の println() が JSコンソールに表示を行うので、Goで実行した内容をコンソールに出したいだけであればそちらを使うのがよさそう。一番大きかったpackageは net/http/pprof で、なんと 11.32MB になりました。
生のままだとファイルサイズが大きすぎるため、実際にGoのwasmを使用する場合は、ブラウザがサポートする形式で圧縮して送信するのが現実的な方法となりそうです。
今回は、Gzip, Brotliの2つで、圧縮結果のサイズを比較してみました。
287KB blank/blank.wasm.gz # This package only contains func main(). 287KB math/math.wasm.gz 287KB strconv/strconv.wasm.gz 290KB io/io.wasm.gz 295KB syscall_js/syscall_js.wasm.gz 307KB time/time.wasm.gz 322KB unicode/unicode.wasm.gz 323KB os/os.wasm.gz 324KB strings/strings.wasm.gz 324KB bytes/bytes.wasm.gz 324KB path/path.wasm.gz 325KB bufio/bufio.wasm.gz 414KB reflect/reflect.wasm.gz 414KB sort/sort.wasm.gz 418KB regexp/regexp.wasm.gz 444KB fmt/fmt.wasm.gz 445KB net_url/net_url.wasm.gz 446KB context/context.wasm.gz 497KB net/net.wasm.gz 1617KB net_http/net_http.wasm.gz 2455KB net_http_pprof/net_http_pprof.wasm.gz
222KB blank/blank.wasm.br # This package only contains func main(). 222KB math/math.wasm.br 223KB strconv/strconv.wasm.br 224KB io/io.wasm.br 228KB syscall_js/syscall_js.wasm.br 237KB time/time.wasm.br 247KB unicode/unicode.wasm.br 249KB os/os.wasm.br 249KB strings/strings.wasm.br 249KB bytes/bytes.wasm.br 249KB path/path.wasm.br 250KB bufio/bufio.wasm.br 312KB reflect/reflect.wasm.br 313KB sort/sort.wasm.br 316KB regexp/regexp.wasm.br 336KB fmt/fmt.wasm.br 336KB net_url/net_url.wasm.br 336KB context/context.wasm.br 375KB net/net.wasm.br 1768KB net_http_pprof/net_http_pprof.wasm.br
最小のblank.wasm, 最大のnet_http_pprof.wasmでそれぞれ比較すると、
となっており、どちらの圧縮法を使っても20%程度にはなるようです。 これだけファイルサイズが変わるのであれば、体感のロード時間は大きく変わるので、やはりGoのwasmの配信は圧縮した上で行うのが基本的な方針になりそうです。
Go + wasmで実際に何か作られる際にぜひ参考にしてください！
久しぶりの更新です。
先週末と今週末の二日を使って、Vuexの勉強がてらTrelloもどきを作ってみました。 これまでちまちまVue.jsは使ってきましたが、SPAを作ったのは初めてです（小さいですが）
デモの方はlocalStorageにデータを溜めるようになっているので、リロードしてもちゃんと前回の結果が残ってます。
Vuexは、ざっくり言うと、Vueのために作られたFluxに相当するライブラリ(詳細はこちら)です。Fluxもそのまま使えると思いますが、VuexはVueに特化したヘルパーメソッド等がふんだんに含まれているライブラリとなっています。
FluxとReduxの公式ドキュメントが英語のみ(確か)だったのに対し、Vuexの公式ドキュメントは全編日本語化されているため、めっちゃ読みやすいです。 いや、頑張って英語読めよ、と言う話ではあると思いますが、読むスピードと理解度のことを考えるとやはり母語で読めるのはありがたい…。
生のJSじゃなくて、*.vueからトランスパイルするようにすると、各コンポーネントに対してスコープを制限したCSS(webpack使えばSCSSとかもいける)を付けられます。
サンプル: trollo/App.vue at master · syumai/trollo · GitHub
コンポーネントの定義とCSS定義が単一ファイルにまとまるので、整理整頓が徹底され、今回のような複数コンポーネントを組み合わせて作るSPAには向いていると感じました。(PolymerとかRiot.jsとかも同じだと思いますが…。)
forEachとか三項演算子とか使う機会が減った気がするv-forとかv-ifのおかげで、React.Componentのrender()でforEachとかmapとか三項演算子で頑張ってたコードがHTML側に閉じ込められるので、JSとHTMLが混在しにくくなっている感じがしました。
ドラッグでカードの移動とかもやってみたいので、来週あたりやれればと思います。
