週刊ニュース Lv8（2023年1月7日～2023年1月13日）
Metadata
Date: January 14th, 2023
Category: 週刊ニュース
今年はお正月だなあというイベントもなく、普通に過ごしていたのですぐに仕事モードに切り替えられました。
さあ今日も振り返っていきましょう。
1月7日(土)
特になし
1月8日(日)
プロダクトの手順書周り更新した
プロダクトの手順が最初の頃変わってきていい頃合いだったのでガッと更新しました。
意外にまとめてみると書きたいことがたくさん出てきて結構時間かかってしまいました。
MUIのコンポーネントでちょっとしたパディングなどを共通化する方法を調べた
フォーム画面でMUIのStackコンポーネントにちょっとしたパディングを当てているのですが、これだと忘れますし、初めての人だと普通に漏れますよね…
<Stack paddingLeft={2} paddingRight={2}>
ということで軽く調べたところ以下のような方向性を感じました。
1. スタイル部分のみ別ファイルに切り出し、AコンポーネントやBコンポーネントでimportして使う
2. スタイルをコンポーネントと同じ場所に配置する
1は、一瞬良さげと思いましたが、結局importする必要があるから忘れたら意味ないよななど思いつつどちらがよいか判断できなかったのですが、emotionで推奨されている方法で下記の記述を見つけました。
スタイルをコンポーネントと同じ場所に配置する 通常の CSS では、コンポーネントのスタイルは別のファイルで定義されます。これにより、どのコンポーネントが特定の CSS を使用しているかを判断するのが難しくなり、コンポーネントを変更した後に関連する CSS を更新するのを忘れやすくなるため、メンテナンスがより困難になります。Emotion の主な利点の 1 つは、スタイルをコンポーネントと同じ場所に配置できることです。つまり、コンポーネントの CSS はコンポーネント自体と同じファイルにある必要があります。 https://emotion.sh/docs/best-practices
確かにスタイルを分離すると、どのコンポーネントがどのCSSを使っているかを判断するのが難しくなるので、コンポーネントに一緒にスタイルをカプセル化するのが良さそうと思いました。
負債タスクとコツコツタスクを統合、ボードを大改修
自社では負債っぽいものは負債ボードでタスクを起こして、中長期的に手を動かして改善していきたいものはコツコツボードでタスクを起こしてという風にしていたのですが、どちらに登録するか迷うということもあり一つのボードに統合しました。
ボードを統合したものの、ただ統合しただけでは中身は何も変わっていないのでこの機会にWinボードというものにリプレイスしました。
以下、リプレイスするためにやったことです(Notionを使っています)。
ボード名称を「Winボード」に変更
不要なプロパティ、一部プロパティ調整
プロパティの追加（得られる成果、Upvoted by (add yourself)、Upvotes、elapsed date）
ビュー調整（新着順、経過日順、いいね順、成果別、着手中、完了）
テンプレート更新
ここまで仕込んであとのタスクの内容を見直すのはDevメンバーに依頼することでガッと一気にリプレイスすることができました。
ボード名称をWInボードにしたのは、負債タスクもコツコツタスクもよくなるタスクなので最初はよくなるボードにしようと思ったのですが、自社ではすでによくなるDBというものがあり名前が被るので色々考えてWinボードにしました。Winボードのタスクをこなすことで負債に打ち勝つぞや己に打ち勝つぞみたいな意味合いがあったり、勝つためにやるぞとなるので個人的には気に入っています。
1月9日(月)
Stripeと戦った
決済機能が近いうちに入るのですが、実際に実装しようとしだして動くとかなり時間がかかる気がしたので個人的にStripe触りたいというものもあって先行で調査しています。
自社ではプラットフォーム上で決済を行ったら、プラットフォーム側で手数料を差し引いて、残りをサービス提供者に支払うというフローをやりたいのでStripe Connect機能を使いますがドキュメントを見てもﾅﾆﾓﾜｶﾗﾅｲ感じでした。
こういうケースは手を動かしてFBを得ていくのが効率がいいので、まずは決済を行う部分に着目して手を動かしていました。
customerオブジェクトやSetup Intents APIやPayment Element、PaymentIntents周りのことを知れたので大収穫でした。
とくに決済する人に関してはStripeアカウント作成する必要がないことがわかったのが大きかったです。
1月10日(火)
初めてのアジャイル現場
新しい現場では2週間スプリントでアジャイル開発をしています。
ガチガチのアジャイルは経験したことがないので、専門用語に苦労したり、タスクを判断していく早さに圧倒されて、スプリントレビューの時間だけでどっと疲れました。
アジャイルの良い部分はどんどん吸収して自社にも活かしていきたいです！
1月11日(水)
ボードを大改修した共有
勝手に自分でガッとやってしまったので、どんなことを言われるかと思っていたのですが良い反応をいただけたので嬉しかったです。
また、タスクをそれぞれ見直さないと着手するときに困るので、アサインした人にテンプレートを使って内容を見直してもらうのを依頼したところ、素早くガッとやっていただいたのはすごく助かりました。
自分もアサインしたものを見直しながら、結構Closeするものがあったり、内容が整理されてやるべきことが明確になったりと良い感触があったのでやって良かったです。
負債やよくなるタスクについて目をそむけずに全員で向き合っていけるような仕組みを引き続き作っていきます。
1月12日(木)
vim-lspで複数言語サーバーが動いていると:LspHoverが思ったように動いてくれない
typescriptのファイルで
efm-langserverとtypescript-language-serverが動くようになっているのですが、型情報などを知りたくて:LspHoverするとefm-langserverで:LspHoverしていまい、型情報が取れません。。efm-langserverを停止すると、typescript-language-serverで:LspHoverしてくれるのですが毎回停止するのも辛いので、いい方法がないかなと思っています…
1月13日(金)
GitHub Actionsで結構レアなCI確定落ちに当たった
直近でGitHub ActionsのrunnerをUbuntu20.04から22.04にアップデートしており、その影響で特定のjobのテストだけ確定で落ちるという事象にあたりました。
テストは4並列で実行しており、それぞれのテスト環境は全く同じでした。
色々調べたのですが、結論からいうとテストを実行する際にfindやgrep、xargsを使ってテストファイルを取得してテストを実行していたのですが、Ubuntuアップデートによってテストファイルの順番が変わったことによる影響でした。
OSアップデートするとそういう不具合も踏み抜くのかという気持ちでしたが、この調査に当たる上でよかったと思う行動は再現するGitHub Actionsのrunnner上でデバッグしたという点です。
下記記事を参考にすると、簡単にSSHで入ることができました。これによってローカルでは再現しない内容も再現することができ、解決に至ることができました。