思ったよりつらい
2025年が明けて早々、コロナとインフルにダブルでかかってしまった。
年始にディズニー地方に出掛けたのだが、帰ってきたあたりでまず我が家の乳幼児の調子がおかしくなった。通院してみるとコロナとインフル両方が陽性だった。タミフルだとか熱冷ましだとかであっという間に復調したように見えてそれは良かったんだけど、案の定というか、その後は家族の体調がおかしくなっていった。それはね、濃厚接触しておるからね。やむなしではある。
自分はしばらくピンピンしていたのだが、家族のみんなが復調するころになって急に体調がおかしくなった。明日から仕事というタイミング、1/13 のことである。
1/14 の朝イチで通院し、コロナとインフルの検査 (鼻に棒を突っ込まれるやつ) をしてもらった。コロナの検査は鼻の入り口あたりだからいいんだけど、インフルの検査は鼻の奥のほうまで棒を突っ込むんだよね。つらい。やめてほしい。涙が出てくる。「あっ、でもいい鼻なんですんなりでしたよー！」って言われた。喜ぶところか？
で、結局どちらも陽性でありまして、薬をいっぱいもらって養生しているところ。熱はそこまで高くないのだが、とにかく節々が痛む。特に腰が痛む。座ってても寝てても痛む。元からそうだったか？いや、きっと熱のせいだ。
年初にアンラッキーということは、今年の残りは全部ラッキーと信じる。悪霊退散悪霊退散。
10年前の PC を復活させる試み
ちょいとコードを書くためのラップトップがほしくなった
子守でまあまあ忙しい日々を送っており、この 2 ヶ月ほどはコードも書かず、なんなら PC に触りすらしない生活を送っていた。ちょいちょい iPad で本を読むくらいのことはしているが、技術書を読めばサンプルコードが出てくるわけで、サンプルコードが出てくるならばちょっと自分で書いてみたりもしたくなってくるわけである。しかし忙しい。ならばどうするか。
ということでスッとスキマ時間でも使えるラップトップが欲しくなってきたわけである。ちょいとコードを書くくらいならば昨今は GitHub Codespaces なんていう便利な代物があるわけで、だったら OS は Windows でも Mac でも Chromebook でもなんでもいいってことになりそう。
Chromebook でいいやって思ったが英語キーボードな製品がない
だったら安い Chromebook がいいだろうってことで調べてみたんだが、どういうわけか英語キーボードな製品がほぼ存在しないということが分かってきた (2024年3月時点)。輸入すればある。けど、サポートとか返品とか修理とかのことを考えると、やっぱり輸入ではなく普通に購入したい気持ちがある。
Windows でもいいやって思ったけど鬼高い
英語キーボードじゃなきゃヤダ！ってことで試しに Microsoft の Surface シリーズなんかもちょっと確認してみたんだけど、英語キーボードが選べる機種を選んで実際に英語キーボードを選択してみたら30万円くらいのお見積りになってしまってだな。30万って。ちょいとコードを書くために30万はちょっと。
Sony Vaio Pro 13 に ChromeOS Flex を入れてみたけど割と戦えそう
ところで Chromebook は、昨今のデバイスでもメモリ 4GB がメインストリームっぽい。8GB っていうとちょっといいヤツっていう雰囲気。そういえば 10 年前に買った Sony Vaio Pro 13 (英語キーボードにカスタマイズしている) がメモリ 8GB だったことを思い出し、こいつに ChromeOS Flex を入れたら案外快適にイケるんじゃない？なんてことを思いついたのだった。
たしかこれ。メモリは 8GB、SSD は 512GB にカスタマイズしてある。ChromeOS Flex はスクショも撮れる…！
インストールはすんなり済んだ。フル充電して電源をつけてみると「残り4時間」という表示。10年選手だしバッテリーがへたっているのは当然であろうが、とはいえまあまあか？YouTube で 1080p の動画を 20 分くらい流してみたところ、残り時間は 2 時間という表示になっていた。ヘビーな使い方をせず、GitHub Codespaces でちょいとコードを書くくらいなら十分に役割を果たしてくれそうな気がしてきた。
自分にとって ChromeOS Flex の便利ポイント
- 軽い仕事ならサクサク動く。ブログ記事を書くだとか GitHub Codespaces 使うだとかには不便しない。
- 起動も早くて、電源ボタンを押してからおよそ 7〜8 秒くらいでログイン画面にキー入力できるようになる。
- ツイッターもサクサク動く。
自分にとって ChromeOS Flex の不便ポイント
- Android アプリは入らない。
- 本物の ChromeOS を使っているならば Android アプリが入るらしい。ChromeOS Flex はパチモンなので (?) Android アプリが入らないようだ。
- Kindle アプリが入れられないので、Kindle したかったら必然的に Cloud Reader を使うことになる。が、Cloud Reader はパーソナルドキュメント (オライリーや翔泳社で買った PDF を Send to kindle したもの等) が読めなくて自分にとってはだいぶ微妙である。
- Firefox やら Vivaldi やらのお好みのブラウザも入れられないこともない。Linux 版があればインストールできるようだ。が、ちょっと挙動が怪しくて文字やカーソルがぼやけていたりする。まあ Chrome 使えってことなのかもしれない。
Sony Vaio Pro 13 (10年前の PC) の不便ポイント
(個人の感想です。公私に渡って数年使い込んでいる PC です。)
- 画面が汚い。画面を閉じるとキーボードと画面がこすれるタイプのデバイスなんだよこいつは。
- 電池がヘタっている。
- キーボードが汚い。使い込みすぎていて手垢がきつい。
- USB は Type-C などというものはない。USB の穴がでかい。
- 充電は専用のケーブルとアダプターが必要。USB Type-C で充電することはできない。
- 画面がしばしば瞬間的に暗転する。チカチカすると表現するのがいいだろうか。もう限界なのかもしれない。自分がまばたきするくらいの頻度でこいつもまばたきする。
ということでしばらく使ってみよう
ユースケースさえ合えば ChromeOS Flex を化石みたいな PC に突っ込んで遊ぶのは有力な選択肢になりそうだよ、という話でした。あとはなんだ、Geforce NOW も ChromeOS Flex 動くらしい。2024年4月4日に NVIDIA 版の Geforce NOW がサービス開始するような気配があるので、時がきたらちょっと試してみようかと思う。キーマウがまともじゃないこともあり (特にマウス部分はタッチパッドである)、まったりゆっくりしたゲームならなんとか遊べるのかもしれないね？
ヘアドネーションをやってみよう！ということで 2021 年 6 月から髪の毛を伸ばし始めておよそ 2 年が経過した。ほったらかしにしとくだけなんだから楽な挑戦だろうと思っていたのだが、まあまあ面倒な気持ちになりつつある。とはいえまだ頑張る。
何がつらいって
つらいことを書いてみる
お風呂編
- シャンプーするのがつらい。ワンプッシュでは泡が立たないぞ
- 抜け毛がすごい。髪の毛の長さで抜け毛の量が変わるかっていうとよく分からないが、シャンプー後に排水口に貯まる髪の毛の量を見ると割と引く (長いので目立つのだと思う)
- お風呂からあがったあとのドライヤーがつらい。なかなか乾かないぞ
- 特に夏場がつらい。汗だくになりながら髪の毛を乾かしている
日常編
- 風呂場でなくとも抜け毛がすごい目立つ。そのへんにいっぱい落ちてる。割と引く
- 風に吹かれた髪の毛がちろちろ目の辺りを刺激してたいへん鬱陶しいぞ
- 後頭部で束ねる (ポニーテール的な) ようにしても、ヘアゴム一個では耳の上あたりの髪の毛が束ねきれなくて結局髪の毛がちろちろ目の辺りを刺激して大変鬱陶しいぞ
- これらを解決するために風上に顔を向けることが多くなるぞ
- さらにこれらを解決するためにバンダナを巻き始めたが、家内や同僚からあんまり評判がよくないぞ
- 夏は何割増しかで暑いぞ
逆に嬉しいこと
ない。はやく丸坊主にしたい気持ちでいっぱいだ
とはいえ
2 年も伸ばしたので、ここまできたら一応達成を迎えたい気持ちではある。もう少し頑張ろう。
もう少しといってもおそらくあと 3 年は伸ばさないといけないのであるが。まだ折り返しですらないと思うと気が遠い。
梅雨になったら雨がいっぱい降るんだけど、傘をさすと濡れなくて便利。
ところで shupatto というメーカーが出している傘があって、これはどうも閉じるときに留め具を使わなくていいらしい。
https://marna.jp/product/s498/
傘を閉じるときにきっちり閉じようと思うと、くるくるって巻く必要があって左手がびちゃびちゃになるっていう一面があるよね。そもそも雨ってそんなに清潔じゃない気もするし、できれば雨で濡れた傘って触りたくない。あれが起こらないっていうのは結構文明開化なんじゃないかっていう気がする。
傘ってすごい盗まれるもんだと思っていて (たまたま自分ちの周りがスラム街みたいな治安なのかもしれないが)、その点、この傘はちょっとお値打ちなので買うかどうか迷っちゃうわね。あと自分は結構電車の中に置き忘れるみたいなことも多いので、あわせて「なくさない仕組み」を入れられたら買ってもいいかなーなんて思っておるところ。
これがあれば雨の日のお出かけもウキウキ気分かもしれないね！
誰だただの風邪とか言ったやつは
Covid-19、いわゆるコロナに掛かった
2023-01-04 あたりに旅行に出掛けたんで、そこでもらったとする説が有力かと思う。2023-01-07 (金) の夜あたりから熱が出始めて、土日を過ぎても治ってこない感じ。そんでこれはってことで検査キットを使ってみたら「陽性」であったという流れ。陽性が判明したのは 2023-01-10 (月) のことであった。
なかなか治らん
これを書いている 2023-01-13 (金) AM 現在では平熱に戻ったが、昨日までは 37.5 度から 38.5 度くらいをずっとウロウロしていた。かれこれ 7 日くらい発熱し続けたようである (途中で市販の解熱剤を飲んだりもしつつ)。こんなに長く発熱が続くのは、幼少の頃を除けば初めてな気がする。ずっとかったるくてなかなかしんどかった。
症状
出た症状はいわゆる「風邪症状」だった。
- 熱が出る
- 喉が痛い (← なにげにこれがとても痛かった)
- 鼻水が出る
- 咳が出る
コロナに掛かると「ごはんの味がしなくなる」っていう話とか、あと「ブレインフォグ」になるみたいな話も噂に聞いたことがあった。しかし今回の自分にはこの手の症状は出なかったようだ。たまたまラッキーだったのかもしれない。
妻も子も「陽性疑い」であったものの (市販の検査キットを使って陽性になると「陽性疑い」になるようだ。ちゃんとした検査じゃないからバッチリ陽性！とは言えないって話かな)、症状にはだいぶ差があった。子は一日くらいの発熱を経て割とさっくり平熱に戻り、妻に至っては多少の喉の痛みがあったものの発熱することもなかった様子。つまりまあ、普段の生活でどんだけ免疫力を培っていますかって話かもしれねえな…。
何がツライって
発熱しているもんだから寝て過ごすんだけども、自分のような腰痛持ちは寝続けていると「腰が痛くなっちゃう」わけで…。痛くなってくると横になっているのもしんどいので縦になるしかないんだけど、熱出てるもんだから縦になってんのもツライというね。どうなってりゃいいのか分からん。最終的には椅子に座って寝たりしていた。
寝たきりするのも、腰痛のない健康な体が必要というのが分かったのが今回の教訓であった。日頃からちゃんと運動しような…！
どこにも書いてない気がしたのでひとまず備忘録として残しておく。Rancher Desktop で host.docker.internal みたいなことがしたいときは host.rancher-desktop.internal を使えばいい。
Rancher Desktop
Rancher Desktop というのがあり、これは自分の PC 上に k8s 環境を構築できるという代物。 必要な k8s manifest が揃っていれば割とサクッと自分の PC をノードに見立てて pod を生やすことができる。便利。
Rancher Desktop
https://rancherdesktop.io/
pod 上からホストと通信したい
docker であれば container 内から host.docker.internal に対して通信することで container はホストマシンとやりとりすることができた。これは container 上の特定の通信をホストでプロキシしたい時などに便利だった。
Rancher Desktop においてこれと同等のことをしたい場合は host.rancher-desktop.internal を使えばいいようだ。ソースは Rancher Desktop の Slack チャンネル。Slack チャンネル内を host.docker.internal みたいな単語で検索していたら発見した。試したらちゃんと動くことを確認した。
補足
この情報は公式ドキュメントには載ってないような気がする (2022-04-28 時点)。自分のググり力の問題かもしれないが、ちょっとググッたくらいでは出てこなかった (どっかに書いてあったらすまぬ)。
2022-04-28 の時点では host.rancher-desktop.internal というアドレス指定が動作することを確認した。動作確認した環境は 2019 年の Mac Book Pro、Intel な CPU、OS は Monterey。あと Rancher Desktop の設定でコンテナランタイムに containerd を選択していた。使った Rancher Desktop は v1.3.0 だった。
2021年はどんな趣味で人生を楽しんだのかを振り返ってみる。
書くこと
- 技術書典で Engineering Manager に関する本を書いて販売した。書くのはしんどかったが、とはいえそこそこ書くことを楽しめることが分かってきた。執筆にはまたトライしていきたい。
- ブログは GitHub issue をブログ記事に変換する仕組み & しばらく書いてなかったらリマインドする仕組みを作ってからいくらか書きやすくなった。今年は 10 記事くらい書いたかしら。昨年よりは進歩してそう。
- 読書ノートを書き始めた。続くか不明。
作ること
- ゲーム作るっていってちょっと作ったっきり放置している。なんとなく動くところまではできてると思う。まだ作る気はあるので再開しよう。
- ToDo 管理アプリの hashira をウェブからもとりあえず使えるようにした。いくらか我慢すれば普段使いできるような気はしている。割と便利。UI がへぼいのをちょっとずつ直していこう。
文を読むこと
いくらか読んだ中で印象に残ってるのをピックアップしてみる。
- 認知症世界の歩き方
- 認知症の人への理解が深まったような気がしないでもない。認知症の人に限らず、人間の認知は人それぞれ違っていて、人それぞれの世界があるんだなーということに思いを馳せた。
- 同志少女よ、敵を撃て
- 女性でスナイパーで凄腕で、みたいな設定だけでテンションあがってくる話だった。似たようなのもっと読みたくなる。
- 君はポラリス
- 同僚が読んでたので自分も読んでみよって思って読んだ本。恋愛？小説の短編集。どれも良かったが、犬の話が一番気に入った。
- ドラッカーのマネジメント エッセンシャル版
- マネジメントってそもそも何なんだろな、みたいなことを思って手にした一冊。知りたいこといっぱい書いてあったという印象。また読み直したいと思うが、やや読みにくい文体だったなーという感想もある。unless いっぱい使われてるソースコードを読んでる気持ちになる文体だった。
- リーダーの仮面
- 読んだのを忘れてて二回買ってしまった。僕はそんなに仮面が気になるんだろうか。
観ること
こちらもいくらかピックアップしてみる。
- シドニアの騎士の映画
- 原作改変してたけど良かったと思う。何かをやるたびにいちいち長々とした発射シーケンスが挟まるのが最高だった。
- 鬼滅の刃の映画
- 興行収入がエグいことになってた。よもやよもやだ。
- ジョジョ 6 部のアニメ
- ジョリーンの「ぬぁんなのよくぉれわーー！」がとても良い。プリキュアと同じ声優とは思えない。
- ダンダダン
- ジャンププラスで連載中のマンガ。連載の中ではいま一番楽しみにしている。ジャンププラスでは忘却バッテリー、左利きのエレン、ゴリラ女子高生あたりが推し。
遊ぶこと
つまりゲーム。今年やった中でいくらかピックアップ。
- Oxygen Not Included
- 面倒なゲーム。その面倒を自動化して快適にするのが楽しい。ハマる。何日か徹夜させられた。
- 7 days to die
- ゾンビをシバくゲーム。最近は鉄砲でゾンビを倒してもあんまりシバいてる感じがしないので、もっぱら鈍器かショットガンを扱うようにしている。
- メトロイドヴァニア系
- 横スクロールアクションゲーム。月風魔伝、デッドセルズ、momodora、Bloodstained、ENDER LILIES などに手を出した。Bloodstained がもっとも馴染んだけれどもクリアしたらそれまでなので、そう考えると長く遊べるのはローグライク系である月風魔伝かデッドセルズだなー。
- 真・女神転生5
- 2021年11月に購入。その後の可処分時間はほとんどこれやってたと思われる。年内には何とかクリアできた。プレイ時間は 50 時間くらいかな？妻は 120 時間くらいやり込んでて強い…。
- いままでの女神転生に比べるとストーリーにそれほどエグみがない気がして、少し物足りないようにも思う。戦闘や悪魔合体はとてもオモロい。まだしばらくやれそう。
- 鉄拳
- ほぼやってない。そんな日がくるとは思ってなかった。会社の帰りにゲーセン寄るっていうムーブが封じられてしまったからやむなし。
その他
- 髪を切ったり伸ばしたり
- 人間に髪の毛は不要では？と思い立って坊主にしたのが 2021 年の 6 月。しかしその後、自分は髪の毛いらないかもしれないが、世の中には髪の毛がほしい人はたくさんいるよな、とも思った。ということで一転して髪の毛を伸ばし始めた。目標はヘアドネーション。30 cm (だいたい 5 年間) くらい伸ばすとヘアドネーションできるらしい。ひとまず半年は切らずにこれているが、すでに髪の毛が鬱陶しい気持ちなので断念する可能性はある。
- せっかくなので、ある程度伸びたらまたパーマでもあてて楽しもう。パーマあてたりしても過度に傷んでなければヘアドネーションは可能らしい。
まとめ
ちょっとマンガの発掘が足りないな？と思うがしかし来年の目標は来年立てよう。
見るからにアレな感じがしてしまうタイトルだが、割と悪くなかったのでちょっとメモしておく。
アマゾンをぶらぶらしてたらたまたま目に入ってしまった一冊。曰く、「本を読んだそばから内容を忘れてしまうでしょあなたー！」とのこと。ホントにそのとおり。自分が今年何冊読んだのか、何を読んだのか、なんならオススメは何か、って言われてもすぐ出てこない。
自分としては、本の内容をつぶさに覚えてなくても、何となくエッセンスを吸収して血肉になってるだろうからまあ良かろう、くらいの気持ちでいた。しかしこの本は「そういうなんとなくな読み方ではエッセンスは吸収されてないぞ」と言い切っている。そうかー、まあそう言われればそんなような気はするが、そうかー。
それで、この本では「読書ノート」をつけるとより一層本の内容が記憶に定着していいぞ、と言っている。大仰なものは書かなくてよくて、何月何日に何を読んで何を思ったー、くらいのことを書けばよいと。
確かに、感想を書こうと思ったら読了後にもう一度要所を巡る必要があるかもだし、気になったところを引用したりちょっと気分を言語化したりするのに頭を使う必要もある。この手の営みはただ読むより少し能動的な本との向かい合い方になるような気がする。手を動かすとよく覚えてられるってのも体感的には分かる。ちょっとした感想でよいっていうのであればそんなに大変じゃなさそうだし、やってみてもいいかもしれない。あと単純に「俺ってあのときどんな本を読んでたっけ…」というのを後から見返すのは面白いかもしれないとも思う。
読書ノートの要件
紙のノートが良いという話だが、ノートやペンを常備しておくのも大変なので、やはりここは IT に頼りたいところ。なんか都合の良いツールはあるか。
読書ノートの要件としては、
- だいたいいつも決まったフォーマットで書ける (日付、タイトル、著者、出版社、感想文、くらいか)
- 画像貼れる
- あとから検索したり一覧できると良い
- 続けていくためにはとにかく手軽に追記編集できると良い
このへん。こう見るとテンプレートを添えた GitHub issue でも良さそうかって気がする。手軽かって言われるとやや重い気もする？けどとりあえずやってみてから考えようと思った。
ということでリポジトリを作ってみた。続くことを祈る。
https://github.com/pankona/reading-note
2021-12-15 追記
先述のリポジトリに、近頃読んだ本をいくらか issue として書いてみたが、なんとなくこれじゃない感を感じてしまった。登録しにくいということはないが、なんというか、なんとなくぱらぱら見返すのには適さないなと思った。ツイッターのタイムラインみたいな見た目で見れると良さそうな気がする。
GitHub issue とってきてタイムラインみたく表示する機能なんて聞いたことないが、どっかにすでにそういうのあったりするかな…？なければ簡単にそういうものを自作してもいいかもなー。
2021-08-28 (土) にコロナワクチン一回目を接種した。ちなみにファイザー製。副反応の記録を軽くしたためておく。
やや雑だが時系列的には以下のような感じ。
2021-08-28
- 14:00 接種を受ける
- 14:30 出掛けたついでにラーメン食う
- 15:00 出掛けたついでに本屋に立ち寄る
- 15:30 帰宅。まだなんともない
- 19:00 なんとなく接種した肩のあたりが痛む気がするが騒ぐほどでもない
- 21:00 寝る
2021-08-29
- 7:00 起床。だいぶ肩が痛いことに気付く
- 鼻水がちょっと出る。あと多少の倦怠感。熱は平熱。
- 外出予定があったけど取りやめ。一応静かにしておくことに。
- 一日中こんな感じだった。良くなりもせず悪化もせず。
2021-08-30
- 7:00 起床
- 肩の痛みは和らいでいた。
- しかしこの段にきて発熱し始める。37.5 度くらい。
- 鼻水だとか関節が痛むだとかの風邪っぽい症状あり。
- 働こうかなーとも思ったがあんまり集中できる気もしないので休みにしといた。
- 12:00 熱が 38 度くらいになる。
- お腹が減ったので納豆ご飯を食べる。うまい。
- かったるいので寝続ける。
- 16:00 熱が引く。36.5 度くらいに。
- とはいえなんとなくかったるいのは続いていたので、引き続き寝っ転がって過ごした。
- 19:00 症状らしい症状は概ねなくなる。
- ご飯を食べてシャワーを浴びる。
- 20:00 寝る。
症状が、遅れて、やってくるぞ
ワクチン接種から初日と二日目が大したことなかったので安心していたら、三日目で発熱してしまい、予期せず仕事に差し障るような事態になった。なんとなく筋肉痛のノリで考えていた (一日遅れでやってくるみたいな) ので、あ、割と長いこと影響出るのねーという感想。
肩が痛むとか発熱するとか書いたものの、倒れて動けないようなレベルの体調不良でもなかったので、副反応の出方として大したことない部類に入るんだろう (聞くところには熱が 40 度くらい出たみたいな話もあるようだし) 。よかった。
二回目の接種は三週間後。二回目のほうが副反応が強く出るみたいな話も聞くので、ちゃんと対策して臨むぞ。
プルリクエストのレビューは業務で日常的に行っているのだが、時々レビューがとても難しいと感じる場面に出くわすことがある。そんなときどうするか。
何が難しいのか
僕がレビューすることになるプルリクエストの概ねは、同じチームで働いている人々が出してくるプルリクエストである。普段から同じドメイン領域で仕事をしているチームなので、出されるプルリクエストが「全然意味分からん」みたいなことは割と少ない。
少ないんだけど、しかし、時々普段のドメイン領域をはみ出すようなプルリクエストが提出されることがある。そうなると急に土地勘がないというような感覚になる。全然意味分からん。まともなレビューができる気がしない。とはいえこういったものも限られた時間の中でレビューせねばならない。どうする。
こういう難しいレビューが課せられたとき、どういう手が取れるか、あるいは取ってきたか、というのを考えてみた。
パターン 1. 斜めに読んで LGTM
良くないと思いつつやっちゃうことがある。それなりに読みこんでいけばなんとなく分かるときもあるが、それにしたってもう少し効率いいやり方、特にちゃんと品質に寄与しようと思ったら良いやり方があるよね、って思うところ。他にもレビュアーがいるときなんかに起こりがち。甘え。戒めとして言語化しておく。
パターン 2. 書き手に解説を依頼する
だいたいの場合、プルリクエストについて一番詳しいのは書いた本人である。書いている本人はプルリクエストを提出するために様々な調査を重ね、コードベースを熟読し、既存機能を壊さないよう気をつけながら編集している。そりゃー詳しい。なので書いた本人に解説してもらう (文書ではなく口頭のほうが良かろう) というのがこれ。同期的なコミュニケーションになる場合もあり、場合によっては資料の準備なんかも必要になり、あとは複数人数が一緒に解説を聞くとするとスケジュールの調整も必要になり、ということでややコストは高い。あと解説をしてもらっても、プルリクを書いた本人ほどの理解を得るのは難しいという一面もある気がする。
だけど、後々そのコードベースを自分やチームメンバーがメンテナンスしていくことを考えたら、ちょっとでも理解度を上げておくというのはコスパ良いということになるかもねーと思わないでもない。ただ、手間を考えるとやや気後れする案のようにも感じている。
パターン 3. 動かす
コードレビューじゃないじゃん、って言われたらそうなんだけども。読んで分からないのであればとりあえず動かす。
実際にプルリクエストのコードを手元にもってきて動かしてみて、期待通り (仕様通り) に動いているか確認をするというのもある意味ではレビューであると思う。動かしてみて実際の振る舞いの確認した後にふたたびコードレビューに戻ると理解が進む、みたいな場合もある。ドメイン知識が不足している部分であるという前提にたつと、そもそも UI 上のどこに反映される変更なのか、ということすら理解があってないこともある。期待動作についてプルリクエスト上で認識合わせをするのも良い。確認した期待動作についてプルリクエスト上に記載しておけば、将来的に期待動作が不明になったりしたときに、もしかしたら考古学としての役目を果たす可能性もある。
とはいえやっぱり難しいものは難しいので諦めも重要
とはいえ分からないものをきっちりレビューするのは難しいことに変わりない。やや無責任かもしれないけれど、時には諦めて先に進もう、やむなし、というくらいのメンタリティでいないとツラくなってしまうような気もする。
今年こそはいっぱいブログ書くんだって宣言するのはいいんだけど、結局なかなかコンスタントに書き続けることができず、気付いたら半年過ぎているみたいな人生を送っている。ので、それを打破すべく「最後にブログを書いてから n 日過ぎました」というリマインダーを仕込むことにしたんだ。
こんなようなリマインダーがくる。
仕組みは以下。
- 最後にコミットした日時を git log を使って確認する
- 所定の日数過ぎていたら (7日間とか) Slack に通知する
- ここの最終投稿からの日数計算は Go で CLI を作った
- GitHub Actions で cron job を仕込み、毎朝 7:00 に確認するようにする
できたものはこれ。ちゃんと動いている。
https://github.com/pankona/pankona.github.io/blob/hugo/.github/workflows/notify_long_time_no_see.yaml
そもそも人間 (自分を含む) を信じるな
去年の自分は「ブログをいっぱい書くぞ」って気合を入れたっきりそれで終わりだった。記事は生えてこなかった。
そもそも、ブログをいっぱい書くぞって気合を入れただけでどうしてブログ記事が生えてくると思った？っていうことである。なんとブログ記事は書かないと生えてこない。書かねばならない。そして人間は書くのを忘れるし、書くことを思い出したとしてもネタがないだの時間がないだの言っていったん頭の片隅に追いやってしまい、そして一晩寝たら忘れている。気合だけで達成しようというのがそもそもあまりにも脆弱であった。
ということで、やはりマシンに頼らねばならない。こういうリマインドの類などで圧をかけるような仕事はマシンにやらせるに限る。そして GitHub Actions が cron job の役目を果たしてくれるのは本当に便利。これで今年こそブログをいっぱい書くんだ！
GitHub issue をブログ記事に変換する仕組みを GitHub Actions を使ってこしらえてみた。
できたもの
背景
本ブログの生成には hugo という静的サイトジェネレータを使っており、基本的には PC を使って執筆、生成、デプロイまで行うような建付けで運用している。が、ときどきスマホで記事が書けなくて不便だなーと思うことがあり、うまいやり方はないものかと考えていた。
うすらぼんやり考えていた要件としては、
- スマホでちゃちゃっと記事が書ける
- マークダウンみたいなもので書くことができる
- あわよくば既存の記事を後から編集できる
みたいなもの。
hugo には、たとえばワードプレスについてるような管理画面がない。Netlify CMS みたいなものを使うと管理画面をこしらえることができるようなことが書いてある気がするけれど、それを運用するのもまた面倒だし、もうちょっと簡単に済ませらんないかなー等と考えていた。
GitHub issue をブログ記事に変換するというやり口
ふと、GitHub issue ならばスマホで何となく書くことができ、しかもマークダウンであり、何なら画像貼ったりもできるし、というので要件を満たすものに近いんではないかということに気づいた。なんならもう GitHub issue をそのままブログですって言い張っていく線まで考えたが、せっかく hugo あるし、うまい具合に “GitHub issue をブログ記事に変換” できたら便利かもなー、ということでちょっと作ってみた。本記事もさっそく GitHub issue からの生成してみている。
どういったものを作ったか
こんなようなことをやってくれる Actions にしてみた。
- issue の更新イベントを捕まえて
- ブログのリポジトリをクローン
- issue を取得、hugo が食えるフォーマットに変換し、ブログのリポジトリの所定の位置に配置
- commit して push して pull request にする
その後、一応 pull request を自分がなんとなくレビューしてみて、良さそうだったらマージ。
マージしたあとは別途 デプロイ用の Actions を実行してサイトを生成＆デプロイ、みたいな流れ。デプロイのための GitHub Actions は、pull request がマージされたら勝手に実行しちゃってもいいかもしれない。
課題
なんとなく使えそうだけどもいくらか課題があり、
- issue 変更時には pull request を更新してほしいが、次々 commit を積むというのも難しいので force push にしている
- これは PC での編集と相性が悪いようにも思える (pull request を PC で編集したら issue 側に反映させないといけない気がする)
- 自分以外が issue を立てたときもブログ記事になってしまう。ﾜﾛｽ
- これは actions 実行の条件として、issue を起票あるいは変更イベントを発行した author が自分であること、というのを入れればよさそう
- (追記) その後、issue を変更した人が “pankona” でなかったら actions を何もしないで終了するようにしてみた。勝ったか！？
書けよ
仕組みを作るのはいいがちゃんとブログを書こうな (戒め)
いままで本ブログは Octopress を使って生成していたのであるが、
久々に動かしたり別のPCでやったりするときに上手く動かないことがままあり、まあまあストレスであった。
ということで、爆速サイトジェネレータとして高名な Hugo を使うように変えてみた。
なるほど、噂に違わぬ爆速サイトジェネレーティングである。しばらく使ってみよう。
Octopress から Hugo への移行は概ねすんなり済んだ。以下のような作業を行った。
テーマ選びに大半の時間を費やしたものの、概ね丸一日の作業となった (7.5h くらい)
- Hugo の使い方確認 (ドキュメントを見る等して)
- Hugo でサイトを生成し、Octopress 時代に生成したポスト一式をコピー
- ファイル名、各ポストのヘッダー等は若干適合しない部分があったので修正を加えた
- 各記事のパーマリンクを従来サイトと同じになるように設定
- Hugo の設定 (config.toml) に各種サイトの設定を記載 (ブログ名、Twitter、GitHub へのリンク等)
- BlackFriday をちょっとだけ設定し、hardLineBreak が有効になるように
- テーマ選び。ここがめちゃめちゃ時間が掛かった。結局シンプルなの選んである程度カスタマイズする方針に
以下はもう少しやっておきたいところ。
- フォントがダサい。というか見にくい。のでもうちょっと目に優しいやつを選ぶ
- サイトマップというか記事一覧というか、みたいのが欲しい
- favicon 設定
- about.html 的なやつを置く
- (あまり利用の実績がないが) SNS へのシェアボタンを追加。ツイッターだけ置いておいた。はてぶも欲しい。
- (まったく利用の実績がないが) disqus を置く。利用実績がまったくないところからして置かなくていいかも。優先度低。
昨年は勉強会レポートと ZenPad レビューと、みたいなどちらかというと受動的な強いられポストが多かったため、
今年はもっと能動的に日常的に息を吐くように記事を更新していきたい所存。今年もやっていくぞー。
2016.04.18 に、六本木は森タワーのメルカリさん宅にて、atte fes が行われました。
アッテの開発技術をお伝えする atte FeS【Go・Swift開発編】を開催しました - Mercari Engineering Blog
本イベントにブログ枠にて参加させていただきましたので、ひとつそのレポートをば、したためます。
発表時に用いられた資料は、↑のリンク先にアップしていただいているので、参照されたし。
ちなみに、冒頭の画像は会場でいただいたデカールです。ねこかわいい。
最初にビールと軽食で乾杯
いきなり技術的な話題ではないところからなんですが、実にシャレオツだったビールブースにふれないわけにはいかない。
図1. 三種類のビールが提供されている。しかも缶じゃない。感動。
図2. 軽食が提供されている。
ビールは3種類とも一杯ずついただきましたが、とても美味でございました。
また夕飯食べずに駆けつけたものだったので、普通に空腹でありました。軽食もいただけて良かった！
おかげさまで集中して発表に耳を傾けることができました。ありがとうございました。
図3. 司会の方の音頭で乾杯。
アッテ開発の技術：
Golang と Google Cloud Platform (鶴岡達也さん)
さて、発表内容について。
図4. 鶴岡さん
ひとつめは鶴岡達也さんによる「Golang と Google Cloud Platform」。
発表の具体的な内容は実際に資料をご覧いただければ分かると思いますので、
本記事では私が印象に残った箇所について触れていくことにします。
なぜ Web アプリ開発に Go/GAE を採用したか？
さまざま理由があったようですが、個人的には、
「3年後にもエンジニアにとって魅力的な場所であるため」 に、多様性と技術の開拓の意味もふくめての採用であったというのが印象的でした。
そういうふうな文化があると、エンジニアにとって満足感が高い職場になっていくんじゃないかなー、等と。
とてもいいと思いました。ええ、弊社でもぜひそうしていきたい…。
Go言語はチームで開発しやすい
私も個人的にちょいちょい Go 言語を触りますが、ほんとに周辺ツールの充実っぷりが凄まじい。
lint、コードフォーマッタ、変数名には Go 言語公式のポリシーが存在する、等。
チーム開発に採用すれば、やれインデントが〜とか、インポートの順番が〜、とかをソースレビューに持ち込むこともなくなる。
そういう点も学習コストを下げるのに役立っているかな。Go 言語、私もオススメです。
GoDoc を有効に使う
GoDoc は概ね常に最新に保っているとのことで、つまり、
「API を使いたいひとはとりあえず GoDoc 見て」で済んでいる、らしいです。
チームで開発しやすい、効率化という面で GoDoc を有効に使えている例かな、と。
ドキュメントをおざなりにしないところ、素敵です。
またこういうドキュメンテーションのためのツールが提供されているのも Go 言語のいいところ。
Go 言語、私もオススメです。
GAE のインスタンスは 200 ms で立ち上がる
速い！この速さはオートスケール時にとっても活きてくる模様。
アクセス過多でスパイクしてもあっとうい間に平穏を取り戻す図は、私の心にも平穏と興奮を与えるものでありました。
その他の話題、RDB vs NoSQL、DataStore の良いところ、等
他にも興味深いトピックについて話されていました。
ぜひ、スライドを直に見ていただければと。
アッテ開発の技術：
Swift と RxSwift (大庭慎一郎さん)
図5. 大庭さん
正直に言うと Reactive Programming というものがほぼ分かってない私ですが、
発表は非常に興味深く聞かせていただきました。Reactive Programming ええな！
Swift の採用を決めた経緯
Swift を採用した経緯について。そもそも流用する資産がなかったとのことで、
だったら色々機能の豊富な Swift にしましょうよ、ということだったと思います。
Objective-C は、それはそれで今まで蓄えられたノウハウが Web 上に豊富に転がっていたりして、いわゆる「ハマりにくさ」では Swift より上のような気はする。そういう意味では Objective-C にも良いところはあるだろう。
とはいえ、Swift と Objective-C、どっち採用したらテンションあがるかと言われれば、やはり Swift であるかなと。3年後もエンジニアにとって魅力的な場所を醸造しているひとつかもしれない、等と思いつつ。
リアクティブプログラミングに頼るとプログラミング能力が下がる？
プログラミング能力が下がるは言い過ぎかも？
スライド上のサンプルコードは短く完結にわかりやすく書かれていて、いったん慣れてしまったら辞められない的なものを感じた。
なるほど、馴染んできたら普通のプログラミング (？) のやり方忘れちゃうかもしれないですね。
とはいえ学習コストは高い模様。
質疑応答では「急に全部ではなく、部分的に採用していくこともできる」と。
データバインディングから始めるのがやりやすいのではないか、と仰っておられました。
リアクティブプログラミング 参考サイト
スライド中でも触れられていますが、リアクティブプログラミングについては以下のサイトが理解の助けになったとのこと。
【翻訳】あなたが求めていたリアクティブプログラミング入門 - ninjinkun’s diary
以下のページでは、Reactive な動き (Stream) を図で理解できるようになっています。
RxMarbles - Interactive diagrams of Rx Observables
アッテ開発の技術：
アッテ iOS の設計と開発フローの変遷 (石川洋資さん)
図6. 石川さん
同じ構造の実装の一元化
よくある同じ構造のもの、 ページネーション、フォームのバリデーションであるとかの共通化の話。
MVVM でいうところの VM 部分で、共通するGenericな部分 + 型スペシフィックな部分は型パラメータもらって作る、という構造の紹介。
特にページネーションは、10回書いたら7回くらいバグってるくらいのバグを埋め込みやすい部分らしく、
共通化することで、「高速な開発で、かつ安全」な設計に近づくことができたとのこと。
新しい設計を試すのは、場合によっては難しいことだと思う。
つい、いま動いているところは触りたくない、以前作ったものと同じような構造が出てきたら踏襲する、等と
してしまいがちな昨今（ですよね）、飽き足らず、より良いモノ作ろうぜという熱気にあふれている、等と感じておりました。
素敵だ。
自動デプロイの話
ご多分にもれずというか、やはり iOS アプリも自動ビルド/自動デプロイをなさっている模様。
構成要素としては、
- Travis CI (CI 時間は7分くらい)
- agvtool でビルド番号を振る (Xcodeに付随)。
- DeployGate (dev) と TestFlight (prod) にデプロイ
また、その他の作法として、
- 手元でのアーカイブはしない。
- QAが通ればそのまま審査へ
というのが紹介されていました。
ビルドとかデプロイ、あと審査もだと思いますが、ものすごく属人化しがちな部分であると思う。
「病気で倒れても誰でもデプロイできる」 と仰っていましたが、これって本当に大事なこと。
作業をひとにロックインしない工夫をしていかないとね。属人化は不幸の始まり。
ところで CI に掛かる時間が7分って結構早いような気がしている。
早さ、特に CI とかそういう常日頃から何度も繰り返し行われる事柄の早さは重要。
何も考えずにそこそこの規模の iOS アプリビルドしたら、結構時間かかっちゃうと思うんだよね。それこそ10分くらい余裕で。
さらっと7分って言っていましたが、ここにはきっと色々な工夫がなされているんだと想像します。
その後
図7. 懇親会。みな思い思いの方を捕まえては話し込む。
図8. 懇親会。運営おつかれさまでした。
おわりに
Mercari からスピンアウト (?) した SOUZOH という組織は、なんというか、
新しいやり方をどんどん取り入れていて、エンジニア的にはテンションあがる環境であるという印象でした。
それで実際うまいことやれているっていうのは、なお凄いことかな。
そんな感じで、おいしいビールをいただきながら学ばせていただいた atte fes でございました。オススメは Tokyo White。
運営の方々、登壇の方々におかれましては、大変おつかれさまでございました！
Code Review Best Practices - Kevin London’s blog の日本語訳を作成した。
Code Review Best Practices 日本語翻訳
コードレビューのやり方に関しての記事であるが、分かりやすいしフムフムと感じる内容だったため、
本人に許可をいただいて、翻訳、掲載をさせていただいた。
ありがとう、ケビンさん。
おかしい点、改善点にお気づきの方がいらっしゃれば、issue登録、pull request、なんでもいいので連絡いただけると嬉しい。
リポジトリはこちら
実はPOSTDに同じ記事を訳したものがあることが分かったのだが、、、
まあいくつあってもいいかな、等と思いつつ。ちなみに訳はほとんど同じだった。
この手のものは英語のままでいいと思う気持ちがある反面、
やっぱり日本人は日本語のほうが速く読める人が多いだろうし、一定の価値はあるかな、等と思うところである。
記事の中で印象深かったのは、Compliment / reinforce good practices の部分である。
平たく言えば、コードレビューで見つけた良いところを褒めていけ、という内容。
コードレビューではとかく指摘を探すことに終始しがちであるが、
確かに、褒めるというかイイネというか＋１というか、をしていくことで、
いい空気、もっといいコード書いてやろう的なモチベーションアップ、とか そういう効果もあるんじゃないかと思ったりもする。
ギスギスしがちなコードレビューの現場にはオススメ。私もやっていきます。
12月のことであるが、実は月間300ヒットを達成していた。
うち250ヒットは自分の手によるもの、、、とかそういうことではなく、
概ね自分以外の方々によって、月間300ヒットを達成できたのである。
300ヒット。たかが300ヒット。されど300ヒット。 一日平均10人。
これからもほそぼそ、ぼちぼち、書いていこうと思う。
学んだことをアウトプットするのが大事だと誰か偉い人も言っておった。私もそう思う。
書いたことによって、誰かひとりでも何かの助けになればと願いつつ。
自分のページがGoogle検索にヒットしない理由
なかなか自分のページ（ここのブログのこと）がGoogle検索に引っかからないので、
いや、大層なことを書いているわけでもないから引っかからなくても怒ったりはしないが、
いやでもなんで引っかからないんだろう、と思って調査をしていたところ、
GithubのリポジトリはGoogle日本の検索に引っかからない
といった記事を見つけた。ほんまかいな？
もしかしてそのせいでうちのページはGoogleに引っかからないんじゃああるまいか？
（Github pagesを使って公開しているページなので）
等と考えつつ、調査を続行していったところ、、、
結論からすると、GithubのリポジトリはGoogle日本の検索にちゃんと引っかかる。
ただし条件がある模様。それは（おそらく）、
ページ（リポジトリの場合はREADMEかな？）に日本語が含まれていること
つまり、Google日本の検索に引っかからない、というよりは、
**“日本語のページを検索”**に引っかからない、ということである模様。
全編英語で書いてたら英語のページと判断して、“日本語のページを検索"には載せない、ってことかなー。
そして、Google日本の検索は、おそらくデフォルトは"日本語のページを検索"になってる。という話。
加えて、GithubのリポジトリのREADMEなんかは、英語だけで書かれているケースが多い。
だからGoogle日本を使ってそのまま検索をしていると、Githubのページがあんまり出てこないという現象が。
だので、英語だけで書かれたGithubのページも、検索オプションで言語に依らない検索にしてあげれば、Google日本の検索でも出てきます。
じゃあ日本の人にもリポジトリにリーチしてもらうにはどうするか？
自分のGithubのリポジトリに日本人を呼び込みたい！と思ったら、READMEに日本語をちょっと混ぜてあげればリーチできる人が増えるかも？
と思っているがどうか。たぶん、おそらく、きっと、効果あると思われる。つまり自信ない。
自分のリポジトリ使って実験してみます。そのうち調査結果を書きます。