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

えー、ポケモンSVが発売されて、祝うべき26日を4日ほどぶっちぎって30日でございます…。
我が家にゆかりさんが来て5年と数日が経ちました。
ざっくり8歳です。まぁまだまだお年寄りという感じでは全然ないですね。
ずっと元気でいてくれたまえよ…。

膝の上で顎をかいかいされるゆかり

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

様子

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

かいぬしの仕事ぷりを監視しているゆかり

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

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

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

怠惰な姿勢でお水を飲むゆかり

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

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

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

猫グッズ

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

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

猫を飼いたい人へ

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

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

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

我が家にゆかりさんが来てちょうど4年が経ちました。
ざっくり7歳です。猫的にはそろそろシニアと呼ばれてもおかしくない年齢になってきました。

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

かいぬしにヘッドホンスタンドにされてしまったゆかり

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

様子

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

わっしと掴まれ やめ ってしているゆかり

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

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

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

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

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

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

ここ暖かいしかいぬしが困るしお得な場所なのよしてるゆかり

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

伸びをしてから膝に向かおうと思っているゆかり
超貴重な膝の上で裏返し（普段は嫌がる）になってるゆかり

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

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

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

猫グッズ

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

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

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

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

Catlog Board

Catlog Boardの空き箱は遊び場になる設計なのだ！

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

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

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

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

猫を飼いたい人へ

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

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

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

我が家にゆかりさんが来てちょうど3年と1日が経ちました。
うっかりブログ書くのが1日遅れてしまった…。
ざっくり6歳です。おおむね3歳くらいだろう、というとこでうちに来たので、そろそろ半生をうちで過ごしていることになりました。

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

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

かいぬしの作業をおじゃまするゆかり

様子

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

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

おこゆかり(最近の写真じゃないけど)

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

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

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

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

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

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

猫グッズ

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

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

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

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

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

猫を飼いたい人へ

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

かいぬしと目があったゆかり

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

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

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

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

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

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

ゆかりさん(猫)の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での後日販売なども行うと思います。

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

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