2022年もいそがしくしている間に振り返りせずにすでに半年が経過してしまいました。これではマズいなーと思ったのでやっていきます。

出来事/体験

年末年始、GWとムスメ氏を連れて実家に帰ったり。その折に子供も遊べる施設に行ったり、以前よりはコロナの影響で制限してたこともなくなり、また子供の成長とともにいけるところも広がりました。

本当に子供の成長はすごいもので、日々いろんなことを吸収し、できることが増えています。以前より楽にはなったものの、ステージが上がればまた新たな悩みもでてきて、親であることの難しさを実感する毎日です。

1月あたりに感染性の胃腸炎で30分置きに嘔吐したのは本当に焦りました。医療相談に電話して、それから夜間診療し、吐き気止めの座薬を入れ一段落。なんとかなったと思ったら僕も妻氏も感染し発症。時間差じゃなかったらヤバかったです。

習慣

できてないですねー。 体力の衰えを感じるので、そろそろ本当にちゃんと運動していきたい。

アウトプット/創作活動

こちらもできてないですね。 意欲はあるものの……

最近は構成管理ツールitamaeのmruby版、mitamaeを使ってMacの環境構築をするための設定をポチポチ進めています。

装備、環境

仕事の日用に服を決め、平日はまったく同じ服を着ている生活になって早3年。そろそろヨレてきたので刷新しました。 自分自身を含め、誰も自分の服装なんて気にしちゃいないし、毎日服を選択する手間が省けるのでこれはみんなにオススメしていきたい。私服的作業着スタイル。

半年なのでその他いろいろ買いました。

2021年も終わってしまいました。昨年は本当に早く感じました。コロナ禍にあり外出や集まりを制限せざるを得なくなり、刺激が減って同じような日常が多かったせいなのかな、と感じています。 2022年は状況良くなると良いなあ、と思いつつ遅くなったふりかえりです。

来た道[2021-12]

出来事/体験

僕自身ではないですが、妻がムスメ氏を連れて妻の友人と動物園に行く日がありました。ムスメ氏自身も楽しんでいて、僕も一人の時間として使えたので良い日になりました。ムスメ氏の成長具合とコロナで様子を見ていましたが、今年はこういう日が増やせると良いなあ。逆パターンで妻が一人になれる時間も含め。

そしてクリスマスがありました。ムスメ氏はサンタさんやクリスマスソングなど楽しんでるものの多分イベントとしてクリスマスを認識してないよう。それでもプレゼントであげたおままごとキッチンは大喜びで遊んでるので父親の面目躍如でした。

習慣

そろそろ運動習慣再開しないと思いつつなんか毎日ヘトヘトなのでがんばれない。 体がバキバキなのでストレッチだけでもやっていきたい。

アウトプット/創作活動

なにもできてない。2022年はなんかしら個人開発をして世に出したいなあ。

装備、環境

鍵の締め忘れ防止になるやつを買いました。アナログな仕組みで鍵をかけるとインジケーターの色が変わるやつです。これによって僕みたいな「あれ？鍵しめてきたっけ？」みたいに不安になる民にオススメのやつです。 これはマジもっと早くに買っておけばよかった感。

お仕事環境

インターン氏が12月いっぱいをもって終了になり、僕のメンターも終わりました。やはり人を指導するという経験は教えられることがたくさんあるなあと思いつつ、上手くできなかった反省点も山ほどあったのでこれからも精進していきたい。

消費趣味

相変わらずドッジボール（Knockout City）三昧です。 悲しいことにプレイ人口がそう多くなく、嬉しいことにプレイヤーのみんなはこのゲームを大好きでやりつづけている結果、けっこうなプレイヤーと何度も当たり、その結果仲良くなっています。

クルーというギルド的なチームのシステムをあるものの、その枠組みを越えて楽しくゲームできる仲間がたくさん増えた2021年でした。

2022年、そのつながりを保ったままドッジボールに限らずいろんなゲームで楽しんでいけたら嬉しいなあと思います。

OKR

• Objective：丁寧にコントロールできる環境を作る

  • ❌ KR：GTDを再整理して再開できている
  • ❌ KR：家の中のモノが整理、収納がきちんとされている

GTDはぜんぜんレビューがおいついてないです。年末年始に実家に帰ったのでその折にやろうと思ってたんですが、結局できなかった。考えが甘かったですね。

そして整理収納もまだまだ。棚を新調したのでだいぶ片付き進捗はありますが、完了したとは言いきれず。

ORK振り返り

じゃあどうすれば達成できたかというと、結局のところそれらの事にあたる時間をいかに捻出するか、なんですが、それはもう結局ゲームする時間を少しガマンするしかなさそうな。

行く道[2022-01]

Objective：丁寧にコントロールできる環境を作る □ KR：GTDを再整理して再開できている □ KR：家の中のモノが整理、収納がきちんとされている

できてないので再トライです。とりあえず、GTDだけでもちゃんとやっていきたい所存。

来た道[2021-11]

出来事/体験

ムスメ氏と妻氏の親友家族と一緒に動物園に行きました。11月初旬は11月とは思えないくらい暖かくて、芝生でランチが楽しかった。コロナの影響であまりいろんなところに連れてってやれてないのでこれから機会を増やしていきたいな。

あとは妻氏がおでかけしてムスメ氏を日中僕一人で見てる日がありました。自我が芽生え始めてからは始めてで、それでも不機嫌になることなく一日を終えられたのが良かった。これから親もリフレッシュに遊びにいけるという試金石になりました。

習慣

やはりいったん習慣がストップすると再度スタートするのはなかなか難しく運動できてません。そしてまた風邪をひきました。無念。今のところ100％ムスメ氏の風邪を移さされてますが、よく考えると歯磨き当番なので、その後にろく手を洗ってないのが原因っぽい。気をつけよう。

最近、以前に買った猫背にならないようなコルセットを装着しています。まる一日つけてるとちょっと痛みがでますが適度にやる分にはけっこういいです。背筋のばして、肩甲骨引いていきましょう。

アウトプット/創作活動

珍しく有給をとったので一日ガッツリ勉強兼趣味開発してました。仕事より集中した気がします。とても良い時間だったのでやはり将来的に週4勤務、週1個人開発で生活していきたい欲が高まりました。

装備、環境

ブラックフライデーのセールでmi band 6を買いました、ちょっと前のやつ（3ぐらい？）は持ってたんですが、どこかに行ってしまい、買いなおし。この価格で電池持ちが良く小さいサイズっていうのはやはり最小限スマートウォッチとしてはとても良いですね。

来た道[2021-10]

出来事/体験

10月は自分の誕生日がありました。もう40になってしまったことに自分で驚きです。初老です。不惑です。が、いまだに惑ってばかりです。前の節目、30になるときは世界を旅してる時でキルギスで迎えたのはよく覚えています。あれから10年、あのときなりたかった自分になれてるだろうか……

運動の秋ということでムスメ氏の運動会がありました。保育園の送迎は妻氏がやってくれてるのでムスメ氏が他者と触れあってるのをあまり目にしないですが、それが見えたので感動でした。ウチの子に限らず、どの子も眩しいほどに微笑ましさが爆発していました。

ロボット掃除機ルンバをサブスクで導入しました。こういう高額なものがサブスクでお試し的に使えるのは良いですね。自分の家と使い方にどのモデルがマッチするか、どのぐらい効果あるのかわからなかったのでサブスクで導入しました。

まとめ

• PS plusで新規プレイヤーが爆増し、初心者も多い今が始める最大のチャンス！
• エイムがほとんど要らないので楽しめる人が多い
• TPS要素と読み合い、立ち周り重視のアクション性の高いシステム
• プレイヤーの民度が高い

なぜ今が始める最大のチャンスなのか

• PS Plusフリプ入りで新規プレイヤーが爆増中
• 新規プレイヤーが多いほど、新規プレイヤー同士で対戦することになり新規プレイヤーにはやりやすい
• 先日のアップデートでBotとの練習もできるようになった

（僕も含め）リリース初期から今もプレイする人のほうが割合的に多かったこれまでは、初心者でも熟練者とマッチしてしまうこともあり、初心者にとっては苦くツライ試合をさせられてたことは否定できません。

ですが、新規プレイヤーが爆増中の今は違います。リリース直後以来の、初心者が初心者と試合して、ゆっくりと上手くなる土壌が復活しました。

なぜ今、新規プレイヤーが増えているのか？　ノックアウトシティは試用版がありランク25までは無料でできますが、それ以後は通常2,000円です。これがPS Plusの11月のフリープレイ特典になり、制限のない製品版が今なら無料で手に入ります。

これにより今まで興味を持ってたプレイヤー、試用版をやって興味はあるが買うに至らかなったプレイヤー、リリース直後の無料期間以後やめてしまったプレイヤー、知人がやるから誘われたプレイヤーなど様々なプレイヤーがプレイ開始しており、リリース直後以来では最大の新規プレイヤーの波が来ています。

これは今だけ無料化されてるPSユーザーだけでなく、他機種でも有料ではありますが、新しく始めるチャンスです！　今しかないってぐらいチャンスです！

来た道[2020-08,09]

出来事/体験

8月は毎週風邪を引いてたような気がします。恐るべし保育園の洗礼。そして落ちついたと思ったらワクチンの副反応。もう本当に毎週熱だしてました。重ならなかったのを幸いと喜ぶべきか。 そんななか9月のあたまには100人以上が参加する社内ハッカソンイベントの実行委員長として準備を頑張るも忙殺され、よく生き延びたな、という感じでした。 9月の終わりには体調も仕事も落ちつき、シルバーウィークに夏期休暇を混ぜて一週間やすみ、ムスメ氏を連れて実家に帰省しました。言葉を覚え始めたムスメ氏の語彙力がぐんぐん伸びてますが、刺激があるとさらに爆発的に伸び、成長ってすごいなあと関心するばかりです。

そして僕は大して成長してないっていうね。

そうそう、もう何年も眼鏡の度を変えておらず、眼鏡をつくるときも以前と同じ度で、みたいに作ってたので、休みがとれたときに眼科にちゃんとした検眼に行きました。結果は眼鏡ありで2.0。見えすぎぐらいなんで疲れるようならたびを落としてもいいかも、という話でした。

なんにせよ悪化してないとは良かったです。が、せっかく休みなら瞳孔を開く目薬とか使った本格的な検査までやればよかったかもなあとちょっとだけ後悔。その対応ができる眼科を調べるのを怠りましたね。まあまた来年ぐらいにやりましょう。

習慣

体調悪いのが続き、運動の週間も勉強の週間も続けることができずいったん停止。10月から本気だす。

アウトプット/創作活動

最低限の振り返りブログすらサボってしまったのでなにもなく。

強いていえば、唯一の楽しみだったノックアウトシティというドッジボールゲームのプレイング改善点を言語化したぐらい。これは今月ブログに書きたい。

装備、環境

布団に入って寝る前の読書が至福の時間なんですが、愛用のKindle Paperwhiteが完全に沈黙しまして。無いのに耐えられないのでなくなくセールでもなく普通の日にすぐに買いました。

が、その後、すぐにセールかつ新バージョンが出てヘコみました。しかも数日後文鎮化した旧Paperwhiteを付けてみたら正常に動くっていうね……もうなんだったのか。

が、防水Paperwhiteは良いですね！　特にお風呂読書もたしなむ僕としてはノーガードでお風呂に持って入れるのは嬉しいかぎり。

来た道[2020-07]

出来事/体験

ムスメ氏の初外食デビューでした。大き目の公園にいった帰りによってみました。想像してたより全然おとなしくモグモグしてくれたのが嬉しかったとともに、これからムスメも連れて外食できる選択肢が増えたことがありがたいです。

初水族館にも行ってみました。ここのところ急激に言葉を覚えだしたので「おおっきいねー」とか言うのが可愛くてたまらんでした。コロナでいままで自粛してたぶんワクチンで落ち着きが見えたらいろんなものを見せてあげたいなあ。

そして月末近くはムスメ氏からの風邪が家庭内パンデミックひきおこしてダウンしてました。全然直らなかったで立てつづけに2種の風邪を引いたもよう。

習慣

毎日の振り返り全然してないです。週次も。これはいかんです。習慣がとぎれたというより、振り返りをしない習慣がついてしまったような感じ。コーディングする機会が減ったことにより技術知見が増えにくくなってるのもあるかもしれません。でもそれそれで他のことに対する振り返りをしたほうが良いですね。

それとは別に、機嫌良くふるまうことを習慣化しようとトライしてみました。 先月の振り返りでも書きましたが、機嫌良く居ることではなく振る舞うこと、というのがポイントです。そう意識してたからか少しはできた気がしますが、まだまだです。

アウトプット/創作活動

なんにもできていない。

装備、環境

とくになんにも変わってない。

お仕事環境

特に変わりありませんが、自分が実行委員長になっている社内イベントのあれこれが本格化して忙しくなってきました。やることはそこまで多くないんですが、普段のエンジニアリングと全然違うことをやり、かつ、初体験なので脳内リソースがハンパなく取られるというか。

逆に採用の協力として技術面接の一員として参加するのは慣れてきました。が、英語でのやりとりなので英語力が酷く落ちてるのを実感する日々です。なんとかしたいなあ。

消費趣味

あいかわらずドッジボール（Knockout City）ばっかりです。

実はクルー（というクラン的なグループ機能）を組んでいて、そのキャプテン（=管理者）なんですが、Discordサーバーを立ち上げたり管理したり、Botを入れたりしていました。人数の少ないクルーなのでそれほど大変ではないんですが、クルーの方針を決めたりするのはなかなか面白い体験です。

メインはDiscordになるんですが、これは使えば使うほど面白いシステムですね。従来のボイスチャットとは全然違う。サーバーという単位で自由に運営できるので中のカスタマイズも自由で自分達の色がでるし、Botで機能を拡張したり。Slackと似ているけど、ボイスが主体なのとあくまでメインのゲームなどがあってその補助ツールの側面なので違うところも多いですね。なによりボイス回りが素晴しく快適なのはすごいの一言。

前も書いたかもしれませんが、オンラインメインのゲームの攻略やコミュニケーションは匿名掲示板の時代ではなくなってきたなぁと実感します。あちらは後ろ向きな発言する方々がかなり目立ちます。面白いと思えるゲームに出会ったら人数多く活発な公開Discordサーバーを探して入ってしまうほうがよっぽど楽しめると思います。

OKR

• Objective：いつも上機嫌に振る舞えるようになる

  • ✅ KR：上機嫌でいることに関する本を読む
  • ✅ KR：上機嫌でいられるための身体的アプローチをする

本は二冊読みました。

来た道[2020-06]

出来事/体験

瞬間最大風速的に人生で数えるほどのメンタルが不安定になりました。色々と反省。やりたいこと、やらなきゃいけないこともありますが、7月、まずはここをなんとかしようと思いました。

習慣

日次、週次の振り返りが疎かになってきています。日次についての原因はスケジュールしてるにもかかわらずスケジュールを守っていないことですね。日次ができてないから週次もおっくうになりできていないと。

インプットの習慣は上々です。お風呂では大体読書していますし、技術書から実用書まで幅広く読むようになってきました。これは苦と思ってないので引き続きできる範囲で継続していきたい。

アウトプット/創作活動

React（Next.js）とFirebaseで軽くWebアプリを作ろうと思ってたんですが、なかなか進まず。キモはフォームの入力内容から画像を作るところです。イメージできてるものを作るのは楽しいんですが、どうすればいいかってところから学習コストを払いつつ作ることへ、最近はなかなか面倒と思うようになってきました。

勉強しながら作る、というは学習のあり方としてかなり有効なのは知っていますが、まったく知見がない状態で技術やライブラリ選定から始めるのはツライですねえ。相談できる場があれば良いのですが。

装備、環境

今月の消費は全然ないですね。強いていえばPS5用のコントローラグリップを買ったぐらい。ただ使い心地はめちゃくちゃ向上した、という感じでもないので、完全に好みによる感じですかね。

お仕事環境

まず、業務では海外拠点もあり、そこのエンジニア採用に協力するようになりました。採用系は初挑戦ですし、候補者のコードも見なければいけないし、加えて実際の面接（オンライン）も英語でやらなきゃいけないというなかなかハードシチュエーションですが、新たな挑戦、無理しすぎず頑張っていきたいです。

加えて弊社では年イチで1週間の社内ハッカソンイベントがありますが、今回の実行委員長になりました。これも新たなチャレンジですね。自分の幅を広げるために頑張っていきたいです。

どちらの話も嫌ではないものの、自分から率先して手を上げたわけではないので、年数や経験を重ねていくとコード書いてるだけじゃダメなんだなあと身に沁みて感じました。

消費趣味

あいかわらずドッジボール（Knockout City）の毎日です。知人を誘ってもイマイチ反応薄かったんですが、実はリアルなドッジボールやくにお君を想像してたようで、言葉だけでは全然面白さが伝わってませんでした。

ちょっと上手くなるのに見返すためにも布教にも使えるので最近ではプレイ動画をちょいちょい撮るようにしています。

目標

• ❌ 日次と週次振り返りを継続する
• ✅ 3日に一度、5分はインプットorアウトプットのための行動をする
• ❌ 自分のWillと、仕事をしていくなかWillを見つめなおす

冒頭書いたように日次、週次レビューできてないわけではないですが、疎かにしているので達成とは言えないですね。

インプットはバッチリ。

自分の仕事でのWillは多少考えたもののまだぼんやりとしています。今月（7月）仕事での目標に対していろいろアクションがあるのでその中でなにか答えが見い出せたら、と思っています。

行く道[2020-07]

1. Objective：いつも上機嫌に振る舞えるようになる

   • □ KR：上機嫌でいることに関する本を読む
   • □ KR：上機嫌でいられるための身体的アプローチをする

今月は一重にこれでいきます。

僕は、「気持ちをコントロールするのはほぼ不可能。身体操作から気持ちにアプローチするほうがよっぽど簡単で頼りになる」という理念があります。笑うから、笑顔だから楽しい、というアプローチです。落ちつくには深呼吸、そういう話です。

我々は人間には気持ちという掴みどころのないものを操作する方法は未だ確立されてないんです。そんな難しいことを頑張ろうとせず、身体操作をきっかけに気持ちを制御する方法に注力すべきです。

今回は上機嫌でいること。本当に心から上機嫌でいるかは二の次で、上機嫌に振舞いつづけることが重要と感じました。

肩の力を抜いたり、楽しそうにしていたり。発声や言動も含みます。

そして不機嫌は伝播しますが、気持ちは不機嫌でも振舞いが上機嫌だったら伝播させずにいられるはずです。

それらをひっくるめていつも上機嫌に振る舞えるようになる、です。どのようなアプローチができるかは本を読んでから考えようと思います。特に実際達成できたか（振る舞えてたか）を測る指標を立てづらいのでどうできるかなあ、といったところ。

来た道[2020-05]

出来事/体験

GW、実家に帰りました。両親、兄弟ともにムスメ氏にメロメロでした。人見知りもせず、かといっていろいろわかってきだしたので可愛い盛りですね。ムスメも楽しそうだし、両親も大喜びだったのでとても良かった。また車移動オンリーだったので他人との接触を最小限に抑えれたのもの良かったです。

出来事としてあったというか、できなかったというか。結婚記念日があったはずななのに育児を含めた日々を生きることにせいいっぱいで何もできませんでした。なんかしたいと思いつつも。

習慣

習慣というか、Udemyでの学習を始めました。定期的に学習しなきゃと思いつつも、就業後に体力、精神力のどちらか一方または両方が枯渇していて、本を開いてーとか手を動かしてーというのがハードル高いです。

ちょうどこういうインプットしたい、と思ってたUdemyが安いのを見つけたので見だしたら動画のため、ハードルが低く、また、お風呂にスマホ持ちこめばお風呂でも観れるので重宝しています。

アウトプット/創作活動

とくにありませんでした。無念。

装備、環境

今月は（も）いろいろ買いましたね。

来た道[2021-03]

出来事/体験

ムスメ氏が保育園に行きはじめ、妻さんが職場復帰しました。ムスメ氏は人見知り全然しないのでさっそく嬉々として保育園に登園し、親としては大助かりです。

妻さんも基本出勤ですが、たまにリモートでも仕事しており、ムスメ氏がいない家で二人でいるのが新鮮です。かなり久々に二人で外食をしました。自分の仕事はあまり変わらずだけどそれでも4月になれば環境かわるものですね。

習慣

週イチブログやめました。理由としては、あまりネタがないのに週イチを継続することを目的としてなんとか捻り出した出枯らしのように薄い記事を書きつづけることの無為さ、ネタはないか探しつづけながら過す一週間のストレス、それらが意味のあるものに思えなくなったことが理由です。 もちろん、週イチブログコミュニティを通してある程度習慣化でき、強制力がなくともコンスタントにブログを書いていける気がしているのも大きな要因です。結局ネタの濃度は上がらないかもしれませんが、今後は楽しみながらブログを続けていきたいと思います。

先月、今月の目標として挙げた日次と週次の振り返り、ちゃんとできています。なかなか良い感じ。詳しくは後述。

アウトプット/創作活動

Slack App用のフレームワーク、Boltの最新版（v3)をいじってました。socket-modeというWebSocketによる通信ができるようになったお陰で開発と動作確認にngrokのようなサービスを使わなくていいのはとても良いですね！ ですが、今あるものをリプレイスしようと思ったらfirestoreを使うんですがこれをちゃんとTypeScriptでやろうとする学習コストを時間的に払うのがおっくうでまだ進めていません。

装備、環境

実際にやりかたをNotionでやってみていますが、これがなかなか良いという話。

概要

• Notionのテンプレート機能はいいぞ
• Linked Database機能もいいぞ
• 合わせてやるといいぞ

Notion is何？

情報管理ツールの1つで、EvernoteやScrapboxと同系統のWebサービスです。

来た道[2021-03]

出来事/体験

なんか胸に違和感というか苦しさがあり病院に行きました。一応異常なしとのことでした。以前から稀に胸がグッと苦しくなることもあったのでやはり心配ではあります。今も違和感が完全にないわけではないんですよね。なんだろう。しばらく様子見たあと、再検査に行きます。

PS5を買いました。ようやく。現行のPS4ゲームのクオリティアップと4月からのゲームをやりたいという理由です。疲れましたね。いろんなところの抽選に落ち、Amazonや楽天の争奪戦に破れ。結局ヨドバシカード持ちの妻とヨドバシアキバに土曜の朝行って買いました。それからめっきりPS5発売情報を追ってないですが、ヨドバシカードで店頭販売狙いが一番楽で早いかもしれません。

無事買えたことより、これで争奪戦からイチ抜けたできた気持ちの安堵の恩恵のほうが大きいというのがなんとも。もちろんゲームライフ自体も向上しましたが。

習慣

あまり習慣化ちゃんとできてませんね。良くない。ストレッチも英語学習も全くやってないわけではないのですが、頻度は大分落ちています。

アウトプット/創作活動

CLI用のコマンドをちょっと作ろうとしたんですが、 結局開発環境を整えたところで止まってしまっています。

装備、環境

PS5以外にもいろいろ買いました。

しかし、英語の発音の正しさよりも一般的に言われている発音をするほうが、コミュニケーションに齟齬が生まれず良いんではなかろうか、そもそも和製英語だってあるし、正しさを貫くよりも共通認識を合わせるが良いだろうな、と自分のなかで決めた話です。

概要

• エンジニアが日常で使う単語に英語が多いけど、変な発音が一般化してたりする
• 正しい発音にこだわって伝わなければ意味がないので、正しさは置いておいて認識を合わせにいく
• 一方で正しい発音も知っておくほうがいい

発端

僕が気持ち悪く感じてた代表選手はwarn。カタカナにするとウォーンが正しいです。warningならウォーニング。warはウォーですね。スターワーズとは言わないし、ワールドワートゥーとも言わないです。なんだけど、みんなwarningって出るとワーニングと言っていて、日本人（エンジニア）同士の会話でウォーニングと発音されているのを聞いたことはありません。

最近よく耳にするようになった、賞を意味するaward ですが、これはもっと一般的にアワードと言われていますね。ミュージックアワードとか。これも同じくアウォードがより正確です。が、なぜかアワード。みんなスターワーズとか言うのだろうか、というと言わない。このブレが気持ち悪くないですか？

そして僕は英語として考えるのを止めた

warに限らずこういう英語の発音からするとちょっと変な発音はいくつかありますが、 気になるものの気にしないことにしました。

コミュニケーションの本質は意思疎通ができること

発音が正確でも伝わらない言葉は意味がないし、逆を言えば発音が不正確でも伝わればいいんです。ウォーニングが出てますよって言って伝わらない状況より、ワーニングが出てますよ、っていって伝わるほうがコミュニケーションとしてはよっぽど価値があるはず

気持ち悪さに自分で理屈をつける

その行為を自分でヨシとするにはまだ少しの気持ち悪さが残る。これを飲み下すには何かしらの理屈が必要でした。

そもそも例えば僕も含めてDatabaseを意味するDBをデービーと言う例に始まり、すでにして自分も英語的発音に近くない言葉も許容しています。他にはnullをヌルとか。defaultもデフォルトが一般的ですね。正しくはディです。

となれば今さらこれは良い、これは良くないなんて考えないで一般的にそう言われてるものに従うので良いんじゃないかと思いました。

もとは英単語を見ても英語に近いカタカナな日本語として認識するというか。そう、英語のような日本語なんだ。そう思うことにしました。

お互いに英語を母語としないときもある

そもそも僕等がそうであるように、コミュニケーションに英語を使う場面でも相手も英語ネイティブではないケースもあります。我々がカタカナに引きづられガチなのに対して、各国いろいろな発音の癖もあります。だからもう英語の発音的正しさを気にしすぎても仕方ないかな、と思いました。伝わればいい、というの唯一の正義。

ものすごい余談ですが、僕はいろいろと今までの経験で、英語を聞いてその人の母語が何語かけっこうな確度でわかります。英語ネイティブでも場所によって訛りがあるのだから音の正しなんてものはきっとあってないようなもんです。

短縮系をどう読むか、ネイティブもブレブレな件

charとかenumとか。charはcharacter、enumはenumerationとかから来ていますね。これらはチャーだったりキャラだったり。enumもイニュムではなくイナムだったり。directoryを指すdirはディルだったりディアだったり。

なにが正解かわからないのでもはや気にするのをやめました。

とはいえ英語でちゃんとした発音も知っておいたほうが良い

世界がどんどん距離が縮まり、海外の人とのやり取りも多くなってきました。で、あるなら、やはりここまで書いた話はともかく、英語としてはどう読むのか知っておかないとこんどは海外の人とのコミュニケーションに支障をきたします。自分が喋らない場合でも聞いてわかるかわからないかは重要ですね。

発音記号をちゃんと見る

個人的な偏見かもしれませんが、知らない英単語を調べるとき、発音記号まで見る人って少なくないですか？　いやそれ以前に発音記号の読み方を知らないのかもしれない。

英語を調べるとき、Google検索でササッと見るのではなく、発音記号付きのサイトでみる。もしくはMacであれば付属の辞書アプリにちゃんと和英辞書も入ってますのでそっちを使う。

余談ですが、その時ちゃんと品詞まで見るといいです。英語を扱ううえで品詞はめちゃくちゃ重要です。

今まで僕が出会った気になったもの

route

routingとか、routesとか良くでてきますね。アメリカ英語的にはラウタ、と発音するのが近いです。が、日本人同士でルート、ルーティングと言っていてラウタと言ってるのを聞いたことはありません。これも知識として知っておいたほうがいいですね。

parse

ス、じゃなくてズ、濁ります。パーズとかパーザーとか。ただし、これはもしかしたら米語と英語で違うかもしれません。濁ってもいいんだな、と思っておけば良さそう。僕は日本語時でもたまに癖で濁ってしまいますが、通じるのであまり気にしていません。

そのほか誤読されがちなやつ

感想

そもそも、fとh、lとr、bとv、sとth、あたりをちゃんと言い分けてないのでもう英語発音的正しさを日本語の会話の中で気にしても栓なきことですね。それでも誤読は多少気になりますが。

伝わればいいのだ！　日本語で会話してる時は、warnはワーン、awardはアワード、でもStar Warsはスターウォーズ、それでいいじゃない。はい、解散！

概要

• ある用途で思いたってCLIのコマンド作ろうと思った
• oclifというCLI用のフレームワークがあったので試してみた
• 簡単すぎてびっくりした
• 追加でPrettierとJestも対応してみました

動機

誰しもCLIのコマンドをつくりたくなることがたまにある。僕はある。

今回はGUIを作るまでもなく、コマンドでシュッと実行したい作業があったので勉強と遊びを兼ねてコマンドを作ることにしました。CLIの開発ツールはいろいろありますが、今回はやりたいことを実現するのにすでに知見としてあるものを流用したい背景aからNode.jsでやることにしまた。

Node.jsにもCLI用を作るためのライブラリがさらにいくつかありますが、今回はoclifというものを使うことにしました。

$ foo --bar baz

$ foo bar --hoge
$ foo baz --fuga

$ npx oclif single sample

     _-----_     ╭──────────────────────────╮
    |       |    │      Time to build a     │
    |--(o)--|    │  single-command CLI with │
   `---------´   │  oclif! Version: 1.17.0  │
    ( _´U`_ )    ╰──────────────────────────╯
    /___A___\   /
     |  ~  |
   __'.___.'__
 ´   `  |° ´ Y `

# npmのpackageの名称を設定
? npm package name sample

# コマンドの名称
? command bin name the CLI will export sample

# コマンド説明
? description a sample command by oclif

# 作者
? author Aqui TSUCHIDA @AquiTCD

# バージョン
? version 0.0.0

# ライセンス
? license MIT

# GitHubのオーナー
? Who is the GitHub owner of repository (https://github.com/OWNER/repo) AquiTCD

# GitHubのリポジトリ
? What is the GitHub name of repository (https://github.com/owner/REPO) sample

# package manager(yarn or npm)
? Select a package manager yarn

# TypeScriptを使うか
? TypeScript Yes

# ESlintを使うか
? Use eslint (linter for JavaScript and Typescript) Yes

# テストフレームワークとしてmochaを使うか
? Use mocha (testing framework) Yes

# CIを設定するか（e.g. circleCI)
? Add CI service config

$ cd sample # sampleとして作ったので移動

$ bin/run
# => hello world from ./src/index.ts

$ bin/run --name Aqui
# => hello Aqui from ./src/index.ts

$ bin/run --help
# describe the command here
#
# USAGE
#   $ sample [FILE]
#
# OPTIONS
#  -f, --force
#  -h, --help       show CLI help
#  -n, --name=name  name to print
#  -v, --version    show CLI version

 $ yarn add -D prettier eslint-config-prettier

module.exports = {
  extends: ['oclif', 'oclif-typescript', 'prettier'],
  rules: {
    // ...ご自由に
  }
}

// ... 略
{
"scripts": {
    // ...略
    "lint:eslint": "eslint . --ext .ts --config .eslintrc.js",
    "lint:prettier": "prettier . \"!test*\" --check",
    "fix": "yarn fix:eslint && yarn fix:prettier",
    "fix:eslint": "yarn lint:eslint --fix",
    "fix:prettier": "yarn lint:prettier --write"
 }
}

$ yarn add -D jest ts-jest @types/jest

module.exports = {
  testEnvironment: 'node',
  moduleFileExtensions: ['ts', 'js', 'json'],
  testPathIgnorePatterns: [
    '/node_modules/',
    '<rootDir>/__tests__/helpers/'
  ],
  transform: { '^.+\\.(ts|tsx)$': 'ts-jest' },
  coverageReporters: ['lcov', 'text-summary'],
  collectCoverageFrom: ['src/**/*.ts'],
  coveragePathIgnorePatterns: ['/templates/'],
  coverageThreshold: {
    global: {
      branches: 100,
      functions: 100,
      lines: 100,
      statements: 100,
    },
  },
}

 transform: { '^.+\\.(ts|tsx)$': 'ts-jest' },

testPathIgnorePatterns: [
  '/node_modules/',
  '<rootDir>/__tests__/support/'
],

{
// ...略
"scripts": {
    // ...略
    "test": "jest",
  }
}

export const testCommand = async (
  klass: typeof Command,
  argv: string[] = []
): Promise<{ stdout: string[] }> => {
  const result: string[] = []

  const originalWrite = process.stdout.write

  const writeMock = jest
    .spyOn(process.stdout, 'write')
    .mockImplementation((val, encoding, cb): boolean => {
      result.push(val as string)

      if (process.env.TEST_OUTPUT) {
        originalWrite(val, encoding, cb)
      } else if (cb) {
        cb()
      }

      return true
    })

  await klass.run(argv)

  writeMock.mockRestore()

  return {
    stdout: result,
  }
}

import Sample = require('../src/index')

describe('elgtm', () => {
  it('returns hello world', async () => {
    const { stdout } = await testCommand(Sample, [])
    expect(stdout[0]).toContain('hello world')
  })
})

ちなみにその後、鬼滅の刃を読み、面白かったと思ったし、使われていた言葉も理解できたので今は嫌いではないです（かといって好きでもなく、普通に面白かった作品の1つ、という位置付けですが）

爆発的ヒットによる大衆の常識化

鬼滅の刃が近年稀にみる爆発的なヒットとなったのは記憶に新しいと思います。メディアはこぞってとりあげ、タイアップものも沢山でるようになりました。テレビではなんとかの呼吸だとか全集中だとか良く耳にしましたね。 この時の世界はまるで、全ての人間が鬼滅の刃の内容を知っていて、呼吸だとか集中だとかも知っているのが常識みたいな流れではなかったでしょうか。

当時、鬼滅の刃に興味を示さなかった僕としては、すごい疎外感を覚えました。それと大の大人が割とマジメになんとかの呼吸だの全集中とか言う様を見て、なんか恥ずかしいような気持ちさえありました。 これらがいろいろ混ざりあった結果、その元になっている作品がなんとなく嫌いだな、という感情に発展しました。

僕らの世代がやってきてしまったこと

しかし、ふと冷静になってみるとこの現象は僕らの世代が今までやってきたことにとても近いなと考えるようになりました。 僕はいわゆるジャンプ黄金期と呼ばれる時代に少年期を過ごしました。化け物のようはヒット作が数多くでましたが、その中でもドラゴンボールは突出してると言えたでしょう。 そう、僕らの世代でドラゴンボールを知らない人がいるなんて考えたことありません。かめはめ波はもちろん、界王拳やスーパーサイヤ人などみんなもっている共通認識だと疑ったこともないほどです。

そしてドラゴンボールは原作のほかTVシリーズでは続編があったこと、再放送やゲームが出続けたことにより、幅広い世代に受け入れられたと認識しています。今と比べて娯楽が少なかったことや、ネットやスマホなど同じ時間を食い合う存在が少なかったこともあるでしょう。

規模や期間は違えど最大瞬間風速的なものは同じ感じかなと思います。

以前、今の若者世代の中でドラゴンボールにあまり馴染みがない層から、オッサンはなんでもドラゴンボールに例えるから不快、という意見を効いたことがあります。まさしく、今回の鬼滅ヒットではこの逆の現象が僕におきてたのかもしれません。

まあ、呼吸や集中というWordや行動はドラゴンボールのそれに比べて日常により近く、その結果だれでも口にしやすい背景はあると思いますが、それでも僕が界王拳！　とか高校生にもなって叫んでたら恥ずかしいので、やっぱりなんとかの呼吸！　とか全集中！　とかみんなよく恥ずかしくないな、と思わざるをえませんが。

知っていることが前提で進まれることへの不快感

とまあ、ここまでで何が言いたかったかいえば、前提知識が必要なことをさも常識のように話されると不快だというだけの話なんですが、思いあたったことが他にもあります。

ロードオブザリング（指輪物語）つまりファンタジー

今あるファンタジーの基礎を作ったものの1つではないでしょうか。映画、ヒットしましたが、僕は1作目の冒頭でつまらなさが勝ちました（後に理解してちゃんと観ましたが）。 いわゆるエルフ、ドワーフ、オークなどがでてきます。これらはそれ以後いろいろな作品にも登場します。基本は近いものがありますが、作品数が多すぎてわりとブレています。

そして映画ロードオブザリングのツラかったところは、こういう存在がどのようなものかほとんど触れられないことです。つまり予習前提の映画になっています。映画というある程度限られた尺の中に詰めるのは無理があったのかもしれません。

時代劇

僕は時代劇が大好きなんですが、そんな僕に言わせれば、時代劇もファンタジーの一種です。日本の中世ベースにしたファンタジーです。

同年代で若い世代であまり時代劇が好きな人にあったことがありません。逆に僕らの親やその親の世代はわりと好きな人は多い印象です。これは親やその親の世代は時代劇の世界と自分達がそれほど遠くなく、またさらに娯楽の少ない時代ですので慣れ親しんでいたのもあるでしょう、つまり上の話で言う予習済み状態です。

自分が何も知らない前提で時代劇を読んでみると驚くほど説明が少ないです。将軍とか、殿様とか、侍とかそのへんはまあ知ってる人も多いと思いますが、時代劇を読むと普通に大目付や近習などの役職や、部屋住みなどの背景事情が含まれた用語が沢山でてきます。これを知らずに世界を味わったりはもちろん時には物語を追うのが難しいほどです。しかもこれらに対して説明があることは稀です。あったらあったで野暮なんですが。

と、こういうことが原因で時代劇の入口はなかなか狭いんだろうなあ、と感じます。

その後の対策

結局そこまで鬼滅の刃に興味はなかったものの、知らないことで受ける微弱なストレスが面倒に感じたので原作がそう長くもないのもあって一気に読みました。読んだことが無駄だとは思わない程度には面白かったです（残念ながら世間で話題になるほどハマりもしませんでしたが）。

今回思ったのは、一過性のヒットが常識のようになって、知っている前提で話されることが多くなってくると寂しい気持ちになることが多いので、とっとと履修してしまったほうが楽だなあ、という話でした。

その教訓を元に次は中学三年生以来見ていないエヴァを序から追っていこうと思います。

概要

• 運動不足が気になってステッパーを導入した
• なかなか良いけど本当に集中するときは足は止まる
• スタンディング状態も長くなったのでヨシ

ステッパー is何？

トレーニンググッズの1つで足踏み機です。台的なものに乗り、その場で歩く運動をするものです。電源も不要なものがほとんどです。踏み込みの種類で大きくわけてストレート、ツイスト、サイドとあります。

やってみた結果

僕はスタンディングデスクで仕事していますが、メモリー機能付き電動型な頻度で座っていました。今回はステッパーを導入し、スタンディングデスクと併用して、足踏みしながら仕事する作戦です。 ちなみに今回買ったのはコレです。

出来事/体験

とくに目新しいものはなしです。緊急事態宣言下なのでそれが正しい姿ではある気はするんですが、やはり何かしら刺激が欲しいものですね。

強いていえば家の壁紙の補修をしました。転居後の整理などで、壁をちょっと黒くしてしまったところと、壁紙を削ってしまったところがあったので補修にトライしてみました。

概要

• あるレコードが条件に合わないとき、レコードを削除できてしまうと困る
• 条件に合わない場合はdestroy時にエラーにして、削除が成功しないようにする
• before destroy と throw abort を使おう

動機

例えば1 projectに関連するの複数todoがあるとします。 Rails的に言えばproject has_many todosですね。そしてtodoはstateとしてbacklogをデフォルトとして、wip,doneと遷移していく3パターンの状態のどれかを持つとします。

この時、todoはwipの状態では削除できないものとします。そしてprojectの削除時も関連するtodoの中にwipのものが1つでもあれば削除させたくないとします。

このようなとき、Railsではdestroyできてしまえないようにするにはどんな方法があるでしょうか、という話です。

期待すること

あるレコードを削除するとき、条件に合わない場合レコードの削除を成功しないようにしたい。

さらにdependent: :destroyなど関連レコードを一緒に削除する場合、関連レコード側が削除できない条件にひっかかった場合、元もと削除しようとしたレコードも削除できてはいけない。

その制約をなんとかして担保したい。

実際やったこと

まず最小限のサンプルとしてRailsでProjectとTodoのモデルがどうなってるか確認したいと思います。

親となるProject

# /app/models/project.rb

# == Schema Information
#
# Table name: projects
#
#  id          :bigint           not null, primary key
#  title       :string           not null
#  created_at  :datetime         not null
#  updated_at  :datetime         not null
#
class Project < ApplicationRecord
  has_many :todos, dependent: :destroy
end

そしてその子であるTodo

# /app/models/todo.rb

# == Schema Information
#
# Table name: todos
#
#  id          :bigint           not null, primary key
#  project_id  :bigint           not null
#  title       :string           not null
#  state       :integer          default(0) not null
#  created_at  :datetime         not null
#  updated_at  :datetime         not null
#
class Todo < ApplicationRecord
  belongs_to :project

  enum state: { backlog: 0, wip: 1, done: 2 }
end

という感じです。stateは今回はenumで定義してDB的にはIntegerにしました。

今この状態では特になにもしてないので、

todo.destroy!とするとエラーもなくレコードが削除されますね。

projectがいくつかtodoをもっている場合、project.destroy!すると、dependent: :destroyが設定されているため、子のtodoも同時に削除されるはずです。コンソールでやるとなると

$ bin/rails c -s
#
> project = Project.create(title: 'new project')
...
> todo1 = Todo.create(title: 'todo1', project: project)
...
> todo2 = Todo.create(title: 'todo2', project: project)
...
# ここまでで project は 2つのtodoを持つ状態

> todo2.destroy!
# todo2単体が削除される

> project.destroy!
# projectと子のtodo1が削除される

という感じでしょうか。

では、前述のとおり、現在wipな状態にあるtodoを削除できなくさせたいとします。

これにはActiveRecord::Callbacks の before_destroyを使ってdestroy時に状態を確認するメソッドを作って指定します。今回はwipではないことを保証するとしてensure_not_in_progressというメソッドをつくることにします。

# /app/models/todo.rb

class Todo < ApplicationRecord
  belongs_to :project

  enum state: { backlog: 0, wip: 1, done: 2 }

  before_destroy :ensure_not_in_progress

  private

  def ensure_not_in_progress
    if wip?
      errors.add(:base, 'todo is still work in progress')
      throw :abort
    end
  end
end

という感じですね。ちなみにRailsのenumを使うとenumの定義に?がついた、 確認用のメソッドが自動で生えます。つまりwip?というメソッドはenum定義時に自動で使えるようになっていて、stateがwipの場合はtrueを返してくれます。

そしてwip?がtrueなら、まずバリデーションメソッドと同じようにerrors.addでエラーを追加します。そして大事なのがthrow :abortです。これによって削除が成功しないように止めることができます。

ではまたコンソールで試してみましょう。

1projectに1つは普通のtodo、もう1つはwipなtodoを作ります。

$ bin/rails c -s
#
> project = Project.create(title: 'new project')
...
> todo = Todo.create(title: 'todo', project: project)
...
> wip_todo = Todo.create(title: 'wip_todo', project: project, state: :wip)
...
# ここまでで project は stateがbacklogとwipのtodo1つづつを持つ状態

# wip_todoの削除を試みる

> wip_todo.destroy!
ActiveRecord::RecordNotDestroyed: Failed to destroy the record

# 削除できないことを確かめられました！

はい、これで期待どおり削除できないようになりました。そのまま続けて親のprojectを削除しようとするとどうなるかも見ていきましょう

> project.destroy!
D, [2021-02-27T20:51:39.855214 #1555] DEBUG -- :    (0.2ms)  SAVEPOINT active_record_1
D, [2021-02-27T20:51:39.860684 #1555] DEBUG -- :   Todo Load (4.7ms)  SELECT `todos`.* FROM `todos` WHERE `todos`.`project_id` = 1
D, [2021-02-27T20:51:39.863723 #1555] DEBUG -- :   Todo Destroy (0.3ms)  DELETE FROM `todos` WHERE `todos`.`id` = 1
D, [2021-02-27T20:51:39.891990 #1555] DEBUG -- :    (26.1ms)  ROLLBACK TO SAVEPOINT active_record_1
ActiveRecord::RecordNotDestroyed: Failed to destroy the record

# 削除できないことを確認できた！

はい、こちらも削除できないですね。ちゃんとROLLBACKしてくれています。削除できるもう片方の子も削除されていませんね。

これであとはstateがwipじゃなくなったら削除できればいいですね、それも試してみましょう。

> wip_todo.update!(state: :done)
#  wip_todo の state を done に変更

> project.reload
# projectのインスタンスをreloadして子のtodosを取得しなおし

> project.destroy!
D, [2021-02-27T20:54:53.359573 #1555] DEBUG -- :    (0.2ms)  SAVEPOINT active_record_1
D, [2021-02-27T20:54:53.361002 #1555] DEBUG -- :   Todo Load (0.4ms)  SELECT `todos`.* FROM `todos` WHERE `todos`.`project_id` = 1
D, [2021-02-27T20:54:53.364240 #1555] DEBUG -- :   Todo Destroy (0.3ms)  DELETE FROM `todos` WHERE `todos`.`id` = 1
D, [2021-02-27T20:54:53.365608 #1555] DEBUG -- :   Todo Destroy (0.2ms)  DELETE FROM `todos` WHERE `todos`.`id` = 2
D, [2021-02-27T20:54:53.366736 #1555] DEBUG -- :   Project Destroy (0.2ms)  DELETE FROM `projects` WHERE `projects`.`id` = 1
D, [2021-02-27T20:54:53.367482 #1555] DEBUG -- :    (0.1ms)  RELEASE SAVEPOINT active_record_1

はい、wipではないので期待どおりprojectとそれがもつ2つのtodoごと削除が成功しました。

今回あまり触れなかったこと

上記ではあまり触れてないですが、destroy!としているところdestroyにすると単純に失敗した場合falseが返ります。成否を判定して処理を変える場合でないのであれば基本的には!付きのほうがエラーがわかりやすくていいですね。

あとは当然deleteやdelete_allの場合は効きません。が、意図的にそれらを使わないときの削除は基本destroyを使うのが一般的なので問題ないはずです。

感想

今回は削除時にある条件によっては削除が失敗する実装をしました。コールバックメソッドは賛否両論ありますが、今回のように1モデル内で簡潔するような単純な場合はアリかな、と思っています。

それでなかったら削除用のメソッドやサービスを別で作ることになり、それはそれで使い忘れるという不安な点もありますし。

ともあれ、簡単ですが使いどころは意外に多いので備忘録的に書いておきます。

まとめ

• 英語の技術記事が良かったので翻訳することで学習に役立てようとした
• どうも上手く訳せなかった部分もあったのでDeepLも使ってみた
• DeepLのほうが良かったのと、（僕は）英語は英語のままで理解できるので翻訳駆動学習が駆動しなかった

DeepL is何？

来た道[2021-01]

出来事/体験

なにか特筆すべきはなかったように思いますね。やはりコロナ禍の今は何か新しい出来事が起こりにくい、起こしにくいですね。ううむ。

習慣

ストレッチをまた再開しました。今度はちゃんと本を見て、カウントするタイマーをセットしてやっています。痛みを少し感じるまで、とか伸びるまで、とかではなくカウントでやるのはやりやすいですね。

アウトプット/創作活動

ブログは良い感じでできてますね。やはり昨年終わりに見につけた日々、ちょこちょこ書く戦略が僕には向いてるようです。

装備、環境

こちらも特に変わりなし。

お仕事環境

昨年終わりごろから変わらずフロントエンドやっています。やればやるほどサーバーサイドとの違いやフロント専任の人との格差を思い知らされちょっと疲れてきました。こう、ただでさえ自分で自分の自己肯定感を削るタイプなところに追い打ちをかけられるような。

現プロジェクトが落ちつくまではやりますが、その後、フロントエンドに完全に転身するかというと、そのモチベーションはあまりないかな、という気持ち。

消費趣味

Ghost of Tsushimaのマルチが一段落して今はRemnant from the Ashesに戻ってきました。やはりこのゲーム面白いです。最近の僕はシビア目なCoopが性に合うという自覚を得ました。

OKR

1. Objective: 継続的なアウトプット駆動でスキルアップを実現する

   • ✅ KR：最低週4ではアウトプットする時間を実践する

2. Objective: 平穏な心とともに日々を楽しむ

   • ❌ KR：毎日、最低でも朝昼晩のどこかで心身とも安らぐ時間をつくること

アウトプット、主にブログを書いていますがこれは良い感じでした。濃度はともかく技術系記事ばかりだったのも良かったです。

一方で「心身とも安らぐ時間」を具体的にどうしていいかわからずでした。月の半ばからストレッチをやってみましたが、心身ともに安らいでるかと言うとNOですね。仕事のお昼休みにヨガのシャバーサナを意識してねっころがってたりもします。瞑想もちょっとまたやってみたり。でもどれもしっくり来ない感がありますね。

結局総じて特に何もない一月でした。ただメンタルも現在進行形であまり良くないのでローギアで進む月だったのでしょう。焦らずです。

行く道[2021-02]

• □ 最低週4でストレッチする
• □ 最低週4で積んでる技術書、実用書を読む
• □ 最低週4で何か運動する

いつもOKR式でやっていますが、考えて考えてもコレといってピンとこなかったので粛々と小さなことから習慣化に向けてやっていきます。

なんでも習慣化する、しないの境界は週4回らしいです。週4以上のペースを保つとそのまま習慣化する確率が高く、それを下回ると習慣化しにくいらしいです。それを約8週は続けるのが良いさそうな。

今月はガッと頑張るのではなくローギアで一歩ずつ行こうと思います。

概要

• Railsの脆弱性診断にBrakemanを使う
• CI（GitHub Action）で自動で診断するようにする

Brakeman is何？

BrakemanはRails用の脆弱性診断Gemです。SQLインジェクションなどの代表的な脆弱性を始め、様々な脆弱性を静的解析してくれます。これをやっておけば完璧、ということではありませんが転ばぬ先の杖として定期的に診断しておくと安心です。

期待すること

もしもうっかり脆弱性を含んだ実装をしてしまった場合、リリースする前やマージする前に気づいて脆弱性を含んだアプリケーションをリリースしてしまうことを防ぎたい、というのがモチベーションです。

実際やったこと

ずBrakemanをインストールします。普通にgem installしたり、RailsのGemfileに書いたり、Dockerで走らせたり、といろいろありますが、今回はシンプルにGemfileに書いていこうと思います。

group :development do
  gem 'brakeman', require: false
end

ですね。そうしたらいつもどおり bundle installを実行します。これで入ったはずなのでとりあえず実行してみましょう。

$ bundle exec brakeman
# =>
Loading scanner...
Processing application in /path/to/rails_project
Processing gems...
[Notice] Detected Rails 6 application
Processing configuration...
[Notice] Escaping HTML by default
Parsing files...

みたいな感じで実行され、結果がでると思います。例えばここで、あえてSQLインジェクションの可能性を持つコードを書いてみましょう。

User.where("name = '#{params[:name]}'")

こんな感じ。それで再度Brakemanを回すと

$ bundle exec brakeman
# =>
Loading scanner...
# 中略...
== Warning Types ==

SQL Injection: 1

== Warnings ==

Confidence: High
Category: SQL Injection
Check: SQL
Message: Possible SQL injection
Code: User.where("name = '#{params[:name]}'")
File: app/controllers/home_controller.rb
Line: 4

のように表示されます。想定どおり検出されました。

自動化する

せっかく検出できることがわかりましたが手動で実行するのは心もとないですね。

できれば自動でチェックするのが良いでしょう。

パっと思いつく手段としてはGit hooksのpre-commitやpre-pushでやるか、CIでやるかでしょうか。

CIでできるのであれば個人的に前者はお勧めしません。Git hooksは—no-verifyオプションで回避できますし、個人の設定如何で変わってしまうので担保にするには弱いです。

ではCIでやることにしましょうか。幸い、最近のGitHubではGitHub Actionが使えますのでそれでやってみます。

.github/workflows/brakeman.ymlを作り

name: brakeman
on:
  - pull_request
jobs:
  brakeman:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-ruby@v1
        with:
          ruby-version: '2.7'
      - run: gem install --no-document bundler
      - run: bundle install --quiet --jobs 4 --retry 3
      - run: bundle exec brakeman -Aqw1 --no-pager

と書きます（runで指定しているオプションは一例なので必要に応じて変更してください）

次にGitHubにpushしPull Requestを作ります。そうするとこのYAMLに従って、GitHub Actionsが走り、最終的に

と表示されます。

もちろん誤検出や大丈夫なケースもありますし、逆にBrakemanでは検出できない脆弱性もあると思うので工夫が必要ですが、ひとまずこれで疑わしきコードの混入に気づきやすいようになったはずです。

今回触れなかったこと

上にも書いたようにBrakemanの設定オプションにはあまり触れませんでした。—helpで見るか

今回はそれをキャッチアップしながら導入してみます。

概要

• エラー監視のためにsentryをRailsで使えるようにしたい
• sentry-Ruby, sentry-railsを使ってsentryを導入する（not sentry-raven）
• 実際に試してみる

Sentry is何？

Sentryとはアプリケーション監視、とりわけエラー監視ツールのSaaSです。Developer Planであれば件数の制限こそありますが無料で使いはじめることができます。

フロントエンドでもサーバーサイドでもどちらでも使うことができ、対応する言語やフレームワークも多く、導入も簡単なので手始めに入れるにはもってこいです。

なぜやったか

動機はエラー監視したいこと。やはり動作確認だけでは限界がありますし、ユーザーが実際にどんなエラーに遭遇しているかも知りたいです。また関連するAPIなどを使っている場合、連携先に問題がおこってる場合でも把握しやすいです。

冒頭でも書いたように、Railsで使うには今まではsentry-ravenというGemを使っていました。それが開発が終了し、メンテンスモードに入りました。これからはsentry-rubyとsentry-railsを使うように案内されているため、実際にやりながら導入してみようという流れです。

期待すること

sentry-ravenを使わない方法でRailsで出たエラーをsentryで監視、なんらかの方法で開発者に通知する、というのが今回のゴールです。

実際やったこと

Sentryに登録

ここからSignUpします（すでにしてある場合は不要）

gem "sentry-ruby"
gem "sentry-rails"

Sentry.init do |config|
  config.dsn = 'https://examplePublicKey@o0.ingest.sentry.io/0' # ここは書き換えが必要
  config.breadcrumbs_logger = [:active_support_logger]

  # To activate performance monitoring, set one of these options.
  # We recommend adjusting the value in production:
  config.traces_sample_rate = 0.5
  # or
  config.traces_sampler = lambda do |context|
    true
  end
end

config.enabled_environments = %w[production]
config.environment = Rails.env

config.send_default_pii = true

class ApplicationController < ActionController::Base
  before_action :set_sentry_context

  private

  def set_sentry_context
    Sentry.set_user(id: current_user&.id)
  end
end

Sentry.init do |config|
  filter = ActiveSupport::ParameterFilter.new(Rails.application.config.filter_parameters)
  config.before_send = lambda do |event, hint|
    # note1: if you have config.async configured, the event here will be a Hash instead of an Event object
    # note2: the code below is just an example, you should adjust the logic based on your needs
    event.request.data = filter.filter(event.request.data)
    event
  end
end

概要

• JavaScriptでは文字列のカウントはlengthメソッドでは不十分
• サロゲートペアを含む文字列のカウントがズレる
• 代替の方法と正規表現のカウントについて

普通にやる文字数カウント

TypeScriptを含むJavaScriptのフロントエンド環境では、例えばフォームの文字数によるバリデーションなどを代表として文字列をカウントする状況があると思います。

特に深く考えず文字数のカウントをする場合は、String.lengthと書くと思います。

しかし、実はこのlengthは厳密には文字数ではなくコードユニット数です。これで問題になるのがUnicodeでサロゲートペアを含む文字列です。

では、ちょっと動きを見てみます。

'aeiou'.length
// => 5
'あいうえお'.length
// => 5
'ニコ😀'.length
// => 4
'𠮷野屋'.length
// => 4

となります。

絵文字だけならまだしも一部、漢字の異体字も2文字判定になります。

これが困るケースはフロントエンドでのカウントとサーバーサイドやDB側でのカウントにズレがある場合ですね。

正確にやる文字数カウント

では、どうすればいいかというと結論から言えば[...string].lengthでカウントする方法です。

[...'aeiou'].length
// => 5
[...'あいうえお'].length
// => 5
[...'ニコ😀'].length
// => 3
[...'𠮷野屋'].length
// => 3

解説すると、配列の中で文字列をスプレッド構文で展開、配列の要素数を数えることで正確な文字数を出しています。

ちなみにこの方法はMDNにも案内されています。

/^.{5,10}$/.test('aeiouあいうえお')
// => true

/^.{5,10}$/.test('aeiouあいうえ😀')
// => false

/^\w{5,10}$/.test('aeiouあいうえお')
// => false
/^\w{5,10}$/.test('aeiouuoiea')
// => true

デフォルトで設定されているもの以外、拡張機能で追加されるものもありますし、キーマップセット専用の拡張もあります。これらは基本的に便利なんですが、中には自分の好みと合わないものもあります。そして場合によっては意図せず発火してしまい、何が発火してるかわからないと変更も難しいという逆に使いづらい現象にハマります。

今回はそれを特定し、不使用にしたという話。

概要

• 意図せず発火し、何が発火しているかわからないので調べて潰しようがないものがあった
• VSCodeで発火しているショートカットを調べる方法
• 調べて判明したらそのショートカットを潰す方法

動機

様々なケースがあると思いますが、今回、僕の状況としてはEmacsキーバインドを実現するための拡張、Awesome Emacs Keymapを使っています。

[2021-01-11 16:59:30.988] [renderer7] [info] [KeybindingService]: / Received  keydown event - modifiers: <key>Ctrl</key>], <key>c</key>ode: KeyB, keyCode: 66, key: b
[2021-01-11 16:59:30.988] [renderer7] [info] [KeybindingService]: | Converted keydown event - modifiers: <key>Ctrl</key>], <key>c</key>ode: KeyB, keyCode: 32 ('B')
[2021-01-11 16:59:30.988] [renderer7] [info] [KeybindingService]: | Resolving<key>Ctrl</key>+[K<key>e</key>yB]
[2021-01-11 16:59:30.988] [renderer7] [info] [KeybindingService]: \ From 4 keybinding entries, matched emacs-mcx.executeCommands, when: editorFocus && findWidgetVisible && !isComposing && !replaceInputFocussed, source: user extension tuttieee.emacs-mcx.

{
    "key": "Ctrl + b",
    "command": "-emacs-mcx.executeCommands",
    "when": "editorFocus && findWidgetVisible && !isComposing && !replaceInputFocussed"
},

テストコードというものは必要だし、大切だし、適切に使えばそれはそれは心強い武器となります。が、そうはいってもやはり書くのが手間で、人間面倒だとつい疎かになりがちですね。

今回はRSpecを書くにあたってちょっと横着するための手段として、aggregate_failuresの設定とRequestDescriberの導入をしていきます。

概要

• テストの必要性や有用性は十分に理解してるもののやはり面倒
• だから少しでも楽をしたい
• 設定の変更と、Gemを入れてちょっと楽に書こう

aggregate_failures is何？

it "ユーザーの姓、名がレスポンスにあること" do
  subject
  expect(response.body).to include user.first_name
  expect(response.body).to include user.last_name
end

it "ユーザーの姓、名がレスポンスにあること" do
  subject
  aggregate_failures do
  expect(response.body).to include user.first_name
  expect(response.body).to include user.last_name
end

RSpec.configure do |config|
  config.define_derived_metadata do |meta|
    meta[:aggregate_failures] = true
  end
end

group :test do
  gem 'rspec-request_describer' 
end

RSpec.configure do |config|
  config.include RSpec::RequestDescriber, type: :request
end

RSpec.describe 'GET /users' do
  it { is_expected.to eq 200 }
end

require 'rails_helper'

RSpec.describe "Achievements", type: :request do
  describe "GET /achievements" do
    subject { get "/achievements" }
    let(:achievements) { FactoryBot.create_list :achievement, 3 }

    before do
      FactoryBot.create_list(:achievement, 3)
    end

    it "returns 200" do
      subject
      expect(response.status).to eq 200
    end

    it "returns body with achievements" do
      subject
      expect(response.body).to include Achievement.first.title
    end
  end
end

require 'rails_helper'

RSpec.describe "Achievements", type: :request do
  describe "GET /achievements" do
    let(:achievements) { FactoryBot.create_list :achievement, 3 }

    before do
      FactoryBot.create_list(:achievement, 3)
    end

    it "returns 200 with achievement titles" do
      is_expected.to eq 200
      expect(response.body).to include Achievement.first.title
    end
  end
end