# ビジネスサイドとのコラボレーションを重要視する理由

- 過去に、バグが起こりやすかったり、追加機能開発が難しいプロダクトの開発をしていたことがあった
    - 当時は自分もジュニアで、やりづらさを感じながらも解決できないままずるずると開発していた
- その後新しい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がある

# 次にやること

- ページレイアウトのコンポーネント開発方針を決める

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

# 背景

- アプリを開発するときに、コンポーネントの作成に迷うことがある
    - 例えば、アプリ自体にメニューがあり、ページの中にもメニュー的要素があるとき、どう命名するか迷う

# 目的

- 0からのアプリ開発で、コンポーネントの作成をスピーディに行う

# やり方

- 有名なデザインシステムやUIライブラリを比較し、共通要素を抜き出す
    - 比較は、HTML要素の外側（body要素）から内側に進める
    - GithubのPrimerは要素が多いことを前提にしているので、特にこれを参考にする
- 自分なりにコンポーネント開発の方針を決める
    - 色や余白などは決めず、ワイヤフレームレベルで作る

# 次やること

- アプリレイアウトの比較

# 参考

[グッドパッチエンジニアが選ぶ、推しデザインシステム10選](https://goodpatch.com/blog/i-love-design-systems)

コンポーネント開発方針決め-はじめに

なるべくChakra UIの標準のパーツを使うようにして実装することで、ダークモード対応した。独自に色を設定しなければいけないときは[useColorModeValue](https://v2.chakra-ui.com/docs/styled-system/color-mode#usecolormodevalue)を使った。

ダークモード対応

# js / フロント
- [仕組みと嬉しさから理解するeslint FlatConfig対応](https://zenn.dev/cybozu_frontend/articles/about-eslint-flat-config)
  - 今でも旧設定のほうで説明している記事が多くヒットするので、なかなか移行は進んでなさそう。
- [実例で学ぶFlexboxとCSS Gridの使い分け](https://www.tak-dcxi.com/article/learning-by-example-flex-vs-grid-usage/)
	- floatを使うことほとんどないな
- [Storybookを導入する際にやるべきこと3選](https://zenn.dev/sum0/articles/9463d16d9d40e2)
	- この記事を参考にStorybookを導入していて、plopでコード生成もしている
- [自然に見える画像の枠線を求めて](https://qiita.com/xrxoxcxox/items/073d30615a1d73c089fc)

# Ruby / Rails
- [Add Brakeman by default to new apps](https://github.com/rails/rails/issues/50501)
	- 7.2.0からbrakemanがデフォルトで入る
- [マイグレーション生成オプションにnot-nullを生成する!演算子が追加](https://techracho.bpsinc.jp/hachi8833/2024_08_08/143917#1-10)
- [Kaigi on Rails 2022 - 既存Railsアプリ攻略法 CTOが見ること・やること・考えること](https://speakerdeck.com/fujimura/kaigi-on-rails-2022-ji-cun-railsapurigong-lue-fa-ctogajian-rukotoyarukotokao-erukoto)

# Docker
- [DockerfileのENV](https://docs.docker.com/reference/dockerfile/#env)
	- たしかBunを入れてPATHを通そうとしたときに使った気がする
- [ENTRYPOINTは「必ず実行」、CMDは「（デフォルトの）引数」](https://pocketstudio.net/2020/01/31/cmd-and-entrypoint/)
	- よく忘れるのでメモ

# その他
- [ネタ](https://x.com/justansub/status/1819618712280010806)
- [最低限押さえておきたいPostgreSQL(基本的な操作、文字セット、ロケール)](https://maasaablog.com/blog/2tqyr_-hy2g/)
	- `postgresでは、utf8mb4という文字セットはなくutf-8が相当しpostgresのutf-8は4バイト文字も対応している`
	- 久々にPostgresを使ったときに絵文字対応どうするか迷ったのでメモ。
- [登壇中にうっかり見せちゃいけないもの見せないようにするための技術](https://zenn.dev/tenntenn/scraps/4b011b9e14dbf0)

2024年8月のブックマーク

# Rails

- [bin/rails notesの結果をブラウザでも表示可能になった](https://techracho.bpsinc.jp/hachi8833/2024_06_25/142649#1-10)
  - `rails/info/notes`でTODOなどを一覧できる

# フロント

- [ravixUI がアクセシビリティ対応の参考になりそう](https://zenn.dev/chot/articles/4a96fdbaf0f9b4)
	- Testing Libraryみたいに、実装してる中で自然と勉強になるライブラリはありがたい

2024年7月のブックマーク

「テストツールにこういう機能があれば良いのに」と考えた時、最終的に「アプリケーションコードの設計を見直したほうが良い」という結論に至ることが多い。

しかしすでに動いているコードに対してテストコードを追加しようとした場合、設計の見直しの必要性に気づいても修正が大変なので、やはり最初からテストコードをちゃんと書くべき…。

テストコードは本当に最初からちゃんと書いたほうが良い

# フロント

- [Web制作者はダウンロードしておきたい！ CSS関連の最新版チートシートのまとめ](https://coliss.com/articles/build-websites/operation/css/css-cheatsheets-for-web-development.html)
- [Interactive story generation](https://storybook.js.org/blog/interactive-story-generation/?ref=storybookblog.ghost.io)
	- StorybookのstoryをGUIから作成、編集できる
	- storyのコード生成はplopで自動化しているので、この機能は使いどころが限定されそうだけど、面白そう
- [デジタル庁 ウェブアクセシビリティ導入ガイドブック](https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook/)
- [rgb()](https://developer.mozilla.org/ja/docs/Web/CSS/color_value/rgb)
	- `rgba(0, 0, 0, 1)`の記法が古いと見かけたので確認今は`rgb(0 0 0 / 1)`のような書き方だった。
	- Figmaの何かのプラグインだと古い記法で出てくるので、そういうものかと思っていた
- [2024年版最近の実装に合わせた、HTMLでWebページを実装するための必要最小限をまとめたテンプレート一式](https://coliss.com/articles/build-websites/operation/work/html5-boilerplate-professional-template.html)
	- 色々考慮されたHTMLスケルトンファイル
- [じゃあなんすか、Noto Sans JP使うんならボタンにアイコン入れるなって事すか｜chot Inc. デザイナーユニット](https://note.com/chot_designer/n/n85ef47a2ec69)
# Rails

- [ドキュメント: 「生成されるDockerfileはproduction用です」](https://techracho.bpsinc.jp/hachi8833/2024_05_29/142211#1-4)
	- `「自分もrails newで生成されるDockerfileを開発用に使っていいのかどうかが気になってたんですが、おかげでスッキリしました」「開発用のDockerコンテナは例のdevcontainer（ウォッチ20240228）でやっていく流れっぽいですね」`
	- `.devcontainer`下のDockerfile、compose.yaml、devcontainer.jsonが開発用っぽい
- [field_with_errorsによるレイアウト崩れを防ぐ #Ruby - Qiita](https://qiita.com/taaaoi/items/bb1ffab51aa9eb9d98fd)
	- `この事象の原因は、エラーが発生している時Railsが自動的にfield_with_errorsクラスを持つdivタグで、labelタグやinputタグを囲むことによって発生します。`

# 組織
- [1on1ミーティングガイド](https://guide.1on1guide.org/index.html)
	- ミーティングパターンによくある失敗があげられていて面白い

# その他
- [OpenSourceAlternative](https://www.opensourcealternative.to/)

記事一覧