私が歌川です

@utgwkk が書いている

新しいスマホの購入を検討

iPhone 12 miniを買うことにしました。あとで新モデルが発表されてもそういうことだと思うことにします。

(追記ここまで)

スマホが壊れると普段の生活に支障をきたすので困る。今回は復活したからよかったけど、壊れる前兆を示したとも取れるので、今のうちに新しいスマホを検討しておく……。

このスマホ (Pixel 3a) を使い始めてから今日で573日が経過していた。1年と7ヶ月弱ぐらい。2年は持たなかったかー。

もともとは親にiPhone 7とかを買ってもらっていたのだけれど、これからは自分のお金で買いなさいということになって、最新iPhoneを買うほどの財力はなかったのでPixel 3aにした。iOSからAndroidに変えたら有償ポイントが引き継がれなかったり、モバイルSuicaの洗礼に遭ったりして大変だったけど、もう慣れた。

iPhoneに戻ってもいいかもしれないけど、またデータ移行について考えるのも面倒な気がする。しかしながら、iPhoneを使っていた頃は2年以上不自由なく使えていたので、長持ちを期待するならiPhoneのほうがいいのかなとも思いつつある。

とりあえず、ぼくがiPhoneを購入しようか迷っている段階で新モデルが発表されそうになっていたら誰か止めてください。

■

夢日記

中学校の卒業式が終わり、もう来ないからと各自が好き勝手に教室のロッカーに荷物を押し込んでいた。棚の上を見るとMIDIキーボードが大量に置いてあった。そんな中ズボンが見つからなくて教室中を探し回っていた。

すっかり暗くなってしまったと思ったけど、教室中の窓に段ボールが打ち付けられていた。他の人たちも戻ってきていて、ロッカーの中身やMIDIキーボードをくすねている。探し回っているうちにズボンをはいていることに気づいた。荷物を抱えて教室を出る。

吹奏楽部が練習してるので迂回して帰ってくださいと言われたけど迂回路が分からず怒られた。天井の低いすべり台みたいなところが正解だったらしい。荷物が引っかかるけどなんとか通った。廊下じゅうに生徒がたむろしていてスペースがない。

アパートの部屋のドアを通ると外に出られた。ここは4階だった。階段が見つからないので非常階段から下りることにする。すべり台になっていたので一瞬で下りることができた。

家の車が迎えに来ていたので飛び乗った。みんな目や精神をやられてしまった、という話を聞いていたら友だちが車に正面衝突してきて、危ない危ない！ って言ってたら目が覚めた。

/usr/share/dict/words をgrepすると意味のある単語がいっぱい出てきて楽しい

技術

i18nのリストが一発で出せます。

% grep -E '^i.{18}n$' /usr/share/dict/words
institutionalization
intercrystallization
interdifferentiation
internationalization

i10nガチャも簡単に実装できます。

% grep -E '^l.{10}n$' /usr/share/dict/words | shuf | head -n5
lubrifaction
labioversion
longshoreman
lepidopteran
lanceolation

ゼロトラストネットワーク

読書

ゼロトラストネットワークを構築する予定は今のところないけど、おもしろそうだったので読んだ。

ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計

ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計

境界ベースのネットワークセキュリティは侵入されると無力、というのはよく事例を見聞きしていたので実感がある*1。イントラネットは安全という前提を棄却したネットワークの作り方みたいな話。

ゼロトラストネットワークの事例の章を読むと、Googleには無限とみなせるリソースがあるのできました、ということがさらっと書いてある。魅力的に見えても所属する組織で実現可能かどうかはまた考えないといけない。一般にGoogleほどのリソースを持っていることはまずないと思う。

Googleはリソースによる制約を受けなかったので、従来のネットワークセキュリティパラダイムを葬り去るという壮大な目標に向かって突き進むだけでよかった。

*1:みなさまも毎月のように不正アクセスによる情報流出のニュースを目にしていると思う

APIについて考える機会があったので読んだ本

読書

新しくAPIを作るにあたって、REST APIとして作るイメージはすぐに付くけどGraphQL APIでも要件にマッチするかもしれないね、という話があった。GraphQLについてはインターンでちょっと触ったことがあるけど、概念をあまり思い出せなかったので入門しておきたいと思って本を読んだ。REST APIは知ってるつもりだけど知識の再確認をしたかった。

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

APIが人を左右するのではない… 人がAPIを左右するのだ!!*1

GraphQL APIを作るとなると、REST APIとは考え方が違うところがけっこうある。スキーマファーストでやっていく、という指針がはっきりしているのは良さそう。フィールドを指定して、関連するオブジェクトも一気に取ってくることで転送量を押さえられる、というのは魅力的に見える。

一方で、実際にAPIを運用するにあたっては負荷対策とかキャッシュ戦略について考えることになりそう。ぜんぶ POST /graphql みたいなリクエストになるので、従来のキャッシュ戦略とはまた違ったものが求められる？ 負荷対策については、クエリの深さやcomplexityの概念が確立されているのでひとまずそれに乗っかるとよさそうかな。

オブジェクトのフィールドのうち、取得コストが低いものと高いものがあるときにどうするべきか、というのが気になった。低いものはオブジェクトのフィールドにしておいて、高いものは別の型にしておくとそこで実装を分けられてすっきりする？ このあたりはもうちょっと手を動かしてみると分かりそうか。

Web API: The Good Parts

Web API: The Good Parts

Web API: The Good Parts

趣味のWebサービスでなんとなく自分が使う用のAPIを生やしたことはあるけど、実際のAPIはどうなっているか、を知るために読んだ。over HTTPでAPIを叩くのだからHTTPの仕組みに最大限乗っかるべき、というのは確かに、と思った。ステータスコードとかHTTPヘッダとか。GitHub APIを叩いたときはクライアントサイドキャッシュが活用されていた。

LSUDs (不特定多数の開発者) 向けのAPIは一般的に作るので不要なフィールドを引っぱってくることになりがちとか、フィールドを絞り込む工夫、というのも紹介されていた。このあたりは各自で工夫しているという感じに見える。

APIの仕様を変えられるようにバージョニングすべきとか、仕様変更の戦略の例もあっておもしろかった。非互換変更でユーザーを振り回さないための取り組み、という感じ。

これからWeb APIを実装する予定がなくても読んでおくとよさそう。既存のAPIのベストプラクティスを抽出して解説してくれているし、HTTPの仕組みへの理解も深まる。

*1:帯の文より

■

夢日記

家族でカラオケに行った。仕切りのない大きな部屋に案内されて、横にゲームセンターとかある。曲を入れようとしたら検索語句が3文字しか入力できないし、十字キーでカーソルを合わせて確定していくタイプなのだけれど、ひらがなが階段上に並んでて使いづらい。

部屋に家族連れが乱入してきて怒鳴っているので店員を呼びに行った。