【第4回】2024年03月31日

[kagomen]

目次

例）

• [トピック: これは例です]
  • 下記のスレッド内にて決定→：[Aにする]
• [トピック: これは例です]
  • [B]に関して、再度MTGで共有・確認する！

---

• トピック: Tailwind CSSのサイズの使用についての確認
  • 基本余白は、16の倍数でいく！
  • [px]は使わない方向にするので、後にリファクタする！
  • 現在のサイトにある[Step]は、コンポーネント切って、ループする！
• トピック: CONTRIBUTING.mdに追記したい内容について
  • 新しく決まったことがあればWikiに書き加えていく
  • バージョンリリースなど大きな区切りで、WikiからCONTRIBUTING.mdに転記すべきものがあるかを確認->転記する
• トピック: developブランチについて
  • 一旦、今まで通りmain + 作業用ブランチの方式で！
• トピック: バージョン2のデザイン担当について
  • 簡易的なデザインカンプをみんなで作って持ち寄り、みんなの案をもとに1人がデザインをまとめ、デザインカンプを完成させる
• トピック: デザインはスマホ版から考えるべきか？PC版から考えるべきか？
  • 下記のスレッド内にて決定→：デザインは先に用意する！実装自体はスマホから組んでいく！
• MTGの議題は事前にDiscussionsで意見を出し合いたい #145
  • 採用
  • 事前にMTGで話したいことはDiscussionsに投稿、意見を出し合う
  • MTGで話したいトピックを目次に追加、結論はトピック追加した人がまとめる
  • 決定したことはさらっと確認、必要なものは話して詰めていく

---

次の1週間でやること

今後の大まかな流れは下記：

• バージョン１リリースまで：
  • ドッグフーディングしてみる
  • ドッグフーディングにて、見つかった修正箇所などをリストアップする（discussionの専用スレ → issue化）
  • 上記の修正＋スクショの追加
  • バージョンのタグと、リリースノートを作る！
• バージョン1.0.n：リファクタリングなどの修正で、バージョン２の開発はまだ行わない
• バージョン２の仕様決め：
  1. コンセプト決め：リポジトリのコンセプトやストーリー性、Contributors.jsonに入力してもらうデータを決める
  2. デザインコンペ：それを元に、個別ページ、トップの表示（カード？）などのデザインをみんなでそれぞれ作ってみる
  3. デザインカンプ用意：それぞれのデザインの良いところを取ったり混ぜたりして、1人がベースを整えてまとめる
  4. バージョン２の実装！

その他：

• issuesは、以前の優先度の高いタスクのまとめが、ピン留めしてある方式の方がやりやすいかも？なので、戻してみてもいいかも！

---

以下フォーマット（トピックを追加したら、上記の目次にも追加してください！）

## トピック: タイトル
- 概要

## 結論: 一言でまとめる
- 結論

## 関連 Issues、Discussions

[kagomen]

トピック: Tailwind CSSのサイズの使用についての確認

• 通常のCSSだと8の倍数（細かく調整したい場合は4の倍数）を基準にpxを指定していくが、Tailwindを用いた場合はどうするのか？を確認したい
  • 個人的には、既にTailwind側がそのような数値になるよう調整してくれているので、好きな数値を使っていいと思っていた！
  • また、大きな数値はm-64などとするより[--px]の方がわかりやすいと思っているが、そのあたりの認識のすり合わせもしたい！

結論: 一言でまとめる

• 基本余白は、16の倍数でいく！
• [px]は使わない方向で！
  • なので、リファクタする！
• 現在のサイトにある[Step]は、コンポーネント切って、ループする！

関連 Issues、Discussions

#131
#131 (comment)

[kazzyfrog]

個人的には、[--px]は使わないほうがいいかも、と思ってます！
あえてtailwindの制限（柔軟にpxを指定できない）に従う方が、tailwindのメリットを享受できるのかな、と思っています！

めっちゃ暇な時にこの記事読んで見てもいいかもです！
長いですが、少しtailwindに詳しくなれます！

上記の記事からの引用

いつぞやのバージョンアップで、w-[57px]のように、[ ]構文を用いることで制限に縛られない自由な値を使える機能が追加されました。これは明らかに大きな抜け穴であり、これまで説明してきたTailwindの意義に真っ向から反しています。筆者もこれを知ったとき、Tailwindがどのような方向性を目指しているのかよく分からなくなりました。
Tailwindをデザインシステムのために使っている限り、この機能は明らかに濫用すべきではありません。TypeScriptで言うところのanyやasに相当するものです。

[kazzyfrog]

それと、個人的には、tailwindの思想というか、ベストプラクティスにならって、
細かくコンポーネントを分割する方向で、UIを整理していけたらいいなって思ってます！
（これは個人の好みが強いです）

例えば、<Container>コンポーネント（セクションの余白などを統一する用）を作成し、サイトのセクションをラップすることで、全部の余白など統一できます！
こちらのリポジトリの実装を引用すると、以下のようなイメージ！
Container コンポーネント：

const Container = (props) => {
  return (
    <div
      className={`container p-8 mx-auto xl:px-0 ${
        props.className ? props.className : ""
      }`}>
      {props.children}
    </div>
  );
}

export default Container;

Container コンポーネントでラップして作成するコンポーネントの例：

const Cta = () => {
  return (
    <Container>
      <div className="flex flex-wrap items-center justify-between w-full max-w-4xl gap-5 mx-auto text-white bg-indigo-600 px-7 py-7 lg:px-12 lg:py-12 lg:flex-nowrap rounded-xl">
        <div className="flex-grow text-center lg:text-left">
          <h2 className="text-2xl font-medium lg:text-3xl">
            Ready to try-out this template?
          </h2>
          <p className="mt-2 font-medium text-white text-opacity-90 lg:text-xl">
            Don&apos;t let your visitors see a poor landing.
          </p>
        </div>
        <div className="flex-shrink-0 w-full text-center lg:w-auto">
          <a
            href="https://github.com/web3templates"
            target="_blank"
            rel="noopener"
            className="inline-block py-3 mx-auto text-lg font-medium text-center text-indigo-600 bg-white rounded-md px-7 lg:px-10 lg:py-5 ">
            Download for Free
          </a>
        </div>
      </div>
    </Container>
  );
}

export default Cta;

[kazzyfrog]

同様に、H2やH3などは、<Heading>コンポーネントを作れば、
どこからでも呼び出せて、上下の余白なども１箇所で管理できます！

こちらのリポジトリより引用

type Props = {
  children: React.ReactNode;
  as?: 'h1' | 'h2' | 'h3' | 'h4' | 'h5' | 'h6';
};

const Heading = ({ children, as = 'h1' }: Props) => {
  switch (as) {
    case 'h1':
      return <h1 className='text-4xl font-bold mb-8 text-slate-700 font-cal'>{children}</h1>;
    case 'h2':
      return <h2 className='text-3xl font-bold mb-4 text-slate-600 font-cal'>{children}</h2>;
    case 'h3':
      return <h3 className='text-2xl font-bold mb-4 text-slate-600 font-cal'>{children}</h3>;
    case 'h4':
      return <h4 className='text-xl font-bold mb-4 text-slate-600 font-cal'>{children}</h4>;
    case 'h5':
      return <h5 className='text-lg font-bold mb-4 text-slate-600 font-cal'>{children}</h5>;
    case 'h6':
      return <h6 className='text-base font-bold mb-4 text-slate-600 font-cal'>{children}</h6>;
  }
};

export default Heading;

こういうコンポーネントの分割で、細かく管理するのもいいかもです！
クラス長くなっても、コンポーネント内のコード量自体が減れば、そこまで見づらくならないかも？と少し思ってます！🙌

[kagomen]

こちら https://blog.uhy.ooo/entry/2022-10-01/tailwind/ 読んでみました。とても興味深かったです！ありがとうございます🙏✨
読んでて思ったのが、フレームワークって思想なんだなーってことでした。
自分の中では最初にデザインという目的があって、それを実現する手段としてCSSが存在する、という認識があり、Tailwindもそれと同じように考えていたのですが、ちょっと違うのですね。
Tailwindはプロジェクト（プログラミングのしやすさともちょっと違う）を第一の目的にしていて、デザインはその次なんだなと感じました。それがユーティリティファーストということなのかな、と思ったりもしました。（憶測ですが💧）

[kazzyfrog]

ReactとTailwindと、デザイン？の勉強にもなるので、色々コンポーネントの分割とか、CSS変数使ったりとか、
模索しながら、しっくりくる構成を見つけてもいいかもですね！👍

[kagomen]

トピック: CONTRIBUTING.mdに追記したい内容について

• CONTRIBUTING.mdに、プルリク承認の方法も記載したい

  • 記載する場合、行程を再度確認したい
  • 以前のMTGでSquashするときにタイトルをどうするか、などを聞いた気がするのですが、忘れてしまったため、文章として残しておきたい・・・

• 同時に、バージョン1で区切りがついた段階で、【メンテナー必読: 共有事項】バージョン1リリースまでにすること #52 で集まったコーディング規則などもCONTRIBUTING.mdに転記する

結論:

• 新しく決まったことがあればWikiに書き加えていく
• バージョンリリースなど大きな区切りで、必要があればCONTRIBUTING.mdに転記する

関連 Issues、Discussions

[kazzyfrog]

事例②：雑コミットが複数なら、Squash Merge

#89 で、READMEを作成しました！
これは、コミットを７つ積んでます。
しかし、タスクが複数でもないし、適切に区切って、記録を残したいわけでもないです。。
セーブ的にコミット打って、共有するためにコミットして、PRを出して、フィードバックを元に再度修正のコミット積んで、、、
って感じでした！

この場合は、mainに複数の雑コミット含めるべきでないので、Squash MergeでOKだと思ってます！
（もしくはリベースして、2とか3とか、必要な分だけに厳選してもOK）

[pss-aileen]

• 閲覧：Wikiに、現時点で決まっている規約が書いてあるので、ここを見ればOK！
• 提案：おそらく、discussionやPRでのやり取り内で、相談・提案して、こういうふうにしていこう！というのが決まる！
• 決まったらWikiに書き加える！

取り急ぎですが、こちらで良いと思います！

[kagomen]

細かい事例の説明、ありがとうございます🙏✨

• タスクが1つの場合:
  • コミットが1つの場合: Merge
  • コミットが複数の場合: Squash
• タスクが複数の場合: Merge

理由: タスク単位でコミットメッセージを統一したいから

ってことで合ってますでしょうか？
ちなみにタイトルの変更にMergeとSquashで差があるのはなぜなんでしょうか……🌀

[kazzyfrog]

ってことで合ってますでしょうか？

その認識であっていると思います！
イシューの粒度も、細かく分割して、
基本1タスク+ 分ける方が、かえってややこしくなるような関連する細かいこと
とかにすると、簡潔になりそうですね！

タイトルの変更にMergeとSquashで差があるのはなぜなんでしょうか……🌀

コミットの履歴を見てみると、
Squashの場合は、mainにそのままコミットを追加しているように見えます！
Merge pull requestの場合は、作業したコミットの追加に加えて、mainにマージしました！というコミット（マージコミット）も作成されます！

まとめ：

• Squashの場合は、まとめたコミットを、メッセージを編集してmainに追加する
• Merge pull requestの場合は、作業用ブランチでのコミットがそのまま反映され、Merge pull requestのメッセージは、マージしました！ということを表しているだけなので、デフォルトのままでOK！

[kagomen]

Merge pull requestのメッセージは、マージしました！ということを表しているだけ

なるほどです！理解しました！
ありがとうございます🙏✨

[kagomen]

トピック: developブランチについて

バージョン１の実装終了後、バージョン２の実装はmainブランチの他にdevelopブランチを作成する必要がある（はず？）
その場合のブランチの切り方について

結論: 一言でまとめる

• 一旦、今まで通りで！

関連 Issues、Discussions

[kazzyfrog]

これは、どちらでも大丈夫だと思います！

1. mainブランチと、作業用ブランチで今まで通り進めるパターンか、
2. mainブランチ（バージョン１リリース）と、developブランチ（バージョン２の開発）と、作業用ブランチで進めるパターン

１の場合は、今まで通りです！マージされたらすぐにサイトに反映されます！
２の場合は、developを今までのmainブランチのように扱い、作業用ブランチを切っていく！
そして、バージョン２のリリースのタイミングで、まとめてmainにマージする。
なので、サイトに反映されるのは遅くなります！

[kazzyfrog]

といいつつ、機能自体はそんなに多くないので、
話にあった通り、以下のような感じで良さそうですね：

• まずは、「バージョン1.0.n」で、リファクタリングなどの修正で、バージョン２の開発はまだ行わないので、今まで通りmainと作業用ブランチ
• そして、バージョン２の実装に関しては、developブランチを使って、バージョン２のリリースのタイミングで、まとめてmainにマージする！

もしくは、今まで通り、ずっとmainと作業用でもいいかもです！
UIとか早く確認できるので！自分はどっちでも！！👍

一応、バージョン２のタイミングで、今回と同じように、
どこかで区切っても、「バージョン２」のタグをつけることはできます！

[pss-aileen]

• ドックフーディングのドキュメント周りの修正までで1.0.0
• その他内部的なもの、細かいところは1.0.nでリファクタリング
• ↑をしながら、バージョン2の仕様を考えつつ...
• developにて、バージョン2の開発、バージョン2リリースでmainにマージ、かどうかは今から考える必要あり
• 参考
  • バージョンにあれこれ考えを巡らせてみる #ポエム - Qiita
  • 非エンジニアも知っておきたいソフトウェアのバージョン表記の書き方を解説 | ワードプレステーマTCD

[kagomen]

ローンチするのがバージョン２なので、バージョン１〜バージョン２は今まで通りの実装方法で問題はないかと思うのですが、もしバージョン３があるのだとしたらdevelopブランチを作ることになると思います
その予行練習としてバージョン１〜２でもdevelopブランチを用いた開発を体験しておきたいかも？とは思いました！
が、いつもながら、どちらでも大丈夫です！

[kagomen]

トピック: バージョン2のデザイン担当について

みなさんお時間があれば、デザインに興味ある人全員でデザインカンプ作る、というのはどうでしょう？👀という提案です。
これは個人的な話ですが、Figmaを使えるようになりたいです。
個人開発のときにやろうと思っても、結局ノートに雑に書くとかで終わってしまうので、強制力が欲しいです……。
そこで、三人寄れば文殊の知恵！みなさんが良ければ持ち寄ったデザインの中で良いとこどりをするのはどうでしょうか。
微妙ですかね……❓ご意見をうかがいたいです！

結論: 一言でまとめる

• 簡易的なデザインカンプをみんなで作って持ち寄る
• みんなの案をもとに1人がデザインをまとめ、デザインカンプを完成させる

関連 Issues、Discussions

[pss-aileen]

案出しは必ずしも口頭？でなくても良いと思います。（案出しがはっきり何をどうするかにもよるかと思いますが...！）
デザインであればなおさら作った方が良いかな...と思います。

完成系でなくていいのでワイヤーフレーム的なものでもいいし
図形とテキストを配置するだけでもいいし、
そういって目に見えるものとして作成して
それを事前に共有して、そこからMTGでつめていったりする方向が良い気がします。

確かにデザインを作るのはある程度時間を必要とするので大変かと思いますが...MTGで相談ですね...！

[kagomen]

完成系でなくていいのでワイヤーフレーム的なものでもいいし
図形とテキストを配置するだけでもいいし

たしかに！これなら気軽に図面でアイデア出しできそうです！
ありがとうございます！ぜひ、そうしたいです🙏✨

[kazzyfrog]

良いですね！ 🎨

であれば、ざっくり以下のような流れになりますかね？

1. コンセプト決め：リポジトリのコンセプトやストーリー性、Contributors.jsonに入力してもらうデータを決める
2. デザインコンペ：それを元に、個別ページ、トップの表示（カード？）などのデザインをみんなでそれぞれ作ってみる
3. デザインカンプ用意：それぞれのデザインの良いところを取ったり混ぜたりして、1人がベースを整えてまとめる
4. 実装！

[pss-aileen]

↑そのような感じを考えています！

[kazzyfrog]

Discordの、今後の流れも、上記を組み合わせて置いておきます！

• バージョン１リリースまで：
  • ドッグフーディングしてみる
  • ドッグフーディングにて、見つかった修正箇所などをリストアップする（discussionの専用スレ → issue化）
  • 上記の修正＋スクショの追加
• バージョン1.0.n：リファクタリングなどの修正で、バージョン２の開発はまだ行わない
• バージョン２の仕様決め：
  1. コンセプト決め：リポジトリのコンセプトやストーリー性、Contributors.jsonに入力してもらうデータを決める
  2. デザインコンペ：それを元に、個別ページ、トップの表示（カード？）などのデザインをみんなでそれぞれ作ってみる
  3. デザインカンプ用意：それぞれのデザインの良いところを取ったり混ぜたりして、1人がベースを整えてまとめる
  4. バージョン２の実装！

[kagomen]

トピック: デザインはスマホ版から考えるべきか？PC版から考えるべきか？

• バージョン1ではPC版から実装したが、Tailwindを使うならスマホ版から実装した方が良いのでは？と感じた

結論: 一言でまとめる

• デザインは先に用意する！
• 実装自体はスマホから組んでいく！

関連 Issues、Discussions

[pss-aileen]

同じくです！
メディアクエリーが、min-width: 768px、min-width: 1024px のように、
768pxより大きい場合、1024pxより大きい場合といった書き方なので
スマホから実装して、md:、lg: でCSSを上書きする感じが適切だと思いまいた！

[kazzyfrog]

実装、確かにそれで良いと思います！

自分はいつもは、PCとレスポンシブ同時に実装してしまうことが多いので、
バージョン２では、細かくコンポーネントを切って同時にやってもいいかもです！

デザインはスマホ版から考えるべきか？PC版から考えるべきか？

デザインに関しては、バージョン２では、実装前にPC・スマホなどのデザインカンプを先に用意しておきたいですね！
なので、実装しながら考えることは減らせそう？です！

[pss-aileen]

デザインに関しては、バージョン２では、実装前にPC・スマホなどのデザインカンプを先に用意しておきたいですね！
なので、実装しながら考えることは減らせそう？です！

ですね、実装とデザインが頭でごちゃっとしてしまっていましたが

デザインは先に用意するので、その部分での迷いは少ないはず！
実装自体はスマホから組んでいく方が効率的！といったかんじですね！

[kagomen]

デザインは先に用意
実装自体はスマホから組んでいく

ですね！！
これで良いと思います！👀✨

[kazzyfrog]

次の1週間でやること

[kazzyfrog]

Discordの、今後の流れも、上記を組み合わせて置いておきます！

• バージョン１リリースまで：
  • ドッグフーディングしてみる
  • ドッグフーディングにて、見つかった修正箇所などをリストアップする（discussionの専用スレ → issue化）
  • 上記の修正＋スクショの追加
• バージョン1.0.n：リファクタリングなどの修正で、バージョン２の開発はまだ行わない
• バージョン２の仕様決め：
  1. コンセプト決め：リポジトリのコンセプトやストーリー性、Contributors.jsonに入力してもらうデータを決める
  2. デザインコンペ：それを元に、個別ページ、トップの表示（カード？）などのデザインをみんなでそれぞれ作ってみる
  3. デザインカンプ用意：それぞれのデザインの良いところを取ったり混ぜたりして、1人がベースを整えてまとめる
  4. バージョン２の実装！

[kazzyfrog]

まず、ドッグフーディングの修正！

ディスカッションで話して、
イシュー化して、
着手！

[kazzyfrog]

バージョンのタグと、リリースノートを作る！

[kazzyfrog]

イシューは、ピン留め方式に戻す！

[pss-aileen]

@kazzyfrog @kagomen
ちなみにリリースノートってどの媒体で出すか等決まってますか？
これから確定させていく流れでしょうか？

[kagomen]

GitHubにリリースノートを自動生成してくれる機能があるので、ひとまずこちらを使おうという方針になりました。
mdファイルなどが生成されるわけではなく、リポジトリトップページのサイドメニューにあるReleases欄が使えるようになる感じっぽいです。！
参考：
https://docs.github.com/ja/repositories/releasing-projects-on-github/automatically-generated-release-notes

[kazzyfrog]

このリポジトリのこのページに、
バージョンタグの区切りごとに、変更内容のノートが、溜まっていく感じです！

同じように、リリースノートをGithubに載せているリポジトリの例：
https://github.com/vercel/swr/releases

[pss-aileen]

なるほど、承知しました！