Programmer's Pocket Reference はいいぞ…!

本記事は【推し祭り】技術書典で出会った良書 Advent Calendar 2019の1日目として書かれた記事です。

vvakameです。

1日目ということで、熱っぽくやっていきたいと思います。

僕は技術書典7でNanoseconds Hunterさんが頒布したProgrammer’s Pocket Referenceを紹介します!

先に書いておきますが、現時点では上記リンクからBOOTHさん経由で電子版を購入することができます。
よかったですね。

時は技術書典7からおおよそ5日後、社で毎週金曜日に行われている社内勉強会で、僕が購入し、電子データがあった戦利品すべてに短評を述べ、みんなの購買意欲を煽る儀式をやりました。
そこで、あまりに熱のこもった本があったので気持ちになってしまった時のツイートがあるので引用しておきます。

繰り返しますが、この本、今はBOOTHで入手できます!!


さて、改めて本書の内容を紹介していきます。

本書の内容に関しては、私の著作部に当たる部分に関しては、許可を得ることなくコピ ー・再配布を行い、教育や学習などの目的に使用することが出来ますが、出典を記載していただければ幸いです。

とのことなので、連絡しないほうが煩わしくなくてよかろう、ということで連絡なしにいきなりこの記事を書いています。
問題があったらご連絡ください…。

手帳の後ろの方についてくる付録部分が大好きでした。行ったことのない都市の地下鉄の路線図や、郵便料金の一覧表、元素記号表など眺めているだけでも楽しく感じていました。
本書は、プログラマー・エンジニア向けの手帳の付録です。「あれなんだったかな…」というときにすぐ調べれるよう、見開きサイズに情報を凝縮して、内容をまとめています。

あーそれめっちゃわーかーるー!
手帳の小さなページに、情報が詰め込まれて載っているのが面白かった記憶があります。
子供の頃に手帳の付録でワクワクした人、もしくは学校でもらえる副教材を見るのが好きだった人にぜひともおすすめしたい!

さて、本書は1部と2部に分かれています。
1部は様々なプログラミング言語の仕様がまとめられ、2部は様々な知識・仕様・規格がまとめられています。

私が好きなのは2部全般で、まずはASCIIコードの話。ジャブですね。

ASCIIのお話 P.82, 83より引用 オリジナルはもちろん高精細です

ついでUnicode、こんな複雑な決め事やバリアントがあるのかと思うと具合が悪くなってきます。
これをみたら自分でバイト列を文字列として操作するコードを書きたくなくなることうけあいです。
標準ライブラリって偉大だ。
便利なフォントとして、Last ResortとGNU Unifontというのがあるそうです。R-Typeに出てくる機体みたいな名前だ。世の中色々あるなぁ…!

Unicodeのお話 P.86, 87より引用 6P中の2P オリジナルはもちろん高精細です

この調子で、POSIX標準や正規表現についてなど、エンジニアならまれに参照したくなる情報がドンドン続きます。大量です。

軽く書いただけでもiPhoneの見分け方、PDFファイルの規格、HDMI規格の説明!
USB Type-C!文字化け!三角関数!
誰がそこまでやれといった!!

文字化けの説明に次のような説明がありました。

下駄(〓; U+3013)は、活版印刷で該当する字がない場合、とりあえず活字を裏返し に入れて印刷していた際に紙面に現れていた記号に由来する。

アレはなんかなんとなくバイト列の具合でそういうのが出てると思ってたけどちゃんと理由があったのか!?
知らねぇ〜〜〜知らねぇ〜〜〜〜〜俺は知らなかった…!

文字化けの解説の次がx86ですよ。
緩急ありすぎる…。
だがそれがいい……!!

そしてPOSIXの成り立ちや160個のユーティリティコマンド”すべて”の解説がされていたり、
Ethernetの物理層の説明がされていて、100BASE-Tがどういう意味なのか解説されていたり、
WPA3が2018年に策定されていたことが知れたり、
USB-Cのピンヘッダの図説が載っていたり、
USB4が最近制定されていたことが知れたり、
HDMIには6種類のケーブルがあることが知れたり、
抵抗器のカラーコードを見て懐かしい気持ちになったり、
浮動小数点の解説が読めたり(大学で習ったなぁ)、
盛りだくさんで眺めていて大変おもしろいのです。

組版も凝っていて、PDFを見るとちゃんと断ち切りまで塗り足しがあり、さらにリンクはちゃんとハイパーリンクになっています。
やりおる… 手間が… 手間がかかってるよぉ…。

そして本書は全編フルカラーという力の入りよう!
これは読むしかない…!
この本を読んで 知らなかった! が1個もないエンジニアはおそらくいないでしょう。
駆け出しエンジニアの人でも楽しく読めると思います。
いい本だ!

技術書典7で頒布された紙版は本文はスミ1色だったそうですが、それもしかたのないこと…。なんとこの本、全204ページなのです。
日光企画さんでALLフルカラーの価格を調べるとなんと300冊スタート、かつページ数148Pまでしか掲載されておりません(問い合わせ確認まではしてない)。52ページと100ページ、100ページと148ページの価格差がともに17.6万円ほどなので安く見積もっても204Pの印刷はおよそ300冊73万円強となり余裕の原価2500円弱という雑な見積もりです。
それは印刷できんわガッハッハw

というわけで、皆様ぜひこの本を買って眺めて、ついでに職場などで人にチラ見せして布教していきましょう!

購入は!>>>ここ<<<から!!

よろしければ、この本を読んで思ったこと・間違っているところ・追加してほしいこと、なんでも良いので巻末のアンケートフォームよりぜひご意見いただければと思います。

とのことなので、本書を読んだ結果、手帳の付録力の高いネタをタレこんでいきましょう!(僕はしました)

ゆかりさん(猫)の2年目

我が家にゆかりさんが来てからちょうど2年が立ちました。
ざっくり5歳ですね。

Twitterでは ふわふわちゃん とツイートしてますが、実はゆかりさんです。
最近は ふわふわちゃん おふわちゃん ゆかちゃん ゆかゆかちゃん ねこちゃん まうちゃん かわゆちゃん など適当な名前で呼んでいます。

去年と比較して、可愛さが30%ほどアップした気がします。
毎日のんびりと過ごし、かいぬしにもふられるがままになっています。

ゆかりかわいいフォト

様子

最近はベッドで寝ていると胸板の上におすわりするようになりました。
おいでー!といって床とか太ももとかを叩くとそこに来てほしいことがわかっているらしく、気が向くと来てくれます。
去年の時点でかなり仲良くなったな!と思っていましたが、まる2年が経ち、さらに仲良くなった気がします。
レベル100が上限だと思っていて、今レベル80くらいだなと思ってたらレベル120になってしまい、えっこれ上限どこ!?って感じです。
野生の警戒心は完全に消失し、気軽に僕の近くをちょろちょろするのでそのうち踏んづけたり潰したりしないか心配です…。

コミュニケーションは慣れて理解できるようになったものと、未だにまったくわからないものがあります。
かいぬしが晩ごはんを食べ始めると、なぜかベッドから呼びつけて今すぐ撫でろ!と主張します。
ご飯食ったらあかんか!?あとじゃダメか!?ダメらしいです…。

お通じがあまり良くないのは今年も変わらずでした。
ある程度食生活にパターンができたので多少マシになった気はします…。
うーん、もうちょっとぷりが緩くなるといいのかもしれないけど…?

お尻を拭かれるのは多少慣れたようで、前よりは嫌がらなくなりました。
前よりは… なので未だにめっちゃ嫌がってますが…。
なるべく健康で長生きしてほしいものです。

性格は相変わらず、物怖じせず優しくぼちぼち愛想もよい… というすごく良い子です。
あとの希望は、毎日スッパリとぷりとおしっこをして、たまにスリスリしてほしい…くらいのものです。
何故かスリスリはしてくれないんですよね。まいいか。

猫ヒーターを導入してからというもの、僕が起きている間はPCの横にいるので気が向いた時に撫で撫でしほうだいです。
寝る時はかいぬしの寝相がクソ悪いので、かいぬしが寝付くまではそばにいて、その後は高いところで寝ているようです。

Google Photosの ゆかりさん厳選 アルバムも1784枚になりました。
去年が1101枚なので、それなりに落ち着いたペースになってきました。
アルバムを見ると、大抵僕の上に乗ってくつろいでいる写真なので、バリエーションがほぼない…!
もうちょっと遊んであげたほうがいいと思うんだけど、やる気があるんだかないんだかよくわからない対応をされます。外部からやる気がもうちょっと観測可能にならんか?ならんか…。

猫グッズ

猫ヒーターですね。
暖かくて気持ちいいらしくて、滞在時間がかなり長いです。
PCの横に置いてあります。
一度、ゆかりさんがリモコンの上を歩いていき電源を切ったことがあります。
暖かくない💢と抗議されましたが、僕は悪くないと思います。

窓に貼り付けるハンモックみたいなやつです。
乗せておくと乗ってますが、自分からは乗りません。
というわけで利用率が激烈に低い…。
猫が出窓でくつろぎ、お日様に目を細めている情景にあこがれる…。
南向きの出窓がある家がほしい…。

動物病院に行ったときにお医者さんが使ってたっぽいのを買いました。
あまりウケがよくなかった…。
でかいので怖いらしいです。
爪切りは未だにすごい嫌がるので大変です。
猫の爪をいい感じに にゅっ! って不興をかわずに出す方法をどこかで教わりたい…。
今は爪を出そうとぷにぷにすると、ふんぬっ!!スポン!!!って足を引っこ抜かれます。

会社の人に勧められて買ったやつ。
前から使ってるやつと併用しているんですが、最近はこっちをよく使っています。
前から使ってるやつのほうが掃除がしやすくて匂いも全然しないのでかいぬし的にはそっちがよかったんだけどなー。
砂の粒子が細かいのがいいんですかね?

猫を飼いたい人へ

猫はいいぞ…!
一度飼い始めたらもう後戻りはできないけど、毎日は幸せになります。
こんなかわいい生き物が毎日家にいるのはこの世の奇跡。

最後に、Amazonの干し芋を晒しておきます。
猫用
人用

Goの net/http のClientにHAR形式でログ取れるTransportを作ってみた

Source: Goの net/http のClientにHAR形式でログ取れるTransportを作ってみた

vvakame vvakame -2019-10-03 16:52:41

sinmetalと話をして、GCSとかCloud Pub/Subは裏がREST APIなので、Transportで頑張ればプロダクションコードに手を加えずにモック実装にできるのでは?という会話があった。
そっちはそっちでやるといいと思うんだけど、裏側で行われている通信内容をとりあえずチェックしたくない?という気持ちになったのでやってみることにした。

HTTPリクエストの可視化というとまぁ HARファイルじゃない?ということで net/http のClientのTransport(RoundTripper)にログ取りの処理を突っ込んでみるべ、という発想で作られたのがこのライブラリ。

https://github.com/vvakame/go-harlog


2019-10-03 16:53:03

とりあえず適当にGCSにアクセスしてHARファイルを作ってみる。
こんな感じの使い方です。
Transportを https://github.com/vvakame/go-harlog 製のものに置き換えて後は普通に実行する。
処理が終わったらJSONにしてどこかに出力しておく。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
ctx := context.Background()

hc, err := google.DefaultClient(ctx, storage.ScopeReadWrite)
if err != nil {
panic(err)
}

// inject HAR logger!
har := &harlog.Transport{
Transport: hc.Transport,
}
hc.Transport = har

client, err := storage.NewClient(
ctx,
option.WithHTTPClient(hc),
)
if err != nil {
panic(err)
}

bucket := client.Bucket(*bucket)

{
object := bucket.Object("2019-10-01-harlog/hello.txt")
r, err := object.NewReader(ctx)
if err != nil {
panic(err)
}
b, err := ioutil.ReadAll(r)
if err != nil {
panic(err)
}
fmt.Println(string(b))
}
{
object := bucket.Object("2019-10-01-harlog/goodnight.txt")
w := object.NewWriter(ctx)
_, err = w.Write([]byte("Good night, world!"))
if err != nil {
panic(err)
}
err = w.Close()
if err != nil {
panic(err)
}
}

// dump HAR file!
b, err := json.MarshalIndent(har.HAR(), "", " ")
if err != nil {
panic(err)
}
err = ioutil.WriteFile("gcs.har", b, 0644)
if err != nil {
panic(err)
}

HARファイルのインポート

ChromeのDevToolsとかで見れる。
連続して同じファイルをimportしようとすると黙って無視したりされて若干不親切なので、こっち使ったほうがいいかもしれない。


2019-10-03 16:53:06

GCSからファイルを読み出す処理のログの様子。
ヘッダ類、レスポンス、各種タイミングが記録されているのがわかる。

Headers

Response

Timing


2019-10-03 16:53:14

gRPCでも同様のことができるといいなーと思うけど、streamとかあるしHAR形式では難しいかな…。
REST APIとかでは便利だけどgRPCとかでは無力…!

『GraphQLスキーマ設計ガイド』を技術書典7で頒布します

書影

現時点で55RTs 140Likesいただいております。ありがとうございます。

技術書典でのサークル詳細ページからチェックができるんですが、これも今のところ218人からチェックをいただいていて、過去最多タイなので過去最多記録更新は確実です。
ありがとうございます。

今回レビューをお願いした方々がいい感じの書評をツイートしてくれたので貼っておきます。
うふふ。

とのことでした。ドヤ!

技術書典7 9/22 あ20C 池袋文化会館 3F 展示ホールCです!
現金 or かんたん後払いで500円で電子書籍のみの頒布です。
公式のダウンロード機能(β)にももちろん対応しています。

イベント終了後boothでも販売します。
また、気が向いた時にGitHubにて全文を公開する予定です。

目次

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
    10KB   4706C   167L  前書き (preface)
17L 1 本書概要
7L 2 謝辞
58L 3 予備知識1:GraphQLの概要
44L 4 予備知識2:どうやってGraphQLサーバは動作するのか
1. 18KB 8637C 319L GitHub v4 APIに倣え! (github)
17L 1 Relay向けサーバ仕様への準拠
37L 2 ID設計論
53L 3 命名規則について
101L 4 interfaceとunion typesとURL設計
85L 5 セキュリティのためのrate limitとcomplexity
10L 6 Schema Changes
2. 24KB 12837C 564L Relay 各仕様解説 (relay)
124L 1 Global Object Identification
236L 2 Cursor Connections
78L 3 Input Object Mutations
108L 4 Mutations updater
3. 13KB 5609C 202L データベースとの親和性 (database)
59L 1 DBのスキーマとGraphQLのスキーマの相似について
54L 2 N+1問題への対応
33L 3 ページネーションの実装について
47L 4 分散DBはいいぞ…!
4. 16KB 8329C 282L graphql-schema-linter のルールの作り方 (linter)
50L 1 チェック対象のスキーマをどう得るか
22L 2 デフォルトで用意されているルール
101L 3 どうやって動作しているか
90L 4 広げようカスタムルールの輪
5. 21KB 9592C 379L スキーマ設計の実践と考察 (tips)
30L 1 画面の都合とGraphQL
19L 2 架空のフィールドをひねり出す
129L 3 スキーマ定義を複数ファイルに分割する
46L 4 エラーハンドリングのパターン
36L 5 エラーを返していいとき悪いとき
22L 6 フィールドに他の型のIDをもつか?
18L 7 虚空から型をひねり出さない
42L 8 ドメイン層とGraphQL resolverのレイヤを分けて考える
34L 9 directiveの利用とドメイン層でのチェック
1. 30KB 11758C 424L リアルワールドスキーマ(ただの日記) (tbf-ticket)

metagoを作った話

Source: metagoを作った話

Files changes: 1

  • go/metago/README.md (+113, -0)

vvakame vvakame -2019-08-23 16:44:55

リポジトリ

metagoはGo言語向けのメタプログラミングライブラリです。
考え方のベースとしてwireのシグニチャを定義し実装は機械的に生成する考え方と、VのReflection via codegenのホスト言語の構文でメタ構造を書く、というのを使っています。

本ライブラリはある程度動きますが、現時点ではトップレベルの定義を生成したり動的な名前のメソッドを生成したりすることはできません。
テストケースも圧倒的に不足しているため実用レベルに達しているかといわれると疑問があります。
でも面白いよ!

モチベーション

Goは言語自体の持つ型の表現力が弱く、ボイラープレートなコードをたくさん書くことになりがちです。
そこで、何らかのデータを元にGoのコードを自動生成しよう!というアイディアに至るのに時間はかかりません。

一番最初に思いつくであろう、GoのコードをASTで組み立てる戦略は破滅的にめんどくさいです。
これは、生成したいと思っているGoのコードとASTを組み立てるコードにまったくもって相似ではないからです。

次のアイディアとして、Goのコードをテキストとして組み立てるものがあります。
jwgでは Printf を使ってソースコードを生成しています。
gqlgenでは text/template を使ってソースコードを生成しています。
これは、ASTを使って組み立てるのに比べるとだいぶ仕上がりが想像しやすいです。
一方でIDEからの支援が得にくく、出力後のコードがvalidなコードかというのは出力してみるまでわかりません。

新しいアプローチとして、本ライブラリ metago を考え、実装しました。
metagoでは生成するべきGoのコードをGoのコードで書きます。
鋳型になるGoコードのASTをこねこねして、ほしいGoコードに変換するイメージです。
これならば、IDEの支援を今までに比べると圧倒的に楽に実装することができます。

metago について

metagoでは、実際のソースコード中にマーカーを仕込んでいき最終的なソースコードを生成します。

あるオブジェクトのフィールド名と値を出力するテンプレートは次のようになります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
//+build metago

package main

import (
"fmt"

"github.com/vvakame/metago"
)

type Foo struct {
ID int64
Name string
}

func main() {
obj := &Foo{1, "vvakame"}
mv := metago.ValueOf(obj)
for _, mf := range mv.Fields() {
fmt.Println(mf.Name(), mf.Value())
}
}

これをmetagoで処理すると次のコードが得られます。
実際にプログラムとして動作させるのはこちらの生成されたコードです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// Code generated by metago. DO NOT EDIT.

//+build !metago

package main

import (
"fmt"
)

type Foo struct {
ID int64
Name string
}

func main() {
obj := &Foo{1, "vvakame"}

{
fmt.Println("ID", obj.ID)
}
{
fmt.Println("Name", obj.Name)
}
}

reflectパッケージに少し似ています。
どういったことができるかというのはtestbedディレクトリを見てみてください。

主なfeatureとして…

  • mv := metago.ValueOf(obj) によって metago.Value な値を取得
  • for _, mf := range mv.Fields() によって各フィールドに対する処理を展開・記述
  • mf.Name() によってフィールド名の取得
  • mf.Value() によってフィールドの値の取得
  • mf.StructTagGet("json") などでstructのタグの取得
  • mf.Value().(time.Time) といった型アサートとif文の組み合わせによるフィールドの型毎の処理の振り分け
    • type switchもサポート
  • インラインテンプレート(第一引数が mv metago.Value の関数)の利用

などに対応しています。

metago のインストールと実行

1
2
$ go get -u github.com/vvakame/metago/cmd/metago
$ metago -v .

今日試したことを爆速でブログ化するツールのご紹介

Source: 今日試したことを爆速でブログ化するツールのご紹介

vvakame vvakame -2019-06-03 03:25:20

TL;DL

  • pull request をブログ記事に変換するツール作った
  • GitHub Actionsで動くようにした
  • このブログ記事もこのツールで書かれました

Motivation

ブログを書いたほうがいいのはわかっている。
しかし、ブログを書くのは面倒くさい…。
一回やってわかってしまったことをわざわざまとめ直す必要、ある?

もちろん、書く意義はわかっている。
調べただけでまとめなかったら検索に引っかかってこないし、そうすると知見が共有されないし、シェアもされにくい。
一方、自分がわかってしまったら、それでもういいのではないか?と考えてしまうのも事実としてある。

僕が調べたり試したりしたことはだいたい https://github.com/vvakame/til に置かれている。
3日でだいたいのことを忘れる脳みそなので、Q毎(3ヶ月!)の振り返りができるよう、週報を書いている。
GitHubのアクティビティをリスト化するツールを作ってやったことをリスト化しているため、調査したことについてもmaster直pushをやめてpull requestを経由するようになった。

つまり、試行錯誤の過程をちゃんとpull requestにメモしておけば、それを元に調査記事が1本書けるのでは??

How does it works?

pull requestがmergeされたら、そこに書かれている内容をmarkdown化してブログ記事化する。
Twitterに意見をバーーっと書いて、ツイートのembed機能で記事に貼り付けてブログ記事をでっちあげるのと発想としては同じだ。

僕の今のブログhttps://github.com/vvakame/vvakame-blog で管理されていて、 https://hexo.io/ + https://www.netlify.com/ が使われている。
なので、新しい記事を作りたかったらhexoの作法に従ってmarkdownや画像を配置し、それをpull requestにして、僕がチェックして、mergeするだけでよい。はず。


2019-06-03 04:37:15

Implementations

https://github.com/vvakame/github-actions にActionを置いてあります。
pull request を markdown に変換するやつと、markdownをpull requestに変換するやつです。

これを活用し、 .github/main.workflow に次のような内容のファイルを置くと動きます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
workflow "make blog post" {
resolves = [
"blog to slack",
]
on = "pull_request"
}

action "filter PR merged" {
uses = "actions/bin/filter@master"
args = "merged true"
}

action "pr2md" {
uses = "vvakame/github-actions/pr-to-md@master"
args = ["--timezone", "Asia/Tokyo"]
secrets = ["GITHUB_TOKEN"]
needs = ["filter PR merged"]
}

action "md2blog" {
uses = "vvakame/github-actions/md-to-blogpost@master"
args = ["--owner", "vvakame", "--name", "vvakame-blog", "--timezone", "Asia/Tokyo", "result.md"]
secrets = ["BLOG_REPO_GITHUB_TOKEN"]
needs = ["pr2md"]
}

action "blog to slack" {
uses = "Ilshidur/action-slack@master"
args = "PR merged!: {{ EVENT_PAYLOAD.pull_request.html_url }}"
secrets = ["SLACK_WEBHOOK"]
needs = ["md2blog"]
}

実用上、 @master の部分はちゃんとコミットハッシュに置き換えたほうがよい気がしますね。

これを実際に動かすと、pull requestが作成され、mergeしたpull requestのURLがSlackに通知されます。
新たに作成されたpull requestのURLを出すのはめんどくさそうだったので妥協しました。
動作させた時の様子を貼っておきます(デバッグのため余計な工程が入っているけど…

実際にGitHub Actionsが動作した時の様子

Slackに通知が来た様子


2019-06-03 07:05:51

Real world example

このPRをmergeしたらブログのPRが https://github.com/vvakame/vvakame-blog/pull/8 に自動で作られる…はず!
そしてそれをmergeすると https://blog.vvaka.me/2019/06/03/pr-to-blog/ にブログ記事があがる… はず!


2019-06-03 07:12:30

Details

細かい仕様とかを少し書きます。

大部分はGitHub Actionsに流れてくるイベントデータのJSONからデフォルト値を取得するので、設定をする必要はほぼありません。
自分でテンプレートをカスタマイズしたい場合とかは適当に args を書き足してやれば変更できます。
各アクションのREADME.mdを参照してください。

ブログをPR化する方のアクションについて、ブログのリポジトリは通常別リポジトリのハズなので、デフォルトの GITHUB_TOKEN では権限が足りません。
自分で適当な権限のあるPersonal Access Tokenを生成して BLOG_REPO_GITHUB_TOKEN にセットする必要があります。

ブログのURL中の /2019/06/03/pr-to-blog/pr-to-blog 部分はデフォルトではブランチ名を使うようになっているので、よさそうなブランチ名をつけるようにしましょう。

文中の画像について、基本的には自分で貼り付けたものだろうと考え、自動的にダウンロードして適当にpull request中に混ぜ込みます。
markdown中の ![alt](url) が対象です。
今のところ <img> タグについては書き換えを行いません。

hexo以外のブログに対応させたい!とかがあったら適当に僕に聞いてください。


2019-06-03 07:14:35

Misc

他の人と議論が発生した場合など、自分以外の人の発言も普通にブログ記事中に入ってきます。
掲載許可を取るなり、descriptionに断り書きを書くなり、工夫したほうがいいかもしれません。

以下、最近食べた美味しかったものスレとします。
(コメントを書いた人は自動的にブログ記事化されます。)


knsh14 knsh14 -2019-06-03 07:17:34

サッポロ一番


vvakame vvakame -2019-06-03 07:20:51

鶏そば十番156 麻布十番本店
https://tabelog.com/tokyo/A1307/A130702/13168206/
今日のお昼ご飯ここだったけど割と他では出会わないタイプの味で美味しかった。


tjun tjun -2019-06-03 07:24:19

錫記雲吞麵のワンタン麺


panpanini panpanini -2019-06-03 07:24:50

https://yohobrewing.com/bokukimi-manten/ これ美味しかった


mhidaka mhidaka -2019-06-03 07:36:00

銀だこには24個入りというパーティパックがある
https://www.gindaco.com/menu/003
疲れたときにみんなで食べると美味しい。一人で食べるのはおすすめしない

技術書典6で"Apolloドハマリ事件簿"出ます

来る技術書典6で さ06 ひかる黄金わかめ帝国から”Apolloドハマリ事件簿”を出します!

前回は”GraphQLサーバをGo言語で作る”という本を出しました。

サーバ側は前回やったので、今度はクライアント側だ!とReact+Apollo+TypeScriptでコードを書き始めたらドハマリしたのが今回です。
目次は現時点では次のような感じになっています。

  • はじめに
  • クライアント側でApolloやっていき
    • 型があるって素晴らしい
    • Apolloという魔法
  • Apollo/GraphQLの素晴らしきユーティリティたち
    • graphqlパッケージ
    • graphql-toolsパッケージ
  • キャッシュでドハマリ
    • ローカル状態管理とキャッシュ
    • cache.writeData, Fragment, Query
    • ドハマリ回避のために
    • その他のキャッシュ関連プラクティス
  • Apollo Linkで魔術する
    • Apollo Linkの概要
    • Apollo Linkでサーバ側実装なしにコードを組む
    • Subscriptionを何かしらのPushとQueryに変換する
  • 小ネタ集
    • QueryとfetchMoreの謎
    • 日本におけるGraphQLコミュニティ(の不在)
    • react-apolloでApolloConsumerを使う
    • FragmentがFragmentを使う場合にいい感じに@clientが消してくれない
    • Apolloがコードにドキュメントを書かない
    • エラーハンドリングどうするの問題
    • 雑に大きなデータをstateに突っ込んだら辛かった
  • あとがき

世間様にあまり情報の出ていないエッジケースを突いた気はしますので、Apolloを現在使っている人、これから使おうと思っている人にぜひ読んでみていただきたいです。

本猫による検品の様子

価格は500円。支払い方法は現金 or かんたん後払いの予定です。

媒体は電子版DLカード…のみ!かも!(製法:名刺shop.comで表に書影、裏にGoogle DriveのURLのQRコード印刷しただけ)

紙の本はないです。見本誌は2部あります(製法:製本直送.comで刷った)

全文は後日公開予定ですが、それがいつかは明確には決めていません。
たぶん前回同様booth.pmでの後日販売なども行うと思います。

僕は運営の一味なので当日ブースには終日いない予定ですが、みなさん遊びに来てください。

最後に、みんなひかる黄金わかめ帝国にチェックをつけていってな!
それでは当日無事に生き抜きましょう!

猫の足ピンRTA

@ngsw_taroくん発の猫アドベントカレンダー2日目です。

最初は 買ってよかったものといらなかったもの というタイトルで書こうと思ったんですが、ゆかりさん1周年で買ってよかったものについて書いてしまったので別の話題にします。
この何も考えてない感じ…最高やな!!

最近は猫の足を撫でるとなんかピンとしてくるのが最近楽しいです。
そこで、今日は猫の足をピーンと伸ばすRTA(Real Time Attack)を紹介したいと思います。

レギュレーションはとりあえず次の通りとしています。

  • 猫の足を撫でてピンと伸ばす
  • 猫の足を手で無理やり動かすのは禁止
  • ピンと伸びてからしばらく静止する
  • 道具は使用禁止(TASではないので)
  • 猫に咎められても泣かない

昨日思いついて記録をとってみたら11秒という記録が出ました。

今日も挑戦してみたら16秒かかったので、上記動画はロスが多いムーヴに見えますが結構スムーズにクリアできていると言えそうです。
多分理論値は3秒くらいだと思います。

最近やりこんでいっている時の知見をまとめます。

  • リラックスしていて、かつ目を閉じてない時にやる
    • めちゃめちゃ眠い状態の時にやると反応が悪い
      • くすぐったいので足が上がるわけではないみたい?
    • 寝るのを邪魔すると怒られる
  • 人間で言うアキレス腱のあたりを撫でる
    • 足の裏を撫でてもあまり伸びません
  • のびーーっと伸びている時にやる
    • 丸まってる状態スタートだと撫でる位置を探すのに手間取りやすい
    • クリア判定もわかりにくく達成感を得られづらい

良いタイムが出たらTwitterに#猫の足ピンRTAで投稿してみてください。
それでは良い猫ライフを!

ゆかりさん(猫)の1年目

去年ブログを書いたのですが、我が家にゆかりさんが来てからちょうど1年が立ちました。
ざっくり4歳ですね。

Twitterでは ふわふわちゃん とツイートしてますが、本当はゆかりさんです。
今後もTwitterでは真の名は伏せていく方向です(理由はない)。

毎日毎日可愛さは加速するばかりで、最近は大変わがままで心優しいお嬢さんに育っております。

ゆかりかわいいフォト

様子

だいたい何をしても怒らなくなりました。
むぎゅ!っとしても足をつまんでもお口ぴろーんしても目やにを拭ってもおとなしくしててくれます。
この大きな生き物は自分に危害を加えないように注意して生活している、と理解してもらえたようです。
ゆかりさんは他の一般的な猫と違って、耳たぶを触られるのが嫌ではないようなので手触りを楽しむ毎日です。
あと首のマフマフをさわさわすんすんすると幸せになれます。
お尻が汚れたときに拭くのと歯磨きはトライしようとしてもすぐ嫌がって逃げるので修行が必要です。

お通じがあまり良くないのはうちに来てからあまり変わらずで、だいたい2日に1回くらいでぷりりしてます。
おしっこいく回数も普通の猫よりは少ない気がする…。
なるべく健康で長生きしてほしいものです。

性格は物怖じせず多少のことは気にしないけど優しい…みたいな感じですごく良い子です。
猫飼うって…イージーやな!!と思っていますが他所の子の話を聞くと単にゆかりさんがいい子なだけみたいです。
動物病院に連れて行って、とっても嫌なことされるので大暴れした時も爪は出さずにしがみついてきたので先生がびっくりしてました。
いい子〜〜〜〜〜〜!

写真などを見返すと、映像的には来た当初から距離感にあまり変化はない気がしますが、挙動的にはかなりかいぬしのことを好きになってくれた気がします。
ゆかりさんは膝の上とかが今のところ好きではないようで、撫でてほしいときにはベッドからかいぬしのことを呼びつけます。
ゆかりさん的には呼ぶと来て撫でるので、とりあえずいつもにゃんにゃん言ってます。
離れると なんでーー!! と言うのでずっと撫でてると人間がそのまま寝てしまいます。
結果、家での生産性が最近絶滅しています。
原稿ェ…。

生活の変化

猫がいると人間の生活にも変化が出ます。
体調がおかしいと感じたら近所の動物病院につれていったり、泊りがけでどこかにいくのが億劫になったりします。
この1年は優しい友達にペットシッター業とかを頼みつつアメリカに行ったりもしたのですが、回数いく気にならないのはネックですね。
GraphQL Summit行きたかった気もする…。
とはいえ、もう4歳で人間で言えばアラサーなので1泊2日程度であればトイレを増設してご飯もりもりにしておけば大丈夫ではあります。

この1年ではペットホテルを試してみないとなぁ…2泊3日くらいからで…という気持ち。

可愛さ

大変かわいくてすごいです。
今も机でブログ書いてたらにゃんにゃん騒ぐのでベッドの上にPC持っていって書いてます。
左手のすぐ横にぴったりくっついて文字が画面に現る様を眺めています。
かわいい。

この1年はDropboxのカメラフォルダの容量圧迫具合が悩ましいことになってます。
Google Photosの ゆかりさん厳選 アルバムも1101枚になりました。
アルバムを見ると自分は猫の顔が好きであることがよくわかります。
全体像とか猫のいる風景とかじゃなくて顔のアップが多い…わかるねこかわいいもんな…。

猫グッズ

猫向けの出費はまぁいろいろあったんですが、一番単価が高かったのはカメラですね。

RX100M5を買ったりしたのですがPixel 3のカメラが大変良いので今は全然使ってないマンになってしまいました…。
Pixel 3はいいぞ…。

その他、買ってよかったものを紹介しておきます。
ベッド系とおもちゃ系は基本的に消費財であり飽きられたら終わり的なところがあります。
リピ率が高く長く遊んでくれる大ヒットおもちゃがあるのですがAmazonで売ってない…。

我が家ではこのキャットタワーを使って、カーテンのレールボックスの上に乗れるようにしてあります。 わりと良い作戦だった感ある。 上、前、上下分割と3通りの入出が可能なので便利。 普段から隠れ家として部屋に出してあるので、「入って〜入って〜」と言うと入ってくれて楽です。 使いやすい。単価安い。匂いしない。優秀! このメーカー儲かってるのかな…潰れないといいんだけど。 毛がわりと取れます。 いうてゆかりさんは長毛のくせに毛があんまり抜けないんですが…。 見た目的に難しいんですが、これは毛を挟んで取る感じの製品です。 梳きバサミ的なものではありません。 人間の手に刺そうとしても全然痛くないので、人間の皮膚より頑丈な猫の皮膚ならまぁヨユーでしょう。 このブラシでごしごしされると多少喜んでる気がします。 案外毛が取れるので、このブラシの前にファーミネーターはちゃんとやったほうがよさそう。 それでも結構毛がつくのでうまいこと掃除する方法が知りたい…。 ゆかりさんは基本的にバリバリしていいところでしかバリバリしないのでこれを置いています。 だいたい1〜1.5ヶ月で新品に交換する感じで運用しています。 廃棄するために玄関に立てかけておくと、立てかけている方でバリバリしはじめるので本当は縦置きが好きなのかも。 1泊2日する時の臨時増設トイレ。 普段は畳んでしまっておけるので便利。 もうちょっと切れ味のよい高級品に変えてあげたい気もする。 とはいえこれでもわりと十分。

猫を飼いたい人へ

猫はいいぞ…!
ただし生産性には大きなダメージを受けます。
でも可愛いから仕方ない…。
なんでこんなかわいい生き物が毎日家にいるのか本当に謎。

最後に、Amazonの干し芋を晒しておきます。
猫用
人用

vgoを今やり始めると辛いからやめとけ

注意

ここの記事で書かれている操作は、 https://github.com/golang/go/issues/24917 で報告した https://github.com/ory/fosite-example をvgoでビルドしようとして検証しています。

利用したvgo

  • golang.org/x/vgo203abfb0741bf96c7c5e8dab019f6fe9c89bded3 の時点で go get -u golang.org/x/vgo したもの
  • go version go1.10.2 darwin/amd64 vgo:2018-02-20.1

TL;DL

思った通りの状態にならない。
ライブラリ作者全員semverで殴って回る必要がある。
ログから情報が得られない。
実行もクソ遅い。
ゆえに辛い。

まずはじめに

Goユーザは $GOPATH の中で生きている。
アプリケーションのパッケージ管理のため、vendoringの仕組みができた。
パッケージマネージャとしてgbとかdepとか色々なものがあった。

あったけど、最終的にgoコマンドに組み込みとなる、最終的なパッケージ管理の仕組みが生まれようとしている。
vgoだ。
今はvgoという名前だけど、最終的にはgoに組み込まれる(はずだ)。
このproposalは既にacceptedになっていて、未来は確定しつつあります。

この記事ではこれ以上のvgoについての説明を行わない。
詳しく知りたい人は、Go & Versioning[和訳]を読むといいだろう。

vgoのここが良い!

まずは良いところを。

$GOPATH free

プロジェクトを配置する場所が $GOPATH 配下に限定されなくなります。
好きな場所に置いてよい!やったー!

SemVerの採用とタグベースの運用

Goもsemverで運用されていきます。
何かしら更新があれば、gitでtagを打ちpushされる世界になるでしょう。
この文化が浸透すれば、依存しているライブラリのバージョンアップは非常に容易な作業になっていくでしょう。
npmにpublishしているユーザがみんなお行儀よくなっていったように、Goコミュニティもsemverに慣れていくでしょう。

同一ライブラリの異なるバージョンへの依存への(文化的)解決

複数のライブラリを使う場合、依存関係的には孫にあたるライブラリが重複し、かつ異なるバージョンを参照したい場合があります。
これは、今までの単層のvendoringでは難しかったのですが、これに対して github.com/vvakame/hoge/v1github.com/vvakame/hoge/v2 に分けておけばいいじゃない という斜め上の解決が行われました。

斜め上といえば斜め上なんですが、旧バージョンについてもpatchを受け付けられるとか、管理がしやすくなるという点で良いこともあります。

素直に読むと、リポジトリのrootに置いてあるコードは互換性のためにずっと残しておけ、みたいなことを言っててヤベーこと言いよる…という気持ちです。
でもまぁこれは v0 を切って、最初はそこで開発するなどの開発者側のワークアラウンドでなんとかなるレベルかもしれません。

あとは、エディタがpackage内でちぐはぐなバージョンを自動的にimportしないように気をつける必要があります(つらそう

goコマンドに組み込み

単にgit cloneして、 vgo test all とかすれば、依存ライブラリを自動的に取ってきてくれて動きはじめる!
ライブラリ追加したければ vgo get go.mercari.io/datastore とかやるだけ!
すごい!楽!わかりやすい!初心者の味方!

vgoのここがヤバい

ついでやばいところを述べていきます。

中途半端にタグがついているリポジトリ

google.golang.org/appengine はアクティブに開発されているリポジトリだが、2016年に v1.0.0 タグが切られ、その後は何もない
vgo(やdep)で単純に google.golang.org/appengine を追加すると、2年も前のリビジョンを使わされてしまう!
辛いですね。

この問題はライブラリ作者全員がヤル気を出し、ちゃんとタグをつける運用を開始したら解決されます。
ライブラリ作者全員をsemverで叩いて回りましょう。

使えない master/HEAD

上記の問題を解消するには、 vgo get google.golang.org/appengine@master を実行すれば…。
と思いきや、コレでもダメで、 v1.0.0 にされてしまいます。
vgo get google.golang.org/appengine@b1f26356af11148e710935ed1ac8a7f5702c7612 も同様。
go.mod 中の requiregoogle.golang.org/appengine master に書き換えて vgo get -u しても v1.0.0 に戻される…。

どうすればいいんですかね…?
なにがどうなってどう go.mod が書き換わったのか、というのがログから全く読み取れない…。
気持ちよく動いてる間は便利なのかもしれないけど、意図通りにならない時に完全にブラックボックス化していて辛い。
しかもこのブラックボックスは将来的に go 本体に組み込まれてしまい回避不可能になるんだぜ…。

この問題はライブラリ作者全員がヤル気を出し、ちゃんとタグをつける運用を開始したら(masterを使いたいという欲求がなくなるので)解決されます。

いつの間にか巻き戻るバージョン、消えるパッケージ

vgo get google.golang.org/appengine@master すると何故か require に書かれるパッケージが減ります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
diff --git a/go.mod b/go.mod
index 4c08ba1..d2f7a72 100644
--- a/go.mod
+++ b/go.mod
@@ -2,28 +2,24 @@ module github.com/ory/fosite-example

require (
github.com/asaskevich/govalidator v0.0.0-20180319081651-7d2e70ef918f
- github.com/davecgh/go-spew v1.1.0
github.com/dgrijalva/jwt-go v1.0.2
github.com/golang/mock v1.1.1
github.com/golang/protobuf v1.1.0
github.com/gorilla/context v1.1.1
github.com/gorilla/mux v1.6.2
- github.com/gtank/cryptopasta v0.0.0-20170601214702-1f550f6f2f69
github.com/jtolds/gls v0.0.0-20170503224851-77f18212c9c7
github.com/magiconair/properties v1.8.0
github.com/mohae/deepcopy v0.0.0-20170929034955-c48cc78d4826
github.com/moul/http2curl v0.0.0-20170919181001-9ac6cf4d929b
github.com/oleiade/reflections v1.0.0
- github.com/ory/fosite v0.20.3
+ github.com/ory/fosite v0.12.0
github.com/ory/go-convenience v0.0.3
github.com/parnurzeal/gorequest v0.2.15
github.com/pborman/uuid v0.0.0-20180122190007-c65b2f87fee3
github.com/pkg/errors v0.8.0
- github.com/pmezard/go-difflib v1.0.0
github.com/smartystreets/assertions v0.0.0-20180607162144-eb5b59917fa2
github.com/smartystreets/goconvey v0.0.0-20180222194500-ef6db91d284a
github.com/stretchr/objx v0.0.0-20180531200725-0ab728f62c7f
- github.com/stretchr/testify v1.2.1
golang.org/x/crypto v0.0.0-20180606015541-b47b15873692
golang.org/x/net v0.0.0-20180530234432-1e491301e022
golang.org/x/oauth2 v0.0.0-20180603041954-1e0a3fa8ba9a

なんでやねん。
google.golang.org/appengine は変わってないくせに…。
何がどうなってこうなったのかはログからは全くわかりません。

本当に最新なのかわからない vgo list -m -u

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
$ vgo list -m -u
MODULE VERSION LATEST
github.com/ory/fosite-example - -
github.com/asaskevich/govalidator v0.0.0-20180319081651-7d2e70ef918f -
github.com/davecgh/go-spew v1.1.0 (2016-10-30 05:57) -
github.com/dgrijalva/jwt-go v1.0.2 (2014-08-27 05:51) -
github.com/golang/mock v1.1.1 (2018-04-06 06:54) -
github.com/golang/protobuf v1.1.0 (2018-05-01 03:52) -
github.com/gorilla/context v1.1.1 (2016-08-18 03:46) -
github.com/gorilla/mux v1.6.2 (2018-05-13 12:22) -
github.com/gtank/cryptopasta v0.0.0-20170601214702-1f550f6f2f69 -
github.com/jtolds/gls v0.0.0-20170503224851-77f18212c9c7 -
github.com/magiconair/properties v1.8.0 (2018-05-16 05:40) -
github.com/mohae/deepcopy v0.0.0-20170929034955-c48cc78d4826 -
github.com/moul/http2curl v0.0.0-20170919181001-9ac6cf4d929b -
github.com/oleiade/reflections v1.0.0 (2016-08-17 15:46) -
github.com/ory/fosite v0.12.0 (2017-10-25 19:16) v0.20.3 (2018-06-07 19:52)
github.com/ory/go-convenience v0.0.3 (2018-05-29 20:36) -
github.com/parnurzeal/gorequest v0.2.15 (2017-02-21 02:20) -
github.com/pborman/uuid v0.0.0-20180122190007-c65b2f87fee3 -
github.com/pkg/errors v0.8.0 (2016-09-29 10:48) -
github.com/pmezard/go-difflib v1.0.0 (2016-01-10 19:55) -
github.com/smartystreets/assertions v0.0.0-20180607162144-eb5b59917fa2 -
github.com/smartystreets/goconvey v0.0.0-20180222194500-ef6db91d284a -
github.com/stretchr/objx v0.0.0-20180531200725-0ab728f62c7f -
github.com/stretchr/testify v1.2.1 (2018-02-01 07:38) -
golang.org/x/crypto v0.0.0-20180606015541-b47b15873692 -
golang.org/x/net v0.0.0-20180530234432-1e491301e022 -
golang.org/x/oauth2 v0.0.0-20180603041954-1e0a3fa8ba9a -
golang.org/x/text v0.3.0 (2017-12-14 22:08) -
google.golang.org/appengine v1.0.0 (2016-09-30 05:31) -

上から順に見てVERSIONがくっそ古い jwt-go を適当に見に行ってみました。
最新はv3.2.0です。
確かに、 ^1.0.0 の範囲だと v1.0.2 は LATESTなんですが、プロジェクトを健全に保つために知りたいLATESTは v3.2.0 だと思います。
vgo get github.com/dgrijalva/jwt-go しても v3.2.0 にはなりません。
vgo get github.com/dgrijalva/jwt-go@v3 してみたら go.mod から jwt-go が消えました。
一体全体どういうことだってばよ…。
何がどうなってこうなったのかはログからは全くわかりません。

ひたすらに遅いコマンド類

1
2
$ time vgo list -m -u
vgo list -m -u 1.60s user 0.89s system 8% cpu 28.836 total

何回も実行した上でコレです。
初めて vgo get google.golang.org/appengine@master を実行した時はカップラーメンのためにお湯を沸かしてお湯入れて待って食べてSplatoon2起動するぐらいの時間がかかりました。

まとめ

この中で何が起こってるかもよくわからず --help でロクな情報が得られないシステム、誰が使えるの???
ストレスでハゲそう。

この記事は社内Slackでクダをまいてたらそれを#4 Open Go Fridayで話せと @tenntenn さんに言われたので書かれました。