# ビジネスサイドとのコラボレーションを重要視する理由

- 過去に、バグが起こりやすかったり、追加機能開発が難しいプロダクトの開発をしていたことがあった
    - 当時は自分もジュニアで、やりづらさを感じながらも解決できないままずるずると開発していた
- その後新しいCTOがビジネスサイドを巻き込んでシステム改修したことにより、事態が好転した
    - 具体的な内容
        - 使われていない、あるいは重要度の低い機能を消す
            - CSから顧客にフォローしてもらうことも含む
        - 新機能開発については、本当に使われる機能だけを作る
            - 営業やCSに、運用で回避できないかを問うことも含む
- 改修している中で、そもそも負債が積み重なっていたのは、ビジネスサイドと適切な連携を取りながら開発をしていなかったからだと気づいた
    - 1社しか使わないような機能を作ってしまっていた等
- こういう経験を経て、プロダクトのメンテナンス性や開発速度を高めるためには、ビジネスサイドとのコラボレーションが必須だと考えるようになった
    - また、「ビジネスサイドとの上手いコラボレーション」がどういうものなのかも常に意識するようになった

# 気をつけていること

## ニーズを明確にする

- 顧客から「こういう機能が欲しい」という要望をもらったときに、それをそのまま実現しようとしない
- ビジネスサイドには「なぜその機能が必要なのか」というニーズを明確にしてもらう
    - ビジネスサイドに頼りきるのではなく、自分からも「そう言っているのは、そもそもこういう課題があるのではないか」と仮説を出す
- 明確になったニーズに対して、どのような手段をとるべきかを一緒に考える

## 協力姿勢を示す

- 「ビジネスサイドが要望を出しても、開発サイドが受け入れてくれない」となりがちなので、顧客のことを考えているからこそ開発に慎重になっていることを伝える
- ビジネスサイドが顧客一人一人に向き合ってくれていることを理解しつつも、全要望に応えているとシステムが破綻し、結果的に全顧客に迷惑がかかることを伝える

ビジネスサイドとのコラボレーションで気をつけていること

- [最適解はStimulus](https://stimulus.hotwired.dev/)
- Turboと相性が悪いライブラリは、[ページを強制リロードさせる](https://zenn.dev/shita1112/books/cat-hotwire-turbo/viewer/turbo-drive#%E6%8C%87%E5%AE%9A%E3%83%9A%E3%83%BC%E3%82%B8%E3%81%AE%E5%BC%B7%E5%88%B6%E3%83%AA%E3%83%AD%E3%83%BC%E3%83%89)ことで組み込むことができる

Turbo環境でjsを使う

# Rails

- [Rails7.2のマイナーフィーチャーで気になったところ](https://gist.github.com/willnet/3cc38e20d44fb821209cb8a93c1310a5#%E3%83%AD%E3%82%B0%E3%81%8B%E3%82%89%E7%89%B9%E5%AE%9A%E3%81%AE%E3%82%A2%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%A7%E3%82%AF%E3%82%A8%E3%83%AA%E3%81%8C%E4%BD%95%E5%9B%9E%E5%AE%9F%E8%A1%8C%E3%81%95%E3%82%8C%E3%81%9F%E3%81%8B%E3%81%99%E3%81%90%E7%A2%BA%E8%AA%8D%E3%81%A7%E3%81%8D%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F)
  - `ログから、特定のアクションでクエリが何回実行されたかすぐ確認できるようになった`
- [ankane/production_rails](https://github.com/ankane/production_rails)

# フロント
- [プレースホルダーのアクセシビリティ上の課題と解決策](https://tech.smarthr.jp/entry/2024/03/12/170000)
- [View Transitions API入門 - 連続性のある画面遷移アニメーションを実現するウェブの新技術](https://ics.media/entry/230510/)
	- 全然知らなかった。実務で使うことはなさそうだけど、個人開発で無駄に使ってみるのも楽しそう。
- [相対カラー構文とround()関数を使うことで、背景色に応じて自動的に黒or白どちらか読みやすい前景色を適用することができる🫵](https://x.com/tak_dcxi/status/1834396580222304411)

# Github
- [持続可能なソフトウェア開発を支える『GitHub CI/CD実践ガイド』](https://speakerdeck.com/tmknom/github-cicd-book)
	- 普段dependabotを使っているが、Github Actionsでも使えるというのは知らなかった
	- セキュリティ観点で、車輪の再発明をするのもやむを得ないというのはとてもよく分かる

# その他
- [IPアドレスの例示で xxx.xxx.xxx.xxx を使うな](https://qiita.com/Targoyle/items/1c5454a41ea4519b0c5f)
	- 自動リンクになる場所でxxx〜を書いたことがないので、問題になったことはなかった気がするが、確かにこういうリスクはある

2024年9月のブックマーク

# 背景

- →[はじめに](https://work.aoi-life.link/posts/67)
- 自分はかつてはページのタイトルの文字列のみがページヘッダの要素だと思っていたが、調べるとそれだけでなさそう
    - パンくずやアクションやフィルタ、ソート機能の要素もページヘッダとすることが多い

# 目的

- ページヘッダのコンポーネント開発方針を決める

# デザインシステムの比較

## Primer

- [Components→Page header→Anatomy](https://primer.style/components/page-header#anatomy)
- 下記4つのエリアからなる
    - Context bar
        - パンくずや親ページへのリンクなど
        - 狭い画面サイズでないと表示しないと書いてあるが、その理由は分からなかった
            - Githubを見る限り、PCサイズでもContext barは表示されているように思えた
    - Title bar
        - ページタイトルやバックボタンなど
    - Description
        - 説明文
    - Navigation
        - タブなど

## Atlassian

- [Components→Page header→Usage](https://atlassian.design/components/page-header/usage)
- 4つのエリアからなる
    - Breadcrumbs
    - Title
    - Actions
    - Search bar and filters

# 自分のページヘッダ方針

- Primerに合わせる

# 自分のコンポーネント開発方針

- PegeHeaderコンポーネントを作成し、下記スロットを持たせる
    - Context bar
    - Title bar
        - スロットとしてLeading action（もどるボタンなど）、Title、Actionsを持つ
    - Description
    - Navigation

# 次やること

- 一覧ページレイアウトのコンポーネントを作成する

コンポーネント開発方針決め-ページヘッダ

# 背景

- →[はじめに](https://work.aoi-life.link/posts/67)
- ページのレイアウトは要素が多く、どう整理すれば良いか分からない
    - 「ページタイトル-コンテンツ」ぐらいであれば迷わないが、実際は2つの間に説明文があったりする
    - ページの横にサブメニュー的なものや検索フォームを置くことも多く、ますますどう整理すれば良いか分からない

# 目的

- ページレイアウトのコンポーネント開発方針を決める

# デザインシステムの比較

各デザインシステムのサイトの「Layout」や「Pattern」などを確認した。

## Primer

- [Foundation→Layout→Page types](https://primer.style/foundations/layout#page-types)
- 主に3種類としている
    - Full pages
        - 基本的なタイプ
        - Header、Content、Pane、Footer
    - Split pages
        - Pane、Content
    - Interstitial pages
        - Header、Content
- コンポーネントとして[Page layout](https://primer.style/components/page-layout/react/alpha)を提供している

## Material Design

- [Foundations→Overview](https://m3.material.io/foundations/layout/canonical-layouts/overview)
- 主に3種類としている
    - Feed
        - ページいっぱいにグリッドレイアウト
    - List-detail
        - ListとDetailの2エリア
        - 親子関係があるコンテンツの表示に使う
    - Supporting pane
        - プライマリコンテンツとセカンダリコンテンツの2エリア
        - 親子関係はないが、関連のあるコンテンツの表示に使う

## Polaris

- [Patterns](https://polaris.shopify.com/patterns)
- ページレイアウトについては主に3種類としている
    - App settings layout
        - 2カラム
            - ラベルや説明があるカラム
            - 入力欄のカラム
    - Resource index layout
        - 1カラムで、下記の3エリアに分かれる
            - タイトルやアクション
            - フィルタやソート
            - リスト
    - Resource details layout
        - 1カラムで、ページヘッダとメインコンテンツの2エリアに分かれる
        - メインコンテンツは下記の2カラム
            - プライマリコンテンツ
            - セカンダリコンテンツ

# 自分のページレイアウト方針

- PrimerのInterstitial pagesとPolarisを合わせたようなページレイアウトを作成する
    - 命名はPolarisに合わせる
    - Material Designのようにリストと詳細を同時に表示する実装は多くやるわけではないので、今回は考えない

# 自分のコンポーネント開発方針

- 4つのページレイアウトコンポーネントを作成する
    - InterstitialPageLayout
        - スロットとして、Header、Contentがある
        - 中央揃えにする
    - SettingPageLayout
        - スロットとして、Header、Contentがある
    - IndexPageLayout
        - スロットとして、Header、Content、Paneがある
    - DetailPageLayout
        - スロットとして、Header、Content、Paneがある

# 次にやること

- PageHeaderコンポーネントの開発方針を決める

コンポーネント開発方針決め-ページレイアウト

# 背景

- →[はじめに](/posts/67)
- アプリの一番外のレイアウトのパターンがはっきりしない
    - UIライブラリのコードでいうとAppProvider的な要素の真下に来るものをどう整理すれば良いかわからない
- 概ね「ヘッダ-メニュー＋コンテンツ-フッタ」であると思うが、下記のような例外もあり、自分の中でうまくパターン分けできていない
    - サインアップ系の画面だと「ヘッダ、コンテンツ」だけになる
    - メニューがヘッダやフッタを突き抜けて「メニュー-ヘッダ+コンテンツ+フッタ」という2カラム構成になるものもある

# 前提

- 以降、一番外のレイアウトを「アプリレイアウト」と呼ぶことにする

# 目的

- アプリレイアウトのコンポーネント開発方針を決める

# デザインシステムの比較

調べた限りでは、アプリレイアウトに言及せず、その1階層下のレイアウトから言及しているデザインシステムが多かった。

## Material Design

- [Foundation→Layout→Layout basics→Parts of layout](https://m3.material.io/foundations/layout/understanding-layout/parts-of-layout)
- NavigationとBodyの2領域としている
- **ヘッダがない**
    - デザインシステムのサイト自体にもヘッダがない
    - コンポーネントとして[Top app bar](https://m3.material.io/components/top-app-bar/overview)があるが、あくまでBodyの中で使うものの様子

## Ant Design

- [Components→Layout→Layout→Basic structure](https://ant.design/components/layout#layout-demo-basic)
- 例として4パターンあげている
    - パターン1
        - Header
        - Content
        - Footer
    - パターン2
        - Header
        - Sider+Content
        - Footer
    - パターン3
        - パターン2のSiderとContentが入れ替わっただけ
    - パターン4（メニューがヘッダとフッタを突き抜けるパターン）
        - 1カラム目
            - Sider
        - 2カラム目
            - Header
            - Content
            - Footer

# 自分のアプリレイアウト方針

- Material Designのように、Navigation+Bodyに2カラム構成にする
    - Ant Designのようなアプリレイアウトの方が自分には馴染み深いが、レスポンシブ化対応を考えるとMaterial Designの方が今後楽になりそう
    - 前から薄々「ヘッダをスペースの割に有効活用できない」と思っていたので、思い切って今回からヘッダをなくす
        - ヘッダにあったホームへのリンクや検索バーは、Navigationに置く

# 自分のコンポーネント開発方針

- AppContainerコンポーネントを作成する
    - スロットとして、NavigationとBodyがある

# 次にやること

- ページレイアウトのコンポーネント開発方針を決める

最近の投稿