コンサル一年目が学ぶことを今更ながら読んだ
二年前に少しチラ見しただけで終わってしまっていたので改めて読んだ。
仕事上必要になることだけでなく、プライベートでの会話でも勉強になることが書いてあり読んでよかった。
特筆したいことを抜粋して記載する
結論から簡潔に話す
結論から簡潔に話す。これは普段から意識して経験を積まないととても難しい。
都道府県ごとのコロナウイルスの感染者数が報道されなくなってしばらく経つが、
そうでなくとも普段の仕事でチャットツールを使うことが多い。
そうなるとやはり文章から情報を効率良く得るには結局結論、理由、具体事例、結論の順が一番良いと実感したし、
書籍内に書いてあってなお理解を深めることができた。
なんとなくわかっていたことが言語化できたといったところか。
しかし、文章ならばじっくり考えて相手に伝えられるが対面での会話だとそうもいかない。
つい焦ってすぐ返答してしまいがちなのだ。
特に社内ではなく顧客との会議だとなおさらだ。
なので、書籍にあったように考える時間をすこしくださいと伝えるのは自分にとってハードルがとても高いがこれは実践していくしかないと思っている。
前提を話す
自分はつい前提が抜けてしまうことが多い。
主語が抜けるともいう。
書籍にもあったのでもしかすると自分だけではなく多くの人が陥りがちなのかもしれない。
前提がないとやはり相手に確認されてしまうし理解も遅くなってしまう。
これはプライベートでも気を付けて損がないところだと思う。
本当にやりがちなので気を付ける。
端的に事実を伝える
例えば遅れが生じているとき。
進捗を聞かれるとつい、
「あの…これこれこういうことがあり…」
と言い訳からしたくなる。
この思考に至っても言い訳から入りたくなる時もあるが、
仕事上だと遅れていることを変えようがないので早く伝えてどうにかしたほうが結果会社のためになる。
言い訳してもいいことがないのだ。
何か理由があるなら遅れています！と伝えたうえで変な人でなければ理由（言い訳）を聞いてくれる。
逆に言い訳をしなければならないとなると、
そこは関係性が良くないのかもしれない。
相手との関係を見直せるなら見直すか、環境を変えたほうがいいと思う。
git commitの時にコードが自動整形されて凄かった
二つのプロジェクトを掛け持ちしている。
片方のプロジェクトはインデントは半角スペース4つ
もう一つは2つ
普段は2つのプロジェクトを触っているが、偶に4つの方を触ることがある。
困るのはインデントが半角4つのプロジェクトで新規ファイル作成時、
インデントが2つの方になってしまい直すのがクソ面倒臭かった。
わざわざスペースをちまちま入れていかなければならない。
整形ライブラリも入ってないので本当に手作業なのだ。
PR作成時に指摘はしてくれるようになっているが、数が多すぎると見切れないしレビューをしてもらうにも邪魔なのだ。
その時はインデント以外にもルールに沿ってない場所があり、botにものすごい数のコメントつけられて白目剥いた。PRは一旦クローズした。
ものすごく面倒なので自動でフォーマットしてよ！！！と思ったがインデント2つの方にはすでに入っているのだった。
自動整形してくれるライブラリが！！！
コミット前に自動整形させよう
コミット前に何かを実行するにはhuskyというライブラリがいる。
typicode.github.io
また、自動整形にはPretterが必要だ。
typescriptbook.jp
上記はTypeScriptでの説明だが何の言語で使っても大体同じだろう。
また、JavascriptならESLintでのチェックを挟むこともできる。
いちいち構文チェック走らせて、コードの体裁整えて…はしなくてよいのだ。
エラーがあるとそもそもコミットができないので、コミット後に体裁整えとかいうコミットメッセージでコミットしなおしたり、
git rebase -i でスカッシュして隠ぺいしたりしなくていいのだ。
自動整形が入っていないプロジェクトの方は相乗りしている形なので自分が口をはさむ余地はないが、
これからは絶対に自動整形を導入したい。
CORSエラーと戦った話
CORSエラーと戦った。
Access to XMLHttpRequest at 'http://~~' from origin 'http://~~0' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
こんなやつ。
Next.jsのプロジェクトで結構無茶なことを行い、結果CORSエラーがでない形で実装したので備忘録として書いていく
共通HTMLを外部から読み込みたい
外部から提供されているHTMLパーツ（CSS、jQuery付）をNext.jsのプロジェクトで読み込んでほしいという依頼があった。
SEOのことを考えて、サーバーサイドレンダリング時に読み込みたいらしい。
そうなると、下記手順となる。
①PagesでHTMLを文字列として取得する。
②取得したHTMLをライブラリ（自分はhtml-react-parserを使用した）でDOMにパースし、Document.jsにて埋め込む
404などの静的ページではサーバーサイドレンダリングが行われない
nextjs.org
大体Document.jsに定義すればCSSファイルもjsファイルも読み込んでくれるのだが、
しかし404や500などのエラーページではサーバーサイドレンダリングが行われないため、
Document.jsが読み込まれないのだ。
これでは共通HTMLを読み込むことができない。
そこで最初はapp.jsでfetch定義しようとしたが、ここで表題のCORSエラーにぶち当たることになる
CORSエラーがなぜ今になって発生したのか
サーバーサイドレンダリングでは起きていなかったCORSエラーがなぜ発生するのか。
それはBasic認証の問題やサーバーサイドでの通信かクライアントでの通信かなど、複数条件が絡み合っていた。
Basic認証が共通HTMLの方にかかっていると、サーバー側では一度fetch時に認証するものの、再度クライアント側でも入力を求めてくる。
（別タブで既に認証済みであれば要求されない）
だが、クライアント側では再度の入力を求められず、結果として認証エラー（CORSエラー）が発生するのだ
なのでfetch時のみ認証が通ればよいということではなかった。
これはクライアント（ブラウザ）の挙動によるところがあり、
chromeでは再度の入力をアラートで求めてくるが、safariでは求められないためそのままCORSエラーとなった。
また、サーバー側よりもクライアント側のほうが制約が厳しい。このためサーバーサイドレンダリングではエラーが発生しなかった。
共通HTMLを提供している側にAccess-Control-Allow-Originの設定をしてもらったものの、
Basic認証がかかっているとうまく突破できず、けっきょく*を指定してもエラーを解消できなかった。
（提供側に行ってもらった作業であり、こちらで確認できたわけではない。）
静的ページを使わないことにする
要はクライアント側での通信からエラーが始まっているので、error.jsを作成することにした。
nextjs-ja-translation-docs.vercel.app
ただこの場合、ルーティングがないURLはすべてerror.jsに飛んでしまうため、
ヘルスチェックなどのURLを作成している場合はルーティング定義が必要となる。
まとめ
単純にCORSエラーに対処したという記事ではないが、対処の方法はたくさんあるのであえてクライアント側での通信を避けた経験を記載した。
十二国記 月の影 影の海（下）を読んだ
面白かったので続きをすぐに読んだ。
十二国記の世界にいった後も陽子には優しい世界ではなく、なんだかとてもつらい出来事ばかり。
そのうちに助けてくれるネズミに出会ったところで、そういえば友人がネズミがでてきたらもう安心と言っていたのを思い出した。
合点がいく。
ネズミ可愛い。
と思ったら人型になれるらしい。
面白いものほど感想がへってしまう（面白かった よかったになってしまうので）
のだが、すごいよかった ネズミが人型でいままですごい陽子の支えになっていて…おお…
陽子が元の世界か、今の世界かを迷ってしまう理由がとても分かってしまって少し辛い
こういう時の両親の描写が少し苦手かもしれない。
いくらもともとこちらの世界の人間だからって、愛情をもって育ててきたはずなので…
しかし、今少し障りがあるのところ、ものすごく好みでそれ以外の感想が正直吹き飛んでいる。
これは少女漫画ではないので期待したような展開にはならないのだろう。それは残念だ…
人型になれると知ってからもう一度獣状態である場面をみるとなんとも言えない気持ち（いい意味で）になる。
それなのに本当に残念だ…
友人によるとすべてではないもののこの先もネズミが出てくるらしいので、今度は自分で購入し続きを読みたいと思う
十二国記 月の影 影の海（上）を読んだ
本を開いたら初っ端地図で驚いた。
十二国の地図の隣に巧国北方図があったので、おそらく巧国の人の話がメインなのだろうと予測。
そう思いつつ読み進めると、友人からよく聞いた名がようやく出てきた。
この陽子という方を主人公だと読む前は認識しており、顔も知っていたのでなんだか安心した。
だがなんだか、よくありがちな普通に暮らしている（普通ではないということではないが…）特に問題なく学校生活を送っているわけではなく、
いじめがあったり先生から目の敵にされてみたり（教師の発言は今は大問題なのではないか、特に大勢の前で言うのは）、
なんだか少し出だしから疲れてしまう。
だがさっそく事が起こり、ファンタジーの色が見えてきた。
これもまた陽子の意に沿うものではなく、突然さらわれる形。
学校で事が起こるので子供の被害者が出るのではないかとひやひやしてしまった。
異世界に行ってからはダークファンタジーといった内容で、普通の女の子が異世界に飛ばされたら普通はそうなるよなあといった感じ。
食べるものが無く飢えてみたり、人間不信になってみたり、途中からおそらく陽子の疑心が生み出した生き物が話しかけてきたり。
しかし不思議と重過ぎず、すらすら読めてしまった。
とても途中なので、すぐ続きを読むと思う
今までやりづらくてテストを先に書くことを倦厭していたが先に書くことの良さを知った話
よくテストから書いたほうが良いと聞く。
過去は、バックエンドの複雑さからテストを先に書くことが辛く、ついつい後回しにしていた。
- テストを先に書くことの利点
明確な目標を定められる
結局どうなればいいんだっけ？から解放される。
（様々な条件により過程が変わることもあるが、それこそテストのパターンを増やせば補える。）
テストが通らないということはどこかが明確に間違っている証拠なので、
結果として今までのように画面からテストして
実装漏れを見つけるやり方よりも開発スピードが上がったように思う。
- 現在のプロジェクトについて
現在のプロジェクトではGoで開発を行っているのだが、
良いと思った点を下記に記述する
・テスト用のデータベースを作成している
もし共通の定数などがあれば環境構築時点で最低限のデータを投入しておけばよい。
テストに必要なデータはテスト実行時に投入して、テスト後に削除している。
・関数名に日本語を併用しており、なんのテストケースなのかすぐわかる
日本語も記述できるのは驚いた。
もし複雑な条件だったりテスト観点が複数ある場合は、
関数の最初にコメントで書いておけば関数名自体は簡素でもわかりやすかった。
・単体でテストを実行できるようにする仕組みがある
vscodeでrun testを行えばすぐ単体でテストできるような仕組みを作ってあったのがまた良かった。
なぜかLaravelのプロジェクトの時はテストがやたら重く完了するまでに１０分以上かかり、
またファイル単位でしかテストが実行できないため不便だった。
おそらくテストも最適化が必要で、DBの処理に時間がかかっていたように思う(毎回作っては削除していたように思う)
また、プロジェクトが肥大化すればするほどすべてのテストを実行すると完了までに時間がかかるため、
単体でテストを実行できるようにする仕組みがあるとテストファーストが浸透するように思う。
- まとめ
バグを生まないためには開発に関わる全てのことがストレスフリーでないとならないと思った。
今回はテストに重点を置いているのでテストについて考慮すると、
テストが大事だということをわかってはいても、テストが書きづらいとおざなりになってしまうこともあるだろう。
テストケースがどこまで書かれているのかすぐわからなければ、追うのが大変で漏れてしまうこともあると思う。
テスト実行に時間がかかれば、なるべくテストケースは最低限で済ませたくなり、観点が足りないまま見過ごされてしまうこともあるかもしれない。
どうひっくり返っても開発とテストは切り離せないので、テスト周りの整備の重要性について書いた。
十二国記 魔性の子を読んだ
十二国記が好きな友人がいる。
その友人から贈られたので読んでみることにした。
後から知ったが、どうやら魔性の子は最初に読むかどうかは微妙な立ち位置らしい。
順番を見ると魔性の子が最初に書いてあるのでてっきり最初なのかと思ったが、
話に聞いていたファンタジーらしさがなにもなく進んでいく。
多少は、多少はあるのだが予想とあまりに違ったためｱﾚｯとなった。
また、子供でも容赦なく死ぬ。
なるほどねと思うので苦手な人は要注意。（私は犬が死ぬのが大地雷なので…）
内容としては、広瀬がすこし可愛そうな話だった。
自分が人とは違うという疎外感をもっていて、
高里に共感するのだが、高里は実際に広瀬が生まれてきた世界の住人ではないのでその感覚は正しい。
広瀬は単に周りになじめないだけなので、せっかく共感相手ができたのに自分とは違う存在なのである
自分が相手のことを好きで相手も好きなんだと思ってたら違ったみたいな（少し違う）
また、最後まで読むことでなぜ事件が起こっていたのかがわかるようになっているので、
悪い意味ではなく、単に結構長かったなあという満足感というか達成感というか…が味わえた。
だがあまり読後はよくない。ちょっと悲しいので…心が元気なときに、シリーズを読み進めたらまた読みたい作品なんだろうと思う。
