今年はお正月だなあというイベントもなく、普通に過ごしていたのですぐに仕事モードに切り替えられました。

さあ今日も振り返っていきましょう。

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 で入ることができました。これによってローカルでは再現しない内容も再現することができ、解決に至ることができました。
  • https://qiita.com/shonansurvivors/items/cb8902acfe5c3a1b3ca0