『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/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 さんに言われたので書かれました。

技術書典4で『Re:VIEW+CSS組版やっていき』を頒布します

はい。
明日が技術書典4当日なのであまりにもギリギリすぎるブログです。

ひかる黄金わかめ帝国 サークル詳細ページはこちら。
当日は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さんにも次のお言葉をいただきましたし、やっていきだと思われます。

なお、この本は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分かかっているのでこの辺でやめておく。

参考

猫が我が家に来た話

丁度1ヶ月くらい前の11/26に、我が家ににゃんこがやってきました。
猫飼いたい飼いたい言ってたけど正直積極的姿勢ではなく、消極的猫飼いたいでした。
とかいいつつ去年の12月に引っ越した時にペット可物件を選び敷金もデフォで1月分積み増していました。
口ではなんと言っていても財布は正直だな…！

猫データ

項目 値
名前 ゆかりさん
年齢 3歳？(1歳以上は確定)
体重 3.5Kg
品種 ノルウェージャンフォレストキャットとラグドールのMIX
見た目 ハチワレ（かわいい）

のり子だなんだと名前案が提出されましたがゆかりさんになりました（VOICEROID並感）。
Twitterだと「ふわふわちゃん」とツイートすることが多いですね。
靴下はいてておめめくりくりでふわふわでちっちゃくて可愛い！

様子

来た当初は夜はベッドに乗ってくるにゃんだったゆかりさんですが、僕の寝相が悪かったのに懲りたのかベッドに乗らないにゃんになりました。
避妊手術から帰ってきたあたりから再度ベッドに乗るにゃんと化したふわふわちゃん。
夜寝てる間に蹴っ飛ばさないように、ベッドに斜めに寝るという対処法を編み出しました…。

カラーと包帯をつけてた間は動きが不自由なのでベッドの上にいることが多かったんですが、元気になったらまたキャットタワーの上にお帰りあそばされました。
な、撫でさせてくれぇ……！！

あと過去のツイートをまとめてお茶を濁す！

11/19

面会しに行く。
行く前からこの子がいいかなー、と目星をつけていた。
写真から生後半年枠の子だと思っていたけど3歳くらいだそうな。
子猫はちゃんとお世話できるか自信なかったので丁度エアロ！という気持ちになる。
引き取る事を決め、ひたすら猫グッズを買い集める。

11/26

ふわふわちゃん来る。
引き取りに行ったら自分からケージに入ってくれて嬉しかった。
ペットタクシーで自宅へ。
自宅に来たら割りとすぐにケージから出て部屋を一周探索する。
肝が太い子だなぁ…！と思った（後にそうでもないことがわかる）。

最初からトイレも爪とぎも道具がある場所で適切にできる、躾のいい子で大変楽でした。

11/28

12/02

12/03

12/06

12/09

12/10

12/12

12/13

12/15

12/16

12/18

12/19

なお、この日に避妊手術で入院でした。

12/20

退院。カラーと包帯がストレスなようで可哀想…。
12/26に全てが終わる！

12/24

12/25

一昨日くらいからお腹がピーなので病院に。
注射を打ってもらって飲み薬をもらう。
猫 飲み薬 で検索してみんな絶望しよう！（ちゅーるにお薬載せたら簡単に全部ペロンと食べて杞憂に終わった）

12/27

お薬をまだ飲ませているんだけど、ちゅーるの部分だけ舐めて錠剤をペッ！てする技術を身に着けはじめました。つらい。
ちゅーるでコーティングしていいタイミングで舌の奥に送り込むテクが必要になってきました。

備忘録

わかめさんは大変な心配性かつ保守的人間であるため、にゃんこを飼う前後の心労が激しかったです。
現在、避妊手術の後の包帯&カラー期間なので心労が激しいままです。
来年はもうちょっと心安らかに暮らしたい…。

  • 猫がやりたいことを制限するのはほぼ不可能
    • 行ける所は全部行く！
    • 台所には侵入できないようにしていたが小窓から突入していくのでドアフルオープン化
    • 台所のシンクに突入していくことがあったので台所が常にキレイな状態で保たれるようになった
  • 1週間程度ではまだビビられまくり
    • いかに構わずに放置するかに腐心するフェーズ
  • 1ヶ月程度ではまだ慣れない
    • ちょっと抱っこしたり撫でたりすりすりしたりは平気になった
    • 向こうからすりすりしてきたりはしない
  • 食べ物はあまりちょいちょい変えないほうが良さそう
    • どんな時でもちゅーるは喜ぶ
  • 食べたり飲んだりしてる間はある程度元気な証拠
  • 健康面（ほぼ済）
    • FeLV/FIV陰性
    • 三種混合予防接種
    • 血液検査問題なし
    • 避妊手術
    • マイクロチップ
  • ペットタクシー
    • ワンハウス 動物病院にチラシがあったので利用 Webサイトもうちょっとなんとかならん？
  • ペットホテル&ペットホテル
    • おなじみの猫カフェ ねこまるカフェがサービス提供しているそうなのでいざとなったら…
    • 移動は猫に負担になるので基本はホテルよりシッターさんを頼む方針

猫グッズ

買ってよかったものを抜粋して紹介。

トイレの質が改善された（気がする）。

流れる水がお好きらしい。

あまりご飯を食べないのでどのくらい食べたかの把握に必要。

比較的省スペース。
猫は広さよりも高低差のある運動が必要だそうで。

とりあえず1冊買って勉強。

一番よく遊んでるおもちゃ。

二番目によく遊んでるおもちゃ。一人で遊ぶのが好きで、僕が手に持って遊ぼうとするとすこし及び腰。

大変使い勝手のよいケージ。
普段は入り口のドアを外して部屋の中に置いてあります（たまに入ってくつろいでいる）。

トイレ掃除に。これに入れて縛って捨てると匂いがまじで漏れない（すごい）。

トイレまわりの清掃に便利。

トイレ。シートは週1、砂は月1の交換で全然臭わなくてすごい。
お腹がゆるくなると砂が一瞬で減っていくので買い置きは潤沢に…。

一番お気に入りの爪とぎ。

ご飯茶碗。ちょっと端っこに残ったのが食べにくいっぽい…？

毛がもさもさ取れる。一般的なブラシも試してみたけど、こっちのほうが圧倒的に取れる。
あまり使わせてくれないけど…。気持ちよくはあんまりなさそうな気がする。

最後にほしいも貼っておきますね！（ただし贈ってもらっても恩を3時間で忘れるタイプの雑魚）

きっかけ

色々な要因がありお見合いしにいき、可愛いやん…！ってなってしまったため無事引取…という流れになりました。
ふわふわちゃんかわにゃんオブジイヤーじゃない？