# 背景

- このブログの管理画面で、投稿を更新したときに「更新しました」などのポップアップを出していた
- 実装当時はTurbo下でjsを使う方法がよく分かっておらず、CSSのアニメーションだけで表示/非表示させていた
- Turbo下でjsを書きたいときはStimulusを使えば良いと分かったのと、dialog要素を使ってみたかったので、ポップアップを置き換えることにした

# 目的

- ユーザーが自分のタイミングで消せて、一定時間たつと非表示になるポップアップの実装

# 変更前のコード

- `animate-slide-in-bottom` のアニメーションだけで、ポップアップをスライドインさせたり、visibilityをhiddenにしていた。

```
<% if notice %>
  <div class="absolute animate-slide-in-bottom">
    <div role="alert" class="alert alert-success">
      <span class="material-symbols-outlined">
        info
      </span>
      <span><%= notice %></span>
    </div>
  </div>
<% end %>

```

# 変更後のコード

## View

- はじめから開いた状態のdialog要素を置いて、StimulusのFlashControllerを接続した
- [methodがdialogであるformを設置して、jsなしでdialogを閉じられるようにした](https://developer.mozilla.org/ja/docs/Web/HTML/Element/dialog#html_%E3%81%AE%E3%81%BF%E3%81%AE%E3%83%80%E3%82%A4%E3%82%A2%E3%83%AD%E3%82%B0)
- `animate-slide-in-bottom` のアニメーションは要素をスライドインさせるだけにした

```
<% if notice %>
  <dialog class="bg-transparent animate-slide-in-bottom" open data-controller="flash">
    <div role="alert" class="w-64 max-w-full alert alert-success">
      <span class="material-symbols-outlined">
        info
      </span>
      <span><%= notice %></span>
      <form method="dialog">
        <button class="btn btn-xs">OK</button>
      </form>
    </div>
  </dialog>
<% end %>

```

## StimulusのController

- 10秒たったらdialogをcloseするようにした

```
import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
  connect() {
    setTimeout(() => {
      this.element.close()
    }, 10000);
  }
}

```

diglog要素+Stimulusで作るポップアップ

https://biomejs.dev/guides/getting-started/

[wip]biome所感

* [Button](https://mui.com/material-ui/react-button/)のデフォルトがテキストで意外

[wip]Material UI所感

- Notionをタスク管理ツールとして使うことにおいて、一番微妙な点だと思う
- リレーションという考えに慣れている人はなんとなくで「最初のリンクされたページ」を作れるだろうけど、どう考えても直感的な操作ではない
    - 2021年ぐらいは、Notion側も結構UIをころころ変えていた気がする
    - 一般的なタスク管理ツールであれば「このイシューに紐付くタスクを登録する」ということが自然にできるUIになっていると思う

Notionのリレーションで「最初のリンクされたページ」を作りにくいことが解決できてない

# 基本方針

- Notionのデータベースを利用する
- データベース内のページでは、「何をできるようにするのか」など、目的を管理する
- データベース内のページの中でタスク管理する

# データベースのプロパティ

|プロパティ名|内容|
| --- | --- |
| タイトル | 目的を書く<br>例）○○できるようにする |
| ステータス | 基本的には、一般的な3ステータス（未着手、進行中、完了）を使う |
| 進捗日時 | 日報作成を自動化するために必要 |
| 進捗ボタン | 押すと、ステータスを進行中にする＆進捗日時を現在にする |
| 完了ボタン | 押すと、ステータスを完了にする＆進捗日時を現在にする |
| 締め切り | 一般的なもの |

# タスク登録の流れ

- データベースのページ内に、チェックボックスを使ってタスクを登録する
    - データベースのページでタスク管理をするよりも、下記のメリットがあると考えている
        - タスクの前後関係の管理が簡単
        - タスク粒度が柔軟

# タスク実施の流れ

- 進捗ボタンを押す
    - ステータスが進行中になる
    - 進捗日時が現在になる
- 登録したタスクを行い、チェックをつける
- すべてにチェックがついたら、完了ボタンを押す
    - ステータスが完了になる
    - 進捗日時が現在になる

# タスク振り返り

- 「進捗日時が今日のもの」でフィルタしたViewを作っておき、それを確認
    - これがそのまま日報になる
    - まわりに伝えるためというより、見積もり通りに1日を過ごせたかなど、セルフチェック的な役割

Notionを使ったタスク管理の現状

# 非同期コラボレーションの方法に気をつける理由

- フルタイム稼働ではない人と働くのが当たり前になってきた
    - 現在は自分もフルタイム稼働ではない
- フルタイム稼働ではない人との会話はタイムラグがあり、やり取りの回数が増えると1回の会話にとんでもなく時間がかかるので、なるべく1ラリーで終わるようにしたい

# 気をつけていること

## 回答方法を明確にする

- 回答主が回答方法を気にしなくてよくする
- 例えば実装した画面を見てほしいとき、「気になるところがあれば教えてください」と依頼するよりは「気になるところがあればこの表を埋めてください（画面名、想定していた挙動、実際の挙動の見出しのついたスプレッドシートを渡す）」などにする
    - 「書いてください」よりは「埋めてください」にする

## 論点を分かりやすくする

- 複数論点を効率的に議論できるようにする
- 例えば同じ投稿で複数の論点について相談したいとき、①②③など番号付きの箇条書きにする
- 例えば長文を添削してほしいとき、Slackにそのまま長文を貼らず、GoogleドキュメントやGoogleスライドなど、「特定の文章やページにコメントできるツール」を利用する

非同期コラボレーションで気を付けていること

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

記事一覧