今年も去年と大きく変わりなく、元気で過ごせております。
ちょっと机に飛び乗るときやキャットタワーを上り下りするときの溜めが長くなったような気が…するような…気のせいのような…。
まぁ1m程度のジャンプは毎日何回もしているので、全然元気だと言えます。
慢性的にうんちやおしっこをする頻度が低いのは依然として続いてはいます。これはまぁ大きく改善することはないのでしょう。

基本的に人間のことを信じきっており、撫で回してもつまんでも、大抵のことには動じない感じ。
前からそんな感じでしたが、最近はその傾向が加速したのか、”くだらないいたずら早く飽きなさいよね〜”という雰囲気でされるがままになっています。
たいへんかわゆい。

様子

かいぬしは相変わらず週2出社ですが、特にねこ的には気にしていない様子。
出ていくときも帰ってきたときも特に反応はありません。
こやつ、あまり他の生き物に興味がない…。
帰宅してもぴくりともせず猫ヒーターの上で寝てるので、生きてるか不安になって触ってみるとちゃんと生きてるし起こしちゃう。
というのが度々繰り返されています。
寝てるところ起こされたら僕なら怒るけど、ねこ的には”ぷるる！”って言ってあくびしてもう一回寝ます。
かわいいね。

健康面は去年より導入していたサイリウムハスクは継続的に利用しています。
これのおかげでうんちがなかなか出ないのはあまり変わっていないままですが、カチカチすぎるうんちが出ることも減り、最低限の柔らかさは維持されていそうです。
それでもうんちが出なくて困ることはありますが、まぁそのうち出るだろ…という心構えがかいぬし側にも育ってきて、病院のお世話になる機会はかなり減りました。
下手すると健康診断以外で病院に連れて行ったのは1回だけだったかも？たぶん良いことでしょう！
誕生日を迎えたのでそろそろ健康診断兼予防接種に行かねばなりませんが。

水分摂取は『飲む無一物パウチ』と『金のだしカップ』を1日ごとに交互にあげるのを続けています。
ここは特に変化なさそう。
どちらかというと飲む無一物パウチのほうがウケが悪く、金のだしカップのときのほうが完飲することが多い。
この辺は工夫次第でもっと良い結果が導けそうな気がしなくもない…。

食事についてはこれも変わらず、ヒルズのc/dマルチケアとRoyal Caninの消化器サポートを同量くらい盛り、サイリウムを小さじ半分くらいふりかけてよく混ぜて朝まとめて出す、というスタイルです。
日によって食べが倍くらい違うこともままあるし、自分で食べたいときに食べたいだけ食べ、不要なら残す、という子なので目分量で多めに持って多すぎたら捨てる、というスタイルが続いています。
サイリウムハスクをまぶす都合上、日を跨いで同じご飯のままにしておくのは流石にちょっとよくなさそう。

ゆかりさん厳選 アルバムは総数4575枚でした。
最近はあまり写真も撮らなくなりました。
部屋があまり綺麗じゃないので綺麗な写真が撮れないというのもあるし、あまり変なこともしないのでシャッターチャンスもないという。
稀におやつをあげたときは写真を撮るので、たまにおやつを買うのがいいのかもしれない。

猫グッズ

今年買った猫グッズ紹介のコーナー。
今年も新しいあたりグッズは特になし。

最近は面白い柄の手ぬぐいがあれば買って、猫ヒーターのカバーとして使っています。
可愛い柄とか面白い柄の手ぬぐいがほしい…。

今日はJOKERのまるごとチップ地鶏ささみと、ママクック フリーズドライのシラウオを誕生日のお土産に買って帰ってきました。
両方ともモリモリ食べてるので美味しいのかもしれない。
たくさんあげて甘やかしたいけど、食物繊維が足りなくてうんちが固くなると困るので連日あげるのは躊躇われるところ。

あ、あとメインで利用する通販サイトがAmazonからヨドバシになった影響で、猫砂がLION ニオイをとる砂になりました。
Amazonの砂は粉っぽかったけどこっちはそうでもないので、まぁ良い…のかな？
ねこ的には特に気にしてなさそう。

猫を飼いたい人へ

猫を飼うのは大変でお金もかかるし掃除も増えるけど、ふわふわで可愛くてすごいです。
一度飼い始めたらもう後戻りはできないけど、毎日は幸せになります。

最後に、Amazonのほしいものリストです。
おゆが使うものがまとまっています。
猫用

今年も去年と同様、体調面にも大過なく過ごせてよかったです。
慢性的にうんちやおしっこをする頻度が低いのは依然として続いてはいますが、まぁ個性の一部ということでいいのでしょう。

ここ数年、おもちゃで遊ぼう！と誘ってもお通じが悪いときくらいしか遊んでくれなくなりました。
大人なんだからそんなの楽しいわけないでしょ。みたいな顔。
うーん、まぁ、そうかも…？そうかな…？

10歳になったので、そろそろかわいがるときは「可愛くて優しくて賢い猫」に付け加えて「可愛くて優しくて賢くて健康な猫」にする必要があるかも。

様子

今年は社のアレで基本WFH、週2くらい出社、みたいな感じになってきました。
通勤したくねぇ〜。
ゆかりさん的にはかいぬしが居ても居なくても特に関心は薄いらしく、会社行く時に引き止められもしないし、帰ってきても歓迎してくれる感じでもありません。
まぁいつも通りですね。

体調管理面で一つ変化があったのは、獣医さんの勧めによりサイリウム（オオバコ属サイリウムの種子を砕いたやつ。食物繊維がバリすごいらしい）を1月末ごろから試してみました。
カリカリにまぶしたところ、特に変化なく食べているように見えます。
まぁ食欲旺盛なタイプではなく、気が向いたらちょっと食べる、みたいなスタイルなので僕が判別できないだけで、内心微妙だと思ってる可能性はありますが…。
とまれ、お薬と同程度かそれ以上ににお通じが良くなるっぽくて、うんちがなかなか出ないのはさほど改善しないけどもカチカチ度は下がったように思います。
力みすぎてゲボ吐くことも減った…気がする？
これにより、月1くらいで動物病院にお薬を処方してもらいにいくのがなくなり、ゆかり本猫も1日2回錠剤を口に捩じ込まれることもなくなり平和が訪れました。
まぁ錠剤を飲むのは猫側も人側もぼちぼち慣れて、大仕事ってわけではなかったんですが。
この薬代に月1万円くらいかかっていたので、よかった反面、かかりつけ医なので収入が減って潰れやしないかと心配になる気持ちもちょっとあります。

水分の摂取はなかなか難儀しているのが続いています。
去年紹介した『飲む無一物パウチ』の同じ味を連続で上げ続けたら流石に飽きるらしく、飲んでくれなくなりました。
しかたないので、『金のだしカップ』を併用し、1日ごとに別々のやつを出すようにしています。
今のところまぁ出したら飲んでそう。

同僚に勧められて、Elfin給水機を買って配備してみたんですが、全然使ってくれなくて悲しい…。
3ヶ月弱前に設置したんですが、この間土曜日に僕が昼過ぎまで寝てたら僕に隠れてこっそり飲んでいるのを発見しました。
…実はこっそり飲んでたんか？

この給水機、機械部が水没しないという触れ込みなのですが、掃除は実際簡単でよいです。
ただ、プラスチックの細かい凹凸が普通に食器を洗うように洗っても洗いきれないようで、水垢（赤カビ？）がつく場合があり、どう手入れしたものか悩ましい…。
とりあえず綿棒を使ったり完全乾燥させてみたりしているけどどうするのがいいんだろ？

食事については去年とほぼ変わらず、ヒルズのc/dマルチケアとRoyal Caninの消化器サポートを同量くらい盛り、サイリウムを小さじ半分くらいふりかけてよく混ぜて朝出す、というスタイルです。

ゆかりさん厳選 アルバムは総数4047枚でした。
変化があまりないので写真もあまり撮らないし、部屋の掃除が行われていなくてどう写真をとってもアレな感じになるのであまり撮ってないのは相変わらず…。
いい加減家事を習慣化するべきではある…。
はじめたはいいが、技術書典の繁盛期とかに家事してる場合じゃねぇ！ってなって途切れてそのまま…みたいなのがよくあるんですよね。
鋼の意志でやらないといけない…。

猫グッズ

今年買った猫グッズ紹介のコーナー。
今年も新しいあたりグッズは特になし。

前述のElfin給水機と、あとCatlog Board 1がなんかヘタってきたのか検知してくれないことが増えた気がしたので、Catlog Board 2を買ったりしました。
古い方が完全に浮いてるんだけど下取りとかに出したいな…そういうのなさそうだけど。

猫を飼いたい人へ

猫を飼うのは大変でお金もかかるし掃除も増えるけど、ふわふわで可愛くてすごいです。
一度飼い始めたらもう後戻りはできないけど、毎日は幸せになります。

最後に、Amazonのほしいものリストです。
おゆが使うものがまとまっています。
猫用

私は1人と1匹暮らしです。
自炊はしますがあまり真面目にレシピを見ずに適当に作るタイプです。
リュウジのバズレシピはNkznがよく話題に出すので、今まで受動喫煙してきました。

そんな中、僕が珍しく動画を見て実際に作ったレシピが『究極のほろほろチキン煮込み』でした。

僕はお酒をさほど好きではないので調理前に飲酒キメるのは理解できないなと思いつつ視聴しました。
ホロホロなお肉は好き。

このレシピは（このレシピ以外もそうなんだと思うけど）調理工程が短く、僕が結構な頻度で作るカレーに比べて非常にお手軽です。
3-4食分一気に作って冷蔵し、3-4日かけて食べます。
同じものを食べ続けてもさほど気にならないタイプの人間でよかった。

僕はレシピ情報だと動画よりテキストのほうが好きなので、繰り返し参照する時はWebサイトのほうを見ています。

このレシピで学んだのは、食べるのが面倒だと思っていた鶏もも肉は筋とか皮とか何も気にせず90分程度煮込めばほろほろに崩れて繊維状になるということです。
そういうお肉…好きだ…。

Advent Calendarなので、実際に調理していきたいと思います。
とりあえず適当に煮込んで繊維状になったお肉を一回冷蔵したのが昨日。
それを改めて調理した結果がこちらのカレーになります。

カレーについては2年くらい前に当時のボスだったhidekさんからおすすめされた次の本のレシピを利用しています。
今となってはレシピを参照せずに雑に作っているので似て非なるものになってる気もするけど…。
カレー雑学の本としても楽しめるのでおすすめです。

近況として、技術書典でIdPを作っていました。
たぶん近いうちにサイレントリリースします。

最近、努力というのは難しいなぁ、と思うのでこれについて書きます。

何かを伸ばそうと思ったときに頑張って練習とかをするわけですが、量を確保するのはある意味気合いと体力の話なのでコントロールしやすいです。
質を確保するのがとても難しくて、4時間練習した時に得られる”気付き”の量は一定でありません。
ある意味ガチャです。

実力の伸びが練習の量×質で左右されるとして、質が高ければ高いほどコスパがよくなります。
質というのは言い換えるとコツと言ってもいいかもしれません。

面倒なのが、”コツ”にはレベルキャップみたいなものが存在して、ある一定以上のレベルに達するまで利用できないコツがあると思います。
格闘ゲームでいうと、波動拳が出せない人に「強パンチをガードされたら波動拳で隙を誤魔化せるよ」みたいなやつです。

既存の手法として、コツを外部から供給してもらうための手段として読書や解説動画の視聴などがあると思います。
これらは自分が”コツ”を求めている時に刺さりますが、多くの人に向けて作られているため、自分にもっとも必要な”コツ”だけを得ることは難しいです。
どちらかというと体系的な知識を得るのに向いています。

もう少しコツへの距離が近い手法として、近年ChatGPTが登場しました。
これは低レベル時にコツを得るのにめちゃめちゃ有効で、人間が介在しないので任意の時間に使い放題です。
ある一定レベルを超えると次の理由で頼れなくなってしまいます。

• 高度な質問は前提条件が増えてしまうため質問をするのが難しくなる
• 知識のカットオフの日より後に発生したことは知らない
• ハルシネーションの影響がデカくなってしまう

これを解決しうるのがパーソナルトレーニング的なコーチを頼む（雇う）ことなのかなぁ…と思っています。
自分の知識やプレイを見て壁打ちのようにもっとも今必要な、伸びるコツを自分の知識の外から選んで出してくれる存在というのは、めちゃくちゃありがたいんじゃないかなぁ、という。
頼んだことはないんだけど…！

みたいなことをmhidakaとValorantをプレイして、なかなか上達しないなー（BOT撃ち以外の練習してないんだからそれはそう）と思いつつ考えてました。
この場合LineupsValorantで定点覚えるとか、習得してないキャラコンの解説を調べるとか、安直な伸び代がいろいろあるので質だのコーチだのの前にやる気と丁寧さがまず必要なんだよな。
という話でした。

まぁでも安直にコーチを一回頼んで見るべきかもしれんなー（と言い始めて半年以上経つ）。

という近況でした。
はい。
最終的には本から自分の知っていることを削ぎ落として薄くしてくれるAIみたいなのが出てくるんじゃないかなという気がします。

これだけだとあれなんでKALDIのおすすめ商品を貼っておきます。

• 青いにんにく辣油　青唐辛子
• パンダ杏仁豆腐
• クラフトチャイ

今年は去年に比べると体調に大きな問題はなかった…かな？
2月ごろに一回うっすら血尿が出て病院行って経過観察、他はたまにうんちやおしっこをあまりしない〜といってかいぬしの安心のために病院に連れていった程度でした。

そろそろ年なのかな…？と感じることが増えるかと思いきや、特に変わりのない一年だったと思います。
頭をぷるると振ったときに稀によだれが飛ぶ。ちょっとばっちいね。
相変わらずかわいくてすごかったです。

様子

今年もWFHですので年中家にいました。
特に去年と変わらずに猫ヒーターの位置にいることが多いので、暇なときに撫でたり揉んだりしています。

今年はストラバイトらしきものがエコーで観察されたり不確定だったりしつつ、まぁ寛解している感じで過ごしてました。
2月ごろトイレ砂がちょっと桜色になってて慌てたりしたけど、特に大病なく過ごせているっぽいです。
お水をたくさん飲んで欲しいというのは続いているので、色々試してました。
途中まではちゅーるを水に溶いたちゅーる水を毎朝あげたりしてたんですが、数日続くと飽きてしまうようでなかなか難しかった…。
そんななかshati_ko氏おすすめのはごろもフーズ『飲む無一物パウチ』が神レベルでよかったです。
ゆかり的には美味しいらしく、毎日リピートしてもちゃんと飲み切るのと、かなり希釈してもちゃんと飲んでくれるので大変助かってます。
名前が死ぬほどダサいのと、封を切る時や絞り出す時に勢い余って色々飛び散るのでかいぬしが微妙な気持ちになるのはこの際無視できる…！
獣医さんにも一応相談したけど飲んでるならえんちゃう？的な感じでした。

食事はヒルズのc/dマルチケアとRoyal Caninの消化器サポートを同量くらい一緒に朝出す、というスタイルになりました。
出した分を自分が食べたいときに小分けに食べてるので朝と晩に分ける意味がないことに今更気がついた…！
明け方までに全部食べてあったり食べてなかったりしてます。
おしっこは1-2日に1回、うんちは3-6日に1回くらい。
今年お通じをよくする薬はラクツロースなども試したけど、結局ガスモチンとセンノシドに戻ってきました。
ラクツロースのほうがだいぶ安くて、ガスモチンとセンノシドは1ヶ月分で1万円くらいするのでなかなか大変。
自分でピルカッターとかでやれば安いんだろうけど、まぁ動物病院潰れてなくなっちゃったら困るからね…。

本人はうんちが出なくて困っているその瞬間以外はケロっとしているのは去年の変わらず。

顔をわにっと掴むと、そーっと手が伸びてきて、やめろやめろ と払い除けようとするのが可愛くてついわにっとしてしまう…。

ゆかりさん厳選 アルバムは3585枚でした。
変化があまりないのであまり写真を撮らない感じなのは去年と変わらず。
あと部屋をあまり掃除してないので撮る気があまり起きない…。

この写真を見るとちょっとわかるかもなんですけど、最近ちょっと腹毛が赤っぽくなってきました。
昔は完全に真っ黒ちゃんだった気がしなくもないけど、色って変わるのかな？
これはこれで可愛い色だね。

今年もスリスリはしてくれないので、スリスリはしない主義らしいです。
ブラシかけるとお返しに手を舐めてくれたりはします。
かわいいね。

猫グッズ

今年買った猫グッズ紹介のコーナー。
今年は新しいあたりグッズは特になし…！だったと思う。
はごろもフーズの飲む 無一物は今後もリピしていきます。

今使ってるおちょこが70mlくらいで、おちょことしてはめちゃめちゃでかいです。
可能であればもっと希釈したいので今は120mlくらい入る器がほしいところ。
なかなかいいのないんですよね…。
大は小を兼ねないので難しい。

猫を飼いたい人へ

猫を飼うのは大変でお金もかかるし掃除も増えるけど、ふわふわで可愛くてすごいです。
一度飼い始めたらもう後戻りはできないけど、毎日は幸せになります。

最後に、Amazonのほしいものリストです。
おゆが使うものがまとまっています。
猫用

今年はストラバイトが検出されたり寛解したりまた出たり寛解したりという感じでそわそわすることも多かったものの、1年通してかわいくてすごかったです。

様子

今年も引き続きずっと家で仕事(WFH)でしたので、まぁ年中家にいます。
今年も机の左手側に置いてある猫ヒーターの上でくつろいでることが多いので、気が向いたら左手でもふもふしたり膝に載せたりしていました。

今年はストラバイトが出たり寛解したり出たり寛解したりしていたんですが現時点では寛解しています。
獣医さんの指導の元、ご飯をちょっと変えてヒルズのc/dマルチケアを朝ごはんに、Royal Caninの消化器サポート可溶性繊維を晩ごはんに出す生活になりました。
うんちは相変わらず3-4日に1回、毎回苦戦して出す感じなので気をもみ続けています。
すっと出ないもんかねぇ…。
一応病院でお薬を処方してもらって、うんち出ない3日目になったら朝晩投薬するようになりました。
お薬飲ませるのもだいぶなれた…。

本人はうんちが出なくて困っているその瞬間以外は特になにもなくケロっとしているのも変わらず。

お水をもっと飲んでほしいなぁという気持ちで色々工夫した結果、机の端にお水を入れたお猪口を置くようにしたら結構飲むように。
本当にだらーんとした姿勢で飲むので、怠惰感がすごいです。
下の写真はレディであることに配慮して、多少しゃんとした姿勢で飲んでるところです。
机に飛び乗る時とかに蹴倒すこともちょいちょいあるので、たまに拭き掃除が発生します。
まぁ仕方ないね。

様子とかは去年とあまり変わりがないですね。
僕の膝に乗りたいときは、「特に用はないんだけど、ちょっと目の前で伸びでもしてみようかな〜」という素振りを挟んでから乗ってきます。
かわいいね！

ゆかりさん厳選 アルバムは3127枚でした。
マジで似たような生活を繰り返しているだけなのであまりシャッターチャンスがないのでありました…。

今年もスリスリはしてくれないので、やっぱりずっとスリスリはしてくれない様子です。
これもまた個性。

猫グッズ

今年買った猫グッズ紹介のコーナー。
…といいつつ、あまり新規に買った種類がないという。
CatlogのBoardじゃない、首輪のやつを買ってみたんですが、しばらくつけたあとに使わなくなりました。
ゆかりは毛の生え変わりがすごく少ないので、ずっとつけてると首周りの毛が薄くなってきちゃった気がしたので…。
考えすぎな気はしますけどね。

この1年で読んだ本だとこれで、大変おもしろかったです。
この本に書かれている内容が嘘か真かはまだわかりませんが、本当だといいなぁ…！

猫を飼いたい人へ

猫はいいぞ。
WFHが永続化したりする企業も出つつある現在、あとは思い切るだけ！
一度飼い始めたらもう後戻りはできないけど、毎日は幸せになります。

最後に、Amazonの干し芋を晒しておきます。
最近はお医者さんと相談した結果、ちゅーるをなるだけあげないようにしてます。
…しかしAIM入のやつは気になる…。
猫用

今年はコロナも2年目ということで、微妙に精神が不安定になったりしていたかいぬしですが、ねこは普段どおりです。

すこし加齢を感じなくもないものの、この1年もおゆはずっと優しくて賢くて可愛い猫をしていました。
毎日かわいくてすごい！

様子

今年もずっと家で仕事(WFH)でしたので、まぁ年中家にいます。
仕事中つねに左手の猫ヒーターポジションで寝ているので、気が向いたら撫でたり顔をうずめたりして迷惑がられています。

相変わらずうんちやおしっこが若干ふつうの猫と比べるとスムーズではなく、気をもむことが多いです。
おしっこの様子がおかしくて、ちょっとトイレはいってちょびっと出して にゃおん！ て言ったりしたので病院で検査してもらったら、赤血球が尿に〜とかpHが結構酸性〜とか言われたりしました。
治療のためにお薬を飲ませる必要があったり、対策の専用フードをあげたりしてました。

このときは投薬とご飯制限で問題ない状態に。

その後、おしっこの検体を定期的に持っていったらストラバイトが結構出てますねーと言われて、専用食継続になったり。
食事療法でほぼ検出されなくなったので一安心…。
でも、そうすると繊維ご飯じゃなくなったのでお通じ上の不安が…。

という感じで色々翻弄されていました。
現在のご飯は対尿打線から対うんち打線にシフトして様子をみているところ…。
でもまぁ3-4日くらい普通にうんちしないので困る…。

本人はわりとケロっとしてるんですけどね！
まぁ今後も気をつけていきましょう。
このあたりの問題がなければ本当に文句のないパーフェクトキャットなので、神様もうちょっとだけがんばってほしかった…。

最近は歯磨きをなるべく毎日するようにしているんですが、最近慣れてきたのか10秒くらいは我慢して磨かせてくれるようになりました。
ただ、その代わりヘッドをガジガジ噛もうとするのでそろそろ歯ブラシが大破しそうです。

最近、僕がゲームをしていると自分からｽｰｯと寄ってきて勝手に膝の上で丸くなってくつろいだりしてます。
Guilty Gear Striveをやっているときはアーケードスティックなので膝があいてない！と不満そうです。
FPSとかをやってると膝に乗り放題なので、猫的には FPS >>>> 格ゲー という図式になっていそうですね。

体調面の課題が多いことや外出しずらい世相があったりでかいぬし側がすこし精神の調子を落としていました。
なので、今年はは去年にくらべ、おゆもなんだか不満そうな顔をしている… と思うことが増えたのですが、おそらく気の所為…でしょう。
僕との暮らしにも相当なれたのか、だいたい何をしてもされるがままになっています。
また、撫でたり構ってほしいときもあるようで、膝に乗った後、僕と視線があっていると嬉しそうにしてくつろいでいます。
逆に、僕がYouTubeとかを見てよそ見していると不満なようで、ずっと僕の顔を見てたりします。かわゆい。

ゆかりさん厳選 アルバムは2784枚でした。
相変わらず似たような構図が多い。

将来、スリスリしてくれるようになるかなー、とか去年の記事で書きましたが、まだしてくれません。
まぁ多分ずっとスリスリでは表現してくれないと思います。
これもまた個性。

猫グッズ

今年買った猫グッズ紹介のコーナー。

Wag 消臭猫砂。
会社で同僚におすすめされたものです。
トイレまわりが改善されると本当に嬉しいので、色々試した結果、システムトイレで粒の大きい砂は実は嫌いだということがわかりました…。
他にはPULFINOという高級なお砂を試したりしたのですが、おしっこした後に本当にすぐ固まるので逆に股間の毛に砂の塊がくっついてしまい不評なようでした。

これも会社で同僚におすすめされたものです。
広々としたトイレでわりと使いやすいっぽいです。
砂をめちゃめちゃ外に掻き出されてしまうんですがまぁ掃除すればいいべ、という運用になってます。

上記トイレの出現にあわせて、1回システムトイレを捨てちゃったんですがおしっこ検査のためには層構造になってて下の段に液体が溜められるトイレが必要…ということで再購入するハメに。
これは普段から出しっぱなしにしてありますが普段はマジで使われません。
ここにおしっこしてほしいときは砂トイレを隠す必要があります…。

Catlog Board

昔Makuakeでbackしてた製品が届いたやつです。
今は上記サイトから普通に注文できます。
これはトイレの下に敷くログ付き高性能体重計みたいなやつです。
いつ、どのくらい、おしっこうんちをしたかというのはうちの場合お医者さんに相談する上で非常に重要な要素です。
なので、この製品はマジでめちゃめちゃ助かってます。
今まではSlackのチャンネルに人力で保存していて、いい加減Voice UI的な何かで作らないとかなーと思ってたところでした。

できればWebHookでこっちにデータを共有してほしいというのと、トイレ使用後に1-2分くらい待ってから掃除しないといけないのが細かい不満点ですね。

猫様コードという紹介コードがあって、 GH2ASM がおゆのコードです。
これを入力して購入した人が出ると、おゆの肩書が豪華になるらしいです。
かいぬしじゃなくてねこの肩書が豪華になるあたり、心理をよう突いとる…ってなります。

最近Catlog Pendantという猫用活動計も買ってつけてもらってるんですが、正直こっちはあんまり嬉しさがわかってないです。

猫を飼いたい人へ

猫はいいぞ。
WFHが永続化したりする企業も出つつある現在、あとは思い切るだけ！
一度飼い始めたらもう後戻りはできないけど、毎日は幸せになります。

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

最近は おゆ とか おゆゆ とか おゆり とか おゆかりちゃん と呼んでいます。

相変わらず毎日かわいいので、きっと特別なねこなのでしょう。
でなければ説明がつかないので…。

様子

最近は家で仕事(WFH)するようになったので年中家にいます。
結果、仕事中も左手においてある猫ヒーターやぼくの膝の上にいるので毎日が猫曜日です。

こないだ、なんかｹﾞｺｹﾞｺ言ってて何かを嚥下しようとするようなそぶりがあったので念の為に病院に連れて行ったら、喉がちょーっとだけ赤いので軽い風邪かも…？といって薬をもらってしまいました。
風邪とか初めてなのでドキドキする… とりあえず毎日お薬飲ませてます。
本人はケロっとしてるけど病院につれていかれたので怒って高いとこに避難してしまいました…。

自分から膝に乗るのはなにかイヤらしいので、膝に乗りにおいで！というと猫ヒーターの上に来るので手で持ち上げて膝に乗せています。
乗りたくないときはヒーターにへばりつき、乗ってもいいときはそのままスーッと持ち上げられるがままになっているので、まぁイヤではないようです。

去年と比べて、今年はもっと仲良くなった… というか警戒心が下がった気がします。
お顔もぎゅもぎゅしてもしばらくはやらせてくれますしね。
食器を洗うときや洗濯物を干すとき、足元をチョロチョロするので人間が何か作業しているときは踏まれたり、物が落ちてきたりするかもしれないので近くに寄らないように指導するのですが、聞きはしないようです。
ねこなので…。

おトイレ事情はうまくいくときとうまくいかないときが半々くらいになってきました。
いやこれは上がったのが？下がったのか？わからん。

人の話を聞くと、本当に猫というのは個性がものすごく色々とあって、うちの猫が一番かしこい猫らしいなと思います。
肝が太いらしく地震がきても雷がきてもまったく動じません。
楽だね！
あと何しても噛み付いたりひっかいたりしてこないのでつい色々ちょっかいを出してしまう…。

ゆかりさん厳選 アルバムは2343枚でした。
相変わらずバリエーションがあんまりない。

いやー、将来スリスリしてくれるようになるかなー。
たぶんならないと思うけども！
猫ごとに個性があって、気持ちの表現方法にも幅があるけどもね。

猫グッズ

ぽんちゅーる。
普通のチュールと比べると煮こごりというか？ゼリー状の硬さがある。
カリカリと混ぜてもあまりカリカリに水分が移らないので取り扱いやすい気がする…。

スリッカーブラシです。
今まで、ずっとファーミネーターを主に使っていたんですが、ふわりは毛の生え変わりが何故かあまりありません。
なので、あまり頻繁にファーミネーターを使用していると毛が抜けすぎてしまい、背中がちょっと薄くなったりしてしまうことがありました…。
スリッカーブラシは見た目がどうしても拷問器具なのですが、毛が抜けすぎるということもなく、毛並みをツヤツヤにしてあげられている気がします。

この記事を書くまで、ファーミネーターがトップコート用、スリッカーブラシがアンダーコート用だと思ってたんですが、今調べたらファーミネーターもアンダーコート用らしい…？
両者で取れる毛の性質が違う気がするんだけどな…？

とまれかくまれ、今までより毛並みはつやつやで、毛が薄くなることもなくなった気がする…？んですよね…？

で、あの拷問器具をたくさん使うのはちょっと怖いので仕上げ用ブラシです。
前使ってた豚毛のブラシと違って柄があるので使いやすいです。
でもなんかファーミネーターとかスリッカーブラシと違って毛があるブラシはあまりヨくないらしく、使い始めるとまもなくどっか行ってしまいます。
いいならいいけど…。

猫を飼いたい人へ

猫はいいぞ…！
一度飼い始めたらもう後戻りはできないけど、毎日は幸せになります。
コロナで騒がれるご時勢なので、家にいる機会が多い今の間に猫をお迎えしよう！
家にきてしばらくは病院連れてったりと時間がかかるアレが多いので今のうちに…。

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

vvakameです。

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

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

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

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

社内で技術書典7で売ってたProgrammer’s Pocket Referenceは完全に頭のおかしい最高の本なので全員買ってほしい！見ろこの内容をよォ！と力説したんだけど電書販売を現在行ってないっぽくてしょげてる… https://t.co/J6zJLDoe93

— わかめ@毎日猫がいる (@vvakame) September 27, 2019

この本、前半は色々な言語でこれはこう書くみたいな話で、うんうんそうだね、って感じなんだけど後半ASCIIコードの話やx86のレジスタの話やBluetoothの規格やキーボードショートカットやPOSIXコマンドの解説やOSI参照モデルやUSB Type-Cの規格やピン配置、HDMIやetc etcが狂った情報量で書かれてて

— わかめ@毎日猫がいる (@vvakame) September 27, 2019

なおかつ全ページフルカラーのデータでこれ1ページあたりの編集の手間どんだけかかってんの？みたいなのが200ページ超続いてるんですよ。やばい。到底真似できるものではない。みんなも買って目を通してみてほしい。売ってないんだけど。

— わかめ@毎日猫がいる (@vvakame) September 27, 2019

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

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

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

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

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

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

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

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

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

この調子で、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円弱という雑な見積もりです。
それは印刷できんわガッハッハｗ

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

購入は！＞＞＞ここ＜＜＜から！！

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

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

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

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

様子

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

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

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

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

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

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

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

猫グッズ

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

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

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

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

猫を飼いたい人へ

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

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

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)
}

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

2019-10-03 16:53:06

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

2019-10-03 16:53:14

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

ひかる黄金わかめ帝国 新刊 GraphQLスキーマ設計ガイド 9割の確立で出ます！電書のみ500円！GraphQLに興味ある人みんなに読んでほしい…！技術書典Web開発日記もあるよ！(たぶん) 当日僕はブースにいないと思いますが あ20C で虚空と握手！ #技術書典https://t.co/1CWhurr8zL pic.twitter.com/hEF0lDH7nN

— わかめ@毎日猫がいる (@vvakame) September 15, 2019

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

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

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

レビューで事前に読ませて貰いました

スキーマ設計の際に参考にした方がよいGithub v4 APIとRelayの仕様を読み解いて説明されています

初めてのスキーマ設計ではRESTがクエリーになっただけになりがちなので、お手本となる上記2つを解説してくれているこの書籍はとても貴重

必読です！ #技術書典7 https://t.co/hSZ0avKZtG

— そな太@Swift始めました (@sonatard) September 17, 2019

必読！

自分のSlackとツイートを見る限り、Github v4 APIのルールをAPI仕様から読み解く作業とRelay GraphQL Server Specificationを熟読する作業を7日はやっと痕跡があるので7日分はこの書籍があると回収できます

だから必読！

— そな太@Swift始めました (@sonatard) September 17, 2019

自分もレビューで読ませていただいたんですが、世界でいま一番GraphQLの設計について詳しい本だと思うので、GraphQLやってる人はぜひ読みましょう！

relay specificationや、mutationの設計、権限管理、エラー処理、linterなど、かゆいところに手が届く一冊になってます https://t.co/NneMpt3ET4

— Yoshinori Kosaka (@wawoon_jp) September 17, 2019

わかめさんの新刊、GraphQLの設計についていま世界で一番詳しいのはほんとう。自分はこれまでめちゃくちゃネットで調べてるけどここまでまとまっている情報ソースはなかったです。

— Yoshinori Kosaka (@wawoon_jp) September 17, 2019

レビューという形で一足先に読ませていただきました。GitHub v4 API や Relay の仕様を例に、GraphQL のスキーマ設計をする際の指針が書かれています。GraphQL のスキーマ設計をする前にこの本を読んでおけば先人と同じ地雷を自分で踏み抜く必要がない！便利！ https://t.co/ZAluyoQVj1

— zoncoen (@zoncoen) September 18, 2019

ぼくもレビューに参加しました。「なるほどvvakameさんはGrapqQLのスキーマ設計は考えているのか…！！」という感じでたいへん面白かったです。

GraphQLの仕様そのものからは読み取れないような実践的な話が満載なのでおすすめですよ！ https://t.co/Ur9TQTiM9t

— FUJI Goro (@__gfx__) September 20, 2019

とのことでした。ドヤ！

技術書典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)

Files changes: 1

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

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 .

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を出すのはめんどくさそうだったので妥協しました。
動作させた時の様子を貼っておきます(デバッグのため余計な工程が入っているけど…

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を参照してください。

• https://github.com/vvakame/github-actions/tree/master/pr-to-md
• https://github.com/vvakame/github-actions/tree/master/md-to-blogpost

ブログを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 -2019-06-03 07:17:34

サッポロ一番

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

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

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

錫記雲吞麵のワンタン麺

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

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

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

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

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

技術書典5で頒布した GraphQLサーバをGo言語で作る の全文を公開し、ついでにビルドしたPDFをboothで販売開始しました。
よかったら読んでみてね！！https://t.co/6Vj1E5S4rOhttps://t.co/gNv5r3ZMAd

— わかめ@毎日猫がいる (@vvakame) 2018年10月15日

サーバ側は前回やったので、今度はクライアント側だ！と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での後日販売なども行うと思います。

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

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

@vvakame https://t.co/yk3Ea0fHCI

— たろう (@ngsw_taro) 2018年10月30日

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

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

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

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

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

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

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

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

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

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で売ってない…。

猫を飼いたい人へ

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

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

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

利用したvgo

• golang.org/x/vgo の 203abfb0741bf96c7c5e8dab019f6fe9c89bded3 の時点で 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/v1 と github.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 中の require を google.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 さんに言われたので書かれました。

ひかる黄金わかめ帝国 サークル詳細ページはこちら。
当日は333円、かんたん後払いサービスでのお支払を受け付けています。

筆者である僕が運営スタッフを兼ねているので終日不在の予定です。
ざっくりした店番だけTechBoosterの面々に頼んであります。

TechBoosterのNow and Futureに収録されるか！？されへんか！？どや！？168P？はいドロップ！
という流れだったので、準備がなかなか急でした。

前回の反省は次の通りでした。

• 前日にKinkosでダウンロードカード刷るのつらい
• 慢心して見本誌作成しなかったら案外売れ行き伸びなくてつらい

というわけで、今回はかなり色々な割り切りをすることにしました。

• 現金の取扱をやめ、かんたん後払いのみにする
  • 釣り銭などの準備が不要に！
• 前回同様、製本はしない 電子版のみ
  • 自分がブースにいない想定なので楽を取っていく
  • TechBooster側に収録されるか不明だったので表紙も発注する暇なかったし
• 表紙はゆかりさんに頼む
  • 前回はSurface Proで自分で書いたのだった（めんどかった）
  • 写真+デザイン用ツールとしてAffinity Designerを利用
• ダウンロードカードのダウンロード用URLを全員一律にした
  • Google Driveの共有URLを一律で印刷した
  • Google Driveの場合、後からデータの更新がしやすい
  • URL個別にしたところで再アップロードとかの悪意にあうとさほど意味がない
  • どうせ後でGitHubのリポジトリ公開するし…
  • 表裏のデザインが全カード共通になったので名刺shop.comさんの両面印刷でOK
• 見本誌ちゃんと刷る
  • 今回はネタ的に既存手法（LaTeX版）と提案手法（CSS版）が比較できないと面白くないので必須
  • セブンイレブンの同人プリントでやった
  • 仕様上の癖が結構あったので、前日に1発で成功させるのはつらそう
• お品書きちゃんと作る
  • 当日ブースにいないのでなんとなく内容がわかる紙が必要だよねーってなった

内容はざっくり次の通りです。
後日全文を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

     3KB   1044C    29L  はじめに (preface)
1.   4KB   1782C    54L  {why-css-typesetting} なぜCSS組版か？ (why-css-typesetting)
2.   4KB   1482C    46L  CSS組版について知ろう！ (whats-css-typesetting)
                    26L       1 vivliostyle.jsについて
3.  22KB  11432C   476L  実際にやってみる (practice)
                    12L       1 TechBoosterのワークフロー with Re:VIEW
                    15L       2 ブラウザからPDF出力の下準備
                    25L       3 1枚のHTMLを出力する！気合で
                    36L       4 扉や奥付のページを表示したい！
                    34L       5 目次を表示したい！
                    28L       6 ノンブルを打ちたい！
                    62L       7 柱に現在表示中の章タイトルを表示したい！
                    61L       8 テキスト周りの見た目をなんとかしたい！
                    77L       9 脚注を表示したい！
                    20L       10 画像をセンタリングしたい！
                    53L       11 ボックス系の見た目をいい感じにしたい！
                    24L       12 ページ上部に雑に線引きたい！
                    10L       13 Vivliostyle Viewerを使ってデータを表示する
4.  14KB   6206C   199L  未解決の課題 (issue)
                     6L       1 問題の上手な切り分け方
                    30L       2 PDFの生成とフォントの埋込
                     8L       3 凝ったデザインへの挑戦
                     9L       4 HTMLBuilderが吐き出すアンカーとリンクを修正する
                    13L       5 CSSの管理方法
                    28L       6 ボックス系の見た目と脚注が被る話
                    18L       7 vivliostyle.jsのレンダリングがリロードで壊れる場合がある
                    44L       8 CI上でPDFを生成させ再現性を持たせる
                     8L       9 他のブラウザを検討する
                    29L       10 他の組版エンジンを検討する
                    16L          1 [column] トリムマーク社が爆誕した話
5.   5KB   1852C    73L  まとめ (conclusion)
     3KB   1065C    36L  おわりに (afterword)
     3KB   1726C    94L  Re:VIEW記法出力見本 (syntax-example)
                    89L       1 出力見本
                     1L          1 [column] コラム
                     2L       2 節です
                     1L          1 項です

kmutoさんにも次のお言葉をいただきましたし、やっていきだと思われます。

なんか弊社で踏み抜いてきた地雷が列挙されている気がする（優秀な地雷処理班ができました

— kmuto (@kmuto) 2018年4月19日

なお、この本はpentapodさんの本を読んであるとより詳しく知ることができると思いますのでみんな買おう！

実際に入稿したい場合は、負けたくない！Splatoon2のこの辺のログが参考になると思います。

会社の制度？Mercari Tech Research？

なんかそういう制度があって、世界の色々なとこの進んでそうなサービスやら概念を偵察に行けます。
今年は脊椎反射で色々なことに片足突っ込んでみて、後で痛い目にあったら反省しようということにしたので、この制度に応募してみることにしました。

そしたらなんか当選したので深圳に行きました。
他に上海とかインドとかの選択肢がありましたが、昔の秋葉原の電気街っぽい感じとも聞きますし一番肌に会いそうだったので。

「Mercari Tech Research」について

何をしにいったか

すでにみんながスマホでの決済サービスを利用している世界観を体験しにいく

↑これが僕の目的です。
なんかメルペイ社というやつがあり、決済をやるそうなんですが自分たちが実現したい世界の一端が既にわりとあるっぽい土地があるそうなので、見ておいたほうが後々の話が早かろうということで体験しにいきたかったわけです。
なお、ここで書かれていることはvvakame個人の感想であり、うんぬんかんぬんです。

僕が務めるソウゾウ社はメルカリ子会社なんですが、メルペイ社というやつもあり、両社ともアホみたいにパワフルマンを欲しがっています。
強い人を求めていますので気が向いたら適当にソウゾウ/メルペイに応募してみてください。

TL;DR

• マジで現金1ミリも必要ないしスマホあればなんでもできる
• どこでも使える のが一番えらい
• QRコード決済別に早くない
• NFC（Felica）やっぱ早い
• QRコード（＝非接触読み取り）、応用範囲が広く優れている
• スマホがSPOFすぎて不具合出るとなんも出来ない
• スマホすらなくても決済できたほうが便利じゃね？
• シェア経済、特にモバイルバッテリーのシェア嬉しさがすごい

雑な決済周りのレポート

微信支宝(WeChatPay, weixin)と支付宝(AliPay, 中国語読みわからん)の2強。
外国人(= 俺)でも使いはじめやすいのはweixin。
現地の人は給料の受取もAliPayらしい。weixinは口座に振り込みに手数料取られるそうなので。

weixinで支払いが出来なかったのは空港の茶葉屋さんだけで、他はどんな店でもweixinで支払いができた。
現地で現金は1回も出番なかったです。
“どこでも使える”のが、考えるコストを減らしていて最高に良かった。
ゲーセンのマシンにクレジット追加するのすらQRコードだった。
新規の設備投資無しでも始められるというのも強そう。QRコードとか印刷もできるし…。

weixinでの支払い方は2パターン。
1つ目が自分のスマホでお店のQRコードをスキャンして、金額を入力して、PINコード入れて、店員さんに見せる。
このやり方は屋台などの小売店で多かった。
2つ目が自分のスマホで決済用バーコードを表示して、お店の端末でスキャンしてもらい額面を確認して、PINコード入れて終わり。
こっちはそれなりにデカいお店で多かった。

さて、このQRコードをスキャンする方式ですが、やってみるとわかるんですがスループットが全然出ない。
これで問題になっていないのは、単に店に行列ができないからなのでは？という見立て。
少なくとも日本の朝や昼飯時のコンビニで使う気にはならない。どう考えてもNFC方式のほうが早い。
一方、昼食の会計など、スループットが気にならない場所であれば問題にならない。
慣れてきたら違うのかもしれない…？

QRコードにも良いところがあり、それはNFCのような距離の制限のない光学式であるということ。
僕が一番頭いいなー！と思ったのは、駐車場の出口で壁に1mくらいの大きさのQRコードが貼ってあり、運転席からそれをスキャンして支払いが可能だったこと。
タッチしたりする必要がないので車から出ずに窓すら開けずに出庫できるのはなるほどー考えたなー！という。

で、全てのインタラクションの出入り口がQRコードに集約されているので、町中の支払いとは関係ないQRコードでもとりあえずWeChatアプリで読み取る。
これは企業側としては検索エンジンを自分で作るのに匹敵する”良さ”があるな…と思った。

あと、weixinにはミニプログラムというのが組み込まれていて、要するに認証周りにちょっとチートのあるWebページ(と僕は理解している)で、ここから様々なプログラマブルな決済機能を提供することができる。
具体的に、ゲームセンターの会員サイトや飲食店での注文&決済機能など。
これはあると便利ですわ… 知らない企業に個人情報を渡す頻度が高いのでそこの抵抗感が多少あるけど…。

大変便利なスマホ決済経済圏なんですが、スマホが壊れたり不具合が起こったり電池が切れたりすると一瞬で人権がなくなります。
実際に、現地でアテンドしてくれたエンジニアの人が地下鉄に乗る時に改札でNFCが反応せずに10分くらい詰まってしまい、最終的にチケットを買っていました。
なので、スマホすら無しで決済できるのが最強かもしれない。セキュリティどうするのそれ。

雑にシェア経済について

Mobikeとofoなどの自転車シェアサービスにとどまらず、割りと色々なものがシェアされていてビビる。
傘やモバイルバッテリーや車などもその対象で、スマホの電池が切れると人権がないこの世界ではモバイルバッテリーのシェアは完全に人権が補給できる感じで強そうだった。
そして基本的に料金がハチャメチャに安い…。なんでも、”もってる奴”(＝企業側)が負担しろよ〜という空気感があるそうだ。

深センという土地

深センで使う必要がある言葉は3語だけで、weixin, xie xie(ありがとう), bye byeだけだった。
Yes/Noを中国語でなんというのかすら覚えなかった…。

華強北はざっくり20年前の秋葉原はラジオデパートみたいな雰囲気で、楽しそう。
春節のお尻のアタリにぶつかってしまったのであまり街が稼働してなかったんだけどこれは無限にウロウロしていられる予感がした。

わりと儲かっている地域であり、ここ数年は性善説で世界が回り始めているらしい。
実際にボラれそうになったこともなく、わりとみんな笑顔で怒っている人とかいないし親切ですごい。
いい土地。
上海行った組はボラれそうになったタイミングもあったそうで、運の差か土地の差か…？

現地でアテンドしてもらったofoのエンジニアの人と、企業訪問させてもらったCVTEの人達も、めっちゃ優しくて親切だし気前がよかった…。
この辺りの人はだいたいみんな英語できた。
その辺の店員さんとかの英語力は日本人のそれとあまり変わらなさそうだった。

その他

Googleピンイン入力はいいぞ

読めない文字を手書き入力できて最高。
現地の人にここに言いたいこと書いてくれ！って頼んでMicrosoft翻訳とかに突っ込む。
“あなた3回暗証番号間違えたのでこのカードロックされましたよ”って言われた時は泣いた。

クレカの番号6桁

なんか6桁らしいです。
普段の4桁の頭に00つけるとかお尻に00つけるとか色々あるっぽいのであらかじめ調べていきましょう。
基本的にはweixinでいけるので出番はあまりないですが…。

感想

深圳よいとこ一度はおいで。
他にも色々掘り下げられることはあったんだけど、既にここまで書くのに90分かかっているのでこの辺でやめておく。

参考

• ツアー中の #MTRSZX の様子
• 一緒に行った@tomoaki_imaiさんのレポート
• 深センまとめ Wiki