焼売飯店

GoとかTS、JSとかRubyとか

Go Quiz Advent Calendar【17日目】 - メソッド値は難しかった編

こちらは 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. 1 1
  2. 1 2
  3. 2 2
続きを読む

Go Quiz Advent Calendar【10日目】 - iotaのカラクリ編

こちらは 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)
}

さて、答えはどれでしょう?

  1. compile error
  2. 12
  3. 18
  4. 24
続きを読む

Protocol Buffersのpackageの名前解決ルールを調べた

Protocol Buffersのpackageの名前解決ルールを調べました。 このブログはproto3のドキュメントベースで書いています。

developers.google.com

protobufのpackageについて

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の名前解決ルールについて

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はJSONじゃないと言う話

気になったので調べてみました。

tsconfig.jsonと普通のJSONの大きな違い

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の設定が効かなかったので、違うということに気付きました。

続きを読む

Goの標準パッケージのwasmサイズを計測した

Go 1.11でgo buildのtargetに

  • GOOS=js
  • GOARCH=wasm

を指定できるようになって久しいですが、皆さんこちらお使いでしょうか?

Goが出力するWebAssemblyのファイルサイズが気になり、 これを計測するためのリポジトリgo-wasm-sizesを作ったので、こちらと合わせて実際の計測結果を紹介します。

github.com

wasmのサイズ計測

やっている事は単純で、

  • Goの標準パッケージのリストを書き出す
  • それらをimportだけして使用しないコードを生成する
  • 全てwasmにビルドする

作業を行っているだけです。

コード例

package main

import _ "fmt"

func main() {}

また、比較対象として、何のpackageもimportしていないパターンも用意しました。

計測方法について追記 (2018/12/12)

渋川さんからご指摘いただきましたが、今回の計測方法だと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

わかったこと

  • 何もimportしなくてもwasmのサイズは1.3MBになり、一般的なJSファイルと比べるとかなり大きい。
  • fmtをimportするとサイズが +800KB となり意外と大きく(恐らく内部でreflectを使っているため)、手軽に使うには向かない。
    • builtinprintln() が JSコンソールに表示を行うので、Goで実行した内容をコンソールに出したいだけであればそちらを使うのがよさそう。
  • strconv, math等はほとんどサイズに影響を及ぼさない。何もimportしない状態で既にビルドに含まれているのかも?

一番大きかったpackageは net/http/pprof で、なんと 11.32MB になりました。

圧縮するとどうなる?

生のままだとファイルサイズが大きすぎるため、実際にGoのwasmを使用する場合は、ブラウザがサポートする形式で圧縮して送信するのが現実的な方法となりそうです。

今回は、Gzip, Brotliの2つで、圧縮結果のサイズを比較してみました。

Gzip

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

Brotli

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でそれぞれ比較すると、

blank.wasm

  • Gzip: 22% (287KB)
  • Brotli: 17% (222KB)

net_http_pprof.wasm

  • Gzip: 22% (2455KB)
  • Brotli: 16% (1768KB)

となっており、どちらの圧縮法を使っても20%程度にはなるようです。 これだけファイルサイズが変わるのであれば、体感のロード時間は大きく変わるので、やはりGoのwasmの配信は圧縮した上で行うのが基本的な方針になりそうです。

Go + wasmで実際に何か作られる際にぜひ参考にしてください!

Vue.js (+ Vuex)でTrelloもどきを作った話

久しぶりの更新です。

先週末と今週末の二日を使って、Vuexの勉強がてらTrelloもどきを作ってみました。 これまでちまちまVue.jsは使ってきましたが、SPAを作ったのは初めてです(小さいですが)

プレビュー

f:id:f_syumai:20170320004732g:plain

デモの方はlocalStorageにデータを溜めるようになっているので、リロードしてもちゃんと前回の結果が残ってます。

実装内容

  • リストの追加、削除
  • カードの追加、削除
  • カードの左右リストへの移動

感想とか

Vuexのドキュメントめっちゃ読みやすい

Vuexは、ざっくり言うと、Vueのために作られたFluxに相当するライブラリ(詳細はこちら)です。Fluxもそのまま使えると思いますが、VuexはVueに特化したヘルパーメソッド等がふんだんに含まれているライブラリとなっています。

FluxとReduxの公式ドキュメントが英語のみ(確か)だったのに対し、Vuexの公式ドキュメントは全編日本語化されているため、めっちゃ読みやすいです。 いや、頑張って英語読めよ、と言う話ではあると思いますが、読むスピードと理解度のことを考えるとやはり母語で読めるのはありがたい…。

スコープCSS便利

生のJSじゃなくて、*.vueからトランスパイルするようにすると、各コンポーネントに対してスコープを制限したCSS(webpack使えばSCSSとかもいける)を付けられます。

サンプル: trollo/App.vue at master · syumai/trollo · GitHub

コンポーネントの定義とCSS定義が単一ファイルにまとまるので、整理整頓が徹底され、今回のような複数コンポーネントを組み合わせて作るSPAには向いていると感じました。(PolymerとかRiot.jsとかも同じだと思いますが…。)

React使ってた時よりforEachとか三項演算子とか使う機会が減った気がする

v-forとかv-ifのおかげで、React.Componentのrender()でforEachとかmapとか三項演算子で頑張ってたコードがHTML側に閉じ込められるので、JSとHTMLが混在しにくくなっている感じがしました。

続き

ドラッグでカードの移動とかもやってみたいので、来週あたりやれればと思います。